|> 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.
The real EJB-REF looks like
a d e
/ \ / |
b c f
|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)
rickard please read my first line (hypothesis)... that the Ears are deployed
*independently*
so Cb and Cc already exist in the runtime and are package indenpendently of
the a module being deployed.
|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.
Rickard, we deploy A b and c indenpendently.
|> 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.
I think you missed the point, at the first deploy of A since Cb already
exists and we set Cc Cb we need to undeploy/redeploy Cb...
in other terms Cb being already part of an application we need to stop the
other applications for CL considerations. (this is very fucked up)
In clear we cannot link to other EARS independent in runtime. You need to
instanciate different containers to share entities and our container really
isn't built for that.
Do you understand this point?
|> 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.
LOL, you are putting in XML THE CLASSLOADER DEPENDENCY!!!!!!!!!
no way... that is totally linked to the CL delegation model!!!!
LOL you made my morning
|> 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
what above "reasoning"... the fact that I don't put in XML the
dependencies?...
please... understand the hypothesis, understand what hypothesis you are
proposing. and that the reasoning would be "hypothesis "let's put all CL
dependencies in XML" --> complete nightmare for administration --> stupid
idea"", that is a reasoning (implications).
|> 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.
There has to be a simpler way something with a flat CL ...
|You are missing some points of this. You are not seeing the distinction
|between the ejb-ref dependencies and the classloader dependencies. They
??? what makes you think that?
|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.
huh... where? by specifying the CL dependencies in XML????
rickard, back to the drawing board...
marc
|
|/Rickard
|
|--
|Rickard �berg
|
|Email: [EMAIL PROTECTED]
|
|
