Quick summary of a conversation between dblevins and I on deployment...
Although the infrastructure is there, we currently don't support hot deployment as there is no way of notifying the kernel to install/load a new Configuration.
We currently do cold deployment by pointing the deployer and the server at the same ConfigurationStore - this works, but is not very safe as the store does not support concurrent access. To avoid that, you need to stop the server to do deployment.
To allow hot deployment, there are a few options: 1) Use MBean remoting to invoke the appropriate GBeans in a running server to cause it to install and load a new configuration. This should be trival if MBean remoting works.
2) Provide a servlet that allows a CAR to be posted to the server and which uses the GBeans locally to install/load the new config. This is firewall friendly but requires a web container
3) Use the JSR77 MEJB to invoke the GBeans. This would only require the EJB container and MEJB, but may eat memory as the CAR would need to be passed in a EJBInvocation.
4) A variant of 2 and 3 where the servlet receives the CAR in a POST and streams it to local disk, then uses the MEJB to install it. Avoids having to talk raw JMX but other than that seems clunky.
5) Allow deployer and server to have concurrent access to a config store and send the commands over JMX Remoting, HTTP, EJB-RPC or whatever.
None of these are particularly hard to do - any preferences?
Irrespective of which of these we pick, the only change to the deployer seems to be an additional --distribute option that takes the URL of the target server e.g.
java -jar deployer.jar
--distribute http://server/installer
--module app.ear
--plan plan.xmlor the equivalent ant/maven task.
Can someone give us a quick update on where JMX Remoting is with the new network transport (not RMI) ?
-- Jeremy
