geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "gianny DAMOUR" <>
Subject Re: DeploymentPlanner - Base class
Date Tue, 04 Nov 2003 22:30:17 GMT
Dain Sundstrom wrote:
>>	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.
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:

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 
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 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.
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.

>>>As I said, "registered" files are tracked. More accurately, a scanner 
>>>these files and upon modification executes a command. By now, two files 
>>>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 
>>>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
>>>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.

>>>At the end of the day, I believe that DeploymentController should not be 
>>>entry point to action a start, stop, redeployment or undeployment. Why?
>>>Because one knows, which planner has mounted a deployment and hence one 
>>>bypass DeploymentController.
>You are assuming that only one planner was involved in the deployment.  
>What about ear and other meta deployments.
My idea is that a ear containing say a rar and 2 war will be represented by 
the following deployment-units:
- 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.

>>>BTW, I tried to refactor ServiceDeploymentPlanner and this is not so 
>>>ServiceDeploymentPlanner is a kernel service. if one wants to align it 
>>>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 
>>>to re-package the Container, Component, AbstractManagedComponent et 
>Why is ServiceDeploymentPlanner a Container now?  I dislike the idea of 
>pulling this stuff into kernel unless it is absolutely necessary.
I agree. I assume that ServiceDeploymentPlanner is a container because it 
contains the mounted services.


Hotmail : un compte GRATUIT qui vous suit partout et tout le temps !

View raw message