Its seems to me that we need to instead of having the JSR109Service be a competely seperate deployer from the AbstractWebContainer (which by the way needs to be broken up into a deployer + a container to address some class override issues), that the AbstractWebContainer either needs to incorporate the processing of the webservice.xml descriptor, or delegate directly to the JSR109Service as part of being a j2ee1.4 web app deployer. You actually had done this in the past, why did we decide to make them completely seperated?
Adding the war jars to the parent web service deployment is not going to be violating scoping as the scope of the web app and web service have to be the same. Really the bigger issues is getting better integration with tomcat5 so that we install or obtain the web app class loader earlier on.
-- xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx
Jung , Dr. Christoph wrote:
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 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
