Hi!
marc fleury wrote:
> |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.
I have replied to this enough times now. You have a too restricted view
about what metadata is.
Now is the time to be practical, and not have pointless preconceptions
about what a metadata structure is. Please.
> |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" :)
Depends on your definition of a system.
What is your definition of System?
What is your definition of Application?
> The system as in JMX server is
> outside this scope,
What does the JMX server have to do with anything!?!?? *sigh* This is
getting ridiculous...
> the application as a collection of modules is the
In my terminology that would be "system as a collection of
applications". Same thing AFAICT.
> **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.
No it is not. Why do you want to externalize the metadata? When is that
useful?
> |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?
At every JBoss JVM start, yes. When the system (=set of EAR's) is
running you only redeploy nodes in the systemm, or add/remove nodes from
the system.
> |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 :)
SystemDeployer==Application Manager
> |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
The one inch you have to move sooner or later is to remove the thought
that the metadata structure needs to be externalizable. It does not (we
never do that anyway) so there's absolutely no problem with adding
runtime data such as classloaders to it.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
