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]>
