Revisiting the # of deployer tools

[Aaron Mulder <am...@alumni.princeton.edu>]

	Any more thoughts on one versus (multiple) deploy tools?  It looks
like we have a strategy for an offline deployer, that involves starting
"enough of the server" to do the deployment.  Presumably, this could be
made to work with most of the deploy commands (start/stop/etc.), since
"enough" of the server should be loaded to handle them.

	So the offline mode of a deploy tool would need substantial 
additional initialization logic.  It could probably run similarly to the 
online deploy tool thereafter (using JSR-88) or it could talk directly to 
the deploy services in the partially running server that it started.  So I 
think we have four separate classes of functionality that we've talked 
about:

1) Online JSR-88
  start, stop, distribute, "deploy" (=distribute+start), undeploy,...

2) Offline (JSR-88 or direct-to-GBean)
  much initialization
  start, stop, distribute, deploy, undeploy, ...(implementation TBD)

3) Server Construction (not JSR-88)
  bootstrap deploy tool
  build executable JAR (CAR file plus special settings)

4) CAR file manipulation (not all JSR-88)
  build CAR file from "source" (xAR + plan)
  export CAR file module in config store
  import CAR file from disk to config store

	The current deploy tool handles #1, #3, the first entry of #4, and 
the distribute command of #2 (though only for simple cases).

	Personally, I think putting all four classes of functions into a
single tool makes the implementation plus the syntax very unwieldy, and we
run into problems for things like trying to build a server while a server
is already running.  I would be happy to make classes 1, 2, and 4 each
separate tools.  Class 3 bootstrapping is handled by the bootstrap class,
and class 3 executable JAR building could be handled as a class 1 or 2
deploy plus a class 4 CAR export...

Aaron

On Tue, 16 Nov 2004, David Jencks wrote:
> I talked with Jeremy and Aaron more about this.  Our current idea, very 
> similar to one Dain proposed also, is something like this:
> 
> 
> 1. Each config-builder will be split into two parts: one that needs no 
> particular classes and recognizes whether it knows how to build a 
> module, and one that may need runtime classes and actually builds the 
> configuration for the module.
> 
> 2. The deployer system will include the "recognizer" parts of the 
> builders.  When it's asked to construct a configuration for something, 
> it will use its recognizers to find which builders are needed.  It will 
> load the chain of parent configurations (which is an entirely separate 
> chain of configurations) for the module it's working on, and then 
> construct a child configuration of that last parent config containing 
> the needed builders.  That dynamically constructed configuration will 
> actually build the configuration.
> 
> In this way the "statically deployed" part of the deployer system does 
> not need to include any runtime classes at all, yet any deployers can 
> be added.
> 
> The plan I presented below has several serious deficiencies and should 
> not be considered further.
> 
> If I understand our other conclusions correctly, we think the best 
> solution for an offline deployer that can leave newly deployed 
> applications so they will start when the server starts is for the 
> offline deployer to simply start enough of  server so it can use the 
> local config-store and access the list of started configurations 
> through the appropriate gbean interface.
> 
> thanks
> david jencks
> 
> On Nov 13, 2004, at 4:45 PM, David Jencks wrote:
> 
> > I talked with Dain a bit about this.  We now agree that attempting to 
> > have the deployment system not be a child of the runtime classes 
> > creates too many difficulties in writing deployer/builders.  I at 
> > least am happy to consider other opinions, but I'm satisfied that this 
> > is a reasonable requirement.
> >
> > I suggest that we have the following tree of 
> > configurations/classloaders:
> >
> > system (as at present)
> >      |
> > j2ee-server-classes (a configuration containing only dependencies and 
> > no gbean definitions: the dependencies are those needed for the j2ee 
> > runtime gbeans)
> >      |                                                                 
> >                                                      |
> > j2ee-server-gbeans(just gbean defs)                               
> > j2ee-deployer (dependencies on all builder jars and deployer gbeans)
> >
> > This way we only need only copy of the j2ee-server-classes, but the 
> > j2ee-deployer can be loaded only when required.  Furthermore, for the 
> > "offline" deployer, the j2ee-server-gbeans don't need to be loaded, 
> > althought their classes are available to the deployment system.
> >
> > Comments?
> >
> > thanks
> > david jencks
> >
> > On Nov 11, 2004, at 1:38 PM, David Jencks wrote:
> >
> >> I'd like to get the intended structure for the deployer/runtime 
> >> classloader/plan hierarchies out in the open and well documented and 
> >> agreed on.
> >>
> >> My understanding is that the desired architecture is to have two 
> >> independent classloader hierarchies, one for deployment and one for 
> >> runtime.  The deployer set should not need to include any runtime 
> >> classes: when you construct a configuration for some module, its 
> >> classloader will be a child of some other runtime configuration, and 
> >> any classes needed for deployment will be loaded from that other 
> >> configuration's classloader.
> >>
> >> This desired structure is most emphatically not present today:  the 
> >> j2ee-deployer-plan includes all the runtime classes and the 
> >> j2ee-server-plan includes all the deployer classes, plus as an added 
> >> "bonus", instances of the deployer gbeans.
> >>
> >> I believe that we have split out deployment specific code completely 
> >> enough so that we can divide the server-side hierarchy into two 
> >> plans:
> >>
> >> j2ee-server-plan would contain only runtime classes and gbeans
> >> j2ee-server-deployer-plan, a child of j2ee-server-plan, would contain 
> >> the xxx-builder classes and deployer gbeans.
> >>
> >> The j2ee-server-plan level would be free from, in particular, 
> >> xmlbeans code: AFAIK the only xml manipulation is in jetty, and that 
> >> might be made obsolete by GERONIMO-473. (hmmm. don't know about axis)
> >>
> >> However, I think the original goal was to have the builder modules 
> >> not actually directly use classes from the runtime modules, but allow 
> >> such classes to be loaded from the configuration's classloader only.  
> >> At the moment we cannot achieve this goal because there are several 
> >> classes that are used both in deployment and runtime.  In particular, 
> >> there is a POJO model in security and a few classes in connector.  I 
> >> believe that if we decided to approach the goal of completely 
> >> independent classloader hierarchies we would need another set of 
> >> modules for shared classes, or we would have to eliminate these 
> >> shared classes.
> >>
> >> Please comment.
> >>
> >> thanks
> >> david jencks
> >>
> >
> 
>