Re: How to updated config.list during offline deployment
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
Re: How to updated config.list during offline deployment
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
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
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
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
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
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
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
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
