ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eddie Bernard <>
Subject RE: Getting Local interfaces into an EJB using <ejbjar>
Date Wed, 27 Feb 2002 02:21:30 GMT

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.


-----Original Message-----
From: Conor MacNeill []
Sent: Tuesday, February 26, 2002 6:06 PM
To: Ant Users List
Subject: RE: Getting Local interfaces into an EJB using <ejbjar>


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

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

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.


> -----Original Message-----
> From: Eddie Bernard []
> 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 []
> Sent: Monday, February 25, 2002 4:39 PM
> To: ''
> 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:
> In my build file, I use the following:
>     <ejbjar srcdir="${}"
>             descriptordir="${}"
>             classpath="${opel.classpath}"
>             naming="ejb-name"
>             manifest="${opel.home}/MANIFEST.MF"
>             flatdestdir="true">
>       <weblogic destdir="${opel.release}"
>                 keepgeneric="false"
> 		rebuild="false"
>                 wlclasspath="${wls.classpath};${}"
>                 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:   <>
> For additional commands, e-mail: <>
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message