Weblogic 6, ejbjar and pain

[Andrew Thompson <an...@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)

* 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

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

* Using <support> means every file that one puts in the <support> 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 <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 :(

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

Re: Weblogic 6, ejbjar and pain

[Conor MacNeill <co...@cortexebusiness.com.au>]

Andrew,

From: "Andrew Thompson" <an...@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

RE: Weblogic 6, ejbjar and pain

[Kurt Olsen <ko...@get2hawaii.com>]

Thanks Conor, Later today I'll get some info together and post it.
Can't thank you enough for the response. Till later, Kurt
(the delay is caused by being 27 days from release!).

-----Original Message-----
From: Conor MacNeill [mailto:conor@cortexebusiness.com.au]
Sent: Tuesday, May 01, 2001 11:49 PM
To: ant-user@jakarta.apache.org
Subject: Re: Weblogic 6, ejbjar and <support> pain


Kurt,

If you can give us some more information about what problems you are
having, we may be able to help.

Conor

----- Original Message -----
From: "Kurt Olsen" <ko...@get2hawaii.com>
To: <an...@jakarta.apache.org>
Sent: Wednesday, May 02, 2001 5:44 AM
Subject: RE: Weblogic 6, ejbjar and <support> pain


> Weblogic 6, ejbjar and <support> 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

Re: Weblogic 6, ejbjar and pain

[Conor MacNeill <co...@cortexebusiness.com.au>]

Kurt,

If you can give us some more information about what problems you are
having, we may be able to help.

Conor

----- Original Message -----
From: "Kurt Olsen" <ko...@get2hawaii.com>
To: <an...@jakarta.apache.org>
Sent: Wednesday, May 02, 2001 5:44 AM
Subject: RE: Weblogic 6, ejbjar and <support> pain


> Weblogic 6, ejbjar and <support> 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

RE: Weblogic 6, ejbjar and pain

[Kurt Olsen <ko...@get2hawaii.com>]

Weblogic 6, ejbjar and <support> 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 <support> 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 <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)

  * 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

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

  * Using <support> means every file that one puts in the <support> 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 <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 :(

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