If I can try to summarize briefly, here's the main problem with 
featureful offline support:

        The deployer doesn't know where the server is storing things it
deploys, and doesn't know what configuration engine the server is using to
decide where it is storing things and what should be loaded at startup and
so on.  To get this information, the deployer would need to load a
non-trivial amount of the server, at which point this practically *is* an
online deployment.  (Also: how would it work remotely?)

        For a default setup, these things are well-known and we could
solve the most common case by simply supporting the default.  It would,
however, totally break for a non-default server configuration (e.g.  
storing deployments in database), and someone strongly objected to this.  
There was some talk of "if you change your config store you must rebuild
your deploy tool" but that never really went anywhere.

        As we left ApacheCon, there was a strategy established for the
best way to handle deployment, and specifically offline deployment -- I
think David J understood it best.  I assume it was a procedure for loading 
"just enough" of the server to get the correct config store, etc., but I'd 
have to look at the mail trail myself.

Aaron

P.S. I think JSR-88 is a red herring.  It has offline and online modes.  
If we solve both problems, we can support them both in JSR-88.  The main 
problem with JSR-88 and Geronimo is that JSR-88 doesn't have a facility 
for building "CAR" files or the executable JARs used to start the server, 
deploy tool, client container, etc.  So our "deploy" tool, if it will be 
used for those purposes, must support more than JSR-88 does, and thus 
cannot restrict itself to using only the JSR-88 API to talk to the server.

On Mon, 7 Feb 2005, Geir Magnusson Jr. wrote:
> I'm missing some important clue about deployment.
> 
> It seems I can "deploy" to a running server and "distribute" to a 
> non-running server. I understand the technical difference, but I don't 
> grok why we need this difference, and more importantly, why I can't 
> "undistribute" in the event of a mistake...
> 
> I'd hate to distribute the ImmediatelyScramNuclearReactorGBean and have 
> to start the server to remove it.
> 
> I was perusing JSR88, and it seems to indicate that distribute, start, 
> stop, undeploy and redeploy are the "verbs", all applying to a running 
> server.  There seems to be no concept of offline for JSR88 that's 
> useful.
> 
> I remember the "Deployment Semantics Wars" of 2004 with much dread, and 
> don't wish to rekindle especially now as we're focused on J2EE 
> functionality, but can we revisit this?  I would imagine it would be 
> nice to have :
> 
> 1) A JSR-88 compliant tool that is strict in it's support of the spec, 
> asymmetry and all.
> 
> 2) A Geronimo-specific tool that lets me have the nifty things you guys 
> designed into this, like a redistributable configuration archive.  I'll 
> go re-read the threads...
> 
> geir
> 
> -- 
> Geir Magnusson Jr                                  +1-203-665-6437
> [EMAIL PROTECTED]
> 
> 

Reply via email to