Just out of curiosity, what's the real concern here? Load on the server due
to redeployment of a large application or application downtime. If the real
concern is application downtime, it may be possible to create a new jndi
namespace and deploy the new version to that namespace. Old clients would
continue to hit the old version while any new connections would be handled
by the new. I put some thought into hot redeployment a while back (though
admitedly, I didn't delve too deeply) and it struck me then that there's
about a billion things that can go wrong when attempting to juggle
classloaders. Not that namespace-switching is trivial; there's still quite
a bit that must be worked out, but just a little food for thought...
Mike
----- Original Message -----
From: "marc fleury" <[EMAIL PROTECTED]>
To: "jBoss Developer" <[EMAIL PROTECTED]>
Sent: Thursday, December 21, 2000 11:25 AM
Subject: RE: [jBoss-Dev] The Dumbo problem (Big EARs)
> |> 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]
> |
> |
>
