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

Reply via email to