Hi there,
just like to putting in my last 2 cents for this year (BTW: I wish you very
happy X-MAS).
-----Urspr�ngliche Nachricht-----
>Von: marc fleury [mailto:[EMAIL PROTECTED]]
>Gesendet: Donnerstag, 21. Dezember 2000 18:25
>An: jBoss Developer
>Betreff: RE: [jBoss-Dev] The Dumbo problem (Big EARs)
|> if a,b,c are independently deployed EARs
|>
|> such that
|>
|> a
|> / \
|> b c
To conclude and ensure that I understood correctly, I think we have seen two
different options for the problem of "how to break up a big EAR into several
EARs and how to incrementally link the pieces again at runtime such that
they behave
like the big original":
- Marc�s proposal: EAR dependencies are encoded into a combination of a
central naming repository and the ejb-ref annotations of the individual
classes. This is close to what I originally proposed as the "multiple,
circular dependencies" thingy.
Advantages:
- is very elegant.
- allows fine-grained control.
- can cope with circular dependencies
- lot of possibilities to partition the logical application
- no sacrifice to VM/CL design
Problems:
- Spec compliance (should ejb-ref be reinterpreted?) versus
management problems
(who cares about central naming?)
- What about factoring out just non-bean, not-ejb-referenced
parts
(e.g., shared helper classes, common wars, etc.) of an
application?
- Incremental (re-)deployment cannot be done efficiently
with the
current ClassLoader model. Similar to Marc, I was
constructing myself a
similar, nighmare example:
Altough you could deploy several EAR parts of the logical
application (in your
example: "b" and "c") into a single classloader ... you
probably won�t find
out until "a" is deployed which would force you to tear
down the whole damned
tree again. Very unsatisfying. But maybe preprocessing of
a
central "XML-script" could tell us before to put b into
the same classloader than c ... ? On the other hand, changes to
the XML script at runtime would be
impossible.
- Rickard�s model: EAR dependencies are encoded into a special tag of the
jboss-application.xml. Each ear could only have a single parent EAR.
Advantages:
- spec compliance (ejb-ref would just be interpreted in the
wider scope)
- no central overview over the logical application necessary
- close-to-straightforward, efficient (re-)deployment
- close-to-VM design
- factoring out of arbitrary "modules" inside the EARs
Problems:
- not every partitioning of the logical application can be
done.
- sacrifice to the existing CL hierarchy
- dependencies specified via relative URL�s, not logical
names.
Before coming up with the nightmare example, I was in favor to
the first option (with the relations being nevertheless
specified in the individual jboss-application.xml�s, but that�s a minor
issue.)
Regarding the arguments of simplicity and efficiency,
I now severly tend to the second option. Especially because we can start to
write it
ASAP ...
Doesn�t say that we still can�t write a custom classloader model that can
handle a wider class of partitionings, later, does it? For both approaches,
the meta-model must be revisited ...
Best,
CGJ
