I have applied these changes.
----- Original Message -----
From: "Gabor Herr" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, February 15, 2001 5:29 AM
Subject: Re: [jBoss-Dev] bug in ear deployment in pre 2.1
-J2eeDeployer.java/Installer.java
David Castro writes:
> In the checkin Fri Nov 24
> jboss/src/main/org/jboss/deployment/J2eeDeployer.java v1.12
> jboss/src/main/org/jboss/deployment/Installer.java v1.1
>
> there are a couple of changes that introduce a deployment bug.
Because of this bug the whole shared classloader stuff (as described
in the JBoss docs) is unusable in the current JBoss snapshot. It took
me some time to find this out...
> 1. J2eeDeployer.startApplication() ~line 400
>
> We now start the .war files first, then the .jar files
> Before starting the .jar files, we set the context classloader to be the
> server classloader, not the application classloader. This means that common
> libs in the application classpath are not seen by the ejb jars, forcing the
> deployer to put common libs into the SERVER classpath.
During deployment Tomcat overwrites the context classloader setting,
so it has to be restored after every .war file. The problem is that by
mistake the server classloader is restored instead of the application
classloader.
>
> Unfortuanately, we cannot work around by setting the context classloader to
> be the application classloader, because of this:
>
> 2. Installer.execute() ~line 310
> add all ejb jar files to the application common classpath
>
> because the application classpath contains ALL the ejb-jars, if we set the
> application classloader to be the parent of the container classloader, then
> when we go to load META-INF/jaws.xml, it is loaded by the application
> classloader (possibly from the wrong ejb jar) rather than by the container
> classloader.
>
> Proposed Fix:
> Dont put ejb jars in the common classpath! (ie remove lines
> I dont see why it makes sense for the application classloader to see all of
> the ejb jars. I see that as the distinction between ejb jars and shared
> jars - if I want something shared I will put it in a shared jar. That was
> the behavior in 2.0 final, and it worked fine.
This fix would also conform the specs. According to EJB-1.1, §17.3,
and EJB-2.0PFD, § 22.3, which is more clear about "referencing" of
external class files, the essence is that an ejb-jar has to be
self-contained. This can be achieved either by including every
referenced class or by referencing their locations using the Manifest
classpath.
I applied David´s proposed fixes, here is a patch to fix the current
CVS snapshot:
Index: src/main/org/jboss/deployment/Installer.java
===================================================================
RCS file: /products/cvs/ejboss/jboss/src/main/org/jboss/deployment/Installer.java,v
retrieving revision 1.3
diff -c -w -r1.3 Installer.java
*** src/main/org/jboss/deployment/Installer.java 2001/01/23 18:35:36 1.3
--- src/main/org/jboss/deployment/Installer.java 2001/02/15 13:15:27
***************
*** 307,319 ****
}
*/
// put all ejb jars to the common classpath too
it = d.ejbModules.iterator();
if (it.hasNext())
log.log("add all ejb jar files to the common classpath");
while (it.hasNext())
d.commonUrls.add (((Deployment.Module)it.next()).localUrls.firstElement());
!
break;
}
saveConfig ();
--- 307,320 ----
}
*/
+ /*
// put all ejb jars to the common classpath too
it = d.ejbModules.iterator();
if (it.hasNext())
log.log("add all ejb jar files to the common classpath");
while (it.hasNext())
d.commonUrls.add (((Deployment.Module)it.next()).localUrls.firstElement());
! */
break;
}
saveConfig ();
Index: src/main/org/jboss/deployment/J2eeDeployer.java
===================================================================
RCS file: /products/cvs/ejboss/jboss/src/main/org/jboss/deployment/J2eeDeployer.java,v
retrieving revision 1.17
diff -c -w -r1.17 J2eeDeployer.java
*** src/main/org/jboss/deployment/J2eeDeployer.java 2001/02/08 22:18:44 1.17
--- src/main/org/jboss/deployment/J2eeDeployer.java 2001/02/15 13:15:30
***************
*** 391,396 ****
--- 391,399 ----
// set the context classloader for this application
createContextClassLoader(_d);
+ // save the application classloader for later
+ ClassLoader appCl = Thread.currentThread().getContextClassLoader();
+
// redirect all modules to the responsible deployers
Deployment.Module m = null;
String message;
***************
*** 411,420 ****
// Call the TomcatDeployer that is loaded in the JMX server
server.invoke(warDeployer, "deploy",
new Object[] { m.webContext, m.localUrls.firstElement().toString ()},
new String[] { "java.lang.String",
"java.lang.String" });
- }
// since tomcat changes the context classloader...
! Thread.currentThread().setContextClassLoader (oldCl);
// JBoss
it = _d.ejbModules.iterator ();
--- 414,423 ----
// Call the TomcatDeployer that is loaded in the JMX server
server.invoke(warDeployer, "deploy",
new Object[] { m.webContext, m.localUrls.firstElement().toString ()},
new String[] { "java.lang.String",
"java.lang.String" });
// since tomcat changes the context classloader...
! Thread.currentThread().setContextClassLoader (appCl);
! }
// JBoss
it = _d.ejbModules.iterator ();
/Gabor
--
Gabor Herr [EMAIL PROTECTED]
Computer Science Department [EMAIL PROTECTED]
Darmstadt University of Technology
Germany
