jBoss 3.x slower than jBoss 2.x?

[oravecz]

In jBoss 3.2, each deployment package (EAR, JAR, etc.) share a classloader, which prevents many of us from deploying our applications in the same manner as 2.4. We can mimic 2.4's classloading by adding a jboss-app.xml file to generate a separate classloader repository for each deployment unit, however that is not a complete solution.

In jBoss 3.2, when each deployment unit has its own classloader, JNDI lookups will fail by default. This occurs because the bean that binds its home interface into JNDI is doing so using classes in its own classloader. When another bean needs to access that bound home interface, it will need to cast it, but with the same class in a different classloader. This causes a ClassCastException.

Two solutions exist, and one of them is to repackage your beans all into a single deployment archive and eliminate any duplicate classes. For many of us this is not an option, since classes in deployment components _age_ at a different rate, and having to pick only one version of that class will rarely work.

The second solution seems to be to remove the JNDI in-VM optimizations. This means that all bean calls within the server will now execute using RMI semantics, significantly (so it has been reported) reducing performance. It seems that any performance improvements we hoped to gain by moving to the 3.x platform are negated by this compromise.

Are there any other solutions, or is this summary incorrect?

How did 2.4 provide each component with its own classloader, yet support in-VM optimizations?

[adrian.brock]

It didn't support in-VM optimizations in your example.
It did some extra work to spot the class cast and
reverted to RMI semantics.

Are you using PortableRemoteObject.narrow() for the remote
home? Are you using the ByValueInvoker?

Regards,
Adrian

[oravecz]

Yes, in 3.2 the only way to get my packaging to work is to use the ByValueInvoker. I use PRO in both examples.

It was also necessary to comment back in the localhost provider in jndi.properties.

It would be cool to include, or document all the steps necessary to create a new configuration called 'compatible'. In this configuration, users would be able to drop their 2.x deployments into.