Thanks for the info. Our support classes are in a separate .jar packaged in the .ear and referred to in the ejb.jar's manifest. So when we package our final .ear file, it has every required library for the whole application in it (whether our support.jar or a 3rd party .jar). So we can redeploy the app w/o bringing the app server down.
While there is some loss of flexibility using a .ear, the upside is that WebLogic can optimize certain intra-container calls when all pieces of an app are deployed in a .ear. That's what we've chosen to do. FWIW... Donnie >>> [EMAIL PROTECTED] 01/10/02 01:56PM >>> Donnie- Simply stated, for modularity. A possible scenario would be if I want to replace only 1 one of the 75 EJBs running in the app server, I can build it and deploy it. Otherwise, I would need to rebuild the entire "super" EJB and redeploy it. In this case, it may not be practical to do in a live system depending on the nature of the application itself (particularly in a production-live application). I guess your point you be argued if the support classes are packaged in a separate jar, you would need to bring down the app server, deploy the new support class .jar package, and re-start the server since these types of classes are actually loaded into the server's memory and cannot be "flushed" with a new package. I guess this is an off-topic discussion to Ant, but it has a direct correlation to why I would like the <ejbjar> task to allow modification to the manifest. My particular problem relates to the J2EE specification for packaging and deploying Enterprise Archives. As I've stated in a previous post, if an EJB requires support classes to be part of its classpath you need to either: 1. Include all the support classes in the EJB .jar 2. Add the support classes (in .jar or loose class format) to the server's system classpath 3. Add an entry in the EJB .jar's manifest "Class-Path: list-of-support-classes-or-3rdparty-jars" In such, the <ejbjar> task should allow #3. This would allow me to keep the logic construct I have for creating separately packaged EJB .jar files with each manifest containing the correct "Class-Path" reference to the needed support and 3rd party components. Instead, what I have to do now is add an additional <jar> task to the target that explicitly adds the correct manifest "Class-Path" to each jar, meaning that I have to add this logic for n-number of jars. This is a solution that will not scale, since ongoing development might add an indeterminate number of EJBs which will require me to follow up each time and add this construct to my build file. Hope this clarifies the "why". Cheers! Eddie -----Original Message----- From: DONNIE HALE [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 10, 2002 10:36 AM To: [EMAIL PROTECTED] Subject: RE: Adding/extending a manifest using <ejbjar> Eddie, You're not the first person who's said they put each bean in its own jar. May I ask, out of curiousity, why you package them that way? Are they completely independent of each other and could therefore potentially be deployed in a completely independent fashion? Thanks, Donnie >>> [EMAIL PROTECTED] 01/10/02 12:04PM >>> Donnie- Thanks for the repost (for the third time ;) This looks like it works great, if you're generating one "super" EJB called ejb-depl.jar. However, I want to maintain the granularity the EJBs and have each one reside in its own .jar file. Therefore, this type of logic will not work. Here's what I've used for the last year or so that works. It parses the ejb-jar.xml to get the jar name automatically and it's only one target: <target name="ejbs" depends="classes" description="generates ejbs"> <echo message="--(DT)--> Generating ejbs"/> <copy todir="${opel.build}"> <fileset dir="${opel.src}" includes="**/ejb-jar.xml,**/weblogic-ejb-jar.xml"/> </copy> <copy todir="${opel.build}"> <fileset dir="${opel.src}"> <patternset id="opel.rdbms.deployment.descriptors"> <include name="**/*rdbms*"/> </patternset> </fileset> </copy> <ejbjar srcdir="${opel.build}" descriptordir="${opel.build}" classpath="${opel.classpath}" naming="ejb-name" manifest="${opel.home}/MANIFEST.MF" flatdestdir="true"> <weblogic destdir="${opel.release}" keepgeneric="false" rebuild="false" wlclasspath="${wls.classpath};${opel.build}" noEJBC="${opel.noejbc}" newCMP="false"> </weblogic> <dtd publicId="-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN" location="${opel.home}/ejb-jar_2_0.dtd"/> <support dir="${opel.build}" includes="**/Local*.class"/> <include name="**/ejb-jar.xml"/> <exclude name="**/*weblogic*.xml"/> </ejbjar> This will create individual .jar for any number of EJBs I have and this is really what I want. If I have 75 separate EJBs, this will create 75 separate .jar files. So, what I really want to get working is the "manifest" attribute for <ejbjar> to work as it does for <jar>. Right now it generates an empty manifest. It would be nice if <ejbjar> either worked with the "manifest" attribute or it worked with the nested <manifest> like <jar> does. Example: <ejbjar ....> <manifest> <attribute name="Class-Path" value="lib/foo.jar lib/bar.jar"/> </manifest> </ejbjar> Cheers! Eddie -----Original Message----- From: DONNIE HALE [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 10, 2002 8:12 AM To: [EMAIL PROTECTED] Subject: RE: Adding/extending a manifest using <ejbjar> Here's a message I sent a week or so ago (this is actually the 3rd posting of it): ================================================= I use Ant to build a weblogic ejb.jar file; however, I do not use the ejbjar optional task (or whatever it's called) from Ant. I found the docs for that set of tasks unhelpful; and, if the docs are accurate, the tasks are overly complicated. Here's what I have: 1) An "app.compile" target which builds all my .java sources except the remote, home, and bean-impl classes. These are jarred into an "app.jar" file. 2) An "ejb.compile" target builds the remote, home, and bean-impl classes for all my beans. 3) An "ejb.jar" target uses a <jar> task to put just the .class files from step 2, along with the ejb-jar.xml, weblogic-ejb-jar.xml, etc. into an "ejb.jar" file. 4) An "ejb.ejbc" target uses a <java> task to run ejbc against the .jar file from step 3, explicitly placing the "app.jar" file from step 1 in the classpath. I name the output of that "ejb-depl.jar" to indicate that it's aruper" EJB called ejb-depl.jar. deployable .jar file. Voila! That's it, and it works perfectly for me every time. I separate out "app.jar" stuff from "ejb.jar" stuff because it prevents the warning about the EJB .class files already being in the classpath. BTW, this is with WebLogic 6.1. ================================================= Donnie >>> [EMAIL PROTECTED] 01/10/02 01:07AM >>> Could you post a snippet of your targets, if they're not proprietary? -----Original Message----- From: Donnie Hale [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 09, 2002 6:03 PM To: Ant Users List Subject: RE: Adding/extending a manifest using <ejbjar> I don't have 75 beans, but I have 6 and build them all with one target (not <ejbjar> - actually 2, one for the vanilla ejb.jar and one to put that into ejbc) and won't have to change that if/when we add more beans. Don't know what to say about the manifest problem. Sorry... Donnie > -----Original Message----- > From: Eddie Bernard [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 09, 2002 7:54 PM > To: '[EMAIL PROTECTED]' > Subject: Adding/extending a manifest using <ejbjar> > > > OK, I've haven't completely given up on using <ejbjar> for my WebLogic 6.1 > project. > > The reason I want to use it is that I have approximately 75 EJBs > that I want > to build and the target I've created that uses <ejbjar> neatly > creates each > EJB with only one target. Using some of the other suggested methods > (which, again, I appreciate the responses) would require me to > have a target > for virutally every bean and even worst add more targets if more beans are > added to the project. > > Now with all tht said, I'm in the process of creating an > Enterprise Archive, > but I'm having a deployment problem -- again unrelated to Ant itself. > However, after reading some BEA white papers and the J2EE > specifications for > Application Deployment, it allows the addition of the name:value pair: > > Class-Path: list-of-jars-separated-by-spaces > > Example: > > Class-Path: lib/my_support_classes.jar > > Now the Ant-related problem... It seems that <ejbjar> extends the > <jar> task > meaning that it inherits the "manifest" attribute. If I use <jar> with my > manifest addition it works just fine. However, with <ejbjar> it > generates a > "near empty" file (actually, it has a set of cr/lf). > > Has anybody else come across this problem or have any ideas what I can do? > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: < Here's what I have: mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
