Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <417A981C.6020906@gluecode.com>
Date: Sat, 23 Oct 2004 10:42:52 -0700
From: Jeremy Boynes <jboynes@gluecode.com>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: Geronimo-358: Remote Deployment
References: <Pine.LNX.4.58.0410222203100.4869@saturn.opentools.org>
In-Reply-To: <Pine.LNX.4.58.0410222203100.4869@saturn.opentools.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I think we need to be careful here to avoid overloading JSR-88.

The problem with JSR-88 is that is requires a running server to to 
anything useful; the restrictions on the client environment prevent you 
doing any work in the provider itself.

On the other hand, we need a standalone deployer that can work without 
booting the server.

If the server is running we already have a JSR-88 provider which can use 
it. It talks at a low level to the server (JMX remoting) so that you can 
use it to redeploy higher level components such as the web container. 
The downside is that the module must be local (as sending jar files by 
value over RMI seemed like a bad idea).

I think the servlet approach is the way to go for transport and I 
already have a start on stuff for that.

We have already been down the path of multiple DM implementations (or 
multiple backends to a DM decorator) and that did not prove very effective.

Current thinking is:
* (existing) standalone deployer that boots the deployment config
   in memory and handles all module types (J2EE and non-J2EE)

* (existing) in-server deployer that handles all module types from
   local storage and which is exposed over JMX-remoting

* (existing) JSR-88 provider which proxies calls to the
   in-server deployer for same-server deployment of J2EE modules

* (new) JSR-88 provider that works in conjuction with a servlet to
    remotely deploy J2EE modules; it should be able to spool the
    archive to the ConfigurationStore and work in-situ

* (existing) maven plugin for JSR-88 deployment

* (new) ant plugin for JSR-88 deployment

* (new) command line tool for JSR-88 deployment; could be a standalone
   tool but making it an extension of the current standalone deployer
   seems friendlier to users (as there is just one command-line tool)

I think there is a lot of overlap here with what you propose and suggest 
we discuss futher before you get too far coding.

--
Jeremy

PS I don't hink the tool should discover the server by magic - if you 
are going to connect to one then you should specify URL, username and 
password on the command line (or in some way anyway)

Aaron Mulder wrote:
> 	I'm looking at the issue to enable remote deployment.  In order to 
> do that, I'd like to use JSR-88.  That means we need a remote JSR-88 
> client.  I'm thinking of something like this:
> 
> 1) split the command-line processing off from the Deployer GBean.  Change 
> the CLI implementation so that it reads the command-line input, 
> instantiates a JSR-88 connection, and executes deployment commands using 
> that.  That should open up lots of new CLI functions (hot deploy, 
> undeploy, etc.) while removing the CLI code from the server component.
> 
> 2) Create a new GBean to run in the server and be the contact point for 
> the remote JSR-88 client.  It will be a thin wrapper around the current 
> JMXDeploymentManager (which only works locally right now).  The main 
> change is that it has to expose remote-able ProgressObjects.  (Back in the 
> day, we were using JMX notifications for this; I'm not sure if that's 
> still the way to go.)  It will also probably delete file operands after it 
> has operated on them (see step 4).
> 
> 3) Create a servlet that can receive streamed deployment files (archives 
> and deployment plans).  It will just save them to a temp dir, perhaps 
> under var/staging or something.  This means we'll have to have a web 
> container running at all times, but that seems to be the case anyway.
> 
> 4) Create a new DeploymentManager implementation that speaks to the
> servlet and the GBean from steps 2 and 3.  It will generally speak to the
> server via JMX to the GBean, except that any time it has to send a file it
> will send it through the servlet, get the temp file name back, and then
> make a JMX call to the GBean with the temp file names (and the GBean will 
> delete the temp file when it's done).  We also need to figure out whether 
> for ProgressObjects it should listen for JMX notifications or send over 
> an RMI Remote object to be registered as a normal listener on the server 
> side.
> 
> 5) Create a new DeploymentManager implementation that operates locally 
> only and assumes the server is not running.  It will allow distribute or 
> undeploy but not start,  stop, etc.  To do those things, it will start a 
> kernel with a Deployer when the DeploymentManager is started and stop it 
> when the DeploymentManager is disconnected.  This would be more or less
> like the current deployer.jar works.
> 
> 6) Modify the DeploymentFactoryImpl so it can handle different connection 
> URLs depending on whether it should be used locally or remotely, and 
> whether the server is running.  The cases would be:
>  - Local, server running: Use current JMX-DM
>  - Local, server not running: Use new server-not-running DM impl
>  - Remote, server running: Use new remote DM implementation
>  - Remote, server not running: fail
> 
> 7) Modify the deployer client to detect whether the server is running, and 
> use the appropriate URL to connect to JSR-88 or fail based on the cases 
> above.
> 
> 	I can see an alternative of trying to adjust the current 
> JMXDeploymentManager to handle local and remote connections, and putting 
> the server running/not running logic outside of that so the deployer 
> client would first start server components and then invoke JSR-88 as if 
> the server had been running all along.  But that means that only our tool 
> would be able to operate on a local server when it wasn't running (instead 
> of exposing it to other JSR-88 clients).  It would also make the 
> JMXDeploymentManager kind of ugly, though I supposed we'd just change that 
> to use local and remote plugins of some sort under the covers.  Anyway, it 
> doesn't seem as good as just creating several distinct DM implementations.
> 
> Aaron