Return-Path: Delivered-To: apmail-jakarta-ant-user-archive@jakarta.apache.org Received: (qmail 12279 invoked by uid 500); 1 May 2001 19:46:09 -0000 Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Reply-To: ant-user@jakarta.apache.org Delivered-To: mailing list ant-user@jakarta.apache.org Received: (qmail 12258 invoked from network); 1 May 2001 19:46:07 -0000 From: "Kurt Olsen" To: Subject: RE: Weblogic 6, ejbjar and pain Date: Tue, 1 May 2001 09:44:05 -1000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F0_01C0D223.42EB5060" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <0373D1CCF679D411A80300B0D03DE06FCE7FBA@CHALFONT> X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N This is a multi-part message in MIME format. ------=_NextPart_000_00F0_01C0D223.42EB5060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Weblogic 6, ejbjar and 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 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 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 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 task * The element can put classes into scope, but doing so generates lots of warnings, so its not really viable. * Using means every file that one puts in the 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 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... ------=_NextPart_000_00F0_01C0D223.42EB5060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Weblogic 6, ejbjar and <support> pain
Hi=20 Andy, I'm trying to use ant with weblogic 5.1 and haven't gotten = anywhere with=20 the ejbjar task. Another guy is doing the ejb's but doesn't have time = for ant so=20 the sys-admin guy and I have been trying to figure out the ejbjar task = for 5.1.=20 We'd appreciate any help you can offer and will be glad to pass along = our=20 experience with weblogic 6 when we move to it in a couple of=20 months.
 
Kurt=20 Olsen
Get2Hawaii Inc.
808.945-3313x121
-----Original Message-----
From: Andrew Thompson=20 [mailto:andrewt@quidnunc.com]
Sent: Tuesday, May 01, 2001 = 5:50=20 AM
To: 'ant-user@jakarta.apache.org'
Subject: = Weblogic 6,=20 ejbjar and <support> pain

Hi all,

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

This new situation with the <support> element = seems to=20 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=20 the EJB jar files only, as there is no weblogic classpath (or if there = is, it=20 doesn't apply with EAR style deployment)

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

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

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

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

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

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

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

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

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

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

AndyT...=20

------=_NextPart_000_00F0_01C0D223.42EB5060--