The 2.3 classloader has been turned off in RC2 to
avoid ClassCastExceptions when the ejb jar
is in WEB-INF/lib.
The reason for the UnifiedClassLoader is to have
truly local processing. The servlet and the ejb
share the same classes rather than marshalling objects
between the different classloaders.
You can turn the 2.3 classloader back on in
Set Java2ClassLoadingCompliance to false.
Thanks Adrian, I was wondering why the change in behavior for war files.
I still have a problem with my other deployed files however. In effect we have developed a handful of independent applications (deployed as ear files) communicating through JMS when required. Having developed these independently we would now like to have some more flexibility in how we deploy them. Due to our practice of using a static singleton class to load certain basic system data we run into problems due to the UnifiedClassLoader.
Is there any way of switching this class loading behavior off? If I understand your previous message it is used to reduce the need to serialize objects in inter jar communications. As we use JMS we will never have this situation so get no benefit from this so would like to turn it off.
It would be nice to know if this behavior can be configured or whether we will have to alter the way we load and access system information. If you have a sensible pattern for doing this I would appreciate it (one that does not involve JNDI or a database ideally!).
Thanks in advance
Forgive my moral tone but static singletons are kind of evil;-) Would you consider using an mbean instead? Then you can either include the config info directly in the mbean configuration, eliminating the properties file (what I would do) or have the location of the properties file as an mbean attribute, allowing it to load. The mbean approach has the added advantage of making the configuration editable at runtime (this may require more work to propagate change notifications to those that need them).
I do agree with you that what I am doing is not ideal.
However besides that the problem of a shared class loader does have other issues in my opinion. What happens when after running for some time I deploy a slightly different version of a class in a new jar file? I have some common code that goes into all my modules and this shouldn't really need to be kept in sink. But with the UnifiedClassLoader I will be forced to update everything.
What I really need to know is is there a way of defining, in the jboss configuration, that I don't want to use the UnifiedClassLoader and that a certain jar needs to be run independantly.
You have to use the UnifiedClassLoader, however the point behind it is that you can redeploy your classes and the new version will be used. This is exactly the problem it is designed to solve. (You do have to make sure there are no instances of the old classes hanging around, but if the instances are mbeans, this will be taken care of for you).
Thanks very much! That is the clarification I wanted and I will change my config code accordingly.
It does raise a few minor issues though due to our architecture with independent modules, they will all have to be updated at once which doesn't make them very independent!
Not a real problem though as modules on the same machine will tend to be related, modules deployed apart not so we should get the independence we require.
Minor hassle, great product!
Thanks for you help.