Grrrrrrrr. And I really mean it: I sent a memo "JSR77 -> JSR88" on Thu, 09 Oct 2003 14:02:15 +0200 proposing this idea. Excerpt of this pattern:I thought we were going to use the JMX ObjectNames to identify deployments, rather than keeping an actual repository somewhere?
That is what I thought. We can easily find all deployments with an ObjectName pattern query.
[...] ApplicationDeployer needs to be notified in order to track the state (running, stopped), the type (EJB, WAR, EAR et cetera) and various other pieces of information.
Multiple solutions could be implemented in order to "sync" the JSR77 and JSR88 models.
And this is a possible one only based on naming conventions:
...
This way, ApplicationDeployer "just" have to query the MBeanServer to
retrieve the running ModuleType.WAR modules.
[...]
It is rather clear that I wanted to use naming conventions to identify deployments and their states.
Excerpt of a response to this idea from Aaron:
[...]
While naming conventions are convenient, I don't want to rely on that for basic
operational requirements.
[...]
As a conclusion, I have duplicated the deployment repository and I am implementing what is required to identify the running or available deployments w/o having to poll the MBenServer.
I also agree. So let me re-phrase: I will write a task to bulk transfer a file from a remote host. This task will use under the cover WebDAV. My point regarding the "server push" vs. "client push" idea is that it is up to the server to mount a WebDAV fie system and not the client to do so.I disagree with your assertion that the server should pull code on a distribute -- among other things, that assumes that the server can freely contact that client, which I don't think is necessarily true, or a good idea. However I do agree that the distribute call shouldn't block -- I asked earlier if there was a way to stream data to the server over JMX and got no answer, so I think we need to set up a standard servlet to receive the data or something.
Agree. We need some sort of bulk file transfer system. I think we should really look at using WebDav for this.
As I said, "registered" files are tracked. More accurately, a scanner checks
these files and upon modification executes a command. By now, two files are
automatically created in order to trigger either the redeployment or the
undeployment of a deployment. For instance, when an archive module �
archive.jar in the example - is deployed, the following files are created,
if required:
archive.jar_REDEPLOY: if one "touch"es this file, then the deployment is
redeployed; and
archive.jar_UNDEPLOY: if one "touch"es this file, then the deployment is
undeployed.
These two files are here only as a development convenience.
-1 I really dislike this idea. The biggest problem is this code assumes that it can write to the hot deploy directory, but the real reason I dislike it is it removes the normal file semantics we are all use to. If you want to redeploy, you simply touch the main deployment file, and if you want to undeploy, you remove the file.
OK. This is really a minor update and I will fix this.
My idea is that a ear containing say a rar and 2 war will be represented by the following deployment-units:At the end of the day, I believe that DeploymentController should not be the
entry point to action a start, stop, redeployment or undeployment. Why?
Because one knows, which planner has mounted a deployment and hence one can
bypass DeploymentController.
You are assuming that only one planner was involved in the deployment. What about ear and other meta deployments.
- one ear deployment unit;
- one rar deployment unit; and
- 2 war deployment units.
When I write deployment unit, I mean a deployment meta-data repository. The rar and war units are children of the ear one. When an ear is deployed, a ear planner mount the ear unit. This planner then calls the relevant planners for the rar and war units. These planners create units, which are children of the ear unit. When a start action is triggered, the ear unit requests to the ear planner to perform its job. Then all the children units are started. For instance, it means that a start action is triggered on the rar unit, which requests to its planner to perform its job.
I agree. I assume that ServiceDeploymentPlanner is a container because it contains the mounted services.BTW, I tried to refactor ServiceDeploymentPlanner and this is not so simple:
ServiceDeploymentPlanner is a kernel service. if one wants to align it with
the proposed approach, then one must re-package a lot of classes from the
core sub-project to the kernel sub-project. For instance, as the proposed
approach defines a class which extends AbstractManagedContainer, one needs
to re-package the Container, Component, AbstractManagedComponent et cetera
classes.
Why is ServiceDeploymentPlanner a Container now? I dislike the idea of pulling this stuff into kernel unless it is absolutely necessary.
Thanks, Gianny
_________________________________________________________________
Hotmail : un compte GRATUIT qui vous suit partout et tout le temps ! http://g.msn.fr/FR1000/9493
