geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: Geronimo-358: Remote Deployment
Date Sat, 23 Oct 2004 18:54:53 GMT
	So David J, Jeremy, and I talked a bit on IRC.  David J didn't 
like the idea of splitting protocols -- JMX remoting for sending commands 
but a servlet for streaming files.  We briefly talked about trying to take 
advantage of the protocols underlying ActiveMQ or JMX Remoting, but we 
know little about that.

	Jeremy has done a substantial amount of work on a servlet-only 
protocol for a remote JSR-88 client to use, and will try to have something 
ready to work with in a week or so.


On Sat, 23 Oct 2004, Jeremy Boynes wrote:
> 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

View raw message