Rickard, christoph, Toby...
unifying with the "Complex J2EE deployment" I believe we are all seeing the
need for a "application manager".
See there would be 3 layers
1 Deployer (client GUI Logic)
2 ApplicationManager (the logic for "decision to redeploy" how and what CL)
3 DeployerMBeanSupport [] (many, the services that toby sees as equals from
a deployment standpoint)
all 3 are mbeans. The 3rd ones specify .jar .ear .war or .jcx as their
"type" of file to deploy in the MLET structure.
In fact the only thing I don't like about JMX'in it is that we would strand
teh deployment to one machine (local) the "Deployer" (1) is the one that can
be remote (like today in 8082)
At any rate there would need to be some "federation" of the layer 2... in
the future...
for now let's keep it very simple and the refactoring of the current
J2EEDeployer (a good first try, but a minor catastrophy in its own right)
needs to be.
Sebastien sits on JSR88 (deployment) and said they are stuck at the "how do
you deploy stubs" level... it takes time for them to see the "Dynamic Proxy"
light. So we do have some time :)
The novelty in this proposal is the clear "application" that lives post
deployment. Nothing exists in the J2EE spec to manage or even talk about an
application post "packaging and deployment". That persistent
representation is just not existent in the spec today
marc
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury
|Sent: Sunday, December 10, 2000 11:50 PM
|To: jBoss Developer
|Subject: RE: [jBoss-Dev] Proposed refactoring of ContainerFactory-Ch
|ainingDeployment services in general
|
|
||marc fleury wrote:
||> |extend ServiceMBean with these methods and call it DeployerMBean? Why
||> |not create an abstract implementation of this called
||> |DeployerMBeanSupport that converts the strings to URLs and keeps tracks
||> |of which URLs have been deployed? Doing this would make life easier for
||> |people wanting to add deployers for different kinds of modules (such as
||> |resource adapters).
||>
||> Ok so a specific "deployment aware" service would register with the
||> "DeployerMBeanSupport" and upon deployment you call everyone?
||
||No, I think he meant make a subclass of ServiceMBeanSupport, and have
||deployment service subclass it to ensure that they implement the
||"deployment interface" and also get a default impl. for it.
|
|Ok yes, that is what he meant by "DeployerMBeanSupport" as the basic
|interface for Services that are "DeploymentAware".
|
|So I can be more precise and say that we would register the
|"DeployerMBeanSupport" MBeans with a new J2EE Deployer.
|
|Today we need ad-hoc "Deployers" (as in J2EE Deployer) that takes a
|JSP/Servlet and the EJB stack. Now that we have a generic interface we
|could stack them up in our generalized J2EE Deployer, the only problem that
|remains is "what type of file do you take"... and that would need to be
|specified in the MBean (getExtensionType()) so we could configure it with
|the new jcml files :)
|
|he he
|
|
|marc
|
||
||/Rickard
||
||--
||Rickard �berg
||
||Email: [EMAIL PROTECTED]
||
||
|
|
|
