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 discussion.
thanks 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
