geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: deployment (oh, how I hate to go here...)
Date Mon, 07 Feb 2005 19:36:39 GMT
On Mon, 7 Feb 2005, Geir Magnusson Jr wrote:
> "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.

	My interpretation was "will probably be thrown", but if the spec
says "must be thrown" then there's not too much to be done.  The idea was
that if you're connected you can do anything, but if you're not connected,
you should still be able to configure and save a deployment plan and so
on, you just might not (or in this case, must not) be able to actually try
to send your application and plan to the server.

	In any case, I agree that the offline behavior you're looking for 
is not implemented.  And if you're looking to do it for arbitrary GBean 
configurations (not just J2EE modules), it would be tough to shoehorn it 
fully into JSR-88.  So we can either go with two tools (which no one much 
likes) or one tool that's "JSR-88 plus", using JSR-88 where appropriate 
but offering additional Geronimo-specific features too.

	Still, I think we have more work to do on the requirements.  For
example, when we create a "CAR" (the archive of stuff that you can just
drop in to a server), what should go in it?  What processing gets done
when creating the CAR and what when deploying the CAR?  Should the server
need to be online to distribute the CAR, or should we implement the logic
David described to partially start the server in order to do stuff, or
should there be some "todo"  directory where you dump stuff that you want
the server to execute when it starts?  If the latter, how do you handle
conflicting commands or code in there?  Should a CAR be "sealed" or should 
there be some way to update it (for example, if QA and Prod environments 
have different users that you want to include in the role mapping)?


View raw message