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.
Maybe I wasn't really clear... (since you and rickard seem to miss that
point) the "nightmare" scenario is a "nightmare scenario" in the parent CL
case.
It essentially says that "deploying" beans independently is a fallacy... you
need to deploy *everyone* at once (except perhaps the last one), because the
structure we use today in the container is the parent delegation one and
that is only done at construction time of the CL, in other words, we can't
take an already deployed bean and add the parent for that application....
ALLs CL are still linked to the Applications (in the XML case). There is no
"independent beans assembled independently in the runtime"...
:(
I don't know that anyone in the industry has a solution to that problem
either? but I am wrong? does anyone out there have a solution to the dumbo
problem?
(link various EARS in runtime WITH CL integration) (of course, no CL
integration is a no brainer)
marc
