Both good suggestions.
Thanks!
Joe
Aaron Mulder wrote:
I guess we could also disable stop and undeploy for the system modules
and have an "expert mode" checkbox or something on the screen to
enable them again. That ought to be clue enough. :)
Thanks,
Aaron
On 8/28/07, Aaron Mulder <[EMAIL PROTECTED]> wrote:
It probably would still be good to have some text like "WARNING: only
expert users will be able to restart the server after this is done."
Just seeing a list of components to be stopped won't necessarily clue
in "the average user" to the potential impact... But of course we'd
only want to display that if it was really the case, so perhaps we can
just detect whether the really important startup-fails-without-this
modules are in the dependency list.
Thanks,
Aaron
On 8/28/07, David Jencks <[EMAIL PROTECTED]> 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.
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.
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
