marc fleury wrote:
> so I am trying to put something in code.
>
> if a,b,c are independently deployed EARs
>
> such that
>
> a
> / \
> b c
Note that although this is a tree depiction, the real model is a set
since all EAR's can relate to any other EAR.
> meaning a has ejb-ref to b and c
>
> then here are the possible CL parenthood chains from a (Cx meaning CL for x)
>
> Ca-Cb-Cc
>
> or
>
> Ca-Cc-Cb
You mean c or b is root? Actually the classloader chains from a can be
(left is leaf, right is root):
Ca-Cc (c holds all interfaces, including b. b has chain Cb-Cc, so b is
also leaf)
Ca-Cb-Cc
Ca-Cc-Cb
Ca (a is root and contains interfaces for b and c)
So, the ejb-ref dependency set and classloader tree are quite decoupled.
Actually, if you keep ALL interfaces of the ENTIRE application in one
EAR, then you can have n number of EARs with dependencies to all other
n-1 EARs by simply letting all EARs have the EAR with the interfaces as
classloader parent. I.e. a maximally shallow tree.
> so first of all the line dependency of the delegation model is not the right
> structure for the CL but also what happens when we redeploy a, b or c
>
> Also I don't really know how we can do that since Cb already exists and we
> can't "setParent" on it outside construction time... (neither on Cc for the
> second)
Classloaders are recreated on redeploy, hence parent is passed as
constructor argument.
> if we redeploy a then we need to throw away Ca and we can rebuild
> C'a-Cb-Cc
> or
> C'a-Cc-Cb
Yes, trivially.
> if we redeploy b then since there is no "SetParentCL" on CL we need to
> redeploy
> Ca (to pass it the right ClassLoader)and it gives us
>
> C'a-C'b-Cc
> or
> C'a-C'c-C'b
Yes. Although we are only talking about the classloader dependencies
here really. The ejb-ref's are not in this equation. For example, if c
has ejb-ref to a, then a redeploy of a requires a redeploy of c as well.
> here we see one of the first "arbitrary" problems introduced by the CL
> delegation in that we need to order CL somehow and it is "arbitrary" and in
> one case we need to redeploy applications just because they happen to be in
> the line... (clearly not an optimal structure).
The CL delegation tree needs to be explicit, which is why I introduced
an XML notation that describes this tree. With new terminology we have:
<application>
<ear>
<name>a</name>
<url>...</url>
<parent>b</parent>
</ear>
<ear>
<name>b</name>
<url>...</url>
<parent>c</parent>
</ear>
<ear>
<name>c</name>
<url>...</url>
</ear>
</application>
With this information there is no arbitrary decisions to make.
It would of course also be possible to place this parent selection in
the jboss-application.xml in each EAR file (if we introduce such a
thing), which would make the system more emergent since there is no
umbrella notion that defines how EARs relate to each other. There are
pros and cons with that.
> Also this "redeploy parts of it" assumes that the run-time is shut down
> otherwise you are going to have live references with one old type and new
> references with the new type. -> ClassCast at runtime just because you are
> keeping references somewhere.
Well, your above reasoning isn't correct so no, this will not happen
since all classloader dependencies will be considered during the
redeploy phase.
> In short... this problem of keeping track of the references in memory and
> what CL they come from is *impossible*,
hehe...
> so we need to shutdown the
> containerS (as in "start/stop" and clear all caches and etc etc). We need
> to shutdown all containers... (imho) otherwise we can't guarantee the non
> existence of "shadow" CLs.
hehe.. yes we can, but not with the scheme you have outlined.
Fortunately that's not how it is going to work, so there is no problem.
> you know just thinking as I go... I believe we need a custom CL... something
> more powerful than the URLCL with Delegation... that won't work
UCL is just fine.
> I say
> 1- we need to think more
> 2- I would keep it simple
> 3- Let's go for speed
You are missing some points of this. You are not seeing the distinction
between the ejb-ref dependencies and the classloader dependencies. They
are not really related (as I have outlined in earlier posts).
During partial application redeploy you must consider the effects of
BOTH when deciding what EAR's to redeploy. However, once you have
understood that you will see that there is no arbitrary decisions to
make, and that the whole thing is *very* deterministic in terms of
behaviour.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
