I don't think this is possible.
JBoss uses a unified classloader. This classloader makes sure there is no classloader hierarchy, but one 'repository' in which all deployed classes are registered. The first class version which is registered by an app makes it to the repository, any subsequent attpempt of an app that tries to register the same class fails. Only when the first app to register undeploys the newer versions become available.
What you can do is register the same class under a different JNDI name, making it possible to deploy with one class with different options (CMP/database etc)
Any news on JBoss in Holland?
p.s. keywords are:
UCL(A?) unified classloader architecture
And this: two version of a class are two different classes, no ? 1=2, 2=1 ?? ;-)
Thanks for your reply. What I am trying to accomplish is to have a different environment for each developer.
We have an automated build which compiles and deploys the application each night. Now, I want developers to be able to run the build using their modified sources. When deploying I prefix all the JNDI names with the username. This works fine but the already deployed beans are not replaced with the new versions. So the changes have no effect unless I undeploy everything first.
What I found out so far is that I can use the <loader-repository> element to define a scope for the classloader per ear or ejb-jar. I have not yet fully tested it but sofar it does seem to do the trick!
So ... that's a yes.
I lookedaround and found this download:
Scott Stark of JBoss Group has made available a free excerpt from the (for pay) JBoss Development and Administration that goes into detail on what the issues are when setting up the Classloader architecture in the most recent JBoss versions.
This is a must read for all people that develop on JBoss and use frameworks that rely on a number of jar files from sub projects.
There you go!
The article clears things up for me! Thanks!
I think it is recommendable to use the java:comp/env namespace when looking up references from your beans when deploying the different ear's. This namespace allows for local component lookups.
Take a look at: