Return-Path: 
 <ant-user-return-7318-apmail-jakarta-ant-user-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-user-archive@jakarta.apache.org
Received: (qmail 71299 invoked by uid 500); 2 May 2001 09:35:33 -0000
Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:ant-user@jakarta.apache.org>
List-Help: <mailto:ant-user-help@jakarta.apache.org>
List-Unsubscribe: <mailto:ant-user-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:ant-user-subscribe@jakarta.apache.org>
Reply-To: ant-user@jakarta.apache.org
Delivered-To: mailing list ant-user@jakarta.apache.org
Received: (qmail 71262 invoked from network); 2 May 2001 09:35:30 -0000
Message-ID: <002a01c0d2eb$bafb41f0$6ced3c3f@cognetnt>
From: "Conor MacNeill" <conor@cortexebusiness.com.au>
To: <ant-user@jakarta.apache.org>
References: <0373D1CCF679D411A80300B0D03DE06FCE7FBA@CHALFONT>
Subject: Re: Weblogic 6, ejbjar and <support> pain
Date: Wed, 2 May 2001 19:37:05 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

Andrew,

From: "Andrew Thompson" <andrewt@quidnunc.com>
> 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)

It "wants" this, complains if the support classes aren't there but seems to
work anyway. You'll get an "error" during ejbc and also when you deploy
saying that the bean won't be able to be hot deployed.

>
> * 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

If you want to have all the support code in the jar that is true. This is
required to meet the EJB spec but I must admit we currently have support
classes in a separate jar.

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

wlclaspath was introduced so that you can avoid the warnings :-)

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

Yep. It isn't ideal. I'm not sure the best way to have a task which
processes multiple beans but which allows the <support> classes to vary by
bean.

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

Yes.

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

OK, it should be possible to use the <depend> code to find the closure of
support classes to make the resulting ejb-jar "whole".

>
> 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)

OK, While I am told that the classloaders in WL6 are much improved, I too
am concerned by having the same class in multiple jars when the beans in
those jars interact.

>*OR* we
> have to move to the "one big jar" model...
>

Yes.

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

I guess so, but I presume you can hot deploy the whole kit. The granularity
in EJBs seems to have moved from single beans to ears.

> 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 :(
>

I'm not sure how smart ejbc is either when it comes to regenerating one big
jar. The reason I like a bean per jar is that it cuts down the ejbc time to
just the bean that has changed. If I have one big jar, any change will
trigger the whole ejbc process. I'll look into that.

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

Thats cool. In some respects it is just a "hard" problem. Hot deploy really
requires the one big jar approach since it is difficult to see how beans
which exchange information via support classes could be deployed
individually and still be "whole" as the spec requires.

>
> Have I grapsed what's going on?

Yes.

> Does anyone have any helpful tips on how to
> manage this stuff?

Someone submitted a patch to allow the ejbc results to be sent to a
directory rather than a jar. I think it was supposed to allow for the
incremental ejbc whilst still working as a single jar. I'll be looking into
that patch soon.

Conor