> > -----Ursprüngliche Nachricht-----
> > Von: Scott M Stark [mailto:[EMAIL PROTECTED]
> > Gesendet: Donnerstag, 20. November 2003 15:34
> > An: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > Betreff: [JBoss-dev] Re: deployment classloader in
> > AbstractWebContainer
> >
> >
> > The deployment localCl is only for finding resources, not
> > classes. The classes class loader is created/assigned by the
> > MainDeployer after init as this may be the class loader from
> > an encompassing deployment (ear). Class loading should not be
> > occurring until create.
All right. I changed the ws4ee classloading to use the subdeployment ucl
(which is indeed
equal to the parent [EJB,WAR] ucl, see DeploymentInfo(parent,...)).
Thanks to your hint, the observed inconsistencies in the EJB case thus went
away.
However, we still have the problem that bytecode from WEB-INF/classes and
WEB-INF/lib (which is referenced in the
webservice.xml, e.g., by defining a service endpoint interface, and needs to
be loaded by JSR109Service.start(...))
- either will never find its way into the war-ucl (tomcats
useJbossClassloader=no option)
- or wont be inserted until
AbstractWebContainer.start(...)->performDeploy(...) is executed
(which comes AFTER JSR109Service.start(...) due to ws4ee being a
subdeployment to the war).
The current workaround in JSR109Service.start(...) (which I know is
certainly conflicting with the idea of allowing "scoped" war classloading in
general) is to simply inject these urls into the war-ucl before trying to
load bytecode:
//TODO CGJ: we need to share classes between a war and its
//webservice-subdeployment. We do that, similar to the EJB case,
//by the dis sharing the ucl. However, we need to hence extend
the
//ucl with web-inf/classes and lib at this point.
//This somehow conflicts with the notion of jboss-decoupled
//classloading for which I would propose to add another
//slot into DeploymentInfo that carries the
//final "Classloader applicationClassLoader" as used by the
//individual containers and that should be constructed at
//initialisation time (or is equivalent to ucl per default).
URL warURL = sdi.parent.localUrl != null ? sdi.parent.localUrl :
sdi.parent.url;
String warPath=warURL.getFile();
try{
File classesDir = new File(warPath, "WEB-INF/classes");
if (classesDir.exists())
sdi.parent.ucl.addURL(classesDir.toURL());
File libDir = new File(warPath, "WEB-INF/lib");
if (libDir.exists())
{
File[] jars = libDir.listFiles();
int length = jars != null ? jars.length : 0;
for (int j = 0; j < length; j++)
sdi.parent.ucl.addURL(jars[j].toURL());
}
} catch(MalformedURLException e) {
throw new DeploymentException("Could not extend ws4ee
deployment ucl.",e);
}
As a better solution which bundles the knowledge about war structure in a
central place and which is consistent with the existing classloading
options, I would propose to extend DeploymentInfo with another "ClassLoader
applicationLoader;" which could be equal to ucl per default, but which would
be set to the actual WebCtxLoader in the Tomcat case or a similar construct
for other web containers already during AbstractWebContainer.init(...)
calling a new ConcreteWebContainer.constructWebLoader(...) method. This
applicationLoader could then be consistently used by JSR109Service to load
shared classes.
What do you think?
CGJ
###########################################
This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
