geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@coredevelopers.net>
Subject Re: DeploymentPlanner - Base class
Date Tue, 04 Nov 2003 17:00:11 GMT
On Tuesday, November 4, 2003, at 07:34 AM, Aaron Mulder 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.

>  I guess
> one of the questions to answer on that score is whether we could put 
> the
> status as a property in the ObjectName and change it as the module is
> started, stopped, etc.  If so, then it's almost a no-brainer to do it 
> that
> way.  If not, then it would be more work to pull out the right subset 
> of
> deployed modules.

That won't work.  Dependencies are static and so are notification 
listeners, so when every you changed states you would have to 
reestablish all dependencies and any listener would have to reregister.

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

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

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

-dain

Mime
View raw message