ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Thompson <>
Subject Weblogic 6, ejbjar and <support> pain
Date Tue, 01 May 2001 15:50:29 GMT
Hi all,

As you might have gathered from my last mail, I'm getting involved in a
Weblogic 6 project - I have previously done some 5.1 stuff with ant.

This new situation with the <support> element seems to be a real pain,
though from reading the archives I begin to understand why...

Here's what I understand, please correct me:

* It seems Weblogic 6 wants support classes for EJBs to be in the EJB jar
files only, as there is no weblogic classpath (or if there is, it doesn't
apply with EAR style deployment)

* With ant this translates to using the <support> element to include all of
the classes you need in the "-generic.jar" file; these are then copied to
the final '.jar' file by the <weblogic> task

* The <wlclasspath> element can put classes into scope, but doing so
generates lots of warnings, so its not really viable.

* Using <support> means every file that one puts in the <support> fileset
ends up in every EJB .jar file

* As ejbs can depend on many things (PK classes, bulk data access classes,
"business" interfaces, each other's Home interfaces etc) the set of support
classes is large and complex.

In fact, the possible set of support classes is so large that I find it hard
to see how pattern matching can hope to include the right set of classes,
unless the package structure is horribly warped to fit this when first
designed. I'm not convinced that's even possible. Even if it *is* possible
to express the "right" set of support files for a given bean, then the fact
all support classes end up in the JAR for *each* EJB makes such an effort

So what I basically seem to be concluding is we either have to tolerate
having pretty much every class in our applications in every EJB we create,
thus if you have 30 EJBs you have 30 copies of every class in your
application included. (I pray the classloader can resolve this mess) *OR* we
have to move to the "one big jar" model...

Presumably "one big jar" makes hot-deploying individual beans impossible. 

Sorry if I'm overplaying this, I hope someone tells me I am, but I find it
hard to see how the <support> element can hope to resolve this - to
re-iterate the set of classes which may need to be included is large and
complex, and even if it can be expressed as a patternset, all of the classes
are included in each EJB JAR :(

Just to be clear - I'm not criticising anyone on the ant team's efforts.
More Sun/Bea for creating such a mess.

Have I grapsed what's going on? Does anyone have any helpful tips on how to
manage this stuff?


View raw message