I keep reading these emails even though I understand little of what's going
on other than the big problem in terms of reloading everything. Can't you
build a new class loader which uses a different model in order to avoid the
URL-CL that's forcing you into this parent child relationship which is so
brittle?
Happy Holidays
Jay Walters
-----Original Message-----
From: marc fleury [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 22, 2000 11:46 AM
To: jBoss Developer
Subject: RE: [jBoss-Dev] The Dumbo problem (Big EARs)
|> 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.
that you can't re-use Cb or Cc in second position because you only set the
parent at construction time. PERIOD. You have to deploy everyone at the
same time.
|> 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?
That comes later :)
|> |> 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...
Rickard ... this IS my point exactly, are you repeating my mail?. You
cannot deploy independently because of delegation and the setParent "one by
one" pattern.
So with your solution you have to DEPLOY EVERYONE except the last one
because you need to set "setParent" ... woohoo you saved yourself ONE
deployment (the last element).
mucho pain... where is the gain?
|>
|> 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.
Please rickard read my mails... at deployment time you need to stop other
running beans to deploy new ones...
|> In clear we cannot link to other EARS independent in runtime.
is this sentence clear now?
|> 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.
well the problem is that if you don't stop the running beans then you get a
copy of the entity pointing to the same records potentially and the entity
synchronization is not built for many beans copy ...
We didn't build our container for this solution either Rickard...... this is
SERIOUS container synchronization where you need 2 containers representing
the same entity and you need to sync the caches and the lock and bla bla
bla...
|We are talking about class sharing here, right? I.e. Cc 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.
|
|> 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..??
because there's got to be a better way than to require that our users
understand hardcoded parent by parent delegation model of CL... let's get a
raise of hands, who here clearly has disconnected from this discussion like
a week ago???
Should tell you something about simplicity...
Rickard all this construction is based on the "parent by parent and at
construction time" delegation model of the URL-CL... i.e. it's base is weak.
|Yes. The classloader tree needs to be explicit as it cannot be inferred
|from any other info in the applications.
the *dependency* might need to be explicit the "CLASSLOADER TREE" CERTAINLY
NOT.
|Look, if you want classloader sharing -> need classloader tree
That's an assumption my friend, based on the usage you make of parent by
parent delegation model...
|If you DON'T want classloader sharing, fine, don't do anything, it will
|work anyway but with parameter copying.
yes we agree on that... no problem -> no need for a solution
marc
