Tom,
I agree, but I have some serious security concerns with this method--in fact having stop.jar makes me nervous also. Is stop.jar really supposed to stop the server? It seems to stop the mbeans, but the server doesn't exit. Without some kind of basic authentication method, this is a hazard. Sure, a well laid out network will have the RMI ports and the web admin interface firewalled off (or shut off), but not every user is going to have a secure system. In a UNIX environment, even if you couldn't connect directly to the server from outside your firewall, any user with basic priveleges on the system could issue a stop command without even being asked for a password.
A later email I sent to the list did outline a better way (or at least, a more unixy way) of handling startup and shutdown, but it does require some slight modification to the java source. The existing code uses relative directories (to the jboss_home/bin directory). I propose setting a JBOSS_HOME environment variable, and passing that in at runtime via a -Djboss.home=$JBOSS_HOME (or equivalent for win32). Perhaps we could just detect whether jboss.home was set or not. If it's null, use relative directories--otherwise follow the setting. This will solve the problem of only being able to launch jboss from a working directory of jboss_home/bin, and allow for more flexible system administration. I think this might make most systems admin types a little happier when jBoss starts getting used on large production machines that may be running many applications besides jBoss. (we do want to be able to scale up, as well as down, right
-Jason
| Tom Cook <[EMAIL PROTECTED]>
11/14/2000 08:05 PM
|
To: jBoss <[EMAIL PROTECTED]> cc: Subject: [jBoss-User] Starting and stopping jboss automatically in *nix |
Hmmm, the socket listener connected to a 'System.exit(0);' seems a lot
cleaner, to my mind.
Tom
