marc fleury wrote:
> |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.
Yes, and? Was there a problem with my statement? Be more explicit
please.
> |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.
Again, yes, and? Oh, you're saying that the interfaces are duplicated in
the EAR's. Well, then we don't get the benefits of applications as we
have discussed, i.e. class sharing through classloader trees. Was that
your point?
> |> 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)
WHY!? If the chain is (left leaf, right root) Ca-Cb-Cc then there is no
need to redeploy b or c if a is deployed.
> In clear we cannot link to other EARS independent in runtime.
You have not motivated this. Or, you have tried to, but it is not clear
what the problem is (not to me at least).
> You need to
> instanciate different containers to share entities and our container really
> isn't built for that.
>
> Do you understand this point?
Nope. I don't see the problem.
We are talking about class sharing here, right? I.e. c has a class Foo,
and a has c as parent (maybe with Cb in between, but anyway) and thus
Ca.loadClass(Foo) should return the class Cc.Foo. This is no problem.
> |> 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!!!!!!!!!
Yes.
> no way... that is totally linked to the CL delegation model!!!!
Exactly. I am specifying the classloader tree.
> LOL you made my morning
Because..??
> |> 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?...
Yes. The classloader tree needs to be explicit as it cannot be inferred
from any other info in the applications.
> 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 are talking poo poo my friend.
Look, if you want classloader sharing -> need classloader tree -> need
to specify what that three looks like -> use XML as a notation.
If you DON'T want classloader sharing, fine, don't do anything, it will
work anyway but with parameter copying.
> |> 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 ...
"Flat CL"? That's a new term I think. Can you please define it.
> |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?
All of your "reasoning" on the subject makes me think that. You think
there is a problem where there is none.
> |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????
Yes.
> rickard, back to the drawing board...
No, you're just missing what the goal is here.
Let me state it in clear. The goal is:
Instead of having one large EAR with the application, we want to be able
to have several EAR's which logically combine into one application. This
means that we have to be able to specify which EAR files make up that
logical unit, or else we cannot resolve ejb-link's in ejb-ref's. Also,
while it would be possible for each EAR in the application to have
separate classloaders (parameter copying on all calls would be the
result) we want to allow classloader sharing between the EAR's in the
logical application so that there are no duplicates of classes hence
allowing pass-by-reference calls within the application.
This is the goal. Somehow it seems that this is not what you are talking
about, because you think there's a problem in designing/implementing the
above, where in fact there is no problem with the above given that we
can specify the logical applications structure through XML.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
