Problems with passing Objects between Servlet and Jboss cont

[skarlson]

Hi,

I have a problem while trying to pass an object from the servlet container (Tomcat 3.2.3) to Jboss (2.4.4) container.

The object is a Jdom XML Object which is built in the servlet and the passed to the container to a stateless session bean. The bean in turn fills the Jdom object with all kinds of data.

When the method has been executed and changes have been made to the object and the Servlet continues to work with it. The Jdom object is still the same as when it was passed into the Statless Session Bean...

It almost seems to me as the object is cloned while
it is passed to the statless session bean?

Anyone got any clues whats going on?

Sten Karlson

[jimotte]

Just a shot in the dark- are you setting the JDom Object to the return value of the session Bean? Remember that when the bean is called over the network (not running in same VM(- then a copy of the Object is sent to the bean- the bean should return the copied object and you should reset the client object to the returned value (set it to modified copy) to see the changes.

eg
client:

JDOMObjectValue object=...;
Proxy proxy = new Proxy();
proxy.create();
object = proxy.beanDoSomething(object);

Bean:

public JDomObjectValue doSomething(JDomObjectValue object){
object.changeStuff()....;
return object;

}

make sure JDomObjectValue is Serializable! The object returned should be changed according to bean changes.

maybe this is it- because if no return object is generated only the copy is changed in the bean (unless you are in 1 VM- in which case the reference is passed not the copy- as optimization is performed by the container- and you should see changes in Object without setting it to return value)-

Hope this helps
Jim

[skarlson]

Thanks...

It's intresting because I run Jboss and tomcat in
the same VM. And since the setup has worked in previous
versions they must have turned off the container optimimzation for in VM calls for some reason in 2.4.4...

But obviously there is a design fault
in my code?

Sten Karlson

[skarlson]

Thanks...

It's intresting because I run Jboss and tomcat in
the same VM. And since the setup has worked in previous
versions they must have turned off the container optimimzation for in VM calls for some reason in 2.4.4...

But obviously there is a design fault
in my code?

Sten Karlson

[jimotte]

Your observation led me to download and try the new catalina version- and yes whereas before there was an optimization letting in same vm calls be like localInterfaces (ejb2.0)- It does not appear to be there with the catalina integration- I wonder is this configurable??- I sure hope there is a way of getting the optimization with catalina or I will be stuck with changing a lot of code in one of my older apps which relied on this local interface optimization...
Does anyone know if this is configurable??????????

[jimotte]

1 more point- it would be the same as in that "other" app server deployment descriptor:
<enable-call-by-reference>true</enable-call-by-reference>

for each bean- will JBoss also have such a configurable deployment descriptor??

[marc.fleury]

what is going on is that the tomcat class you are using and the jboss class on the other end are not seen as loaded from the same class loader then the jboss engine marshals everyone (as in java.rmi.MarshalledObject) and serializes/deserializes everyone. This is why you see the "clone" it is indeed a different object.

in 2.4 these problems are usually due to faulty packaging in your application, one of the classes being both in different packages. To be sure it works the simplest is to keep just one package with the objects you want to share. If you have many classes chances are it will silently fail.

in 3.0 we try to solve this class of problems by
1- integrating the deployers which results in shared class loaders across the stacks of JBoss (web/ejb) so that you really have the same class definition
2- removing the "silent fail" that enables you to work in 2.x series but masks a packaging problem.

marcf

[jimotte]

Thanks Marc- That explains most of the problem- that I am getting 1 class static variables from the .war file class and another from the ejb .jar class (bundled in as a dependency)loaded by different classloaders. It would really be nice to have them all from the same classloader to avoid these problems. It especially seems that JBoss2.4.4_Tomcat4.0.1 has this problem whereas JBoss2.4.4_Tomcat3.2.3 does not, strange- so in the interest of saving old code- I will stick with Tomcat 3.2.3 that allows the pass-by-reference and hope this is all unified in JBoss 3.0 (with integrated Tomcat)allowing pass-by-reference.

PS- what's up with the timestamp on the forum postings it is 9 1/2 hours behind EST - what weird timezone is that??

[jimotte]

sorry- the time appeared off on my computer- but is correct actually

[alindh]

I'm experiencing exactly the same problem with JBoss2.4.4_Tomcat3.2.3 (I'm not 100% sure it's the downloadable bundle, but anyway, with Tomcat 2.3.2). We haven't properly packaged our application, because it's so much easier during development to have all resources quickly modifiable (deploying beans, and on-the-run editing of JSPs).

The classloader stuff in 2.4.4 seems to have changed from 2.4.3 - What exactly has happened? Do I really need to create a proper ear package of my app, and can this be avoided somehow?

Thanks,

- Anders

[alindh]

Ok, I've done some testing after packaging my application properly to an ear file (it consists of 4 web apps, numerous beans and some utility classes). At the same time I migrated to the JBoss 2.4.4 - Tomcat 4.01 bundle (setting up cocoon and apache with this configuration was the biggest challenge..)

Anyway, things generally seem to work, but passing objects to and from the EJB container remains an issue. It's the same JDom object that isn't modified when returned by the container (updates are done inside the container, however).

I've tried various setups: Having jdom.jar in the system classpath, putting it in the WEB-INF/lib directory and including it in the Class-Path section in Manifest.mf (for ejbs). Nothing works though.

Tomcat 2.3.2 seemed much happier with having the application properly packaged, and the passing of object worked properly. I had to upgrade to Tomcat 4.01 for other reasons, and I'd like to know what causes this behaviour.

Thanks,

- Anders