ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J.D. Fagan" <>
Subject RE: Weblogic 6, ejbjar and <support> pain
Date Wed, 02 May 2001 17:10:28 GMT
I concur with Les.  I just read these same documents a few days ago, and
what I got out of it was its preferable to use ear's vs. separate jars and
wars.  Filing separately forces WLS to create sibling classloaders which you
then must include EJB home/remote interfaces in the .war file, AND WLS must
use the RMI stub/skeleton classes for EJB calls!

This last point has more significance to me because supposedly, WLS will try
to optimize calls to EJBs (when the clients and EJBs are running in same
JVM) by bypassing the intermediate RMI classes.  This effect only happens
with the classloader hierarchy (i.e., deploying ears over jars/wars being
deployed separately).


-----Original Message-----
From: Les Hughes []
Sent: Wednesday, May 02, 2001 2:47 AM
To: ''
Subject: RE: Weblogic 6, ejbjar and <support> pain


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. goes into
this a bit more (but not enough for me....)



> -----Original Message-----
> From: Conor MacNeill []
> Sent: 02 May 2001 10:37
> To:
> Subject: Re: Weblogic 6, ejbjar and <support> pain
> Andrew,
> From: "Andrew Thompson" <>
> > 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

View raw message