RE: Weblogic 6, ejbjar and pain

[Chaganthi, Madhusudan R.]

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:[EMAIL PROTECTED]]
Sent: Tuesday, May 01, 2001 3:44 PM
To: [EMAIL PROTECTED]
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:[EMAIL PROTECTED]]
Sent: Tuesday, May 01, 2001 5:50 AM
To: '[EMAIL PROTECTED]'
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...