Hmmmm. Im just noticing one result of your change is that there is only 1
application object for the whole EAR file. So instead of having containers
grouped into applications grouped into an EAR, you just have a single
application with a bunch of containers, no matter what ejb-jar the
containers come from.
And the shared Application makes the ejb-links work properly between
ejb-jars. So I suppose your way is the only way.
very good...
-----Original Message-----
From: Castro, David
Sent: Monday, February 19, 2001 1:18 AM
To: 'JBoss-Dev'
Subject: [jBoss-Dev] code merge for pet store patch
Tom, Scott:
>From what Marc is saying the behavior of the current code (in terms of
ejb-jars in the classpath) doesnt matter, since it will be rewritten, so Im
happy to do it your way Tom.
Ive merged the PetStore patches (to J2eeDeployer, ContainerFactory,
ContainerFactoryMBean) with the new version of J2eeDeployer, and fixed the
bug that screws up Jaws deployment when there are multiple CMP jars in the
app classpath.
I have one question though...
Why did you (Tom) move the functionality of deploying a whole ear file (ie.
iterating through the EJB-Jars) from J2eeDeployer into ContainerFactory? It
seems more the job of J2eeDeployer to me, and if we left it there then we
could use the current J2eeDeployer (and ContainerFactoryMBean) code
unmodified. (We would have to uncomment the Installer code that puts the
ejb-jars in the app classpath). I would be inclined to go that way, but Im
wondering if you had a particular reason for moving that code or any strong
feelings about that decision.
I guess Ill fix Ole's bug (removing the app CL from Tomcat) while Im at it.
