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
