Geronimo
  1. Geronimo
  2. GERONIMO-3401

Stop of module from "System Modules" in console should warn user of destructive action

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0, 2.0.x
    • Fix Version/s: 2.0.2, 2.1
    • Component/s: None
    • Security Level: public (Regular issues)
    • Labels:
      None
    • Environment:

      Geronimo 2.0.1-SNAPSHOT using Tomcat JEE assembly. Most likely affects others as well

      Description

      When using the Geronimo Console to stop of a module a 404 is received in the console. In this case an attempt to stop OpenEJB. The console then becomes unusable and also does not survive a restart. It appears the console needs to be re-installed.

      Error reported to Browser

      HTTP Status 404 - /console/portal/apps/apps_system/st_apps_system_row1_col1_p1/normal/_rp_apps_system_row1_col1_p1_message/1/_pid/apps_system_row1_col1_p1/_md_apps_system_row1_col1_p1/view

      type Status report

      message /console/portal/apps/apps_system/st_apps_system_row1_col1_p1/normal/_rp_apps_system_row1_col1_p1_message/1/_pid/apps_system_row1_col1_p1/_md_apps_system_row1_col1_p1/view

      description The requested resource (/console/portal/apps/apps_system/st_apps_system_row1_col1_p1/normal/_rp_apps_system_row1_col1_p1_message/1/_pid/apps_system_row1_col1_p1/_md_apps_system_row1_col1_p1/view) is not available.

      Exception LoggedMy Title

      [] received stop signal
      00:59:03,833 ERROR [Servlet] Exception caught:
      org.apache.geronimo.kernel.proxy.DeadProxyException: Proxy is no longer valid to gbean: org.apache.geronimo.configs/transaction/2.0.1-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/transaction/2.0.1-SNAPSHOT/car,j2eeType=JCAConnectionTracker,name=ConnectionTracker
      at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:87)
      at org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTracker$$EnhancerByCGLIB$$4301e6fc.exit(<generated>)
      at org.apache.geronimo.tomcat.interceptor.InstanceContextBeforeAfter.after(InstanceContextBeforeAfter.java:73)
      at org.apache.geronimo.tomcat.interceptor.ComponentContextBeforeAfter.after(ComponentContextBeforeAfter.java:46)
      at org.apache.geronimo.tomcat.interceptor.PolicyContextBeforeAfter.after(PolicyContextBeforeAfter.java:70)
      at org.apache.geronimo.tomcat.interceptor.UserTransactionBeforeAfter.after(UserTransactionBeforeAfter.java:47)
      at org.apache.geronimo.tomcat.listener.DispatchListener.afterDispatch(DispatchListener.java:86)
      at org.apache.geronimo.tomcat.listener.DispatchListener.instanceEvent(DispatchListener.java:59)
      at org.apache.catalina.util.InstanceSupport.fireInstanceEvent(InstanceSupport.java:275)
      at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:682)
      at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557)
      at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481)
      at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
      at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68)
      at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164)
      at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82)
      at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227)
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
      at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
      at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
      at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
      at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
      at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:351)
      at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
      at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
      at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
      at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
      at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
      at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
      at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
      at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581)
      at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
      at java.lang.Thread.run(Thread.java:613)
      00:59:03,835 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing
      org.apache.geronimo.kernel.proxy.DeadProxyException: Proxy is no longer valid to gbean: org.apache.geronimo.configs/transaction/2.0.1-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/transaction/2.0.1-SNAPSHOT/car,j2eeType=JCAConnectionTracker,name=ConnectionTracker
      at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:87)
      at org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTracker$$EnhancerByCGLIB$$4301e6fc.exit(<generated>)
      at org.apache.geronimo.tomcat.interceptor.InstanceContextBeforeAfter.after(InstanceContextBeforeAfter.java:73)
      at org.apache.geronimo.tomcat.interceptor.ComponentContextBeforeAfter.after(ComponentContextBeforeAfter.java:46)
      at org.apache.geronimo.tomcat.interceptor.PolicyContextBeforeAfter.after(PolicyContextBeforeAfter.java:70)
      at org.apache.geronimo.tomcat.interceptor.UserTransactionBeforeAfter.after(UserTransactionBeforeAfter.java:47)
      at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:50)
      at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
      at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
      at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
      at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
      at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
      at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
      at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581)
      at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
      at java.lang.Thread.run(Thread.java:613)

      And the console no longer functions and the console app is unusable even after a restart.

        Issue Links

          Activity

          Hide
          David Jencks added a comment -

          The admin console depends on openejb, so if you shut down openejb, that will also shut down the admin console and it's not exactly surprising it stops working. The stack trace you get is going to occur whenever you shut down a web app from itself and I don't regard it as a problem.

          You can certainly ask why the admin console depends on openejb, and I think its because of the unfortunate dependency between the openejb deployer and the openejb module.

          Show
          David Jencks added a comment - The admin console depends on openejb, so if you shut down openejb, that will also shut down the admin console and it's not exactly surprising it stops working. The stack trace you get is going to occur whenever you shut down a web app from itself and I don't regard it as a problem. You can certainly ask why the admin console depends on openejb, and I think its because of the unfortunate dependency between the openejb deployer and the openejb module.
          Hide
          Matt Hogstrom added a comment -

          Thanks David. I'll have to noodle on this but as we layer in the stuff Paul is working on we should probably define a base set of dependencies so when an uninstall is initiated the user has an opportunity to turn off the safety and fire away.

          Show
          Matt Hogstrom added a comment - Thanks David. I'll have to noodle on this but as we layer in the stuff Paul is working on we should probably define a base set of dependencies so when an uninstall is initiated the user has an opportunity to turn off the safety and fire away.
          Hide
          Joe Bohn added a comment -

          I started to look into this ... and I think the issue is even worse than Matt indicated.

          First off, I get a different exception after I uninstall the openejb. Secondly, I can not even restart the server after I uninstall openejb. I get the following exception attempting to load the axis2-deployer car (which is kind of strange because I noticed after I uninstalled openejb that axis2-deployer was no longer started so IIUC it shouldn't be attempting to start on a server restart either).

          Failure on restart

          Booting Geronimo Kernel (in Java 1.5.0_07)...
          Starting Geronimo Application Server v2.1-SNAPSHOT
          [**********> ] 38% 6s Starting org.apache.geronim...10:37:36,058 ERROR [[/]] "Restricted listeners property file not found
          [****************- ] 57% 8s Startup failed
          org.apache.geronimo.kernel.config.LifecycleException: load of org.apache.geronimo.configs/axis2-deployer/2.1-SNAPSHOT/car failed
          at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:297)
          at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:278)
          at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke(<generated>)
          at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
          at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
          at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
          at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830)
          at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
          at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
          at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
          at org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$1b65b454.loadConfiguration(<generated>)
          at org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:153)
          at org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:78)
          at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
          at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
          at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30)
          Caused by: org.apache.geronimo.kernel.repository.MissingDependencyException: Unable to resolve dependency org.apache.geronimo.configs/openejb//car
          at org.apache.geronimo.kernel.repository.DefaultArtifactResolver.resolveInClassLoader(DefaultArtifactResolver.java:120)
          at org.apache.geronimo.kernel.repository.DefaultArtifactResolver.resolveInClassLoader(DefaultArtifactResolver.java:99)
          at org.apache.geronimo.kernel.repository.DefaultArtifactResolver$$FastClassByCGLIB$$e847b746.invoke(<generated>)
          at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
          at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
          at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
          at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830)
          at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
          at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
          at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
          at org.apache.geronimo.kernel.repository.ArtifactResolver$$EnhancerByCGLIB$$ab898279.resolveInClassLoader(<generated>)
          at org.apache.geronimo.kernel.config.SimpleConfigurationManager.resolveParentIds(SimpleConfigurationManager.java:469)
          at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadDepthFirst(SimpleConfigurationManager.java:428)
          at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadDepthFirst(SimpleConfigurationManager.java:435)
          at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadDepthFirst(SimpleConfigurationManager.java:435)
          at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:294)
          ... 15 more
          [****************- ] 57% 20s Startup failed tetra:~/g-images/trunk/geronimo-tomcat6-jee5-2.1-SNAPSHOT/

          And here's the exception I get when I first uninstall openejb:

          uninstall openejb failure

          ERROR - Exception caught:
          java.util.EmptyStackException
          at java.util.Stack.peek(Stack.java:79)
          at java.util.Stack.pop(Stack.java:61)
          at org.apache.geronimo.tomcat.listener.DispatchListener.afterDispatch(DispatchListener.java:84)
          at org.apache.geronimo.tomcat.listener.DispatchListener.instanceEvent(DispatchListener.java:59)
          at org.apache.catalina.util.InstanceSupport.fireInstanceEvent(InstanceSupport.java:275)
          at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:692)
          at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557)
          at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481)
          at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
          at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68)
          at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164)
          at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82)
          at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227)
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
          at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
          at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
          at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
          at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
          at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
          at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
          at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:351)
          at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
          at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
          at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
          at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
          at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
          at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
          at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
          at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581)
          at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
          at java.lang.Thread.run(Thread.java:613)

          Show
          Joe Bohn added a comment - I started to look into this ... and I think the issue is even worse than Matt indicated. First off, I get a different exception after I uninstall the openejb. Secondly, I can not even restart the server after I uninstall openejb. I get the following exception attempting to load the axis2-deployer car (which is kind of strange because I noticed after I uninstalled openejb that axis2-deployer was no longer started so IIUC it shouldn't be attempting to start on a server restart either). Failure on restart Booting Geronimo Kernel (in Java 1.5.0_07)... Starting Geronimo Application Server v2.1-SNAPSHOT [**********> ] 38% 6s Starting org.apache.geronim...10:37:36,058 ERROR [ [/] ] "Restricted listeners property file not found [****************- ] 57% 8s Startup failed org.apache.geronimo.kernel.config.LifecycleException: load of org.apache.geronimo.configs/axis2-deployer/2.1-SNAPSHOT/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:297) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:278) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke(<generated>) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$1b65b454.loadConfiguration(<generated>) at org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:153) at org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:78) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30) Caused by: org.apache.geronimo.kernel.repository.MissingDependencyException: Unable to resolve dependency org.apache.geronimo.configs/openejb//car at org.apache.geronimo.kernel.repository.DefaultArtifactResolver.resolveInClassLoader(DefaultArtifactResolver.java:120) at org.apache.geronimo.kernel.repository.DefaultArtifactResolver.resolveInClassLoader(DefaultArtifactResolver.java:99) at org.apache.geronimo.kernel.repository.DefaultArtifactResolver$$FastClassByCGLIB$$e847b746.invoke(<generated>) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.kernel.repository.ArtifactResolver$$EnhancerByCGLIB$$ab898279.resolveInClassLoader(<generated>) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.resolveParentIds(SimpleConfigurationManager.java:469) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadDepthFirst(SimpleConfigurationManager.java:428) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadDepthFirst(SimpleConfigurationManager.java:435) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadDepthFirst(SimpleConfigurationManager.java:435) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:294) ... 15 more [****************- ] 57% 20s Startup failed tetra:~/g-images/trunk/geronimo-tomcat6-jee5-2.1-SNAPSHOT/ And here's the exception I get when I first uninstall openejb: uninstall openejb failure ERROR - Exception caught: java.util.EmptyStackException at java.util.Stack.peek(Stack.java:79) at java.util.Stack.pop(Stack.java:61) at org.apache.geronimo.tomcat.listener.DispatchListener.afterDispatch(DispatchListener.java:84) at org.apache.geronimo.tomcat.listener.DispatchListener.instanceEvent(DispatchListener.java:59) at org.apache.catalina.util.InstanceSupport.fireInstanceEvent(InstanceSupport.java:275) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:692) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:351) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:613)
          Hide
          Joe Bohn added a comment -

          Given Matt's change to make this an improvement and the severe impact of the problem on a potential user I'm re-opeing this issue.

          Show
          Joe Bohn added a comment - Given Matt's change to make this an improvement and the severe impact of the problem on a potential user I'm re-opeing this issue.
          Hide
          Joe Bohn added a comment -

          I've done some more investigation into this to discover the other system modules that cause problems for the console and/or the server.

          There are a number of components that fail with different results. Sometime the console is just no longer available. Other times the server itself is in a state where it can not be restarted. I also noticed that sometime a message precedes the stack trace on the console indicating the server stop signal has been received (when it really hasn't). Here's a list of the modules that cause problems when uninstalled and the types of problems. Most of the results are predictable (those that break the console or server) but there are a few surprises.

          config uninstalled console broken server broken shutdown message
          org.apache.geronimo.configs/activemq-broker/2.1-SNAPSHOT/car X X X
          org.apache.geronimo.configs/connector-deployer/2.1-SNAPSHOT/car X X  
          org.apache.geronimo.configs/geronimo-gbean-deployer/2.1-SNAPSHOT/car X    
          org.apache.geronimo.configs/j2ee-corba-yoko/2.1-SNAPSHOT/car X    
          org.apache.geronimo.configs/j2ee-deployer/2.1-SNAPSHOT/car X X  
          org.apache.geronimo.configs/j2ee-security/2.1-SNAPSHOT/car X X X
          org.apache.geronimo.configs/j2ee-server/2.1-SNAPSHOT/car X X X
          org.apache.geronimo.configs/j2ee-system/2.1-SNAPSHOT/car X   X
          org.apache.geronimo.configs/jasper/2.1-SNAPSHOT/car X    
          org.apache.geronimo.configs/jee-specs/2.1-SNAPSHOT/car X X X
          org.apache.geronimo.configs/openejb/2.1-SNAPSHOT/car X X X
          org.apache.geronimo.configs/openjpa/2.1-SNAPSHOT/car X X X
          org.apache.geronimo.configs/rmi-naming/2.1-SNAPSHOT/car X X X
          org.apache.geronimo.configs/server-security-config/2.1-SNAPSHOT/car X X X
          org.apache.geronimo.configs/tomcat6/2.1-SNAPSHOT/car X    
          org.apache.geronimo.configs/tomcat6-deployer/2.1-SNAPSHOT/car X    
          org.apache.geronimo.configs/transaction/2.1-SNAPSHOT/car X X X
          org.apache.geronimo.configs/webservices-common/2.1-SNAPSHOT/car X X X
          org.apache.geronimo.configs/xmlbeans/2.1-SNAPSHOT/car X X X
          Show
          Joe Bohn added a comment - I've done some more investigation into this to discover the other system modules that cause problems for the console and/or the server. There are a number of components that fail with different results. Sometime the console is just no longer available. Other times the server itself is in a state where it can not be restarted. I also noticed that sometime a message precedes the stack trace on the console indicating the server stop signal has been received (when it really hasn't). Here's a list of the modules that cause problems when uninstalled and the types of problems. Most of the results are predictable (those that break the console or server) but there are a few surprises. config uninstalled console broken server broken shutdown message org.apache.geronimo.configs/activemq-broker/2.1-SNAPSHOT/car X X X org.apache.geronimo.configs/connector-deployer/2.1-SNAPSHOT/car X X   org.apache.geronimo.configs/geronimo-gbean-deployer/2.1-SNAPSHOT/car X     org.apache.geronimo.configs/j2ee-corba-yoko/2.1-SNAPSHOT/car X     org.apache.geronimo.configs/j2ee-deployer/2.1-SNAPSHOT/car X X   org.apache.geronimo.configs/j2ee-security/2.1-SNAPSHOT/car X X X org.apache.geronimo.configs/j2ee-server/2.1-SNAPSHOT/car X X X org.apache.geronimo.configs/j2ee-system/2.1-SNAPSHOT/car X   X org.apache.geronimo.configs/jasper/2.1-SNAPSHOT/car X     org.apache.geronimo.configs/jee-specs/2.1-SNAPSHOT/car X X X org.apache.geronimo.configs/openejb/2.1-SNAPSHOT/car X X X org.apache.geronimo.configs/openjpa/2.1-SNAPSHOT/car X X X org.apache.geronimo.configs/rmi-naming/2.1-SNAPSHOT/car X X X org.apache.geronimo.configs/server-security-config/2.1-SNAPSHOT/car X X X org.apache.geronimo.configs/tomcat6/2.1-SNAPSHOT/car X     org.apache.geronimo.configs/tomcat6-deployer/2.1-SNAPSHOT/car X     org.apache.geronimo.configs/transaction/2.1-SNAPSHOT/car X X X org.apache.geronimo.configs/webservices-common/2.1-SNAPSHOT/car X X X org.apache.geronimo.configs/xmlbeans/2.1-SNAPSHOT/car X X X
          Hide
          Donald Woods added a comment -

          Joe, are you uninstalling the config or just stopping the config?
          Matt's original text says stopping through the console, so are we comparing the same things here?

          Show
          Donald Woods added a comment - Joe, are you uninstalling the config or just stopping the config? Matt's original text says stopping through the console, so are we comparing the same things here?
          Hide
          Joe Bohn added a comment -

          Ahh ... thanks for pointing that out Donald. I spoke with Matt and I thought he said uninstall but it is true that the JIRA itself says stop. I'll try the stop scenarios as well. I think we take some action to prevent somebody from shooting themselves in the foot (without proper warning) for both stop and uninstall scenarios.

          Show
          Joe Bohn added a comment - Ahh ... thanks for pointing that out Donald. I spoke with Matt and I thought he said uninstall but it is true that the JIRA itself says stop. I'll try the stop scenarios as well. I think we take some action to prevent somebody from shooting themselves in the foot (without proper warning) for both stop and uninstall scenarios.
          Hide
          Vamsavardhana Reddy added a comment -

          Joe, I guess you are stopping/uninstalling the configurations through admin console. What happens when you stop/uninstall the configurations through command line deployer? Is the server broken in that case too?

          Show
          Vamsavardhana Reddy added a comment - Joe, I guess you are stopping/uninstalling the configurations through admin console. What happens when you stop/uninstall the configurations through command line deployer? Is the server broken in that case too?
          Hide
          Paul McMahan added a comment -

          GERONIMO-3443 looks like another manifestation of this problem

          Show
          Paul McMahan added a comment - GERONIMO-3443 looks like another manifestation of this problem
          Hide
          Joe Bohn added a comment -

          Uninstall breaks the server on those components listed regardless of it being initiated from the console or command line. I haven't yet run through all of the system modules but for openejb stopping only prevents the console from functioning and doesn't prevent the server from a restart. The console function can be easily restored in the stop scenario by a command line start of the console.

          Paul, Geronimo-3443 is somewhat related but I don't think it is directly related. It's a restart scenario. In our restart we must stop the specified component and all depent components (such as the console for DOJO) which is somewhat related to this issue. However, I think the real issue there is that in a restart scenario we only "restart" the subject component and do nothing more with components that were stopped with dependencies upon that component. I think the expected user behavior in that cause would be to restart not only the subject component but all components that were subsequently stopped due to dependencies.

          Show
          Joe Bohn added a comment - Uninstall breaks the server on those components listed regardless of it being initiated from the console or command line. I haven't yet run through all of the system modules but for openejb stopping only prevents the console from functioning and doesn't prevent the server from a restart. The console function can be easily restored in the stop scenario by a command line start of the console. Paul, Geronimo-3443 is somewhat related but I don't think it is directly related. It's a restart scenario. In our restart we must stop the specified component and all depent components (such as the console for DOJO) which is somewhat related to this issue. However, I think the real issue there is that in a restart scenario we only "restart" the subject component and do nothing more with components that were stopped with dependencies upon that component. I think the expected user behavior in that cause would be to restart not only the subject component but all components that were subsequently stopped due to dependencies.
          Hide
          Paul McMahan added a comment -

          However, I think the real issue there is that in a restart scenario we only "restart" the subject component and do nothing more with components that were stopped with dependencies upon that component. I think the expected user behavior in that cause would be to restart not only the subject component but all components that were subsequently stopped due to dependencies.

          Agreed. These two cases could be handled separately or we could consider generalizing the user interface for component lifecycle to address these and other potentially confusing scenarios that will arise all at one go. I think that right now the user interface is technically correct but is not intuitive. For the command line client maybe that is OK, but for the graphical UI we could allow the user to make more informed decisions by providing a better visual representation of the component hierarchy. Attaching the lifecycle controls to the Dependency Viewer might be a good first step. Also, the lifecycle controls for components that are in the console's dependency path could be disabled since they are required by the viewer itself (they can still be controlled from the CLI). Just throwing out some ideas.

          Show
          Paul McMahan added a comment - However, I think the real issue there is that in a restart scenario we only "restart" the subject component and do nothing more with components that were stopped with dependencies upon that component. I think the expected user behavior in that cause would be to restart not only the subject component but all components that were subsequently stopped due to dependencies. Agreed. These two cases could be handled separately or we could consider generalizing the user interface for component lifecycle to address these and other potentially confusing scenarios that will arise all at one go. I think that right now the user interface is technically correct but is not intuitive. For the command line client maybe that is OK, but for the graphical UI we could allow the user to make more informed decisions by providing a better visual representation of the component hierarchy. Attaching the lifecycle controls to the Dependency Viewer might be a good first step. Also, the lifecycle controls for components that are in the console's dependency path could be disabled since they are required by the viewer itself (they can still be controlled from the CLI). Just throwing out some ideas.
          Hide
          Joe Bohn added a comment -

          Agreed. These two cases could be handled separately or we could consider generalizing the user interface for component lifecycle to address these and other potentially confusing scenarios that will arise all at one go. I think that right now the user interface is technically correct but is not intuitive.

          I'm not as sure that either the UI or the command line are technically correct today regarding restart ... but it's probably a bike shed issue. I think a reasonable expectation of a user after a restart is that the system is in the same state WRT active components prior to the restart. If we choose to keep the current behavior then we need to do a better job warning the user of the consequences and help by listing the components that are stopped and not restarted.

          For the command line client maybe that is OK, but for the graphical UI we could allow the user to make more informed decisions by providing a better visual representation of the component hierarchy. Attaching the lifecycle controls to the Dependency Viewer might be a good first step.

          Perhaps ... but the dependency viewer sometimes make it difficult to locate the module that you want to operate on and the dependencies are actually inverted from what is needed for these operations (the current dependencies show what cars/jars this module is dependent upon rather than which modules are dependent upon it which would be the ones affected by the operation).

          Also, the lifecycle controls for components that are in the console's dependency path could be disabled since they are required by the viewer itself (they can still be controlled from the CLI). Just throwing out some ideas.

          Yes, that is certainly the quick and easy way out ... which is also why I did some digging to understand the components that actually create problems for the console and/or the server. The real answer here is I think I need to take this discussion to the dev list soon but I'd like to get some more details first.

          Show
          Joe Bohn added a comment - Agreed. These two cases could be handled separately or we could consider generalizing the user interface for component lifecycle to address these and other potentially confusing scenarios that will arise all at one go. I think that right now the user interface is technically correct but is not intuitive. I'm not as sure that either the UI or the command line are technically correct today regarding restart ... but it's probably a bike shed issue. I think a reasonable expectation of a user after a restart is that the system is in the same state WRT active components prior to the restart. If we choose to keep the current behavior then we need to do a better job warning the user of the consequences and help by listing the components that are stopped and not restarted. For the command line client maybe that is OK, but for the graphical UI we could allow the user to make more informed decisions by providing a better visual representation of the component hierarchy. Attaching the lifecycle controls to the Dependency Viewer might be a good first step. Perhaps ... but the dependency viewer sometimes make it difficult to locate the module that you want to operate on and the dependencies are actually inverted from what is needed for these operations (the current dependencies show what cars/jars this module is dependent upon rather than which modules are dependent upon it which would be the ones affected by the operation). Also, the lifecycle controls for components that are in the console's dependency path could be disabled since they are required by the viewer itself (they can still be controlled from the CLI). Just throwing out some ideas. Yes, that is certainly the quick and easy way out ... which is also why I did some digging to understand the components that actually create problems for the console and/or the server. The real answer here is I think I need to take this discussion to the dev list soon but I'd like to get some more details first.
          Hide
          Joe Bohn added a comment -

          This issue has been resolved by disabling potentially distruptive actions on Geronimo provided components with a checkbox override to enable the actions for expert users. In addition to this there are new, detailed challenges when you attempt a potentially distructive action on a Geronimo provided component.

          Show
          Joe Bohn added a comment - This issue has been resolved by disabling potentially distruptive actions on Geronimo provided components with a checkbox override to enable the actions for expert users. In addition to this there are new, detailed challenges when you attempt a potentially distructive action on a Geronimo provided component.
          Hide
          Donald Woods added a comment -

          updated Fixed For field

          Show
          Donald Woods added a comment - updated Fixed For field

            People

            • Assignee:
              Joe Bohn
              Reporter:
              Matt Hogstrom
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development