|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.
no, rickard, again the metadata object as a mirror of XML tree information
is a traveller an "externalizable" object (in the java sense). The CL
information isn't.
If you don't travel with the MetaData then this is pure "repackage-itis".
|> that we a) have an automatic redeployment feature for "logical"
|applications
|> as you coined it and b) allow ejb-refs to work throughout those logical
|> applications.
|
|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).
Which is why I think the XML proposal from JUNG is superior, you talk about
modules and you pass CL or you query it through the service.
|All of this would be simpler if the SystemDeployer is introduced, which
|has knowledge of the system as a whole.
The more I hear you talk of the SystemDeployer, the more I understand you
really want to say "APplicationDeployer" :) The system as in JMX server is
outside this scope, the application as a collection of modules is the
**only** one that needs that persistent representation of dependencies post
deployment. IN fact the metadata as a tree projection is a poor place to do
it, it is meant as a externalizable object. So let's keep it simple and let
the APplicationDeployer deal with Applications Deployment. The only place we
see the system is at the root of the runtime **classloader** line. (as in
leaf.getParent().getParent()..)
|
|Then you would do:
|1) Deploy System - This will cause the entire thing to be started. This
|is the init/start phase
<snore> **application** </snore>
you want to restart the system everytime?
|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).
right this is the Application Manager we want to write. (all this noise to
essentially say what we were saying 3 days ago :)
|This would have the following benefits:
|* 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..
|
|Sounds ok?
LOL, yes it does kid yes it does.... LOL
PLGC, I love it when you repackage like that :) I am still not one inch
further than I was yesterday... but I did have some fun :)
marc
|
|/Rickard
|
|--
|Rickard �berg
|
|Email: [EMAIL PROTECTED]
|
|
