ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <>
Subject RE: EjbJar task and support classes
Date Wed, 15 Nov 2000 11:55:48 GMT

We do not include support files in our EJBs. I tried it once back with
WL 4.5.1 and IIRC, the server could not even find the class. The result
we have now is that all of our support classes are bundled into a jar
deployed on the classpath. It works pretty well. It does limit the
ability to hot deploy, though, I think.

Having multiple copies of support files coming in from different
classloaders is probably not a good thing :-)


-----Original Message-----
From: Ventimiglia, David []
Sent: Wednesday, 15 November 2000 6:46
To: ''
Subject: RE: EjbJar task and support classes

My preference is to include classes only once, and therefore I'd remove
"support" classes from the ejb jar, as you suggest.  Though the ejb spec
*seems* to say otherwise can possibly be attributed to simple
inconsistency on its part.  And your point about "transitive closure" is
well-taken.  Nevertheless, for those who prefer their "support" classes
inside the ejb jar, is there a way to get Ant to do this?  For instance,
could the <jar> task be used to "update" the ejb jars after the fact.
Does <jar> support something like the "update" option (jar -u)?

-----Original Message-----
From: Andrew Thompson []
Sent: Tuesday, November 14, 2000 11:31 AM
To: ''
Subject: RE: EjbJar task and support classes

heh. Well I've heard other people state that the specs are inconsistant
on this point.
Here's a thought - how many EJBs do you put in your EJB jar? - Do you do
one bean per jar, or all beans in one Jar or something inbetween?
And if you have multiple jars (presumably to simplify maintainence and
upgrades) do you put those support classes in just one of the jars or
all of them? How does your application server react to the same support
class being in 2 jars ... what if 2 jars ever came to have different
incompatible versions of the same support class because one EJB jar has
been upgraded and another hasn't?
For these reasons I'm biased toward not including the support files in
the EJB jars, by YMMV.
I think ultimately it'll depends on your app server. e.g. Weblogic seems
strongly biased towards putting the support classes on the 'system'
classpath (though a seperate jar might make more sense with hot deploy).
Besides = I'm not sure what support class means... if it were to be the
transitive closure of all references classes the entire app would end up
in the jar.
Maybe this sort of crap is a good argument for .war files (J2EE packaged
Andrew Thompson    :: A little bigger on the inside
Software Developer :: Quidnunc
I am the cat who walks through walls, all places and all times are alike
to me.

View raw message