ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hughes <leslie.hug...@rubus.com>
Subject RE: Weblogic 6, ejbjar and <support> pain
Date Wed, 02 May 2001 09:46:50 GMT
Hi,

Here's my 2p :-)

Ear does seem to be the deployment model. WLS's classloaders are
hierarchical for EJB and web app if everything is in an EAR - i.e. your
taglibs, beans or straight JSP can find anything contained in your EJB.jar
because it's classloader is a child of the ejb loader.

If you deploy sep. war and jar files then the classloaders aren't associated
- they all stem from the primordial loader and then you need everything
everywhere.  I'm guessing now but the docs imply that all beans in an ear
are loaded by a single loader which I guess means that you only need your
support stuff in a single place.

http://edocs.bea.com/wls/docs60/programming/packaging.html#1048725 goes into
this a bit more (but not enough for me....)


Bye,

Les


> -----Original Message-----
> From: Conor MacNeill [mailto:conor@cortexebusiness.com.au]
> Sent: 02 May 2001 10:37
> To: ant-user@jakarta.apache.org
> Subject: Re: Weblogic 6, ejbjar and <support> pain
> 
> 
> 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
> 
> 

Mime
View raw message