Jason, I thought TCK was using the maven plugin to start the server. I'm not proposing to change that. But even if start-server command is used by TCK, I don't think that alone should dictate how the command should behave. I'm thinking what happens if you start any command in the background in a regular shell or even use geronimo.sh run or geronimo.sh start. It does not tell you if the command finished starting up ok. So start-server command is unqiue in that respect and I think it would be better if the behaviour was consistent.
Maybe as a compromise, we could add -wait option to the start-server command and only poll the server for successful start up when that option is specified. Jarek On Fri, Mar 14, 2008 at 7:16 AM, Jason Dillon <[EMAIL PROTECTED]> wrote: > The wait for start behavior is required for proper TCK automation, so > that once the start-server command finishes, we know the server is up > and running, else there is some problem. > > I imagine that users also want this type of feedback when they run the > start-server command. I think it would be a bad idea to run the > command and return success and then force the user to use an > additional command or inspect the logs (or process tree) to determine > if the server was started. > > The problem here is that to access this information we need an > authenticated connection via JMX. So if we can provide a limited > system-only account with a passwd that is static then we can get this > information to allow the command to work even when the "system" > account passwd has been changed. Alternatively we can provide another > mechanism to allow tools to query the running status of the server. > There is no security risk here, just need to provide some simple > mechanism to allow tools to determine the state of the server. Which > IMO seems very reasonable to me. > > I'd like to not see this functionality tossed into a separate command, > but have the feature exposed to all tools. > > * * * > > David, how hard is it to implement a JMX authentication and limitation > system which would only grant a specific user access to invoke/get > operations/attributes on a set of gbeans? > > --jason > > > > > On Mar 14, 2008, at 12:44 PM, David Jencks wrote: > > > > > On Mar 13, 2008, at 9:25 PM, Jarek Gawor wrote: > > > >> I'm trying to restart the discussion on the start-server command and > >> the hard-coded user credentials to see if we can fix this somehow. > >> > >> Right now, the start-server command will poll the server periodically > >> using JMX to see if the server started up ok. That's why it needs > >> username/password to check on the status of the server. > >> > >> Jason below described one idea how we might fix/improve the > >> start-server command. > >> > >> I'm wondering if we need to poll the server at all. If the server is > >> running in the foreground the user will know if the server started up > >> ok or not from looking at the console. And even if the server is > >> started up in the background, the command should return as soon as > >> the > >> server process forked ok and not wait until the server finishes > >> starting up. So maybe we should separate the process of starting the > >> server from checking if the server started up ok. For example, add > >> isServerRunning or waitForServer gsh commands (which would require > >> creds) and make the start-server command just fork the server process > >> (no creds required). > >> > >> Thoughts? > > > > OK. IIRC the idea behind the current behavior was so you could > > write scripts that start the server, then do stuff once it is > > running. However I doubt this was explicit for the gshell > > command... Anyway I'd be happy with a separate > > "isServerRunning(boolean wait)" type command. > > > > thanks > > david jencks > > > >> > >> Jarek > >> > >> On Fri, Feb 22, 2008 at 6:51 AM, Jason Dillon <[EMAIL PROTECTED]> > >> wrote: > >>> We might be able to open a port on localhost during startup, which > >>> would only be used to provide status (like starting, started, > >>> shutting > >>> down). Then we wouldn't need to make a JMX connection to the server > >>> at all. Though if possible, a special anonymous system account with > >>> limited proviledges for remote JMX would be more ideal... though > >>> I've > >>> no idea if that is possible asis or if it would be easy to implement > >>> if its not there. > >>> > >>> Anyone have any other ideas? > >>> > >>> --jason > >>> > >>> > >>> > >>> > >>> On Feb 21, 2008, at 12:57 PM, Jarek Gawor wrote: > >>> > >>>> On Thu, Feb 21, 2008 at 2:35 PM, Jason Warner <[EMAIL PROTECTED]> > >>>> wrote: > >>>>> > >>>>> > >>>>> On Thu, Feb 21, 2008 at 1:36 PM, Jarek Gawor <[EMAIL PROTECTED]> > >>>>> wrote: > >>>>>> Yes, I've noticed that too. The deploy/* commands are not > >>>>>> 'integrated' > >>>>>> with the geronimo/* commands. Looks like the JMX connection is > >>>>>> not > >>>>>> being shared between these groups of commands. We should be > >>>>>> able to > >>>>>> fix that. Please open a bug. Also, I just noticed that if an user > >>>>>> changes the default user/password the geronimo/start-server > >>>>>> command > >>>>>> might fail with an error. > >>>>>> > >>>>>> Jarek > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> I just opened a jira for that original issue I mentioned. > >>>>> https://issues.apache.org/jira/browse/GERONIMO-3869 > >>>>> > >>>>> I'm not sure I understand that second issue you mentioned. > >>>> > >>>> The start-server command has hardcoded username/password > >>>> combination > >>>> and it cannot be specified on the command line. So if the > >>>> password is > >>>> changed and if you start the server let's say with: > >>>> > >>>> geronimo/start-server --background --timeout 60 > >>>> > >>>> You will see something like: > >>>> > >>>> ..... > >>>> Geronimo Application Server started > >>>> <after <60 seconds> > >>>> ERROR Exception: Failed to start: Geronimo Server > >>>> > >>>> Even though the server started up fine but then becuase of the > >>>> exception it will be killed. > >>>> > >>>> Jarek > >>> > >>> > > > >
