I apologize for not entering this discussion earlier, but I didn't have time to think through the issues thoroughly. I have thought all along that offline "deployment" was a bad idea and should not be used outside very restricted bootstrap scenarios. I would prefer our assembly to proceed by starting a server as soon as possible and using the maven plugin to distribute the modules to that running server.
I don't think "drop, wait & wonder" hot deployment should be supported. This only supports deployment of applications with embedded plans or applications that need no plan. I think there are almost no useful applications that will work without a plan to at least resolve resource-refs. I would prefer we put more effort into tools that help identify the minimum amount of information needed for a plan and generate the plan, and then deploy to a running server.
To me, making sure the online deployment/undeployment cycle is really reliable even in the face of multiple deployment errors and long chains of parent configurations that are not previously started is a much better idea than supporting any offline deployment.
thanks david jencks
On Nov 6, 2004, at 9:51 PM, Jeremy Boynes wrote:
As promised Thursday, here are the details of my concerns about mixing offline and online deployment.
My concerns on this issue stem from how we package GBeans together for use by the kernel. Rather than handling them one-by-one, Geronimo uses the notion of a pre-canned Configuration which contains a number of GBean instances and the classpath information needed to load them. Configurations can be loaded by the kernel and when started bring all the GBeans they contain online together.
A key feature of Configurations is they are portable between different
Geronimo installations - specifically a Configuration can run in any
Geronimo kernel that can resolve its dependencies. This is less critical
for the single-server mode we have now but is very important as Geronimo
scales to clustered or grid configurations - it allows us to efficiently
move applications between the servers on demand.
This also has benefits where change management is important, such as
business critical installations. For example, a Configuration can be
built and signed in a test or integration environment and moved
*provably unchanged* though the test, stage and release to production
process. Alternatively, an OEM can release an application to channel as
a signed Configuration, end-users can have the assurance it has not been
tampered with, and the OEM can reduce costs by reducing problems caused
by variations in the end-user environment.
In the kernel, the process of loading and unloading Configuration is
handled by a ConfigurationManager that uses ConfigurationStores to store
them. The store exposes a simple API for installing and uninstalling
Configurations and for retrieving them so they can be loaded. We have a
simple LocalConfigStore implementation that uses the local filesystem to
store them; other implementations are possible using different
persistence approaches such as databases, LDAP or proprietary
configuration management systems.
The deployment system in Geronimo is the interface between user-domain artifacts such as J2EE modules (EARs, WARs, etc.) or deployment plans and the configuration management system described above. It essentially combines modules with plans and generates Configurations.
It comprises three parts: * External interfaces such as the command line tool, console or JSR-88 provider that get the modules and plans from the user * ConfigurationBuilders such as EARConfigBuilder and ServiceConfigBuilder that do the combination and produce the target Configuration * Back-end interfaces that store the Configuration either in a ConfigurationStore or as an output file
The ConfigurationBuilders are GBeans and run inside a Geronimo kernel.
Apart from ease of implementation, they also have access to the
resources provided by that system - for example, they can use the
Repository to load classes during processing, and they can use the
ConfigurationManager to load other Configurations that the target may be
dependent on.
To support online deployment, we run a deployment system inside the same
kernel as the J2EE server - it is actually part of the
org/apache/geronimo/Server Configuration although work is progress to
allow it to be run as a separate dependent configuation.
The JSR-88 provider interacts with this deployment system to fulfill the
spec requirements for distribute, start, stop, undeploy etc. For
example, during a distribute operation the module and plan are passed to
the deployment system, it uses an EARConfigBuilder to produce the output
Configuration, which it then installs in the target ConfigurationStore.
A JSR-88 start operation causes the Configuration to be loaded from the
store and then started.
However, this leaves us with a chicken-and-egg problem. The online deployment system above is itself part of a configuration - how do we build that configuation?
To solve this, and because it seemed generally useful, we built a
standalone offline deployment system. Run from the command line, this
would take module + plan and produce a Configuration. To reuse as much of the configuration building infrastructure as possible, it boots an
embedded Geronimo kernel and loads a Configuration containing just the
deployment system. As a running kernel, it also provides access to a
Repository and ConfigurationStore that the ConfigurationBuilders can use
to resolve dependencies (including dependencies on other
Configurations). However, these are *its* Repository and
ConfigurationStores and *not* those from the target server.
To cheat our way around the chicken-and-egg problem we took the simple
but expedient solution of having the standalone deployer and the default
server use the same type and location of store and repository. Then, by
simply telling the standalone deployer to install a configuration into
its own store it would also be available to the default server
configuration. This is a hack, pure, simple and effective.
When we introduce any additional complexity into the situation, then
this hack starts to break down. For example, if the user adds a
database-based ConfigurationStore to the server (for example, to make
GBean state persistence more reliable) then the standalone deployer
would not be able to install the generated Configuration into that store.
All things considered, I think having options in the standalone deployer
that rely on it sharing the same type and location of Repository and
ConfigurationStore will lead to obscure behaviour and strange behaviour
as soon as we progress beyond the most basic default configuration. That
is why I voted at the start for "2 simple tools rather than one complex
one." Going further as has been proposed and coupling the standalone
deployer to the internal implementation of the
PersistentConfigurationList seems like pouring gasoline on the fire.
I have been portrayed on this list as being alone in my opinion but I
will point out that in the initial vote Eric LeGoff, Aaron Mulder and
David Jencks also voted for 2 tools (as opposed to Peter Lynch, Davanum
Srinivas, Hiram Chirino and Bruce Snyder who voted for one); Dain
Sundstrom voted for one tool, but wanted another to support the
functionality we have to output Configurations as jars ("that is another
tool for another day" but we need it now to build the server) which
sounds like two tools to me.
After that vote, Aaron proposed and attained consensus for a single tool. The syntax is simple enough and mirrors the JSR-88 API making it ideal for online deployment (which is all JSR-88 supports).
However, during implementation Aaron ran into the issues described above
and on the thread from 11/4/04 when trying to support the offline mode
not covered by JSR-88. These are clearly technical issues which we need
to resolve. To facilitate that, Aaron proposed to commit his work so
that all could see and discuss; he and I were promptly and unjustifiably
flamed by some members of the community.
Since Thursday he has committed this code and I think we need to review where we are. My belief is that the online side is fully implemented, that the standalone deployer works as before (package option), and the big remaining issue is the one described above where someone is trying to "deploy" applications to an offline server.
In this message
http://nagoya.apache.org/eyebrowse/ReadMsg? [EMAIL PROTECTED]&msgNo=9696
I wrote that you could distribute to your heart's content; this was wrong. The discussion with Aaron highlighted that the problem about store type and location applies to distribute as well as the other operations. It looks like the only thing you can reliably do offline is package a Configuration for later use.
I would suggest then, rather than the --add option I proposed for the server we instead have a --install option which boots the server, restarts all previously running configs and installs the new one. The offline usage would then be:
java -jar deployer.jar package foo.war foo-plan.xml foo.car java -jar server.jar --install foo.car
This also provides a simple mechanism for deploying once and running everywhere: the output configuration can be installed in multiple places as easily as one.
The issue with this is that it fits the admin's view better than the developer's. However, I continue to believe the:
start server repeat write code build (with distribute/start to online server) test until app works or it's time to go home
cycle is what most developers use and that Aaron's changes (in conjunction with the existing Maven plugin) have made it easy for them to work that way. They are not really interested in fancy offline deployment tricks.
To support carrier-grade configuration management, clustered and grid environments and OEMs, I believe we need an effective way of generating pre-packaged configurations using requires Maven/Ant plugins that can be used in the release process, tools like Aaron's that an administrator can use from the command line, and mechanisms for installing them in and for transporting them between between servers.
I think we are very close to achieving this and if we can address these last issues then Geronimo will be acceptable to both the developer community and to serious IT decision makers.
-- Jeremy
