On Feb 7, 2005, at 12:10 PM, Aaron Mulder wrote:
Ah, right. I guess we need to start every conversation by clarifying the terminology. :)
Cool!
I think your scenario makes sense. As
far as I know, we don't have robust handling for CAR files (fully baked
content, configuration, etc.) right now. There are also some issues such
as if you create it based on one server environment (map resource refs,
etc.), what happens if you deploy to a different server with different
stuff running?
Sure.
I think JSR-88 envisioned that the code + deployment plan was the abstract instance-independent module that you could later deploy, undeploy, move, etc.
The problem I have is that JSR-88 is J2EE specific, so what do we do for people who don't care about J2EE and want to use Geronimo The Container for other purposes?
You seem to be envisioning a processed instance-specific module that you could later deploy, undeploy, move, etc.
Not sure about undeploy and move, but certainly move around and deploy to any server that could meet it's dependency and resource needs.
The advantage of yours is that more validation and pre-processing is
done up front. The advantage of JSR-88 is that it isn't assuming that the
server you delpoy to is the same as the server you packaged for. In other
words, if you have to repeat all the validation and code generation and
stuff just to ensure that the server you deploy to won't barf on the
assumptions made by the pre-packaging tool, what's the advantage of the
pre-packaging?
That makes sense if we are just trying to do a generic JSR-88 tool - which I think would be nice to have around - but if we then can't take advantage of Geronimo features that aren't part of J2EE or JSR-88, then we have a problem.
In any case, it would be great if you could make a list of the features that you're looking for (e.g. the requirements) so we can talk about what is or should be implemented.
I'll do that. First one that comes to mind is what triggered this, namely "undistribute". :)
geir
Aaron
On Mon, 7 Feb 2005, Geir Magnusson Jr. wrote:On Feb 7, 2005, at 11:22 AM, Aaron Mulder wrote:
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?)
Ok - I understand what you are saying, but we're talking about "offline", and I have a slightly different POV of what that means.
To me, it doesn't mean the server that I have access to is just simply turned off. I don't need to know anything about where the server stores anything. I should have no clue where the server is.
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.
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.
I think that the config store should be indep of the deployment. The deploy tool spits out a config_archive.jar, and that is given to a server for 'internal deployment'. IOW, I shouldn't care one bit about the internals of the server.
I think of this in the 'unix way' - simple toolchain to create a thingy, and then another tool to send the thingy where it needs to go.
Maybe this is what was intended, that the module+plan is config-store
agnostic, and we just lost the plot somewhere such that deployment can
happen w/o any server nearby. or maybe I just don't grok how to deploy
w/o a server, and it's just a matter of documentation.
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.
I know you're an 88 expert, and I know that I'm not. I just got the sense glancing over the spec that the offline mode was fairly useless for the kind of thing we're talking about here.
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.
Right. But the 88 language is somewhat confusing, given the lack of
symmetry (distribute/undeploy) and lack of a viable offline mode. I
don't think of the offline problem as a weakness in 88 as much as we're
applying the wrong tool for the job - we're looking at doing something
beyond the scope of 88, right?
geir
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]
-- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
-- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
