ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Thompson <andr...@quidnunc.com>
Subject RE: Weblogic 6, ejbjar and <support> pain
Date Thu, 03 May 2001 04:18:30 GMT

Essay alert!!

>>AndyT said
>Conor said

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

Yes, I realised that if I did think this was "the end of the world" I could
always use the <include><exclude> mechanism to filter by deployment
descriptor and write a separate <ejbjar><support/></ejbjar> for each bean
or
group of beans to limit the repetition. Probably worthwhile on a truly
largescale project with a *lot* of classes.

I know its mentioned in the documentation in the preamble, but I don't think
the docs explicitly state that these elements are supported on ejbjar? At
least, they're not listed alongside the <dtd> element etc?


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

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

Is this something you intend to pursue? ant being able to build JARs that
are "as slim as possible" for you would be something worth shouting from the
rooftops. 

Essentially its the transitive closure you want, then you limit it to
importing only classes from the ejbjar source directory, so only user
written classes are included.

The problem I see is whether you'd want ot include the Home and Remote
interfaces of other beans. While these might be requires to make things
compile, automatically including them could lead people down the wrong path
conceptually. As the Sun documentation points out, its entirely valid to
create a pair of ejbs, or a much more complex cycle, which are circularly
dependent on each other. At this point the concept of trying to deploy one
of the ejbs in the cycle without the others becomes meaningless. You can
break the cycle in order to get things deployed, but it'll never run right.
In this case, it makes more sense to indicate to people that they should
build a .jar with all of the mutally dependent beans in it than it does to
include only the Home and Remote interfaces merely to make it compile.

(when I say it won't work, obv, it will work if you deploy all of the jars
with all of the dependent beans together, but this seems like a lot of work
to avoid doing what one should do, which is to package dependent beans
together in the same jar)

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

Indeed. I'm assuming so long as only one version is deployed, then its OK.
All the more reason to deploy sensibly constructed units that satisfy all
their own dependencies I suppose.

Of course, not supporting versioning of JAR files properly is something Sun
deserve to be dragged over hot coals for. Its ridiculous the way that
there's no simple standardised way to ask "just what version of  xerces is
this anyway?" at runtime. Or for an app to say "sorry, but you have JFoo
version 1.X installed and I require 2.X." A classnotfound exception is the
best Sun seem to be able to offer :(

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

Yes, it does. I guess this makes sense. The people from Hewlett Packard were
trying to sell me Bluestone the other day. They were telling me it has a GUI
console that can transfer an EAR deployed J2EE app between 2 servers in a
cluster while its still running, migrating the users over. Similarly they
can deploy a new version of an app, and all new users log into it, whereas
the old version of the app still exists for users currently logged in, until
they log out and in again, in which case they get the new one. Obviously, it
can rollback to an eariler version.

If this works as advertised (I haven't had a chance to try) this is clearly
evidence of how the whole EAR thing can pay off. Similarly, Weblogic 6.0 is
so much more cleanly organised than 5.1. HP are clearly shooting for the
moon on this stuff, and I wish them the best of luck with it. Overally, I
think this stuff is a win, but it has its problems, its true.



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

Absolutely. Absolutely. This is the biggest single issue to my mind. Today,
I merged a lot of the 40 or so EJBs on our project into 8 or so JARs instead
of 40 seperate ones. Build time dropped from 21 minutes to 2 mins 36seconds
(I cheated a little, the earlier time is javac and the later one jikes, but
you get the idea). Clearly this is a huge win, but maintaining the set of
EJBs such that you have to add each new one to the right group so it can
find the beans in depends on is clearly a big admin headache (worth it for
the speed though!). If you could improve the calculation of which support
classes are needed using true dependency analysis such that we can avoid
rebuilding as much as possible (and make the JARs smaller and have less
duplication) then it'd be really really great.  What would be out of this
world would be a "ejbreport" task that would say... "these 5 beans are
independent and can be deployed alone, whereas you must group beans X, Y, B
and F together because they rely on each other". Such a report is probably
really hard to generate, given how long it took me to determine this by hand
today. Finding the "optimum" configuration would be even harder, given some
people would be looking for as much independance as possible (promotes
reuse) and some people for as few jars as possible (builds faster, more hot
deployable).

There's discussion of this on java.sun.com, if you dig. What they say boils
down to "include all dependent classes so you can hot deploy as much as
possible". Then they compare one bean per jar with one big jar and several
smaller logically grouped jars, favouring the later, as I have been
discussing.

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

Yes.


AndYT

...

Mime
View raw message