RE: Sharing classes between WebContainer and JSR109Deployer *was* AW: [JBoss-dev] Re: deployment classloader in AbstractWebContaine r
This could simplify things considerably. You're right, we had a
'delegate to JSR109Service' approach in place for the
AbstractWebContainer and the EJBDeployer. I mainly did this because I
was not happy with the order of deployment (subdepoyment start/create
before parent start/create). Realy the EJB/Webapp should be up before
the webservice.
For the client programming model we might want to consider a simmilar
'tight' integration.
-thomas
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Scott M Stark
Sent: Freitag, 21. November 2003 18:18
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Sharing classes between WebContainer and JSR109Deployer
*was* AW: [JBoss-dev] Re: deployment classloader in AbstractWebContaine
r
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.
--
Scott Stark
Chief Technology Officer
JBoss Group, LLC
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
Sharing classes between WebContainer and JSR109Deployer *was* AW: [JBoss-dev] Re: deployment classloader in AbstractWebContaine r
-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
Re: Sharing classes between WebContainer and JSR109Deployer *was* AW: [JBoss-dev] Re: deployment classloader in AbstractWebContaine r
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.
--
Scott Stark
Chief Technology Officer
JBoss Group, LLC
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
AW: [JBoss-dev] Re: deployment classloader in AbstractWebContaine r
-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. Ahhh. ... that is the ucl then? Guess that ignoring this relation and basing too much on the localCl was my fault. I think I know what to do ... I will care for it, Thomas. 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
Re: AW: [JBoss-dev] Re: deployment classloader in AbstractWebContaine r
Yes, the localCl is only for deployers to find their descriptors or deployment local configurations prior to the creation of, or assignment to the deployment ucl, which does not occur until after init. -- Scott Stark Chief Technology Officer JBoss Group, LLC Jung , Dr. Christoph wrote: 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. Ahhh. ... that is the ucl then? Guess that ignoring this relation and basing too much on the localCl was my fault. I think I know what to do ... I will care for it, Thomas. 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
