On Feb 7, 2005, at 1:04 PM, 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've come to the conclusion that we have, from a users POV
a) live server deployment - can deploy to a running server somewhere, local or remote
b) local stopped server installation - seems to add files and update an index in the local servers config-store
and what I was thinking of as 'offline deployment' doesn't exist.
That's fine. We can just add it at some point when we have time.
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.
What does "stop", applied to a stopped server, mean to the average joe? Or undeploy? Right now, we can't undeploy from a stopped server. (Nor do I think we should... the only thing I would suggest to do this to avoid having to dork w/ the servers private files is some sort of 'command object' that one could leave around for the server to pick up that gets it to undeploy or -ish when it wakes up.
And lets distinguish between what seems to be the definition of "offline" here, meaning "I can do stuff locally to the file system because if have access and know the layout" and what I think "disconnected" means in 88 (since "offline" doesn't appear to be a defined concept). I think that "disconnected" is a limited functional set, described as
"A DeploymentManager running disconnected from its J2EE
product can only configure modules but not perform administrative operations.
It might not have access to any product resources. If any of the administrative
operations, distribute, start, stop, undeploy, or redeploy are called,
an IllegalStateException must be thrown."
(JSR-88, 4.1, bullet # 3)
Maybe Aaron can shed more light on this.
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.
To me, the issue isn't the number of them, because we're talking about two different functional requirements. The JSR-88 tool is designed for J2EE specifically, and can't by definition do things that are Geronimo's "value add" to the J2EE specification. I'm all for having a generic JSR-88 tool, but I don't see why the existence of that would prohibit us from having our own Geronimo-specific 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.
That's reasonable if you are talking about /usr/bin/mail on a unix system, reading the local mbox file, but for any modern mail client, there are separate handlers for the protocols. For example, reading the local mbox, accessing POP3, accessing IMAP are all different, handled by subsystems. I don't care if we have only one Official Deployment Tool, but it can easily be a wrapper around handlers for the different kinds of deployment. I assume that would be ok, unless you require there be only one deployer Class or something, but i don't think that's what you mean.
I knew I didn't want to go here :)
geir
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.
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
-- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
