I think we need something more global. What I am thinking of is a dynamic extension of the server lib directory. A deployment package identifies a jar as being an extension jar and it has a version. If a jar with the same version exists in the extension cache, the package jar is ignored, else it is added to the extension cache. A jar needs to be explicitly removed from the extension cache. Removal is not tied to the original deployment package. The class loader for the extension cache is the parent class loader of every deployment unit, and it in turns delegates to server class loader.
xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ----- Original Message ----- From: "David Jencks" <[EMAIL PROTECTED]> To: "Scott M Stark" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, April 28, 2002 7:54 PM Subject: Re: [JBoss-dev] CustomSocketsUnitTestCase muti-run failures > We might be able to finally find a use for the local directory feature marc > insisted I put in. Something copied into a local directory are just left > there forever, not undeployed. So perhaps an mbean could set up and add a > classloader for the jars in the local directory from the package. We'd > just need to make sure the classloader isn't removed when the package is > undeployed. > > david jencks > > > On 2002.04.28 20:58:55 -0400 Scott M Stark wrote: > > As it is packaged now, the > > org/jboss/test/jrmp/test/CustomSocketsUnitTestCase > > cannot be run more than once because it includes the custom RMI > > socket factories it uses in the deployment package. Because of how the > > RMI subsystem tracks socket factory uniqueness(it considers the factory > > class loader), this test will always fail on redeployment with an address > > in use bind error. > > > > We would need a class loader cache service into which the classes > > that need to be consistent across deployments are loaded in order > > to allow this test to run multiple times. That might be an interesting > > service and have other applications, but its not something I want to > > get into for the initial 3.0 release. > > > > xxxxxxxxxxxxxxxxxxxxxxxx > > Scott Stark > > Chief Technology Officer > > JBoss Group, LLC > > xxxxxxxxxxxxxxxxxxxxxxxx > > > > > > _______________________________________________ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
