geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Geronimo-358: Remote Deployment
Date Sat, 23 Oct 2004 02:52:03 GMT
	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

Mime
View raw message