I like the class loading scheme for web modules. It loads web module specific jars first without worrying about already loaded jars and if not found then it will look to the parent. Makes perfect sense. Web module can choose to use already existing version or use a new updated one with no effect on other modules.
That's because the spec mandates that each web module has its own classloader.
If I put a different version of jar inside ejb module it will not be loaded by jboss.
Could you please explain as to what you mean by placing a jar "inside an ejb module"?
When you place a jar inside the lib folder of EAR, it becomes available to the entire application.
Are you sure that you want two different versions of a jar inside the same (EAR) application? I don't think what you are trying to do, would be possible.
Thanks for getting back to me on this issue.
I meant literally putting the jar file inside TestEJB.jar. The idea was that EJB container will load the jar inside TestEJB.jar before looking in lib folder inside EAR.
Trying to use two versions of same jar is exactly what I am trying to do. My EAR has lot of EJB modules some of which make use of earlier ( ancient) version of Castor which is in EAR/LIB folder. I am writing a new EJB that uses latter version of castor. I have written the code assuming later version of Castor. Now while testing I found out that earlier version of castor is stepping on my castor.jar which is inside my TestEJB.jar.
If I replace the castor.jar in EAR/lib folder my ejb will work but many others which are using old version are failing. My code does not work with old version of castor.
I was hoping to find some way of using two versions of jar in same EAR. I guess my only option is to rewrite my code using earlier version. I also thought of writing a custom classloader but am not sure if that will even work given that earlier version is already loaded by jboss.
Is there anything preventing you from packaging two EARs, one for each version of Castor you need to support?
I would not recommend ClassLoading hacks; this is a notion that you should be delegating out to the Container, and we're not exposing the internals to be altered.
That is a possibility. Only issue would be we already have 4 ears. If 4 is ok then 5 cannot be too bad. :-)
Any way. Thanks for the suggestions. I probably will go with either a new ear file or back porting my code to previous version of castor depending on how long it will take me to back port the code.