[daemon] more comments

[co...@covalent.net]

I did a more detailed review of the code. Haven't made any 
code change yet.

There are some very serious issues right now. 
For example, the shutdown() native method just can't work - at
least based on my knowledge of unix. It is executed in the child,
not in parent - and it tries to access the field storing the pid
of the child, which is 0. So it'll send a signal to 0.

There are other gray areas, and overall the fact that it requires
an interface is the smallest problem. 

The major issue remains the fact that it requires the application
to use a special programming model - wich is different from what
most people do. 

You can't store the user id ( for chuid ) in the program config, and
it doesn't have a config file ( where system properties, java flags,
etc are stored ). 

There are also problems with the stop mechanism - I would expect the
unix side to work the same as the windows service manager, i.e. try
to restart a failed app. Right now restarting it happens only if
exit status is 123 - if the server dies, it'll not be reloaded.

There is a lot of usefull and nice C code - the windows part looks
great, and I'm +1 on it. 

What I would like to do is merge the 'chuid' code into jk2 - there
is already some code there, and it's quite easy. This will give tomcat
( all versions ) the ability to change the user id ( and bind on 80 ).
This will be configured in the jk2.properties. That seems to be 
the biggest feature that tomcat uses.

I'm also +1 on the unix code, as long as it is fixed to have the
same behavior as the windows service manager and is made generic.
The whole 'chuid' and lifecycle stuff is very shaky - again, not
only because of interfaces. Keeping things simple ( SoC :-) is 
much better.

One nice functionality is the delivery of signals. 
This works only for 3 signals ( actually 2, there is one cut/paste
error ), with reload hardcoded to HUP. It would be much better
if this would actually provide a way for apps to use unix 
signals in a flexible way.

There is another chunk of code for starting the VM - and I need
to review it closely and see how it can be merged with jk starting.

I think it may be a good idea to also merge the lauching/deamon
native code into jk - and eventually add back the old jserv
launching capabilities. But for now it would be better to do
it in tomcat.

Costin





--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>