geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: deployment (oh, how I hate to go here...)
Date Mon, 07 Feb 2005 18:27:50 GMT

On Feb 7, 2005, at 10:04 AM, Dain Sundstrom wrote:

> On Feb 7, 2005, at 7:34 AM, Geir Magnusson Jr. wrote:
>> 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...
> This has bugged me for a while
>> 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.
> Just because spec choose to ignore offline deployment doesn't mean 
> that the "verbs" applied to a stopped server don't have meaning to the 
> average joe.
>> 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...
> I an definitely against having more then one deploy tool.  It is like 
> having a mail reader to read internet mail and a separate mail tool to 
> read corporate mail.  Mail is mail and deployment is deployment.
> On Feb 7, 2005, at 8:22 AM, Aaron Mulder wrote:
>> 	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.
> I remember everyone liking the strategy, but I can't remember it 
> myself anymore :)  Maybe David, can jog our memories.

The idea is to basically:

1. have a micro-pre-deployer-thingy that looks at what you are trying 
to deploy and determines its parentId. This probably requires little 
bits of each  builder to recognize the package and give back a default 
parentId if its missing.

2. the main part of the builders is in a special configuration.  The 
predeployer sets it's parentId to the parentId of the package you are 
trying to deploy, and loads and starts it, then calls the deployer in 
it to build stuff.

The point is to only have one "deployer" plan, and to get all possible 
usable classes into its parent classloader and to try to avoid all 
duplicate class loading problems.  I'm not sure how it relates to this 

david jencks

> On Feb 7, 2005, at 8:28 AM, Geir Magnusson Jr. wrote:
>> IOW, I should be able to, in a parallel universe where no Geronimo 
>> server exists, run the deployer and produce a instance-independent 
>> artifact (I think they have been called 'configuration archives') 
>> that I can then transport through a rift in the time-space continuum 
>> and give to you to deploy on your machine.
>> Now, if you don't buy the parallel universe schtick, imagine a 
>> regular production environment where developers have absolutely zero 
>> access to the production machine, and are probably separated by 1-2 
>> layers of QA and testing, either something like
>>   dev ->   QA  ->  prod
>> or
>>   dev -> QA -> stage/client eval -> prod
>> In my past, deployment to QA systems came from tagged CVS.  After 
>> passing QA, it was deployed to staging system from a tag in CVS... 
>> same w/ prod.   Ops didn't get to modify things, like where to find 
>> the database and ish.
> The parallel universe scenario doesn't work anyway.  The generated CAR 
> files are basically keyed to the server that generated them.  Maybe 
> with a ton of work one day we will be able to do that, but for the 
> foreseeable future it is not possible.
> -dain

View raw message