ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chaganthi, Madhusudan R." <m...@cdc.gov>
Subject RE: Weblogic 6, ejbjar and <support> pain
Date Tue, 01 May 2001 21:39:52 GMT
Just an idea.
 
What if you jar up all your common classes initially into "common.jar"
have that jar in the classpath and then 
jar up all your beans by referring to that "common jar"?
 
While packaging your ear file, you use the "common jar", "jar1", "war1", etc
into an "ear" file
 
 

-----Original Message-----
From: Kurt Olsen [mailto:kolsen@get2hawaii.com]
Sent: Tuesday, May 01, 2001 3:44 PM
To: ant-user@jakarta.apache.org
Subject: RE: Weblogic 6, ejbjar and <support> pain


Hi 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