Aaron Mulder wrote:
Just to reiterate, I think Jeremy is saying that using the deployer tool for offline install is limited because it doesn't know what GBeans the server is using for the ConfigStore and PersistentConfigList and so on. If we instead actually start the server to do an "offline" deployment/installation, then all the corrct GBeans will be running and that is no longer an issue.
An alternative would be for the deployer to inspect the server's configuration when it starts, and load every dependency from the immediate parent of the module to be deployed up through the "root", and that should identify the correct ConfigStore and PersistentConfigList.
But this is tricky too, since how would it know what ConfigStore to load the configurations out of (including the configuration for the ConfigStore, aargh!). In the end, I suspect this depends on how server.jar was packaged, and if you plan to start your server with start-my-server.jar instead of server.jar then I don't know how the deployer would know that, so I don't know where it would get the original ConfigStore reference from -- perhaps we'd need to give it an option to identify your server startup JAR. But I think this would still fail if the server was running (since you'd probably clash for ports trying to load some of the services between ConfigStore and application), so it's an "offline" deploy in name only.
Another option is that we can provide a tool that works 100% for
the default server configuration (LocalConfigStore+FileConfigurationList). But it would not work in the face of customizations to the 2 core
components: if you swap out your LocalConfigStore, then the tool would not
work (it would install into the wrong place), and if you swap out your
PersistentConfigurationList then the tool would be unable to mark any
module to be started. If we wanted to, we could make offline deploy tools available for different combinations of those GBeans, or give you a procedure to build a new deploy tool from an old one.
The main reason I feel that this is important is that most other
products support it. Generally if you copy a new EAR over an old one
while the server is not running, and then start the server, the new
version of the EAR will deploy on startup. (Tomcat 5 in the one I can
think of that doesn't do this). I just hate to tell people that things that used to work won't work any more if they move to Geronimo. On the other hand, I think this behavior was mostly implemented via a hot deploy directory, so if we provide a GBean for a hot deploy directory, then maybe we don't need a offline deploy tool at all (beyond for building the server).
And I guess the last issue is related. In the long run, it will be nice/necessary to have some kind of packaged-configuration-handling features, in the deploy tool or another tool: - extract a CAR file from an entry in a server's ConfigStore - sign a CAR file (either in the server's ConfigStore or as a file) - transfer a packaged configuration directly from one server to another - deploy a CAR file into a server
Aaron
On Sat, 6 Nov 2004, 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/[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.
I spent part of last night and part of this morning re-reading all of this info to better understand the dilemma over the deploy tool. After reading these two messages a couple times I feel like I understand the issues at hand far better than when I cast my vote.
I'm sure that others will find themselves with the same quandary I currently have, whereby upon further education of the issues surrounding the deployment tool, I wish I could recast my vote. If others do, in fact, have the same sentiment, then I propose that the deploy tool vote be recalled and we start a fresh vote on the same topic, or, I just change my vote. Does anyone else feel this way?
Bruce
--
perl -e 'print unpack("u30","<0G)[EMAIL PROTECTED]&5R\\"F9E<G)E=\\$\\!F<FEI+F-O;0\\`\\`");'
The Castor Project http://www.castor.org/
Apache Geronimo http://geronimo.apache.org/
