HeirarchicalLoaderRepository is a traditional parent delegation model loader. Its usage only allows one to not pollute the shared class loading space with a deployments' classes. As David said you can achieve the desired affect by having both ears use a scoped loader repository. In general singletons in server envrionments are problematic as they depend entirely on the class loading architecture of the server and this is largely undefined by the specs.
I'll add a config flag that allows the HeirarchicalLoaderRepository to change the order of loading to be child first and then the parent ala the servlet 2.3 model. xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ----- Original Message ----- From: "Kristian K�hler" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, February 15, 2003 6:11 AM Subject: AW: [JBoss-user] Strange Classloading behaviour with singletons in JBoss 3.0.6 while using the loader-repository tag Hi David > I don't know the cause of the behavior you are seeing, but I would not > depend on it. I would give both .ears loader-repository tags. I think this behaviour arise from the fact that the org.jboss.mx.loading.HeirarchicalLoaderRepository3 asks his parent repository before looking if he could load the class by itself. I'm not sure if this behaviour is desirable, but wouldn't it be better if the HeirarchicalLoaderRepository3 should try to load the class be itself before delegate the call to his parent repository? (If no other application loaded the class before everything works fine but if an other application loaded the class the parent repository returns this class and the class shipped within the ear is never be used.) I think if someone uses the loader-repository tag he or she would expect (as we did) that all classes packaged within the .ear would be used rather than classes loaded by other applications? This could be a tricky problem in a bigger application environment i think. :-) Thanks in advance Kristian > On 2003.02.14 10:02 Kristian K�hler wrote: > > Hi all > > > > we've got a question regarding the class-loading behaviour in > > JBoss-3.0.6. > > > > The following simple scenario demonstrates our problem: > > > > We've got a util class with a static getInstance method (singleton). We > > are > > using this class in a regular application packaged as a EAR containing > > this > > class in a JAR. So far so good. As soon as we're deploying a second EAR > > containing the same class they start to interfere or more precisely > > calling > > getInstance() returns the same reference in both EARs. This behaviour is > > correct according to the JBoss classloading.pdf as far as we can tell. > > > > To suppress this behaviour (thereby separating the two EARs) we added a > > loader-repository tag to one of the jboss-app.xml files. Now comes the > > part > > that is puzzling for us, if we do so, the behaviour seems to depend on > > the > > order in which the EARs are deployed. If the EAR with the > > loader-repository > > tag is deployed first, the two references to the singleton object are > > different. If the EAR without the loader-repository tag is deployed > > first, > > the reference of the singleton object seems to be used in each > of the two > > EARs. > > > > Shouldn't it be the case that when a loader-repository tag is supplied > > the > > singleton class of the respective EAR should be used rather then using > > the > > one of an EAR which has been deployed before without such a tag? > > > > Thanks very much in advance > > > > Steffen & Kristian > > > > -- > > Orientation in Objects GmbH > > http://www.oio.de > > > > > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: FREE SSL Guide from Thawte > > are you planning your Web Server Security? Click here to get a FREE > > Thawte SSL guide and find the answers to all your SSL security issues. > > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > > _______________________________________________ > > JBoss-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: FREE SSL Guide from Thawte > are you planning your Web Server Security? Click here to get a FREE > Thawte SSL guide and find the answers to all your SSL security issues. > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
