JBoss 3.0 Classpath question

[alarik]

Hi all--

I have a couple of quick questions regarding class loading in JBoss 3.0:

(1) Is it possible to control the order in which archives are searched for a particular class. For example, specificying a directory using the ClassPathExtension feature of the JBoss 2.4.x branch, would cause the archives in the directory to be searched alphabetically, it seemed like.

(2) Is it possible to include a directory of un-archived class files as part of the classpath?

Thanks,

Alarik

[davidjencks]

I don't advise including more than one copy of a class in jboss 3 deployments.

You can control the order of deployment by listing the files explicitly in the deployment scanner mbean (end of jboss-service.xml in conf). However, due to the flat classloading model, I'm not at all sure this will result in a class being loaded from the first deployed archive that contains it.

In jboss 3 rc1 you should be able to include a directory inside the deploy directory with class files in it. It should be named something like myclasses.jar so the jar deployer will find it.

[craigday]

David.
Just wanted to ask you whether you believe that there should be isolation for the web applications and ears from the new flat classloader. It seems pretty fundamental to me that if a developer follows the packaging spec then the jars and classes in the appropriate places under WEB-INF are in fact the classes that get used, even if there are other web apps using similarly named classes. if the classes are not found then as a last resort the system should resort to using the UnifiedClassLoader? i dont think people are going to go for a system that doesnt isolate the behaviour and composition of the webapps deployed within it.

c

[davidjencks]

I'm sure I don't understnad all the issues here. I'm also curious about what you mean by a web application. My current thinking is that jboss servers are not all that large, so you should run each application on a separate jboss server. This definitely prevents conflicts between classes in different applications;-). Is there a situation where you need several wars with incompatible class versions running against the same set of ejbs in the same server?

Remember that the original motivation for the unified classloader was to be able to work with extremely large applications that are deployed as several ears, needing each other, and needing to be independently redeployable: furthermore all the ears need mutual class visibility.

At the moment, in order to get this to work reliably in our lifetimes, we have sacrificed the ability to have several versions of the same class loaded in mutually invisible classloaders. I really don't know enough about this to judge whether we should plan to support this in the future. If we do it will definitely take some thought about how best to do it.

[rblack]

I agree with craig on this one. EARs should be guaranteed that they will be using the classes they contain, not the classes from some other EAR that happen to have the same class name.

I've got a bunch of parallel webapps (ears) on the same server. One for each client. When I want to test a change to one of the classes, it's nice to be able to deploy it in only one EAR.

I understand from another posting that the UnifiedClassLoader is supposed to pick up the latest version of the class when it gets deployed. My own empirical testing shows that this is only the case when the new version of the class gets deployed to the same ear that the UnifiedClassLoader originally loaded it from, so when you have a bunch of ears with the same classes, it's anybody's guess which one the UnifiedClassLoader got its classes from.

Further, if you do get it right and deploy to the correct webapp, the other webapps will continue to hang on to the old version of the class. Yucky. So basically you have to deploy the new version of the class to ALL the webapps, and then restart jboss.

This makes me wonder if there's a better way...

Should I be putting my common classes in some common place, instead of in each of the ears? Then I can deploy the new classes to one spot and have them picked up by all the ears. Is there a way to do this?

Thanks,
Russell