pffff....
give me some more time,
here is what I was looking at yesterday ... a one level delegation with a
"module/app cluster of CL" at the 2nd level. You still keep a valid
"initiating CL" (per VM spec) but you can cycle the "defining loaders" as
nodes under it....
still research (so I am not saying I will find something) but give me some
time...
marc
PS: also I strongly recommend that ACM paper I posted yesterday it really
helps
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Jung , Dr.
|Christoph
|Sent: Friday, December 22, 2000 2:30 AM
|To: 'jBoss Developer'
|Subject: AW: [jBoss-Dev] The Dumbo problem (Big EARs)
|
|
|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
|
|
