David Jencks wrote:
I don't like prohibiting people from doing stuff because we think we
know better. I think there are valid reasons to stop and uninstall most
of these modules, although you may need to be an expert to be able to
start the server afterwards.
Yes, I see your point ... and it does get tricky trying to decide when
to permit an action and when to prevent it.
How about if for both stop and uninstall we show a list of the modules
that will be stopped or rendered inoperable as a result? This would be
the transitive closure of the "child" view in the modules pages.
We already show the immediate children (as you point out) and I think
the user kind of glazes over at that list. The transitive list would be
even larger and possibly more likely to be ignored. Still ... it's
worth exploring.
For a quick fix for now I think I will just go with a sternly worded
challenge if the module to be stopped/uninstalled is a SERVICE or starts
with org.apache.geronimo.*
Thanks,
Joe
thanks
david jencks
On Aug 28, 2007, at 7:41 AM, Joe Bohn wrote:
GERONIMO-3401 ( https://issues.apache.org/jira/browse/GERONIMO-3401 )
records a problem where it is possible for the user to cripple the web
console, the server or both with 1 or 2 mouse clicks.
When stopping some system-modules such as the following from the web
console, the web console itself is also stopped due to direct and
transitive dependencies:
- activemq-broker
- connector-deployer
- geronimo-gbean-deployer
- j2ee-corba-yoko
- j2ee-deployer
- j2ee-security
- j2ee-server
- j2ee-system
- jasper
- jee-specs
- openejb
- openjpa
- rmi-naming
- server-security-config
- tomcat6
- tomcat6-deployer
- jetty6
- jetty6-deployer
- transaction
- webservices-common
- xmlbeans
The result is an error in the browser, and exception in the server,
and the web console disabled. One cheap way to help prevent this
problem is to add a challenge when any system module is stopped to
ensure the user is aware that stopping a system module might result in
rendering the web console unusable. The situation can be recovered
via the CLI by subsequently starting the web console but this might
not be obvious to the user and often a server restart is necessary
before the CLI itself can function again.
However, there is another problem that is much more serious. If the
user selects "uninstall" on any of the modules listed above, in
addition to the web console being disabled, the server itself is
corrupted. In fact, in most cases the server cannot start once it is
shutdown. AFAIK, there is no easy recovery from this. There is a
challenge already provided to he user when uninstall is selected but
it doesn't hint at the potential severity of the consequences.
I'm thinking we should remove the uninstall capability from the system
module view in the web console until we have more pluggable components
that can be installed/uninstalled without crippling the entire server.
A challenge (even if worded more strongly) just doesn't seem
sufficient. Of course we have this same exposure with the CLI but it
isn't quite as easy to shoot yourself in the foot there with just 2
mouse clicks. Thoughts?
Joe
