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