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