-----Urspr�ngliche Nachricht-----
>Von: Rickard �berg [mailto:[EMAIL PROTECTED]]
>Gesendet: Dienstag, 19. Dezember 2000 09:47
>An: jBoss Developer
>Betreff: Re: AW: [jBoss-Dev] Complex J2EE Deployment was RE:
>Proposedrefactor ing ...
>As in earlier posts, I propose that the metadata object is sent around
>instead, and that the CL is a part of that metadata. You would have a
>much more powerful way to do things that way.
this listserver really sucks. My posts have been reordered. My "first" mail
that was
totally agreeing with this idea was indeed my second one that followed the
posting
that wasn�t yet enlighted. I�m sorry.
>Yes those are key. And I think both almost rely on the ability to send
>the metadata around so that two leaves in the deployment tree can see
>each other (just sending the classloader would not give us that).
right.
>But if the parent is not deployed you can't deploy the child, since you
>don't have the URL to the parent.
>All of this would be simpler if the SystemDeployer is introduced, which
>has knowledge of the system as a whole.
>Then you would do:
>1) Deploy System - This will cause the entire thing to be started. This
>is the init/start phase
>2) Whenever you want to update *a part* of the System, you call
>SystemDeployer.redeploy(appname). The SD knows what URL the appname
>refers to, and determines the dependency chain (with respect to other
>applications), and correctly undeploy and deploy the applications (=the
>desired one plus all dependent apps) in the right order (which is
>trivial since we have all the info we need).
Ok, up to now, I was thinking of relating the application parts of the
"logical system" via
relative urls just as Class-Path does: if an app a has url
<someAbsoluteprefix>/a.jar then you would identify its referenced parent
<someRelativePrefix>/b.jar as
canonicalize(<someAbsolutePrefix>/<someRelativePrefix>/b.jar) ...
The problem that I see with a (that�s how I understood your approach)
statically and globally specified system.xml is that someone must have the
total
overview over the complete complex thing before the system is deployed! I�m
more in favour to let the system.xml emerge from the individual annotations
in the relevant jars. This allows us, e.g., to dynamically add new
functionality/component/application to the logical federation at runtime.
I dont see your following points being violated by such an approach. IMHO
they are valid for both approaches provided we agree on the
MetaData/ClassLoader thingy (which we did):
>* Minimal changes to J2EEDeployer. SystemDeployer only needs "deploy"
>and "undeploy" methods to do its work!
>* Clear chain of responsibility. J2EEDeployer doesn't do more than what
>it's supposed to do (=deploy applications).
>..etc..
hmm, looks like code is still not on the stage ...
Best,
CGJ
