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
>>>
>>>
>
