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