ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kurt Olsen" <kol...@get2hawaii.com>
Subject RE: Weblogic 6, ejbjar and <support> pain
Date Tue, 01 May 2001 19:44:05 GMT
Weblogic 6, ejbjar and <support> painHi Andy, I'm trying to use ant with
weblogic 5.1 and haven't gotten anywhere with the ejbjar task. Another guy
is doing the ejb's but doesn't have time for ant so the sys-admin guy and I
have been trying to figure out the ejbjar task for 5.1. We'd appreciate any
help you can offer and will be glad to pass along our experience with
weblogic 6 when we move to it in a couple of months.

Kurt Olsen
Get2Hawaii Inc.
808.945-3313x121
  -----Original Message-----
  From: Andrew Thompson [mailto:andrewt@quidnunc.com]
  Sent: Tuesday, May 01, 2001 5:50 AM
  To: 'ant-user@jakarta.apache.org'
  Subject: Weblogic 6, ejbjar and <support> pain


  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 futile.

  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?

  AndyT...


Mime
View raw message