On 2002.11.26 20:13:14 -0500 Scott M Stark wrote: > > ----- Original Message ----- > From: "David Jencks" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, November 26, 2002 12:50 PM > Subject: Re: [JBoss-dev] ClassLoader issue with protected access and > manifest refs > > > > Won't this eliminate the possiblity of redeploying a subpackage of say > an > > unpacked .ear deployment? In fact, I have been able to redeploy > subpackage > > of a packaged .ear using emacs ability to modify a .jar file's contents > and > > the main deployers ability to redeploy packages explicitly. > > > Not necessarily. I'm thinking that the shared class loader only handles > manifest > and sar library jars and is the parent class loader of the current > DeploymentInfo > UCLs. The problem redeployment of a nested component introduces in this > scheme is that you have to be able to update the parent component. I > don't see > this happening now in 3.2 or 3.0, is it being done in 4.0? I don't think so. I don't understand what you mean here. If I have an [expanded] .ear with
entities.jar sessions.jar webstuff.war I think I should be able to redeploy: webstuff.war or webstuff.war and sessions.jar or all three. In all cases, I don't see why the .ear should be "redeployed" (maybe there's something else in it that all of these depend on). Also, I don't see what will happen in your scheme if ejbsA.jar and ejbsB.jar both reference lib.jar in their manifest classpaths. Am I missing the point? I really don't see how to make this work without disabling the manifest classpath stuff, which as you point out, can't simply be ignored. thanks david jencks > > > I take it this behavior occurs even though the jar referenced on the > > manifest classpath has been loaded in its own ucl, so the only other > > approach would be to disable the manifest-classpath tracking behavior > of > > URLClassloader? > > > It occurs because the referenced jar is loaded by each referencing UCL. > This > is what causes the two classes in the same package name to not really be > the > same package. > > > I suppose one possiblity would be to rewrite the manifest to omit the > > classpath when we make the local copy. > > > This can't be done in general as the jar could be sealed and have > security > permissions that include the jar signer. > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Get the new Palm Tungsten T > handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ------------------------------------------------------- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
