You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Aaron Mulder <am...@alumni.princeton.edu> on 2004/11/04 19:39:52 UTC
How to updated config.list during offline deployment
I'd like to be able to add entries to config.list when the server
is not running and I'm doing a deployment. The problem is, the
configuration list GBean isn't running -- it's not in the minimal set
started by the deployer. And even if it was, it would install a shutdown
hook that basically saved an empty file when the deployer finished.
Anyone mind if I just have a little logic in the deployer to
update this file directly?
Aaron
Re: How to updated config.list during offline deployment
Posted by Dain Sundstrom <ds...@gluecode.com>.
On Nov 4, 2004, at 10:39 AM, Aaron Mulder wrote:
> I'd like to be able to add entries to config.list when the server
> is not running and I'm doing a deployment. The problem is, the
> configuration list GBean isn't running -- it's not in the minimal set
> started by the deployer. And even if it was, it would install a
> shutdown
> hook that basically saved an empty file when the deployer finished.
>
> Anyone mind if I just have a little logic in the deployer to
> update this file directly?
+1
Can you also try to grab an NIO lock on the file, so we can prevent two
deployers trying to update it at the same time? Actually, I think the
server should grab a lock on start up, to stop offline deployers
messing with the index while the server is running, since the server
will overwrite it on shutdown.
-dain
Re: How to updated config.list during offline deployment
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Actually, it will be
java -jar bin/deployer.jar deploy [module] [plan]
As per the proposed deployer syntax thread. (Though I currently
have a separate new-deployer.jar until we feel comfortable axing the old
one).
Aaron
On Thu, 4 Nov 2004, Dain Sundstrom wrote:
> So I would have to do this:
>
> java -jar bin/server.jar --install file.ear
> java -jar bin/server.jar --add my/new/config
>
> I think that the vast majority of the time I would just want this:
>
> java -jar bin/server.jar --deploy file.ear
>
> which would do both of the above commands in one go
>
> -dain
>
>
Re: How to updated config.list during offline deployment
Posted by Dain Sundstrom <ds...@gluecode.com>.
On Nov 4, 2004, at 11:18 AM, Jeremy Boynes wrote:
> Aaron Mulder wrote:
>> I'd like to be able to add entries to config.list when the server is
>> not running and I'm doing a deployment. The problem is, the
>> configuration list GBean isn't running -- it's not in the minimal set
>> started by the deployer. And even if it was, it would install a
>> shutdown hook that basically saved an empty file when the deployer
>> finished.
>> Anyone mind if I just have a little logic in the deployer to update
>> this file directly?
>
> Yes, I mind. The config.list file is specific to the actual
> implementation of the PersistentConfigurationList GBean and the
> deployer should not assume that as other implementations may exist.
>
> The other thing is that the --install option does just that - install
> but not start (it is meant to be similar to JSR-88 distribute).
>
> I believe this can be better solved by adding an option to server.jar
> that adds a new configId to the list to be run, something like:
>
> java -jar bin/server.jar --add my/new/config
So I would have to do this:
java -jar bin/server.jar --install file.ear
java -jar bin/server.jar --add my/new/config
I think that the vast majority of the time I would just want this:
java -jar bin/server.jar --deploy file.ear
which would do both of the above commands in one go
-dain
Re: How to updated config.list during offline deployment
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Thu, 4 Nov 2004, Jeremy Boynes wrote:
> No, you were proposing having the deployment tool hack the internal file
> used by a specific GBean. I object to that as it relies on
> implementation detail.
Hmm. Obviously we're not on the same page here.
So you would be totally comfortable with this if we use the GBean
to access the file, rather than writing to it directly?
> > You seem to be sugesting that the deploy tool should only work fully
> > when the server is running, and if the server is not running, then you
> > need to use a different command to start the server and deploy at the
> > same time. Is that right?
>
> No, I was proposing adding the command line option to the server that
> added a configId to the list retrieved from the last-known-configs
> GBean. This is a portable way of achieving what you were trying to do
> above. It is also simply "start" and not "deploy"
Is this your position:
- the deploy tool should not support "start" when the server is not
running (but it's fine to support it when the server is running)
- the server should offer a command line argument that gets you the
"start" functionality
If so, I would claim this uses two tools (deployer.jar,
server.jar) and also makes the deployer behave differently depending on
whether the server is running (start works, start doesn't work).
Also, how is the server.jar option you're proposing different than
the existing option to just pass a configId on the command line? What
does the new option do that the old one doesn't?
Thanks,
Aaron
Re: How to updated config.list during offline deployment
Posted by Jeremy Boynes <jb...@gluecode.com>.
Aaron Mulder wrote:
> What I am proposing is the equivalent of using the current deploy
> tool, and then adding the module's configId to the server command line
> next time you start it -- which is what you can do today. I don't see how
> that makes the situation worse.
>
No, you were proposing having the deployment tool hack the internal file
used by a specific GBean. I object to that as it relies on
implementation detail.
> You seem to be sugesting that the deploy tool should only work
> fully when the server is running, and if the server is not running, then
> you need to use a different command to start the server and deploy at the
> same time. Is that right?
>
No, I was proposing adding the command line option to the server that
added a configId to the list retrieved from the last-known-configs
GBean. This is a portable way of achieving what you were trying to do
above. It is also simply "start" and not "deploy"
You can install(distribute) offline to your heart's content but I don't
want the user fooled into thinking their app is startable when it isn't.
The "deploy" tool (as in distribute/start) can *only* work with a
running server as that is the only way to tell if the application is
startable.
I think the typical usage will be:
start server
repeat
write code
build (with distribute/start to online server)
test
until app works or it's time to go home
rather than
repeat
write code
build (with 'deploy' to offline server)
start server
check logs for errors
test
stop server
until app works or it's time to go home
We should make the first simple and reliable.
--
Jeremy
Re: How to updated config.list during offline deployment
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
What I am proposing is the equivalent of using the current deploy
tool, and then adding the module's configId to the server command line
next time you start it -- which is what you can do today. I don't see how
that makes the situation worse.
You seem to be sugesting that the deploy tool should only work
fully when the server is running, and if the server is not running, then
you need to use a different command to start the server and deploy at the
same time. Is that right?
Aaron
On Thu, 4 Nov 2004, Jeremy Boynes wrote:
> You mean, you hope that it starts - you would have to look at the server
> to see if it actually did. So this has the same "copy-and-pray" utility
> as dumping the module in a directory.
>
> I think either you would be checking as you watched the server start
> (the --add option) or you would test by pinging the server once it had
> started. The latter option here is exactly as hard as just calling "start"
>
> My issue is the ambiguity in the outcome of what you propose.
Re: How to updated config.list during offline deployment
Posted by Jeremy Boynes <jb...@gluecode.com>.
Aaron Mulder wrote:
> If you "deploy" to a server that's not running, then the module
> will be started next time the server starts. If you "distribute" to a
> server that's not running, then the module will not be started next time
> the server starts.
>
You mean, you hope that it starts - you would have to look at the server
to see if it actually did. So this has the same "copy-and-pray" utility
as dumping the module in a directory.
I think either you would be checking as you watched the server start
(the --add option) or you would test by pinging the server once it had
started. The latter option here is exactly as hard as just calling "start"
My issue is the ambiguity in the outcome of what you propose.
--
Jeremy
Re: How to updated config.list during offline deployment
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Thu, 4 Nov 2004, Jeremy Boynes wrote:
> Pardon me for being dumb but how can you start a module if the server is
> down?
>
> I think we may be trying to hard to kludge 88-style operations into a
> mode that 88 was not intended to support.
If you "deploy" to a server that's not running, then the module
will be started next time the server starts. If you "distribute" to a
server that's not running, then the module will not be started next time
the server starts.
The alternative is to have two tools for online/offline mode (you
missed the boat if you intend to fight for that), or one tool where only
half the options work any any given time (ick).
Aaron
Re: How to updated config.list during offline deployment
Posted by Jeremy Boynes <jb...@gluecode.com>.
Aaron Mulder wrote:
> I'm working on the new deployer not the old one. As per the
> "proposed deployer syntax" message, this one actually offers a JSR-88
> start method while the server is not running, which equates to updating
> the config list to include the module. I'd rather not start the server to
> do that... Also, the bulk of the feedback on the thread before that was
> that having two tools to handle deployment tasks was bad.
>
Pardon me for being dumb but how can you start a module if the server is
down?
I think we may be trying to hard to kludge 88-style operations into a
mode that 88 was not intended to support.
--
Jeremy
Re: How to updated config.list during offline deployment
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I'm working on the new deployer not the old one. As per the
"proposed deployer syntax" message, this one actually offers a JSR-88
start method while the server is not running, which equates to updating
the config list to include the module. I'd rather not start the server to
do that... Also, the bulk of the feedback on the thread before that was
that having two tools to handle deployment tasks was bad.
Aaron
On Thu, 4 Nov 2004, Jeremy Boynes wrote:
> The other thing is that the --install option does just that - install
> but not start (it is meant to be similar to JSR-88 distribute).
>
> I believe this can be better solved by adding an option to server.jar
> that adds a new configId to the list to be run, something like:
>
> java -jar bin/server.jar --add my/new/config
>
> --
> Jeremy
>
Re: How to updated config.list during offline deployment
Posted by Jeremy Boynes <jb...@gluecode.com>.
Aaron Mulder wrote:
> I'd like to be able to add entries to config.list when the server
> is not running and I'm doing a deployment. The problem is, the
> configuration list GBean isn't running -- it's not in the minimal set
> started by the deployer. And even if it was, it would install a shutdown
> hook that basically saved an empty file when the deployer finished.
>
> Anyone mind if I just have a little logic in the deployer to
> update this file directly?
Yes, I mind. The config.list file is specific to the actual
implementation of the PersistentConfigurationList GBean and the deployer
should not assume that as other implementations may exist.
The other thing is that the --install option does just that - install
but not start (it is meant to be similar to JSR-88 distribute).
I believe this can be better solved by adding an option to server.jar
that adds a new configId to the list to be run, something like:
java -jar bin/server.jar --add my/new/config
--
Jeremy