Conor- Thanks for your reply. I was beginning to wonder if I was the only one and perhaps I was marooned on a desert island...
I'm preferential to option 2 personally. I like the minimal set in the jars as it allows me to mix-and-match EJBs in my deployment architecture. I also prefer to have all "support" (quoted because I use the term loosely), in a separate jar file. Again, these are my druthers but others may have different notions. I too am curious what others may think. Perhaps it will sway my opinions and impressions as well... P.S.- I almost didn't answer your question regarding "what problems this may cause". Actually, I'm not certain if it's a problem just yet. I'd have to build using 1.5 alpha to determine any issues. My only concern would be what I call "bloating" of the EJB jar with additional classes that I would prefer to have in a separate support classes jar. Under the 1.5 paradigm each EJB would potentially have a set of the same classes/interfaces in its own jar. This could potentially be a problem if I'm looking to re-deploy one specific EJB -- this one could potentially contain different signatures versus the ones already deployed on the server. Again, just my $.02. In reality, I'm not certain that we would do this in our environment but I don't want to close the door to it since individual EJB deployment can be considered a means to "patch" a running environment. Cheers! Eddie -----Original Message----- From: Conor MacNeill [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 26, 2002 6:06 PM To: Ant Users List Subject: RE: Getting Local interfaces into an EJB using <ejbjar> Eddie, The short answer is to use the 1.5 alpha since it addresses this specific problem. I understand this causes you some other problems. I'd like to know more about these. At the moment, ejbjar is trying to include all required classes in the jar by determining the classes referenced by the bean classes. This is more than the 1.4.1 version does - it just tries to add the super interfaces and superclasses. I realize many people work by having minimal beans and incorporating a support class jar. I'm looking for suggestions on what can and should be done here. We could add another option to ejbjar to allow for the following behaviours 1. Include just the bean classes and interfaces 2. Include the super classes / super interfaces (1.4.1 style) 3. Include the referenced classes to generate a "complete" jar (current nightly build behaviour) 4. Generate (or add to) an additional support jar containing the additional classes The <support> tag behavour would be affected by this option. I'm really looking for feedback on what ejbjar should look like in 1.5 and what it should support not just in this area but more generally too. Conor > -----Original Message----- > From: Eddie Bernard [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, 27 February 2002 10:23 AM > To: 'Ant Users List' > Subject: RE: Getting Local interfaces into an EJB using <ejbjar> > > > Not trying to pester, but does anyone have any insight or > thoughts on this? > I'm sure *someone* has experienced this same problem before? > > > -----Original Message----- > From: Eddie Bernard [mailto:[EMAIL PROTECTED]] > Sent: Monday, February 25, 2002 4:39 PM > To: '[EMAIL PROTECTED]' > Subject: Getting Local interfaces into an EJB using <ejbjar> > > > Has anyone else encountered this problem? > > I have several EJBs that use local interfaces as prescribed by the J2EE (a > link to the tutorial explanation: > http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/EJBConcepts6.html#62983). > > In my build file, I use the following: > > <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"/> > <include name="**/ejb-jar.xml"/> > <exclude name="**/*weblogic*.xml"/> > </ejbjar> > > With this, it generates the EJBs but does not include the Local interfaces > in the corresponding jar. The only way that I can get this to > work is using > the nested <support> element to include these classes, but since > this target > iterates to create all EJBs it "bloats" every EJB jar with > unnecessary Local > interface classes. > > I'm currently using Ant 1.4.1 and I've tried using Ant 1.5 builds > to do the > same, but 1.5 actually attempts to include extraneous support > classes in the > EJB jar. This, again, is bloating since I create a support > classes jar file > which contains all pertinent support classes any EJB may need to > reference. > > The local interfaces are declared correctly in the deployment descriptors > (both generic and Weblogic-specific). So, my assumption is that the task > should be "smart" enough to include the local interface classes > pertinent to > the EJB jar it's creating during this step. > > Does anybody have any ideas on this? > > > > Cheers! > Eddie > > -- > 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]>
