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