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
