[jira] Assigned: (GERONIMO-3913) NPE in org.apache.geronimo.security.SubjectId.hashCode() caused by incorrect JAVA_HOME or JRE_HOME
[ https://issues.apache.org/jira/browse/GERONIMO-3913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] toby cabot reassigned GERONIMO-3913: Assignee: Kevan Miller (was: toby cabot) Hi Kevan, please take a look at your leisure and let me know if this fix looks OK. Thanks! > NPE in org.apache.geronimo.security.SubjectId.hashCode() caused by incorrect > JAVA_HOME or JRE_HOME > -- > > Key: GERONIMO-3913 > URL: https://issues.apache.org/jira/browse/GERONIMO-3913 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.0.1, 2.0.2, 2.1 >Reporter: Kevan Miller >Assignee: Kevan Miller > Fix For: 2.0.2, 2.1 > > Attachments: bug-3913-2.0.2-patch.txt, g2-trace.txt > > > An incorrect setting of JRE_HOME or JAVA_HOME can cause the following error. > We should indicate to users the potential cause of the problem. Known to be a > problem with 2.0.x, depending on the method used to start geronimo, may be a > problem with 2.1 > ERROR [org.apache.geronimo.gbean.runtime.GBeanInstanceState] [main] Error > while starting; GBean is now in the FAILED state: > abstractName="org.apache.geronimo.configs/webconsole-jetty6/2.0.1/car?J2EEApplication=org.apache.geronimo.configs/webconsole-jetty6/2.0.1/car,j2eeType=JACCManager,name=JACCManager" > java.lang.ExceptionInInitializerError >at > org.apache.geronimo.security.jacc.ApplicationPolicyConfigurationManager.(ApplicationPolicyConfigurationManager.java:109) >at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) >at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) >at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) >at java.lang.reflect.Constructor.newInstance(Constructor.java:494) >at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:946) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) >at > org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:539) >at > org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) >at > org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) >at > org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) >at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176) >at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44) >at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) >at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:553) >at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) >at > org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:448) >at > org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) >at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:530) >at > org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke() >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$$e380e87b.startConfiguration() >
[jira] Updated: (GERONIMO-3913) NPE in org.apache.geronimo.security.SubjectId.hashCode() caused by incorrect JAVA_HOME or JRE_HOME
[ https://issues.apache.org/jira/browse/GERONIMO-3913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] toby cabot updated GERONIMO-3913: - Patch Info: [Patch Available] > NPE in org.apache.geronimo.security.SubjectId.hashCode() caused by incorrect > JAVA_HOME or JRE_HOME > -- > > Key: GERONIMO-3913 > URL: https://issues.apache.org/jira/browse/GERONIMO-3913 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.0.1, 2.0.2, 2.1 >Reporter: Kevan Miller >Assignee: Kevan Miller > Fix For: 2.0.2, 2.1 > > Attachments: bug-3913-2.0.2-patch.txt, g2-trace.txt > > > An incorrect setting of JRE_HOME or JAVA_HOME can cause the following error. > We should indicate to users the potential cause of the problem. Known to be a > problem with 2.0.x, depending on the method used to start geronimo, may be a > problem with 2.1 > ERROR [org.apache.geronimo.gbean.runtime.GBeanInstanceState] [main] Error > while starting; GBean is now in the FAILED state: > abstractName="org.apache.geronimo.configs/webconsole-jetty6/2.0.1/car?J2EEApplication=org.apache.geronimo.configs/webconsole-jetty6/2.0.1/car,j2eeType=JACCManager,name=JACCManager" > java.lang.ExceptionInInitializerError >at > org.apache.geronimo.security.jacc.ApplicationPolicyConfigurationManager.(ApplicationPolicyConfigurationManager.java:109) >at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) >at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) >at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) >at java.lang.reflect.Constructor.newInstance(Constructor.java:494) >at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:946) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) >at > org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:539) >at > org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) >at > org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) >at > org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) >at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176) >at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44) >at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) >at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:553) >at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) >at > org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:448) >at > org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) >at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:530) >at > org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke() >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$$e380e87b.startConfiguration() >at > org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:156) >at > org.apa
[jira] Updated: (GERONIMO-3913) NPE in org.apache.geronimo.security.SubjectId.hashCode() caused by incorrect JAVA_HOME or JRE_HOME
[ https://issues.apache.org/jira/browse/GERONIMO-3913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] toby cabot updated GERONIMO-3913: - Attachment: bug-3913-2.0.2-patch.txt The problem was that org.apache.geronimo.security.ContextManager silently ignored exceptions that "can't" happen. I added some code to catch the exceptions and re-throw as unchecked exceptions with a hopefully helpful error message. I also added code to prevent the NPE that Kevan saw, but that isn't as important now since the bug no longer gets that far. Here's a patch for 2.0.2. > NPE in org.apache.geronimo.security.SubjectId.hashCode() caused by incorrect > JAVA_HOME or JRE_HOME > -- > > Key: GERONIMO-3913 > URL: https://issues.apache.org/jira/browse/GERONIMO-3913 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.0.1, 2.0.2, 2.1 >Reporter: Kevan Miller >Assignee: toby cabot > Fix For: 2.0.2, 2.1 > > Attachments: bug-3913-2.0.2-patch.txt, g2-trace.txt > > > An incorrect setting of JRE_HOME or JAVA_HOME can cause the following error. > We should indicate to users the potential cause of the problem. Known to be a > problem with 2.0.x, depending on the method used to start geronimo, may be a > problem with 2.1 > ERROR [org.apache.geronimo.gbean.runtime.GBeanInstanceState] [main] Error > while starting; GBean is now in the FAILED state: > abstractName="org.apache.geronimo.configs/webconsole-jetty6/2.0.1/car?J2EEApplication=org.apache.geronimo.configs/webconsole-jetty6/2.0.1/car,j2eeType=JACCManager,name=JACCManager" > java.lang.ExceptionInInitializerError >at > org.apache.geronimo.security.jacc.ApplicationPolicyConfigurationManager.(ApplicationPolicyConfigurationManager.java:109) >at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) >at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) >at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) >at java.lang.reflect.Constructor.newInstance(Constructor.java:494) >at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:946) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) >at > org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:539) >at > org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) >at > org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) >at > org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) >at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176) >at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44) >at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) >at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:553) >at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) >at > org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:448) >at > org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) >at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:530) >at > org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke() >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.RawOperationI
[jira] Updated: (GERONIMO-3913) NPE in org.apache.geronimo.security.SubjectId.hashCode() caused by incorrect JAVA_HOME or JRE_HOME
[ https://issues.apache.org/jira/browse/GERONIMO-3913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] toby cabot updated GERONIMO-3913: - Attachment: g2-trace.txt Here's what the stack trace looks like now. It's still fugly but now there's a nugget of info in the "caused by" part. > NPE in org.apache.geronimo.security.SubjectId.hashCode() caused by incorrect > JAVA_HOME or JRE_HOME > -- > > Key: GERONIMO-3913 > URL: https://issues.apache.org/jira/browse/GERONIMO-3913 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.0.1, 2.0.2, 2.1 >Reporter: Kevan Miller >Assignee: toby cabot > Fix For: 2.0.2, 2.1 > > Attachments: bug-3913-2.0.2-patch.txt, g2-trace.txt > > > An incorrect setting of JRE_HOME or JAVA_HOME can cause the following error. > We should indicate to users the potential cause of the problem. Known to be a > problem with 2.0.x, depending on the method used to start geronimo, may be a > problem with 2.1 > ERROR [org.apache.geronimo.gbean.runtime.GBeanInstanceState] [main] Error > while starting; GBean is now in the FAILED state: > abstractName="org.apache.geronimo.configs/webconsole-jetty6/2.0.1/car?J2EEApplication=org.apache.geronimo.configs/webconsole-jetty6/2.0.1/car,j2eeType=JACCManager,name=JACCManager" > java.lang.ExceptionInInitializerError >at > org.apache.geronimo.security.jacc.ApplicationPolicyConfigurationManager.(ApplicationPolicyConfigurationManager.java:109) >at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) >at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) >at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) >at java.lang.reflect.Constructor.newInstance(Constructor.java:494) >at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:946) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) >at > org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:539) >at > org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) >at > org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) >at > org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) >at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176) >at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44) >at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) >at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:553) >at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) >at > org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:448) >at > org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) >at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:530) >at > org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke() >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$$e380e87b.startConfiguration() >
[jira] Assigned: (GERONIMO-3913) NPE in org.apache.geronimo.security.SubjectId.hashCode() caused by incorrect JAVA_HOME or JRE_HOME
[ https://issues.apache.org/jira/browse/GERONIMO-3913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] toby cabot reassigned GERONIMO-3913: Assignee: toby cabot > NPE in org.apache.geronimo.security.SubjectId.hashCode() caused by incorrect > JAVA_HOME or JRE_HOME > -- > > Key: GERONIMO-3913 > URL: https://issues.apache.org/jira/browse/GERONIMO-3913 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.0.1, 2.0.2, 2.1 >Reporter: Kevan Miller >Assignee: toby cabot > Fix For: 2.0.2, 2.1 > > > An incorrect setting of JRE_HOME or JAVA_HOME can cause the following error. > We should indicate to users the potential cause of the problem. Known to be a > problem with 2.0.x, depending on the method used to start geronimo, may be a > problem with 2.1 > ERROR [org.apache.geronimo.gbean.runtime.GBeanInstanceState] [main] Error > while starting; GBean is now in the FAILED state: > abstractName="org.apache.geronimo.configs/webconsole-jetty6/2.0.1/car?J2EEApplication=org.apache.geronimo.configs/webconsole-jetty6/2.0.1/car,j2eeType=JACCManager,name=JACCManager" > java.lang.ExceptionInInitializerError >at > org.apache.geronimo.security.jacc.ApplicationPolicyConfigurationManager.(ApplicationPolicyConfigurationManager.java:109) >at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) >at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) >at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) >at java.lang.reflect.Constructor.newInstance(Constructor.java:494) >at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:946) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) >at > org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:539) >at > org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) >at > org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) >at > org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) >at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176) >at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44) >at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) >at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:553) >at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) >at > org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:448) >at > org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) >at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:530) >at > org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke() >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$$e380e87b.startConfiguration() >at > org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:156) >at > org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:7
[jira] Commented: (GERONIMO-3913) NPE in org.apache.geronimo.security.SubjectId.hashCode() caused by incorrect JAVA_HOME or JRE_HOME
[ https://issues.apache.org/jira/browse/GERONIMO-3913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583831#action_12583831 ] toby cabot commented on GERONIMO-3913: -- I've seen this before so I'll take a look. > NPE in org.apache.geronimo.security.SubjectId.hashCode() caused by incorrect > JAVA_HOME or JRE_HOME > -- > > Key: GERONIMO-3913 > URL: https://issues.apache.org/jira/browse/GERONIMO-3913 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.0.1, 2.0.2, 2.1 >Reporter: Kevan Miller >Assignee: toby cabot > Fix For: 2.0.2, 2.1 > > > An incorrect setting of JRE_HOME or JAVA_HOME can cause the following error. > We should indicate to users the potential cause of the problem. Known to be a > problem with 2.0.x, depending on the method used to start geronimo, may be a > problem with 2.1 > ERROR [org.apache.geronimo.gbean.runtime.GBeanInstanceState] [main] Error > while starting; GBean is now in the FAILED state: > abstractName="org.apache.geronimo.configs/webconsole-jetty6/2.0.1/car?J2EEApplication=org.apache.geronimo.configs/webconsole-jetty6/2.0.1/car,j2eeType=JACCManager,name=JACCManager" > java.lang.ExceptionInInitializerError >at > org.apache.geronimo.security.jacc.ApplicationPolicyConfigurationManager.(ApplicationPolicyConfigurationManager.java:109) >at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) >at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) >at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) >at java.lang.reflect.Constructor.newInstance(Constructor.java:494) >at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:946) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) >at > org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:539) >at > org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) >at > org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) >at > org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) >at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176) >at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44) >at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) >at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:553) >at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) >at > org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:448) >at > org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) >at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:530) >at > org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke() >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$$e380e87b.startConfiguration() >at > org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:156) >at > org.apa
[jira] Assigned: (GERONIMO-3806) CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB jar
[
https://issues.apache.org/jira/browse/GERONIMO-3806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
toby cabot reassigned GERONIMO-3806:
Assignee: Manu T George (was: toby cabot)
> CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB
> jar
> -
>
> Key: GERONIMO-3806
> URL: https://issues.apache.org/jira/browse/GERONIMO-3806
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: deployment
>Affects Versions: 2.0.2, 2.1, 2.1.1, 2.2
> Environment: Windows XP SP2
>Reporter: toby cabot
>Assignee: Manu T George
>Priority: Minor
> Fix For: 2.1.1, 2.2
>
> Attachments: GERONIMO-3806-2.0.2.patch, GERONIMO-3806_r638814.patch
>
>
> During deployment of one of my EJB jar files in my EAR, I get the following
> WARN messages:
> {code}
> 14:29:37,425 WARN [AdminObjectRefBuilder] Failed to build reference to Admin
> object reference [jms/UnsequencedDestination, jms/MailQueue,
> jms/InboundEventQueue, jms/OutboundQueue, jms/SystemQueue, jms/ActionQueue,
> jms/SequencedDestination, jms/InboundIntegrationQueue,
> jms/OutboundEventQueue] defined in plan file, reason - corresponding entry in
> deployment descriptor missing.
> 14:29:37,440 WARN [ResourceRefBuilder] Failed to build reference to resource
> reference [jms/ConnectionFactory, jms/QueueConnectionFactory,
> mail/MailSession, jms/TopicConnectionFactory] defined in plan file, reason -
> corresponding entry in deployment descriptor missing.
> {code}
> This occurs at the point in the following point in the stack:
> {code}
> AdminObjectRefBuilder.buildNaming(XmlObject, XmlObject, Module, Map) line: 160
> {code}
> The "specDD" that is passed in is a XML fragment for a specific session bean.
> However, the "plan" that is passed in contains all the resource-ref and
> resource-env-ref elements in the openejb-jar.xml plan. Therefore, the
> "refMap" variable does not get completely emptied out, since the specific
> session bean will only contain a subset of the resource-env-refs that are
> defined in the plan.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3806) CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB jar
[
https://issues.apache.org/jira/browse/GERONIMO-3806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
toby cabot updated GERONIMO-3806:
-
Attachment: (was: bug3806-patch.txt)
> CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB
> jar
> -
>
> Key: GERONIMO-3806
> URL: https://issues.apache.org/jira/browse/GERONIMO-3806
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: deployment
>Affects Versions: 2.0.2, 2.1, 2.1.1, 2.2
> Environment: Windows XP SP2
>Reporter: toby cabot
>Assignee: toby cabot
>Priority: Minor
> Fix For: 2.1.1, 2.2
>
> Attachments: GERONIMO-3806-2.0.2.patch, GERONIMO-3806_r638814.patch
>
>
> During deployment of one of my EJB jar files in my EAR, I get the following
> WARN messages:
> {code}
> 14:29:37,425 WARN [AdminObjectRefBuilder] Failed to build reference to Admin
> object reference [jms/UnsequencedDestination, jms/MailQueue,
> jms/InboundEventQueue, jms/OutboundQueue, jms/SystemQueue, jms/ActionQueue,
> jms/SequencedDestination, jms/InboundIntegrationQueue,
> jms/OutboundEventQueue] defined in plan file, reason - corresponding entry in
> deployment descriptor missing.
> 14:29:37,440 WARN [ResourceRefBuilder] Failed to build reference to resource
> reference [jms/ConnectionFactory, jms/QueueConnectionFactory,
> mail/MailSession, jms/TopicConnectionFactory] defined in plan file, reason -
> corresponding entry in deployment descriptor missing.
> {code}
> This occurs at the point in the following point in the stack:
> {code}
> AdminObjectRefBuilder.buildNaming(XmlObject, XmlObject, Module, Map) line: 160
> {code}
> The "specDD" that is passed in is a XML fragment for a specific session bean.
> However, the "plan" that is passed in contains all the resource-ref and
> resource-env-ref elements in the openejb-jar.xml plan. Therefore, the
> "refMap" variable does not get completely emptied out, since the specific
> session bean will only contain a subset of the resource-env-refs that are
> defined in the plan.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3806) CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB jar
[
https://issues.apache.org/jira/browse/GERONIMO-3806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
toby cabot updated GERONIMO-3806:
-
Attachment: GERONIMO-3806-2.0.2.patch
Hi Manu, thanks for giving this your attention.
I tried your patch and it had the same problem as the old code, i.e. it
displayed the spurious warnings. The problem appears to be that a resource ref
might be resolved after you've added its name to unresolvedRefs.
I modified your patch so it applies to 2.0.2 (which is what I'm using) and
added a line to take the name out of unresolvedRefs if we find it later. That
works for my application. I also added back the debug line that I found useful
in looking for the problem.
Thanks!
Toby
> CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB
> jar
> -
>
> Key: GERONIMO-3806
> URL: https://issues.apache.org/jira/browse/GERONIMO-3806
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: deployment
>Affects Versions: 2.0.2, 2.1, 2.1.1, 2.2
> Environment: Windows XP SP2
>Reporter: toby cabot
>Assignee: toby cabot
>Priority: Minor
> Fix For: 2.1.1, 2.2
>
> Attachments: GERONIMO-3806-2.0.2.patch, GERONIMO-3806_r638814.patch
>
>
> During deployment of one of my EJB jar files in my EAR, I get the following
> WARN messages:
> {code}
> 14:29:37,425 WARN [AdminObjectRefBuilder] Failed to build reference to Admin
> object reference [jms/UnsequencedDestination, jms/MailQueue,
> jms/InboundEventQueue, jms/OutboundQueue, jms/SystemQueue, jms/ActionQueue,
> jms/SequencedDestination, jms/InboundIntegrationQueue,
> jms/OutboundEventQueue] defined in plan file, reason - corresponding entry in
> deployment descriptor missing.
> 14:29:37,440 WARN [ResourceRefBuilder] Failed to build reference to resource
> reference [jms/ConnectionFactory, jms/QueueConnectionFactory,
> mail/MailSession, jms/TopicConnectionFactory] defined in plan file, reason -
> corresponding entry in deployment descriptor missing.
> {code}
> This occurs at the point in the following point in the stack:
> {code}
> AdminObjectRefBuilder.buildNaming(XmlObject, XmlObject, Module, Map) line: 160
> {code}
> The "specDD" that is passed in is a XML fragment for a specific session bean.
> However, the "plan" that is passed in contains all the resource-ref and
> resource-env-ref elements in the openejb-jar.xml plan. Therefore, the
> "refMap" variable does not get completely emptied out, since the specific
> session bean will only contain a subset of the resource-env-refs that are
> defined in the plan.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3454) Jetty assembly does not start using Java 6 runtime
[ https://issues.apache.org/jira/browse/GERONIMO-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567185#action_12567185 ] toby cabot commented on GERONIMO-3454: -- Geronimo 2.0.2 works for me with Java 1.6.0_01 on Centos 5.1. The "[" character in the URI above is invalid, but I wonder if this hasn't been fixed already. > Jetty assembly does not start using Java 6 runtime > -- > > Key: GERONIMO-3454 > URL: https://issues.apache.org/jira/browse/GERONIMO-3454 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.0.1 >Reporter: Kevan Miller > Fix For: 2.0.x > > > I get the following startup error on Mac OS X running Java 6 with the Jetty > assembly. I don't get the error running Tomcat. > [*- ] 79% 13s Loading org.apache.gero...ERROR - > Error while starting; GBean is now in the FAILED state: > abstractName="org.apache.geronimo.configs/webconsole-jetty6/2.0.2-SNAPSHOT/car?configurationName=org.apache.geronimo.configs/webconsole-jetty6/2.0.2-SNAPSHOT/car" > org.apache.geronimo.kernel.config.InvalidConfigException: Unable to > deserialize GBeanState in classloader: > [org.apache.geronimo.kernel.config.MultiParentClassLoader > id=org.apache.geronimo.configs/webconsole-jetty6_standard.war/2.0.2-SNAPSHOT/car] > at > org.apache.geronimo.kernel.config.SerializedGBeanState.loadGBeans(SerializedGBeanState.java:124) > at > org.apache.geronimo.kernel.config.SerializedGBeanState.getGBeans(SerializedGBeanState.java:65) > at > org.apache.geronimo.kernel.config.ConfigurationData.getGBeans(ConfigurationData.java:171) > at > org.apache.geronimo.kernel.config.Configuration.(Configuration.java:278) > at > org.apache.geronimo.kernel.config.Configuration.(Configuration.java:295) > at sun.reflect.GeneratedConstructorAccessor172.newInstance(Unknown > Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:506) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:946) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:539) > at > org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:361) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:160) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:310) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:278) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke() > 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.gbean.GBeanLifecycle$$EnhancerByCGLIB$$ae04acb9.loadConfiguration() > 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: java.io.IOException: Unable to deserialize AbstractName for > GBeanData of type org.apache.geronimo.jetty6.JettyFilterMapping > at > org.apache.geronimo.gbean.GBeanData$V0Externalizable.readExternal(GBeanData.java:279) > at > org.apache.geronimo.gbean.GBeanData.readExternal(GBeanData.java:247) > at > org.apache.geronimo.kernel.config.SerializedGBeanState.loadGBeans(Serial
[jira] Updated: (GERONIMO-3830) GeronimoPropertiesFileMappedPasswordCredentialLoginModuleTest assumes a specific Set ordering
[ https://issues.apache.org/jira/browse/GERONIMO-3830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] toby cabot updated GERONIMO-3830: - Attachment: sec-unittest-diff.txt Patch to use a TreeSet so the Iterator can be counted on to iterate over the contents in a specific order. > GeronimoPropertiesFileMappedPasswordCredentialLoginModuleTest assumes a > specific Set ordering > - > > Key: GERONIMO-3830 > URL: https://issues.apache.org/jira/browse/GERONIMO-3830 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: security >Affects Versions: 2.0.2 > Environment: Java 1.6 > Fedora 8 >Reporter: toby cabot >Priority: Minor > Attachments: sec-unittest-diff.txt > > > GeronimoPropertiesFileMappedPasswordCredentialLoginModuleTest fails with Java > 1.6 because it assumes that an Iterator over a Set will have a specific > ordering. Evidently Java 1.6's HashSet is different enough than 1.5's that > it orders its contents differently. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3830) GeronimoPropertiesFileMappedPasswordCredentialLoginModuleTest assumes a specific Set ordering
GeronimoPropertiesFileMappedPasswordCredentialLoginModuleTest assumes a specific Set ordering - Key: GERONIMO-3830 URL: https://issues.apache.org/jira/browse/GERONIMO-3830 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: security Affects Versions: 2.0.2 Environment: Java 1.6 Fedora 8 Reporter: toby cabot Priority: Minor Attachments: sec-unittest-diff.txt GeronimoPropertiesFileMappedPasswordCredentialLoginModuleTest fails with Java 1.6 because it assumes that an Iterator over a Set will have a specific ordering. Evidently Java 1.6's HashSet is different enough than 1.5's that it orders its contents differently. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3806) CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB jar
[
https://issues.apache.org/jira/browse/GERONIMO-3806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
toby cabot updated GERONIMO-3806:
-
Component/s: deployment
Regression: [Regression]
> CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB
> jar
> -
>
> Key: GERONIMO-3806
> URL: https://issues.apache.org/jira/browse/GERONIMO-3806
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: deployment
>Affects Versions: 2.0.2
> Environment: Windows XP SP2
>Reporter: toby cabot
>Assignee: Vamsavardhana Reddy
>Priority: Minor
> Attachments: bug3806-patch.txt
>
>
> During deployment of one of my EJB jar files in my EAR, I get the following
> WARN messages:
> {code}
> 14:29:37,425 WARN [AdminObjectRefBuilder] Failed to build reference to Admin
> object reference [jms/UnsequencedDestination, jms/MailQueue,
> jms/InboundEventQueue, jms/OutboundQueue, jms/SystemQueue, jms/ActionQueue,
> jms/SequencedDestination, jms/InboundIntegrationQueue,
> jms/OutboundEventQueue] defined in plan file, reason - corresponding entry in
> deployment descriptor missing.
> 14:29:37,440 WARN [ResourceRefBuilder] Failed to build reference to resource
> reference [jms/ConnectionFactory, jms/QueueConnectionFactory,
> mail/MailSession, jms/TopicConnectionFactory] defined in plan file, reason -
> corresponding entry in deployment descriptor missing.
> {code}
> This occurs at the point in the following point in the stack:
> {code}
> AdminObjectRefBuilder.buildNaming(XmlObject, XmlObject, Module, Map) line: 160
> {code}
> The "specDD" that is passed in is a XML fragment for a specific session bean.
> However, the "plan" that is passed in contains all the resource-ref and
> resource-env-ref elements in the openejb-jar.xml plan. Therefore, the
> "refMap" variable does not get completely emptied out, since the specific
> session bean will only contain a subset of the resource-env-refs that are
> defined in the plan.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3806) CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB jar
[
https://issues.apache.org/jira/browse/GERONIMO-3806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
toby cabot updated GERONIMO-3806:
-
Fix Version/s: (was: 2.0.2)
(was: 2.1)
Patch Info: [Patch Available]
Affects Version/s: (was: 2.0-M6)
2.0.2
> CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB
> jar
> -
>
> Key: GERONIMO-3806
> URL: https://issues.apache.org/jira/browse/GERONIMO-3806
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: deployment
>Affects Versions: 2.0.2
> Environment: Windows XP SP2
>Reporter: toby cabot
>Assignee: Vamsavardhana Reddy
>Priority: Minor
> Attachments: bug3806-patch.txt
>
>
> During deployment of one of my EJB jar files in my EAR, I get the following
> WARN messages:
> {code}
> 14:29:37,425 WARN [AdminObjectRefBuilder] Failed to build reference to Admin
> object reference [jms/UnsequencedDestination, jms/MailQueue,
> jms/InboundEventQueue, jms/OutboundQueue, jms/SystemQueue, jms/ActionQueue,
> jms/SequencedDestination, jms/InboundIntegrationQueue,
> jms/OutboundEventQueue] defined in plan file, reason - corresponding entry in
> deployment descriptor missing.
> 14:29:37,440 WARN [ResourceRefBuilder] Failed to build reference to resource
> reference [jms/ConnectionFactory, jms/QueueConnectionFactory,
> mail/MailSession, jms/TopicConnectionFactory] defined in plan file, reason -
> corresponding entry in deployment descriptor missing.
> {code}
> This occurs at the point in the following point in the stack:
> {code}
> AdminObjectRefBuilder.buildNaming(XmlObject, XmlObject, Module, Map) line: 160
> {code}
> The "specDD" that is passed in is a XML fragment for a specific session bean.
> However, the "plan" that is passed in contains all the resource-ref and
> resource-env-ref elements in the openejb-jar.xml plan. Therefore, the
> "refMap" variable does not get completely emptied out, since the specific
> session bean will only contain a subset of the resource-env-refs that are
> defined in the plan.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3806) CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB jar
[
https://issues.apache.org/jira/browse/GERONIMO-3806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
toby cabot updated GERONIMO-3806:
-
Attachment: bug3806-patch.txt
Here's a patch that quiets the messages in my case (and adds a couple of debug
messages that I found helpful). With this patch applied and log4j screwed down
to DEBUG I get:
16:36:46,764 DEBUG [ResourceRefBuilder] trying to resolve JobCF, type
reva.job.ra.ConnectionFactory, resourceRef null
16:36:46,766 DEBUG [ResourceRefBuilder] initial 0 unresolved 0 refmap 0
16:36:47,004 DEBUG [ResourceRefBuilder] trying to resolve JobCF, type
reva.job.ra.ConnectionFactory, resourceRef null
16:36:47,005 DEBUG [ResourceRefBuilder] initial 0 unresolved 0 refmap 0
... and no warnings.
Someone who understands the operation of the buildNaming() method better than I
do should inspect the code but I believe (from inspection) that it shouldn't
break the case that GERONIMO-3248 solved.
> CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB
> jar
> -
>
> Key: GERONIMO-3806
> URL: https://issues.apache.org/jira/browse/GERONIMO-3806
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Affects Versions: 2.0-M6
> Environment: Windows XP SP2
>Reporter: toby cabot
>Assignee: Vamsavardhana Reddy
>Priority: Minor
> Fix For: 2.0.2, 2.1
>
> Attachments: bug3806-patch.txt
>
>
> During deployment of one of my EJB jar files in my EAR, I get the following
> WARN messages:
> {code}
> 14:29:37,425 WARN [AdminObjectRefBuilder] Failed to build reference to Admin
> object reference [jms/UnsequencedDestination, jms/MailQueue,
> jms/InboundEventQueue, jms/OutboundQueue, jms/SystemQueue, jms/ActionQueue,
> jms/SequencedDestination, jms/InboundIntegrationQueue,
> jms/OutboundEventQueue] defined in plan file, reason - corresponding entry in
> deployment descriptor missing.
> 14:29:37,440 WARN [ResourceRefBuilder] Failed to build reference to resource
> reference [jms/ConnectionFactory, jms/QueueConnectionFactory,
> mail/MailSession, jms/TopicConnectionFactory] defined in plan file, reason -
> corresponding entry in deployment descriptor missing.
> {code}
> This occurs at the point in the following point in the stack:
> {code}
> AdminObjectRefBuilder.buildNaming(XmlObject, XmlObject, Module, Map) line: 160
> {code}
> The "specDD" that is passed in is a XML fragment for a specific session bean.
> However, the "plan" that is passed in contains all the resource-ref and
> resource-env-ref elements in the openejb-jar.xml plan. Therefore, the
> "refMap" variable does not get completely emptied out, since the specific
> session bean will only contain a subset of the resource-env-refs that are
> defined in the plan.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3806) CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB jar
[
https://issues.apache.org/jira/browse/GERONIMO-3806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565545#action_12565545
]
toby cabot commented on GERONIMO-3806:
--
The fix for GERONIMO-3248 causes two warnings in the log when a webapp has a
resource-ref in web.xml to a resource adapter in the same .ear:
16:24:19,032 WARN [ResourceRefBuilder] Failed to build reference to resource
reference [] defined in plan file, reason - corresponding entry in deployment
descriptor missing.
16:24:19,311 WARN [ResourceRefBuilder] Failed to build reference to resource
reference [] defined in plan file, reason - corresponding entry in deployment
descriptor missing.
This worked OK prior to r572902.
> CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB
> jar
> -
>
> Key: GERONIMO-3806
> URL: https://issues.apache.org/jira/browse/GERONIMO-3806
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Affects Versions: 2.0-M6
> Environment: Windows XP SP2
>Reporter: toby cabot
>Assignee: Vamsavardhana Reddy
>Priority: Minor
> Fix For: 2.0.2, 2.1
>
>
> During deployment of one of my EJB jar files in my EAR, I get the following
> WARN messages:
> {code}
> 14:29:37,425 WARN [AdminObjectRefBuilder] Failed to build reference to Admin
> object reference [jms/UnsequencedDestination, jms/MailQueue,
> jms/InboundEventQueue, jms/OutboundQueue, jms/SystemQueue, jms/ActionQueue,
> jms/SequencedDestination, jms/InboundIntegrationQueue,
> jms/OutboundEventQueue] defined in plan file, reason - corresponding entry in
> deployment descriptor missing.
> 14:29:37,440 WARN [ResourceRefBuilder] Failed to build reference to resource
> reference [jms/ConnectionFactory, jms/QueueConnectionFactory,
> mail/MailSession, jms/TopicConnectionFactory] defined in plan file, reason -
> corresponding entry in deployment descriptor missing.
> {code}
> This occurs at the point in the following point in the stack:
> {code}
> AdminObjectRefBuilder.buildNaming(XmlObject, XmlObject, Module, Map) line: 160
> {code}
> The "specDD" that is passed in is a XML fragment for a specific session bean.
> However, the "plan" that is passed in contains all the resource-ref and
> resource-env-ref elements in the openejb-jar.xml plan. Therefore, the
> "refMap" variable does not get completely emptied out, since the specific
> session bean will only contain a subset of the resource-env-refs that are
> defined in the plan.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3806) CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB jar
CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB
jar
-
Key: GERONIMO-3806
URL: https://issues.apache.org/jira/browse/GERONIMO-3806
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Affects Versions: 2.0-M6
Environment: Windows XP SP2
Reporter: toby cabot
Assignee: Vamsavardhana Reddy
Priority: Minor
Fix For: 2.0.2, 2.1
During deployment of one of my EJB jar files in my EAR, I get the following
WARN messages:
{code}
14:29:37,425 WARN [AdminObjectRefBuilder] Failed to build reference to Admin
object reference [jms/UnsequencedDestination, jms/MailQueue,
jms/InboundEventQueue, jms/OutboundQueue, jms/SystemQueue, jms/ActionQueue,
jms/SequencedDestination, jms/InboundIntegrationQueue, jms/OutboundEventQueue]
defined in plan file, reason - corresponding entry in deployment descriptor
missing.
14:29:37,440 WARN [ResourceRefBuilder] Failed to build reference to resource
reference [jms/ConnectionFactory, jms/QueueConnectionFactory, mail/MailSession,
jms/TopicConnectionFactory] defined in plan file, reason - corresponding entry
in deployment descriptor missing.
{code}
This occurs at the point in the following point in the stack:
{code}
AdminObjectRefBuilder.buildNaming(XmlObject, XmlObject, Module, Map) line: 160
{code}
The "specDD" that is passed in is a XML fragment for a specific session bean.
However, the "plan" that is passed in contains all the resource-ref and
resource-env-ref elements in the openejb-jar.xml plan. Therefore, the "refMap"
variable does not get completely emptied out, since the specific session bean
will only contain a subset of the resource-env-refs that are defined in the
plan.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3421) ClassFinder classloader problems cause deployer to hang
[ https://issues.apache.org/jira/browse/GERONIMO-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] toby cabot updated GERONIMO-3421: - Attachment: deployer-message-patch.txt Here's a patch... > ClassFinder classloader problems cause deployer to hang > --- > > Key: GERONIMO-3421 > URL: https://issues.apache.org/jira/browse/GERONIMO-3421 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 2.0.x > Environment: Java(TM) 2 Runtime Environment, Standard Edition (build > 1.5.0_12-b04) > CentOS release 5 (Final) >Reporter: toby cabot >Priority: Minor > Fix For: 2.0.x > > Attachments: deployer-message-patch.txt > > > I build an ear file (containing a rar and a war) with a bug and tried to > deploy it. The deployer printed this stack trace to the console and then > hung: > Exception in thread "Thread-6" java.lang.NoClassDefFoundError: > org/jdom/JDOMException > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Class.java:2395) > at java.lang.Class.getDeclaredMethods(Class.java:1763) > at org.apache.xbean.finder.ClassFinder.(ClassFinder.java:162) > at > org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.createWebAppClassFinder(AbstractWebModuleBuilder.java:796) > at > org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.configureBasicWebModuleAttributes(AbstractWebModuleBuilder.java:813) > at > org.apache.geronimo.jetty6.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:337) > at > org.apache.geronimo.jetty6.deployment.JettyModuleBuilder$$FastClassByCGLIB$$1a00be84.invoke() > 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.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$35300f85.addGBeans() > at > org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:165) > at > org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$$FastClassByCGLIB$$d0c31844.invoke() > 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.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$35300f85.addGBeans() > at > org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:628) > at > org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke() > 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.j2ee.deployment.CorbaGBeanNameSource$$EnhancerByCGLIB$$6c5d899a.buildConfiguration() > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:304) > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:126) > at > org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMetho
[jira] Created: (GERONIMO-3421) ClassFinder classloader problems cause deployer to hang
ClassFinder classloader problems cause deployer to hang --- Key: GERONIMO-3421 URL: https://issues.apache.org/jira/browse/GERONIMO-3421 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment Affects Versions: 2.0.x Environment: Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) CentOS release 5 (Final) Reporter: toby cabot Priority: Minor Fix For: 2.0.x I build an ear file (containing a rar and a war) with a bug and tried to deploy it. The deployer printed this stack trace to the console and then hung: Exception in thread "Thread-6" java.lang.NoClassDefFoundError: org/jdom/JDOMException at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2395) at java.lang.Class.getDeclaredMethods(Class.java:1763) at org.apache.xbean.finder.ClassFinder.(ClassFinder.java:162) at org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.createWebAppClassFinder(AbstractWebModuleBuilder.java:796) at org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.configureBasicWebModuleAttributes(AbstractWebModuleBuilder.java:813) at org.apache.geronimo.jetty6.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:337) at org.apache.geronimo.jetty6.deployment.JettyModuleBuilder$$FastClassByCGLIB$$1a00be84.invoke() 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.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$35300f85.addGBeans() at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:165) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$$FastClassByCGLIB$$d0c31844.invoke() 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.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$35300f85.addGBeans() at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:628) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke() 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.j2ee.deployment.CorbaGBeanNameSource$$EnhancerByCGLIB$$6c5d899a.buildConfiguration() at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:304) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:126) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() 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:865) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.ja
[jira] Commented: (GERONIMO-3183) fix offline deployment in minimal configurations
[ https://issues.apache.org/jira/browse/GERONIMO-3183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497916 ] toby cabot commented on GERONIMO-3183: -- Chunks 5-8 fix these stack traces. They're unlikely to appear in normal operations but might be seen during development: [EMAIL PROTECTED]:/download$ geronimo-jetty6-minimal-2.0-SNAPSHOT/bin/deploy.sh -o list-modules Using GERONIMO_BASE: /download/geronimo-jetty6-minimal-2.0-SNAPSHOT Using GERONIMO_HOME: /download/geronimo-jetty6-minimal-2.0-SNAPSHOT Using GERONIMO_TMPDIR: var/temp Using JRE_HOME:/usr/java/jdk1.6.0_01/jre Error: Unable to query modules javax.enterprise.deploy.spi.exceptions.TargetException at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.getModules(JMXDeploymentManager.java:175) at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.getRunningModules(JMXDeploymentManager.java:136) at org.apache.geronimo.deployment.cli.CommandListModules.execute(CommandListModules.java:63) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:161) 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.deployer.DeployerCLI.main(DeployerCLI.java:31) Caused by: java.lang.NullPointerException at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.getModules(JMXDeploymentManager.java:149) ... 6 more ... and ... [EMAIL PROTECTED]:/download$ geronimo-jetty6-minimal-2.0-SNAPSHOT/bin/deploy.sh -o list-targets Using GERONIMO_BASE: /download/geronimo-jetty6-minimal-2.0-SNAPSHOT Using GERONIMO_HOME: /download/geronimo-jetty6-minimal-2.0-SNAPSHOT Using GERONIMO_TMPDIR: var/temp Using JRE_HOME:/usr/java/jdk1.6.0_01/jre Available Targets: Exception in thread "main" java.lang.NullPointerException at org.apache.geronimo.deployment.cli.CommandListTargets.execute(CommandListTargets.java:37) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:161) 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.deployer.DeployerCLI.main(DeployerCLI.java:31) > fix offline deployment in minimal configurations > > > Key: GERONIMO-3183 > URL: https://issues.apache.org/jira/browse/GERONIMO-3183 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 2.0-M6 > Environment: Fedora Core 4 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) >Reporter: toby cabot > Fix For: 2.0-M6 > > Attachments: minimal-offline-patch.txt > > > The deployer's offline mode in the jetty6-minimal and tomcat6-minimal > assemblies throws: > org.apache.geronimo.kernel.config.LifecycleException: load of > org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car failed > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:274) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:253) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:112) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke() > 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:127) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) > 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.gbean.GBeanLifecycle$$EnhancerByCGLIB$$26ac0679.loadConfiguration() > at > org.apache.geronimo.deployment.cli.OfflineDeployerStarter.startPersistentOfflineConfigurations(OfflineDeployerStarter.java:120) > at > org.apache.geronimo.deployment.cli.OfflineDeployerStarter.start(OfflineDeployerStarter.java:71) > at > org.apache.geronimo.deployment.cli.ServerConnection.
[jira] Updated: (GERONIMO-3183) fix offline deployment in minimal configurations
[ https://issues.apache.org/jira/browse/GERONIMO-3183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] toby cabot updated GERONIMO-3183: - Attachment: minimal-offline-patch.txt This patch makes a few changes. The most important are to add persistence-jpa10-deployer to the minimal assembly pom.xml files, add the j2ee-system config to the offline-deployer-config.xml files and sync the jetty and tomcat offline-deployer-config.xml files. Along the way I fixed some stack traces caused when no modules or targets can be found (which is not a typical condition) and improved the diagnostics when more than one ConfigurationManager is found (which is also not typical). > fix offline deployment in minimal configurations > > > Key: GERONIMO-3183 > URL: https://issues.apache.org/jira/browse/GERONIMO-3183 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 2.0-M6 > Environment: Fedora Core 4 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) >Reporter: toby cabot > Fix For: 2.0-M6 > > Attachments: minimal-offline-patch.txt > > > The deployer's offline mode in the jetty6-minimal and tomcat6-minimal > assemblies throws: > org.apache.geronimo.kernel.config.LifecycleException: load of > org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car failed > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:274) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:253) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:112) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke() > 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:127) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) > 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.gbean.GBeanLifecycle$$EnhancerByCGLIB$$26ac0679.loadConfiguration() > at > org.apache.geronimo.deployment.cli.OfflineDeployerStarter.startPersistentOfflineConfigurations(OfflineDeployerStarter.java:120) > at > org.apache.geronimo.deployment.cli.OfflineDeployerStarter.start(OfflineDeployerStarter.java:71) > at > org.apache.geronimo.deployment.cli.ServerConnection.startOfflineDeployer(ServerConnection.java:102) > at > org.apache.geronimo.deployment.cli.ServerConnection.(ServerConnection.java:90) > at > org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:158) > 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.deployer.DeployerCLI.main(DeployerCLI.java:31) > Caused by: org.apache.geronimo.kernel.config.NoSuchConfigException: > org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:457) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:271) > ... 19 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3183) fix offline deployment in minimal configurations
fix offline deployment in minimal configurations Key: GERONIMO-3183 URL: https://issues.apache.org/jira/browse/GERONIMO-3183 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment Affects Versions: 2.0-M6 Environment: Fedora Core 4 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) Reporter: toby cabot Fix For: 2.0-M6 The deployer's offline mode in the jetty6-minimal and tomcat6-minimal assemblies throws: org.apache.geronimo.kernel.config.LifecycleException: load of org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:274) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:253) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:112) at org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke() 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:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) 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.gbean.GBeanLifecycle$$EnhancerByCGLIB$$26ac0679.loadConfiguration() at org.apache.geronimo.deployment.cli.OfflineDeployerStarter.startPersistentOfflineConfigurations(OfflineDeployerStarter.java:120) at org.apache.geronimo.deployment.cli.OfflineDeployerStarter.start(OfflineDeployerStarter.java:71) at org.apache.geronimo.deployment.cli.ServerConnection.startOfflineDeployer(ServerConnection.java:102) at org.apache.geronimo.deployment.cli.ServerConnection.(ServerConnection.java:90) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:158) 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.deployer.DeployerCLI.main(DeployerCLI.java:31) Caused by: org.apache.geronimo.kernel.config.NoSuchConfigException: org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:457) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:271) ... 19 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3142) Geronimo / Jetty fails to startup under Sun Java 1.6 update 1
[ https://issues.apache.org/jira/browse/GERONIMO-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] toby cabot updated GERONIMO-3142: - Description: Vanilla Geronimo / Jetty 1.1.1 and 1.2-beta fail to start under JDK 1.6 update 1. JDK 1.5 seems to work though. Logs show ClassNotFoundException resolving key manager: ... Caused by: java.lang.ClassNotFoundException: [Ljavax.net.ssl.KeyManager; in classloader org.apache.geronimo.configs/jetty/1.2-beta/car at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:298) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.apache.geronimo.security.keystore.FileKeystoreManager.createSSLServerFactory(FileKeystoreManager.java:310) ... 53 more An easy way to disable SSL entirely would fix this for me ;) I'll attach relevant logs. was: Vanilla Geronimo / Jetty 1.1.1 and 1.2-beta fail to start under JDK 1.6 update 1. JDK 1.5 seems to work though. Logs show ClassNotFoundException resolving key manager: ... Caused by: java.lang.ClassNotFoundException: [Ljavax.net.ssl.KeyManager; in classloader org.apache.geronimo.configs/jetty/1.2-beta/car at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:298) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.apache.geronimo.security.keystore.FileKeystoreManager.createSSLServerFactory(FileKeystoreManager.java:310) ... 53 more An easy way to disable SSL entirely would fix this for me ;) I'll attach relevant logs. Patch Info: [Patch Available] > Geronimo / Jetty fails to startup under Sun Java 1.6 update 1 > - > > Key: GERONIMO-3142 > URL: https://issues.apache.org/jira/browse/GERONIMO-3142 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: JVM-compatibility >Affects Versions: 1.1.1, 1.2 > Environment: CentOS 5 (~RHEL 5), Java 1.6 update 1 >Reporter: Nikla Ratinen > Attachments: geronimo.log, geronimo.out, j6-patch-classloader.txt > > > Vanilla Geronimo / Jetty 1.1.1 and 1.2-beta fail to start under JDK 1.6 > update 1. JDK 1.5 seems to work though. > Logs show ClassNotFoundException resolving key manager: > ... > Caused by: java.lang.ClassNotFoundException: [Ljavax.net.ssl.KeyManager; in > classloader org.apache.geronimo.configs/jetty/1.2-beta/car > at > org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:298) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at > org.apache.geronimo.security.keystore.FileKeystoreManager.createSSLServerFactory(FileKeystoreManager.java:310) > ... 53 more > An easy way to disable SSL entirely would fix this for me ;) > I'll attach relevant logs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3142) Geronimo / Jetty fails to startup under Sun Java 1.6 update 1
[ https://issues.apache.org/jira/browse/GERONIMO-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] toby cabot updated GERONIMO-3142: - Attachment: j6-patch-classloader.txt This bug appears to be caused by a change in the behavior of ClassLoader.loadClass(). It used to accept array syntax but the version in 1.6 doesn't. I trolled Sun's bug tracker and saw some comments to the effect that it was never considered to be a documented feature and didn't always work, but it always worked for me until Java 1.6. Oh well. In any case, a couple of the comments suggested using Class.forName() instead, so I tried that and it seems to work for 1.5 and 1.6. Will probably work for 1.4 also but I haven't tried it since I'm working on the trunk for now. If anyone cares I can try the same fix on a branch. For background, see: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6446627 - Reading Serialized arrays of objects throws ClassNotFoundException - one of the comments suggests using the 3-argument Class.forName() instead. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6516909 - Clarify that ClassLoader.loadClass() is not meant to be used for array classes http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6249970 - clarification needed: binary name of array type in ClassLoader.loadClass http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4976356 - S1AS 7 calling ClassLoader.loadClass with array syntax > Geronimo / Jetty fails to startup under Sun Java 1.6 update 1 > - > > Key: GERONIMO-3142 > URL: https://issues.apache.org/jira/browse/GERONIMO-3142 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: JVM-compatibility >Affects Versions: 1.1.1, 1.2 > Environment: CentOS 5 (~RHEL 5), Java 1.6 update 1 >Reporter: Nikla Ratinen > Attachments: geronimo.log, geronimo.out, j6-patch-classloader.txt > > > Vanilla Geronimo / Jetty 1.1.1 and 1.2-beta fail to start under JDK 1.6 > update 1. JDK 1.5 seems to work though. > Logs show ClassNotFoundException resolving key manager: > ... > Caused by: java.lang.ClassNotFoundException: [Ljavax.net.ssl.KeyManager; in > classloader org.apache.geronimo.configs/jetty/1.2-beta/car > at > org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:298) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at > org.apache.geronimo.security.keystore.FileKeystoreManager.createSSLServerFactory(FileKeystoreManager.java:310) > ... 53 more > An easy way to disable SSL entirely would fix this for me ;) > I'll attach relevant logs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3171) java 1.6 compile fix for geronimo-naming mock DataSource class
[ https://issues.apache.org/jira/browse/GERONIMO-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496889 ] toby cabot commented on GERONIMO-3171: -- Donald, thanks for the lightning-fast response to this! At the moment I can build geronimo using 1.6 but haven't investigated running it. I see bug 3142 on this topic and I'll report anything else I find. > java 1.6 compile fix for geronimo-naming mock DataSource class > -- > > Key: GERONIMO-3171 > URL: https://issues.apache.org/jira/browse/GERONIMO-3171 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: naming >Affects Versions: 2.0-M6 > Environment: Java(TM) SE Runtime Environment (build 1.6.0_01-b06) > Fedora Core 4 >Reporter: toby cabot > Assigned To: Donald Woods >Priority: Trivial > Fix For: 2.0-M6 > > Attachments: j6-patch.txt > > > I was curious to see if Geronimo could build and/or run using java 1.6 so I > tried to build. There's a compile-time problem in one of the mock classes in > geronimo-naming caused by a change in 1.6's interfaces. > 1.5: http://java.sun.com/j2se/1.5.0/docs/api/javax/sql/DataSource.html > 1.6: http://java.sun.com/javase/6/docs/api/javax/sql/DataSource.html > I'll include a patch that adds the new required methods to the mock > DataSource. They seem to work fine in 1.5 also. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3171) java 1.6 compile fix for geronimo-naming mock DataSource class
[ https://issues.apache.org/jira/browse/GERONIMO-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] toby cabot updated GERONIMO-3171: - Summary: java 1.6 compile fix for geronimo-naming mock DataSource class (was: java 1.6 compile fix) > java 1.6 compile fix for geronimo-naming mock DataSource class > -- > > Key: GERONIMO-3171 > URL: https://issues.apache.org/jira/browse/GERONIMO-3171 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: naming >Affects Versions: 2.0-M6 > Environment: Java(TM) SE Runtime Environment (build 1.6.0_01-b06) > Fedora Core 4 >Reporter: toby cabot >Priority: Trivial > Fix For: 2.0-M6 > > Attachments: j6-patch.txt > > > I was curious to see if Geronimo could build and/or run using java 1.6 so I > tried to build. There's a compile-time problem in one of the mock classes in > geronimo-naming caused by a change in 1.6's interfaces. > 1.5: http://java.sun.com/j2se/1.5.0/docs/api/javax/sql/DataSource.html > 1.6: http://java.sun.com/javase/6/docs/api/javax/sql/DataSource.html > I'll include a patch that adds the new required methods to the mock > DataSource. They seem to work fine in 1.5 also. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3171) java 1.6 compile fix
[ https://issues.apache.org/jira/browse/GERONIMO-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] toby cabot updated GERONIMO-3171: - Attachment: j6-patch.txt > java 1.6 compile fix > > > Key: GERONIMO-3171 > URL: https://issues.apache.org/jira/browse/GERONIMO-3171 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: naming >Affects Versions: 2.0-M6 > Environment: Java(TM) SE Runtime Environment (build 1.6.0_01-b06) > Fedora Core 4 >Reporter: toby cabot >Priority: Trivial > Fix For: 2.0-M6 > > Attachments: j6-patch.txt > > > I was curious to see if Geronimo could build and/or run using java 1.6 so I > tried to build. There's a compile-time problem in one of the mock classes in > geronimo-naming caused by a change in 1.6's interfaces. > 1.5: http://java.sun.com/j2se/1.5.0/docs/api/javax/sql/DataSource.html > 1.6: http://java.sun.com/javase/6/docs/api/javax/sql/DataSource.html > I'll include a patch that adds the new required methods to the mock > DataSource. They seem to work fine in 1.5 also. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3171) java 1.6 compile fix
java 1.6 compile fix Key: GERONIMO-3171 URL: https://issues.apache.org/jira/browse/GERONIMO-3171 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: naming Affects Versions: 2.0-M6 Environment: Java(TM) SE Runtime Environment (build 1.6.0_01-b06) Fedora Core 4 Reporter: toby cabot Priority: Trivial Fix For: 2.0-M6 Attachments: j6-patch.txt I was curious to see if Geronimo could build and/or run using java 1.6 so I tried to build. There's a compile-time problem in one of the mock classes in geronimo-naming caused by a change in 1.6's interfaces. 1.5: http://java.sun.com/j2se/1.5.0/docs/api/javax/sql/DataSource.html 1.6: http://java.sun.com/javase/6/docs/api/javax/sql/DataSource.html I'll include a patch that adds the new required methods to the mock DataSource. They seem to work fine in 1.5 also. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-1418) allow user to specify deployment targets by "nickname"
[ https://issues.apache.org/jira/browse/GERONIMO-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] toby cabot updated GERONIMO-1418: - Fix Version/s: 1.x 1.2 Environment: fedora core 4 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) was: fedora core 2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) geronimo 1.0 branch > allow user to specify deployment targets by "nickname" > -- > > Key: GERONIMO-1418 > URL: https://issues.apache.org/jira/browse/GERONIMO-1418 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 1.2 > Environment: fedora core 4 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) >Reporter: toby cabot >Priority: Minor > Fix For: 1.2, 1.x > > Attachments: geronimo-target-nickname-1_2.txt, > geronimo-target-nickname.txt > > > This is a follow-on to the patch I submitted that allows Geronimo to have 2 > configuration stores. Now that I can specify the config-store on the command > line with the --targets switch I'm getting sick of typing the full target > name (e.g. > geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-system/1.0/car,J2EEServer=geronimo,j2eeType=ConfigurationStore,name=Customer). > This patch allows the user to specify any part of the target name (e.g. > Customer) instead of the whole target name. It's pretty crude, so if there's > a more elegant way to do something like this I'm all ears. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2900) more readable output from list-modules when there's >1 target
[ https://issues.apache.org/jira/browse/GERONIMO-2900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] toby cabot updated GERONIMO-2900: - Attachment: list-modules-by-target-patch.txt Patch to CommandListModules.java. > more readable output from list-modules when there's >1 target > - > > Key: GERONIMO-2900 > URL: https://issues.apache.org/jira/browse/GERONIMO-2900 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: usability >Affects Versions: 1.2 > Environment: Java(TM) 2 Runtime Environment, Standard Edition (build > 1.5.0_06-b05) > Fedora Core release 4 (Stentz) >Reporter: toby cabot >Priority: Minor > Fix For: 1.2 > > Attachments: list-modules-by-target-patch.txt > > > The output from the cli deployer's list-modules command becomes hard to read > when there is more than one target, since it prints the target for each > module. The target name is long so you end up with something like: > Found 20 modules > + org.apache.geronimo.configs/clustering/1.2-SNAPSHOT/car on > org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Local > + org.apache.geronimo.configs/connector-deployer/1.2-SNAPSHOT/car on > org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Local > + org.apache.geronimo.configs/geronimo-gbean-deployer/1.2-SNAPSHOT/car on > org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Local > + org.apache.geronimo.configs/hot-deployer/1.2-SNAPSHOT/car on > org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Local > + org.apache.geronimo.configs/j2ee-deployer/1.2-SNAPSHOT/car on > org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Local > etc... > This patch changes the output so that if there's more than one target the > modules are printed out per target. This is much easier to read: > Found 20 modules deployed to 2 targets > Target > org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Local > + org.apache.geronimo.configs/clustering/1.2-SNAPSHOT/car > + org.apache.geronimo.configs/connector-deployer/1.2-SNAPSHOT/car > + org.apache.geronimo.configs/geronimo-gbean-deployer/1.2-SNAPSHOT/car > + org.apache.geronimo.configs/hot-deployer/1.2-SNAPSHOT/car > + org.apache.geronimo.configs/j2ee-deployer/1.2-SNAPSHOT/car > + org.apache.geronimo.configs/j2ee-security/1.2-SNAPSHOT/car > + org.apache.geronimo.configs/j2ee-server/1.2-SNAPSHOT/car > + org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car > + org.apache.geronimo.configs/jetty/1.2-SNAPSHOT/car > + org.apache.geronimo.configs/jetty-deployer/1.2-SNAPSHOT/car > + org.apache.geronimo.configs/remote-deploy-jetty/1.2-SNAPSHOT/car > + org.apache.geronimo.configs/rmi-naming/1.2-SNAPSHOT/car > + org.apache.geronimo.configs/sharedlib/1.2-SNAPSHOT/car > + org.apache.geronimo.configs/transaction/1.2-SNAPSHOT/car > + org.apache.geronimo.configs/unavailable-client-deployer/1.2-SNAPSHOT/car > + org.apache.geronimo.configs/unavailable-ejb-deployer/1.2-SNAPSHOT/car > + > org.apache.geronimo.configs/unavailable-webservices-deployer/1.2-SNAPSHOT/car > org.apache.geronimo.configs/online-deployer/1.2-SNAPSHOT/car > org.apache.geronimo.configs/shutdown/1.2-SNAPSHOT/car > Target > org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Customer > hello/g6o_RA/1/rar -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-1418) allow user to specify deployment targets by "nickname"
[ https://issues.apache.org/jira/browse/GERONIMO-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] toby cabot updated GERONIMO-1418: - Attachment: geronimo-target-nickname-1_2.txt This patch applies to the 1.2 branch. The code is the same but the target file moved. > allow user to specify deployment targets by "nickname" > -- > > Key: GERONIMO-1418 > URL: https://issues.apache.org/jira/browse/GERONIMO-1418 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 1.2 > Environment: fedora core 2 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) > geronimo 1.0 branch >Reporter: toby cabot >Priority: Minor > Attachments: geronimo-target-nickname-1_2.txt, > geronimo-target-nickname.txt > > > This is a follow-on to the patch I submitted that allows Geronimo to have 2 > configuration stores. Now that I can specify the config-store on the command > line with the --targets switch I'm getting sick of typing the full target > name (e.g. > geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-system/1.0/car,J2EEServer=geronimo,j2eeType=ConfigurationStore,name=Customer). > This patch allows the user to specify any part of the target name (e.g. > Customer) instead of the whole target name. It's pretty crude, so if there's > a more elegant way to do something like this I'm all ears. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-2900) more readable output from list-modules when there's >1 target
more readable output from list-modules when there's >1 target - Key: GERONIMO-2900 URL: https://issues.apache.org/jira/browse/GERONIMO-2900 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: usability Affects Versions: 1.2 Environment: Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Fedora Core release 4 (Stentz) Reporter: toby cabot Priority: Minor Fix For: 1.2 The output from the cli deployer's list-modules command becomes hard to read when there is more than one target, since it prints the target for each module. The target name is long so you end up with something like: Found 20 modules + org.apache.geronimo.configs/clustering/1.2-SNAPSHOT/car on org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Local + org.apache.geronimo.configs/connector-deployer/1.2-SNAPSHOT/car on org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Local + org.apache.geronimo.configs/geronimo-gbean-deployer/1.2-SNAPSHOT/car on org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Local + org.apache.geronimo.configs/hot-deployer/1.2-SNAPSHOT/car on org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Local + org.apache.geronimo.configs/j2ee-deployer/1.2-SNAPSHOT/car on org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Local etc... This patch changes the output so that if there's more than one target the modules are printed out per target. This is much easier to read: Found 20 modules deployed to 2 targets Target org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Local + org.apache.geronimo.configs/clustering/1.2-SNAPSHOT/car + org.apache.geronimo.configs/connector-deployer/1.2-SNAPSHOT/car + org.apache.geronimo.configs/geronimo-gbean-deployer/1.2-SNAPSHOT/car + org.apache.geronimo.configs/hot-deployer/1.2-SNAPSHOT/car + org.apache.geronimo.configs/j2ee-deployer/1.2-SNAPSHOT/car + org.apache.geronimo.configs/j2ee-security/1.2-SNAPSHOT/car + org.apache.geronimo.configs/j2ee-server/1.2-SNAPSHOT/car + org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car + org.apache.geronimo.configs/jetty/1.2-SNAPSHOT/car + org.apache.geronimo.configs/jetty-deployer/1.2-SNAPSHOT/car + org.apache.geronimo.configs/remote-deploy-jetty/1.2-SNAPSHOT/car + org.apache.geronimo.configs/rmi-naming/1.2-SNAPSHOT/car + org.apache.geronimo.configs/sharedlib/1.2-SNAPSHOT/car + org.apache.geronimo.configs/transaction/1.2-SNAPSHOT/car + org.apache.geronimo.configs/unavailable-client-deployer/1.2-SNAPSHOT/car + org.apache.geronimo.configs/unavailable-ejb-deployer/1.2-SNAPSHOT/car + org.apache.geronimo.configs/unavailable-webservices-deployer/1.2-SNAPSHOT/car org.apache.geronimo.configs/online-deployer/1.2-SNAPSHOT/car org.apache.geronimo.configs/shutdown/1.2-SNAPSHOT/car Target org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/1.2-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Customer hello/g6o_RA/1/rar -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2599) deploying RAR leads to message that Geronimo can't find web.xml
[ http://issues.apache.org/jira/browse/GERONIMO-2599?page=all ] toby cabot updated GERONIMO-2599: - Attachment: hello-ra.rar Here's the resource adapter that triggers the problem. It's pretty trivial - it's mostly intended for me to figure out Geronimo deployment descriptors. > deploying RAR leads to message that Geronimo can't find web.xml > --- > > Key: GERONIMO-2599 > URL: http://issues.apache.org/jira/browse/GERONIMO-2599 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 1.2 > Environment: Fedora Core 4 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) > Revision: 477908 >Reporter: toby cabot >Priority: Minor > Attachments: hello-ra.rar > > > When I deploy a standalone RAR archive I get a stack trace indicating that > WEB-INF/web.xml can't be found. The resource adapter gets started but the > message is disconcerting. > java.io.FileNotFoundException: JAR entry WEB-INF/web.xml not found in > /tmp/geronimo-deployer4831.tmpdir/hello-ra.rar > at > sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:114) > at > sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:124) > at java.net.URL.openStream(URL.java:1007) > at > org.apache.geronimo.deployment.util.DeploymentUtil.readAll(DeploymentUtil.java:124) > at > org.apache.geronimo.jetty.deployment.JettyModuleBuilder.createModule(JettyModuleBuilder.java:198) > at > org.apache.geronimo.web.deployment.AbstractWebModuleBuilder.createModule(AbstractWebModuleBuilder.java:154) > at > org.apache.geronimo.web.deployment.AbstractWebModuleBuilder$$FastClassByCGLIB$$459e0cc.invoke() > 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:122) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) > 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.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$81214d9e.createModule() > at > org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.createModule(SwitchingModuleBuilder.java:94) > at > org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$$FastClassByCGLIB$$d0c31844.invoke() > 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:122) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) > 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.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$81214d9e.createModule() > at > org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:273) > at > org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke() > 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:122) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) > 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.j2ee.deployment.CorbaGBeanNameSource$$EnhancerByCGLIB$$b84ec7b3.getDeploymentPlan() > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:232) > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) > at > org.apache.geronimo.deployment.Deployer$$FastClas
[jira] Created: (GERONIMO-2599) deploying RAR leads to message that Geronimo can't find web.xml
deploying RAR leads to message that Geronimo can't find web.xml --- Key: GERONIMO-2599 URL: http://issues.apache.org/jira/browse/GERONIMO-2599 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment Affects Versions: 1.2 Environment: Fedora Core 4 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Revision: 477908 Reporter: toby cabot Priority: Minor When I deploy a standalone RAR archive I get a stack trace indicating that WEB-INF/web.xml can't be found. The resource adapter gets started but the message is disconcerting. java.io.FileNotFoundException: JAR entry WEB-INF/web.xml not found in /tmp/geronimo-deployer4831.tmpdir/hello-ra.rar at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:114) at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:124) at java.net.URL.openStream(URL.java:1007) at org.apache.geronimo.deployment.util.DeploymentUtil.readAll(DeploymentUtil.java:124) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.createModule(JettyModuleBuilder.java:198) at org.apache.geronimo.web.deployment.AbstractWebModuleBuilder.createModule(AbstractWebModuleBuilder.java:154) at org.apache.geronimo.web.deployment.AbstractWebModuleBuilder$$FastClassByCGLIB$$459e0cc.invoke() 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:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) 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.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$81214d9e.createModule() at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.createModule(SwitchingModuleBuilder.java:94) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$$FastClassByCGLIB$$d0c31844.invoke() 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:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) 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.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$81214d9e.createModule() at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:273) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke() 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:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) 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.j2ee.deployment.CorbaGBeanNameSource$$EnhancerByCGLIB$$b84ec7b3.getDeploymentPlan() at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:232) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() 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:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:855) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGB
[jira] Updated: (GERONIMO-1405) support more than one config-store
[ http://issues.apache.org/jira/browse/GERONIMO-1405?page=all ] toby cabot updated GERONIMO-1405: - Patch Info: [Patch Available] > support more than one config-store > -- > > Key: GERONIMO-1405 > URL: http://issues.apache.org/jira/browse/GERONIMO-1405 > Project: Geronimo > Type: Improvement > Components: deployment > Environment: fedora core 2 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) > Reporter: toby cabot > Attachments: geronimo-2configstores.txt > > Most of the code needed to support multiple config-stores is in place, but > Deployer assumes only one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1507) prototype offline deploy tool
[ http://issues.apache.org/jira/browse/GERONIMO-1507?page=all ] toby cabot updated GERONIMO-1507: - Patch Info: [Patch Available] > prototype offline deploy tool > - > > Key: GERONIMO-1507 > URL: http://issues.apache.org/jira/browse/GERONIMO-1507 > Project: Geronimo > Type: New Feature > Components: deployment > Versions: 1.1 > Environment: fedora core 2 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) > Geronimo 1.0 branch, > Reporter: toby cabot > Priority: Minor > Attachments: offline-patch.txt > > Here's a prototype offline deploy tool. It has only one command, for offline > distribution of applications. It's basically a clone of the online tool so > it works in a similar way, but for the distribute-offline command it uses a > hacked version of the packaging plugin's PackageBuilder class to start a > kernel, load some configurations, and then call the deployer. > It has one serious bug at the moment: it doesn't switch between tomcat and > jetty. Not sure why, but I can look into it more. > It has some missing features: > - it should get dependencies from somewhere (maybe download them from an > online Maven repo) > - it should be able to manipulate config.xml > - it needs more commands (at least undistribute) > - it needs to allow the user to specify the config-store to write to > There's probably a lot of unused code there, too, since I haven't figured out > what everything does yet. But it's a start. > You can use it like the online tool. The jar is > $GERONIMO_HOME/bin/offline.jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1507) prototype offline deploy tool
[ http://issues.apache.org/jira/browse/GERONIMO-1507?page=all ] toby cabot updated GERONIMO-1507: - Attachment: offline-patch.txt > prototype offline deploy tool > - > > Key: GERONIMO-1507 > URL: http://issues.apache.org/jira/browse/GERONIMO-1507 > Project: Geronimo > Type: New Feature > Components: deployment > Versions: 1.0.1 > Environment: fedora core 2 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) > Geronimo 1.0 branch, > Reporter: toby cabot > Priority: Minor > Attachments: offline-patch.txt > > Here's a prototype offline deploy tool. It has only one command, for offline > distribution of applications. It's basically a clone of the online tool so > it works in a similar way, but for the distribute-offline command it uses a > hacked version of the packaging plugin's PackageBuilder class to start a > kernel, load some configurations, and then call the deployer. > It has one serious bug at the moment: it doesn't switch between tomcat and > jetty. Not sure why, but I can look into it more. > It has some missing features: > - it should get dependencies from somewhere (maybe download them from an > online Maven repo) > - it should be able to manipulate config.xml > - it needs more commands (at least undistribute) > - it needs to allow the user to specify the config-store to write to > There's probably a lot of unused code there, too, since I haven't figured out > what everything does yet. But it's a start. > You can use it like the online tool. The jar is > $GERONIMO_HOME/bin/offline.jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1507) prototype offline deploy tool
prototype offline deploy tool - Key: GERONIMO-1507 URL: http://issues.apache.org/jira/browse/GERONIMO-1507 Project: Geronimo Type: New Feature Components: deployment Versions: 1.0.1 Environment: fedora core 2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) Geronimo 1.0 branch, Reporter: toby cabot Priority: Minor Here's a prototype offline deploy tool. It has only one command, for offline distribution of applications. It's basically a clone of the online tool so it works in a similar way, but for the distribute-offline command it uses a hacked version of the packaging plugin's PackageBuilder class to start a kernel, load some configurations, and then call the deployer. It has one serious bug at the moment: it doesn't switch between tomcat and jetty. Not sure why, but I can look into it more. It has some missing features: - it should get dependencies from somewhere (maybe download them from an online Maven repo) - it should be able to manipulate config.xml - it needs more commands (at least undistribute) - it needs to allow the user to specify the config-store to write to There's probably a lot of unused code there, too, since I haven't figured out what everything does yet. But it's a start. You can use it like the online tool. The jar is $GERONIMO_HOME/bin/offline.jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1418) allow user to specify deployment targets by "nickname"
allow user to specify deployment targets by "nickname" -- Key: GERONIMO-1418 URL: http://issues.apache.org/jira/browse/GERONIMO-1418 Project: Geronimo Type: Improvement Components: deployment Versions: 1.1 Environment: fedora core 2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) geronimo 1.0 branch Reporter: toby cabot Priority: Minor Attachments: geronimo-target-nickname.txt This is a follow-on to the patch I submitted that allows Geronimo to have 2 configuration stores. Now that I can specify the config-store on the command line with the --targets switch I'm getting sick of typing the full target name (e.g. geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-system/1.0/car,J2EEServer=geronimo,j2eeType=ConfigurationStore,name=Customer). This patch allows the user to specify any part of the target name (e.g. Customer) instead of the whole target name. It's pretty crude, so if there's a more elegant way to do something like this I'm all ears. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1418) allow user to specify deployment targets by "nickname"
[ http://issues.apache.org/jira/browse/GERONIMO-1418?page=all ] toby cabot updated GERONIMO-1418: - Attachment: geronimo-target-nickname.txt > allow user to specify deployment targets by "nickname" > -- > > Key: GERONIMO-1418 > URL: http://issues.apache.org/jira/browse/GERONIMO-1418 > Project: Geronimo > Type: Improvement > Components: deployment > Versions: 1.1 > Environment: fedora core 2 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) > geronimo 1.0 branch > Reporter: toby cabot > Priority: Minor > Attachments: geronimo-target-nickname.txt > > This is a follow-on to the patch I submitted that allows Geronimo to have 2 > configuration stores. Now that I can specify the config-store on the command > line with the --targets switch I'm getting sick of typing the full target > name (e.g. > geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-system/1.0/car,J2EEServer=geronimo,j2eeType=ConfigurationStore,name=Customer). > This patch allows the user to specify any part of the target name (e.g. > Customer) instead of the whole target name. It's pretty crude, so if there's > a more elegant way to do something like this I'm all ears. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-264) exceptions being swallowed at startup
[ http://issues.apache.org/jira/browse/GERONIMO-264?page=all ] toby cabot closed GERONIMO-264: --- > exceptions being swallowed at startup > - > > Key: GERONIMO-264 > URL: http://issues.apache.org/jira/browse/GERONIMO-264 > Project: Geronimo > Type: Improvement > Components: deployment > Versions: 1.0-M2 > Environment: fedora core 2 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) > Reporter: toby cabot > Assignee: Aaron Mulder > Priority: Minor > Fix For: 1.0-M4 > Attachments: Daemon-1_9-diff.txt, Daemon-56609-diff.txt, > Daemon-r159681-diff.txt, daemon-log.diff, daemon-log.diff, log.txt > > some exceptions that are thrown during startup are swallowed and don't show > up in the logs. > i'm at the 'monkey and typewriter' stage of the geronimo learning curve so > i'm a good randomness injector. i had a problem where geronimo would try to > start up and then go directly to shutdown for no apparent reason. actually, > i think i've had a few: > 15:50:17,290 DEBUG [GBeanMBean] geronimo.config:name="skeleton/RA" State > changed from stopped to starting > 15:50:17,292 DEBUG [Configuration] ClassPath for skeleton/RA resolved to > [file:/home/tcabot/try/incubator-geronimo/target/config-store/8/connector/skeleton-ra.jar] > ra test setting configParameter to NewStringValue > 15:50:17,737 DEBUG [SpreadManagedConnectionFactory] > BaseManagedConnectionFactory() > 15:50:17,737 DEBUG [SpreadManagedConnectionFactory] > SpreadManagedConnectionFactory() > 15:50:18,425 DEBUG [GBeanMBean] geronimo.config:name="skeleton/RA" State > changed from starting to failed > 15:50:18,426 INFO [Kernel] Starting kernel shutdown > i'll include a patch that logs the problem in the catch clause in > Configuration.doStart(). There might be better places to do this, but as > long as it gets done *somewhere* i'm happy. > regards, > toby -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1405) support more than one config-store
[ http://issues.apache.org/jira/browse/GERONIMO-1405?page=all ] toby cabot updated GERONIMO-1405: - Attachment: geronimo-2configstores.txt Here's a patch that modifies Deployer.java to handle multiple config-stores. It uses the first one it gets by default but the user can override that on deployer.jar's command line. For more background on this topic, please see the email thread starting on 2005-12-05 with a message from David Jencks titled "Re: list-targets command". http://www.nabble.com/Re%3A-list-targets-command-t682867.html#a1803966 > support more than one config-store > -- > > Key: GERONIMO-1405 > URL: http://issues.apache.org/jira/browse/GERONIMO-1405 > Project: Geronimo > Type: Improvement > Components: deployment > Environment: fedora core 2 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) > Reporter: toby cabot > Attachments: geronimo-2configstores.txt > > Most of the code needed to support multiple config-stores is in place, but > Deployer assumes only one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1405) support more than one config-store
support more than one config-store -- Key: GERONIMO-1405 URL: http://issues.apache.org/jira/browse/GERONIMO-1405 Project: Geronimo Type: Improvement Components: deployment Environment: fedora core 2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) Reporter: toby cabot Most of the code needed to support multiple config-stores is in place, but Deployer assumes only one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-282) servlet calls ejb: "class not found" at deployment and run time
[ http://issues.apache.org/jira/browse/GERONIMO-282?page=comments#action_12358689 ] toby cabot commented on GERONIMO-282: - Not sure if you mean me (Toby). In any case, it works fine for me. As long as Dain's issue in http://issues.apache.org/jira/browse/GERONIMO-282#action_52976 has been resolved to his satisfaction then this can be closed. > servlet calls ejb: "class not found" at deployment and run time > --- > > Key: GERONIMO-282 > URL: http://issues.apache.org/jira/browse/GERONIMO-282 > Project: Geronimo > Type: Bug > Components: web > Versions: 1.0-M2 > Environment: fedora core 2 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) > Reporter: toby cabot > Fix For: 1.x > > I'm trying to deploy a servlet that calls an EJB. I can > deploy the EJB and call if from a command-line Java client, so I think > that part works, thanks to the dev list for help with JNDI. > > > I did the usual stuff in the servlet, but when I add > > > > g6o/SSEJB > Session > g6o.ejbclient.StatelessSessionHome > g6o.ejbclient.StatelessSession > > > > to web.xml I get a stack trace when I run the deploy tool. > > > org.apache.geronimo.deployment.DeploymentException: Remote interface class > not found: g6o.ejbclient.StatelessSession > at > org.apache.geronimo.jetty.deployment.JettyModuleBuilder.assureInterface(JettyModuleBuilder.java:593) > at > org.apache.geronimo.jetty.deployment.JettyModuleBuilder.assureEJBObjectInterface(JettyModuleBuilder.java:573) > at > org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addEJBRefs(JettyModuleBuilder.java:491) > > > etc... > > > I've got the EJB interfaces in a jar in the war file's WEB-INF/lib > directory, but I also tried putting the jar with the EJB interfaces in > geronimo's lib directory with the same result. > > > Copying my ejb client jar to geronimo's repository and adding an element to > geronimo-jetty.xml: > > g6o-ejb-client.jar > > ...allows the deployment to get farther, but then I get a message about how > references that aren't ejb-link are not implemented, so I cut the ejb-ref > element out of web.xml to make the deployment work, and when my servlet tries > to look up the EJB I get: > 13:19:22,715 ERROR [Daemon] Exception caught during kernel configuration, > starting kernel shutdown > org.apache.geronimo.kernel.config.InvalidConfigException: Invalid GBean > configuration for geronimo.config:name="g6o/web" > at > org.apache.geronimo.kernel.Kernel.startRecursiveGBean(Kernel.java:274) > at org.apache.geronimo.system.main.Daemon.main(Daemon.java:146) > Caused by: javax.servlet.ServletException: Naming exception in servlet init: > Cannot lookup /g6o/SSEJB: Received error: Error while communicating with > server: ; nested exception is: > java.rmi.RemoteException: Cannot read the response from the server. > The class for an object being returned is not located in this system:; nested > exception is: > java.lang.ClassNotFoundException: g6o.ejbclient.StatelessSessionHome > at g6o.servlet.Servlet.init(Servlet.java:64) > at > org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:226) > at > org.mortbay.jetty.servlet.ServletHandler.initializeServlets(ServletHandler.java:390) > at > org.mortbay.jetty.servlet.WebApplicationHandler.initializeServlets(WebApplicationHandler.java:287) > at > org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext.java:421) > at > org.apache.geronimo.jetty.JettyWebAppContext.doStart(JettyWebAppContext.java:198) > at > org.apache.geronimo.gbean.jmx.GBeanMBean.doStart(GBeanMBean.java:593) > at > org.apache.geronimo.gbean.jmx.AbstractManagedObject.attemptFullStart(AbstractManagedObject.java:479) > at > org.apache.ger
[jira] Updated: (GERONIMO-1227) please re-allow read-only repositories
[ http://issues.apache.org/jira/browse/GERONIMO-1227?page=all ] toby cabot updated GERONIMO-1227: - Attachment: readonly-repo-patch.txt Removes the repository read/write test so Geronimo will run with the repo on a read-only filesystem. > please re-allow read-only repositories > -- > > Key: GERONIMO-1227 > URL: http://issues.apache.org/jira/browse/GERONIMO-1227 > Project: Geronimo > Type: Wish > Components: core > Versions: Wish List > Environment: fedora core 2 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) > Geronimo source At revision 348532. > Reporter: toby cabot > Priority: Minor > Attachments: readonly-repo-patch.txt > > In our application we build Geronimo and deploy our app on a read/write > filesystem but run it on a read-only filesystem. This used to work, but I > upgraded our Geronimo recently and found that it checks if the repo is > writeable and bails out if it isn't. I disabled that check and then Geronimo > runs fine on a read-only filesystem (after hacking various xml files to put > logs, etc on a read/write partition). > Please consider removing the read/write repository check - I'll attach a > patch that does this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1227) please re-allow read-only repositories
please re-allow read-only repositories -- Key: GERONIMO-1227 URL: http://issues.apache.org/jira/browse/GERONIMO-1227 Project: Geronimo Type: Wish Components: core Versions: Wish List Environment: fedora core 2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) Geronimo source At revision 348532. Reporter: toby cabot Priority: Minor In our application we build Geronimo and deploy our app on a read/write filesystem but run it on a read-only filesystem. This used to work, but I upgraded our Geronimo recently and found that it checks if the repo is writeable and bails out if it isn't. I disabled that check and then Geronimo runs fine on a read-only filesystem (after hacking various xml files to put logs, etc on a read/write partition). Please consider removing the read/write repository check - I'll attach a patch that does this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1069) move demo app security config out of geronimo "core"
[ http://issues.apache.org/jira/browse/GERONIMO-1069?page=all ] toby cabot updated GERONIMO-1069: - Attachment: demo_app-patch.txt I commented out the "jaasTest" GBean since it seems to work fine without it. If it's necessary then please uncomment it. > move demo app security config out of geronimo "core" > > > Key: GERONIMO-1069 > URL: http://issues.apache.org/jira/browse/GERONIMO-1069 > Project: Geronimo > Type: Improvement > Components: sample apps > Environment: geronimo subversion update Oct 12, 2005 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) > Fedora Core 2 > Reporter: toby cabot > Priority: Minor > Attachments: demo_app-patch.txt > > A while back (Aug 10) David Jencks asked me to move the Demo application > security config from its own configuration to the demo app itself. Well, > better late than never. I hope. I'll attach a patch that removes the > org/apache/geronimo/SampleSecurityRealm configuration and adds the necessary > XML to the demo app geronimo-web.xml file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1069) move demo app security config out of geronimo "core"
move demo app security config out of geronimo "core" Key: GERONIMO-1069 URL: http://issues.apache.org/jira/browse/GERONIMO-1069 Project: Geronimo Type: Improvement Components: sample apps Environment: geronimo subversion update Oct 12, 2005 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) Fedora Core 2 Reporter: toby cabot Priority: Minor Attachments: demo_app-patch.txt A while back (Aug 10) David Jencks asked me to move the Demo application security config from its own configuration to the demo app itself. Well, better late than never. I hope. I'll attach a patch that removes the org/apache/geronimo/SampleSecurityRealm configuration and adds the necessary XML to the demo app geronimo-web.xml file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1061) SampleSecurityRealm's LoginService references are obsolete
[ http://issues.apache.org/jira/browse/GERONIMO-1061?page=all ] toby cabot updated GERONIMO-1061: - Attachment: demo_parent-patch.txt this seems to work for me. it updates org/apache/geronimo/SampleSecurityRealm's parent to be org/apache/geronimo/Security and modifies the two references to the JaasLoginService gbean so that they resolve. > SampleSecurityRealm's LoginService references are obsolete > -- > > Key: GERONIMO-1061 > URL: http://issues.apache.org/jira/browse/GERONIMO-1061 > Project: Geronimo > Type: Bug > Components: sample apps > Environment: subversion source updated Oct 12, 2005 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) > Fedora Core 2 > Reporter: toby cabot > Priority: Trivial > Attachments: demo_parent-patch.txt > > The org/apache/geronimo/SampleSecurityRealm configuration has some obsolete > references that need to be updated. I guess that the JaasLoginService gbean > must have moved at some point, probably from org/apache/geronimo/Server to > org/apache/geronimo/Security. In any case, > modules/assembly/src/plan/j2ee-secure-plan.xml needs a small update. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1061) SampleSecurityRealm's LoginService references are obsolete
[ http://issues.apache.org/jira/browse/GERONIMO-1061?page=all ] toby cabot updated GERONIMO-1061: - Priority: Trivial (was: Major) > SampleSecurityRealm's LoginService references are obsolete > -- > > Key: GERONIMO-1061 > URL: http://issues.apache.org/jira/browse/GERONIMO-1061 > Project: Geronimo > Type: Bug > Components: sample apps > Environment: subversion source updated Oct 12, 2005 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) > Fedora Core 2 > Reporter: toby cabot > Priority: Trivial > > The org/apache/geronimo/SampleSecurityRealm configuration has some obsolete > references that need to be updated. I guess that the JaasLoginService gbean > must have moved at some point, probably from org/apache/geronimo/Server to > org/apache/geronimo/Security. In any case, > modules/assembly/src/plan/j2ee-secure-plan.xml needs a small update. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1061) SampleSecurityRealm's LoginService references are obsolete
SampleSecurityRealm's LoginService references are obsolete -- Key: GERONIMO-1061 URL: http://issues.apache.org/jira/browse/GERONIMO-1061 Project: Geronimo Type: Bug Components: sample apps Environment: subversion source updated Oct 12, 2005 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) Fedora Core 2 Reporter: toby cabot The org/apache/geronimo/SampleSecurityRealm configuration has some obsolete references that need to be updated. I guess that the JaasLoginService gbean must have moved at some point, probably from org/apache/geronimo/Server to org/apache/geronimo/Security. In any case, modules/assembly/src/plan/j2ee-secure-plan.xml needs a small update. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-645) geronimo/jetty doesn't respect web.xml load-on-startup order
[ http://issues.apache.org/jira/browse/GERONIMO-645?page=comments#action_12315351 ] toby cabot commented on GERONIMO-645: - Thanks, David. Good catch with the Comparator. > geronimo/jetty doesn't respect web.xml load-on-startup order > > > Key: GERONIMO-645 > URL: http://issues.apache.org/jira/browse/GERONIMO-645 > Project: Geronimo > Type: Bug > Components: web > Versions: 1.0-M4 > Environment: Fedora Core release 2 (Tettnang) > java version "1.4.2_05" > geronimo svn code revision 169673 > Reporter: toby cabot > Assignee: David Jencks > Attachments: load-on-startup-patch.txt, load-on-startup-patch2.txt > > Geronimo doesn't appear to start servlets in the order specified by > . I can't figure out how the order is determined, but if I > modify the values in a couple of elements to try to change > the startup order they come up in the same order as before. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-645) geronimo/jetty doesn't respect web.xml load-on-startup order
[ http://issues.apache.org/jira/browse/GERONIMO-645?page=all ] toby cabot updated GERONIMO-645: Attachment: load-on-startup-patch2.txt the previous attachment has a bug (if there are more than one servlet with no load-on-startup then they don't all get deployed). > geronimo/jetty doesn't respect web.xml load-on-startup order > > > Key: GERONIMO-645 > URL: http://issues.apache.org/jira/browse/GERONIMO-645 > Project: Geronimo > Type: Bug > Components: web > Versions: 1.0-M4 > Environment: Fedora Core release 2 (Tettnang) > java version "1.4.2_05" > geronimo svn code revision 169673 > Reporter: toby cabot > Attachments: load-on-startup-patch.txt, load-on-startup-patch2.txt > > Geronimo doesn't appear to start servlets in the order specified by > . I can't figure out how the order is determined, but if I > modify the values in a couple of elements to try to change > the startup order they come up in the same order as before. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-645) geronimo/jetty doesn't respect web.xml load-on-startup order
[ http://issues.apache.org/jira/browse/GERONIMO-645?page=all ] toby cabot updated GERONIMO-645: Attachment: load-on-startup-patch.txt Here's a patch that adds a "Previous" reference to JettyServletHolder and code to JettyModuleBuilder to build the servlet GBeans in sequence. > geronimo/jetty doesn't respect web.xml load-on-startup order > > > Key: GERONIMO-645 > URL: http://issues.apache.org/jira/browse/GERONIMO-645 > Project: Geronimo > Type: Bug > Components: web > Versions: 1.0-M4 > Environment: Fedora Core release 2 (Tettnang) > java version "1.4.2_05" > geronimo svn code revision 169673 > Reporter: toby cabot > Attachments: load-on-startup-patch.txt > > Geronimo doesn't appear to start servlets in the order specified by > . I can't figure out how the order is determined, but if I > modify the values in a couple of elements to try to change > the startup order they come up in the same order as before. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-645) geronimo/jetty doesn't respect web.xml load-on-startup order
[ http://issues.apache.org/jira/browse/GERONIMO-645?page=comments#action_65667 ] toby cabot commented on GERONIMO-645: - I wrote on the dev list (this system was down): I started looking at this but I think I've gone as far as I can without some advice. I started by modifying JettyModuleBuilder to create the servlet gbeans in the order specified by the load-on-startup elements, and that worked the first time I ran the server. But not the second time. So I looked into it a little more and found that the BasicDependencyManager stores the dependencies as a set, so when GBeanInstanceState.startRecursive() gets the children (in this case the servlets) to start there's no order to them. So I'm at a loss for what to do. Modifying the dependency manager to use lists instead of sets seems pretty drastic (since some of the methods return sets) but it would probably make the server start up more predictably. But I'm not sure that's enough to ensure that the load-on-startup order is respected all the way through deployment and startup. David Jencks responded: Certainly the simplest solution is to give JettyServletHolder a Previous reference so they form a linked list and set this reference in the builder so as to be consistent with and enforce the startup order. The JettyFilterMapping uses this idea... > geronimo/jetty doesn't respect web.xml load-on-startup order > > > Key: GERONIMO-645 > URL: http://issues.apache.org/jira/browse/GERONIMO-645 > Project: Geronimo > Type: Bug > Components: web > Versions: 1.0-M4 > Environment: Fedora Core release 2 (Tettnang) > java version "1.4.2_05" > geronimo svn code revision 169673 > Reporter: toby cabot > > Geronimo doesn't appear to start servlets in the order specified by > . I can't figure out how the order is determined, but if I > modify the values in a couple of elements to try to change > the startup order they come up in the same order as before. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-645) geronimo/jetty doesn't respect web.xml load-on-startup order
geronimo/jetty doesn't respect web.xml load-on-startup order Key: GERONIMO-645 URL: http://issues.apache.org/jira/browse/GERONIMO-645 Project: Geronimo Type: Bug Components: web Versions: 1.0-M4 Environment: Fedora Core release 2 (Tettnang) java version "1.4.2_05" geronimo svn code revision 169673 Reporter: toby cabot Geronimo doesn't appear to start servlets in the order specified by . I can't figure out how the order is determined, but if I modify the values in a couple of elements to try to change the startup order they come up in the same order as before. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-587) deployer can fail but appear to succeed
[ http://issues.apache.org/jira/browse/GERONIMO-587?page=history ] toby cabot updated GERONIMO-587: Attachment: deployer-error-patch-2.txt Gianny, thanks for looking at this. Here's a new patch that should address the problem that you're talking about. It waits until after all the work is done, then prints the results that succeeded, then throws if anything went wrong. I think that this is more or less what we want to do. > deployer can fail but appear to succeed > --- > > Key: GERONIMO-587 > URL: http://issues.apache.org/jira/browse/GERONIMO-587 > Project: Geronimo > Type: Bug > Components: deployment > Versions: 1.0-M3 > Environment: fedora core 2 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) > Reporter: toby cabot > Assignee: Gianny DAMOUR > Priority: Minor > Attachments: deployer-error-patch-2.txt, deployer-error-patch.txt > > If you run the deployer "distribute" command, but have a copy of Geronimo > running on the same machine, the command fails but returns 0 so any ant/shell > script that runs it thinks it succeded. I'll attach a patch that fixes the > second problem, i.e. when it fails for this reason it will return non-zero. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-264) exceptions being swallowed at startup
[ http://issues.apache.org/jira/browse/GERONIMO-264?page=history ] toby cabot updated GERONIMO-264: Attachment: Daemon-r159681-diff.txt here's an updated patch for revision 159704 of Daemon.java > exceptions being swallowed at startup > - > > Key: GERONIMO-264 > URL: http://issues.apache.org/jira/browse/GERONIMO-264 > Project: Geronimo > Type: Improvement > Components: deployment > Versions: 1.0-M2 > Environment: fedora core 2 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) > Reporter: toby cabot > Assignee: Dain Sundstrom > Priority: Minor > Attachments: Daemon-1_9-diff.txt, Daemon-56609-diff.txt, > Daemon-r159681-diff.txt, daemon-log.diff, daemon-log.diff, log.txt > > some exceptions that are thrown during startup are swallowed and don't show > up in the logs. > i'm at the 'monkey and typewriter' stage of the geronimo learning curve so > i'm a good randomness injector. i had a problem where geronimo would try to > start up and then go directly to shutdown for no apparent reason. actually, > i think i've had a few: > 15:50:17,290 DEBUG [GBeanMBean] geronimo.config:name="skeleton/RA" State > changed from stopped to starting > 15:50:17,292 DEBUG [Configuration] ClassPath for skeleton/RA resolved to > [file:/home/tcabot/try/incubator-geronimo/target/config-store/8/connector/skeleton-ra.jar] > ra test setting configParameter to NewStringValue > 15:50:17,737 DEBUG [SpreadManagedConnectionFactory] > BaseManagedConnectionFactory() > 15:50:17,737 DEBUG [SpreadManagedConnectionFactory] > SpreadManagedConnectionFactory() > 15:50:18,425 DEBUG [GBeanMBean] geronimo.config:name="skeleton/RA" State > changed from starting to failed > 15:50:18,426 INFO [Kernel] Starting kernel shutdown > i'll include a patch that logs the problem in the catch clause in > Configuration.doStart(). There might be better places to do this, but as > long as it gets done *somewhere* i'm happy. > regards, > toby -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-587) deployer can fail but appear to succeed
[ http://issues.apache.org/jira/browse/GERONIMO-587?page=history ] toby cabot updated GERONIMO-587: Attachment: deployer-error-patch.txt makes AbstractCommand. waitForProgress() throw DeploymentException if something goes wrong. makes the methods that call waitForProgress() propagate that exception up. > deployer can fail but appear to succeed > --- > > Key: GERONIMO-587 > URL: http://issues.apache.org/jira/browse/GERONIMO-587 > Project: Apache Geronimo > Type: Bug > Components: deployment > Versions: 1.0-M3 > Environment: fedora core 2 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) > Reporter: toby cabot > Priority: Minor > Attachments: deployer-error-patch.txt > > If you run the deployer "distribute" command, but have a copy of Geronimo > running on the same machine, the command fails but returns 0 so any ant/shell > script that runs it thinks it succeded. I'll attach a patch that fixes the > second problem, i.e. when it fails for this reason it will return non-zero. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-587) deployer can fail but appear to succeed
deployer can fail but appear to succeed --- Key: GERONIMO-587 URL: http://issues.apache.org/jira/browse/GERONIMO-587 Project: Apache Geronimo Type: Bug Components: deployment Versions: 1.0-M3 Environment: fedora core 2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) Reporter: toby cabot Priority: Minor Attachments: deployer-error-patch.txt If you run the deployer "distribute" command, but have a copy of Geronimo running on the same machine, the command fails but returns 0 so any ant/shell script that runs it thinks it succeded. I'll attach a patch that fixes the second problem, i.e. when it fails for this reason it will return non-zero. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-575) updates to the web site
[ http://issues.apache.org/jira/browse/GERONIMO-575?page=history ] toby cabot updated GERONIMO-575: Attachment: website-patch.txt patch to freshen the maven-generated web site. > updates to the web site > --- > > Key: GERONIMO-575 > URL: http://issues.apache.org/jira/browse/GERONIMO-575 > Project: Apache Geronimo > Type: Improvement > Components: web > Environment: subversion revision 153446. > Reporter: toby cabot > Attachments: website-patch.txt > > per the discussion on the user mailing list in early February (I'd link but > the archive appears to be broken at the moment) here's a patch to freshen the > maven-generated web site. highlights include: > o removing links to old source releases > o adding "Getting Involved" section on front page > o removing download section from front page (it's got its own page) > o adding a news item > there are a lot of smaller changes, too. you can see the results at > http://www.caboteria.org/~tobyc/g6o-docs/ . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-575) updates to the web site
updates to the web site --- Key: GERONIMO-575 URL: http://issues.apache.org/jira/browse/GERONIMO-575 Project: Apache Geronimo Type: Improvement Components: web Environment: subversion revision 153446. Reporter: toby cabot Attachments: website-patch.txt per the discussion on the user mailing list in early February (I'd link but the archive appears to be broken at the moment) here's a patch to freshen the maven-generated web site. highlights include: o removing links to old source releases o adding "Getting Involved" section on front page o removing download section from front page (it's got its own page) o adding a news item there are a lot of smaller changes, too. you can see the results at http://www.caboteria.org/~tobyc/g6o-docs/ . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-558) "distribute" doesn't deploy web apps
[ http://issues.apache.org/jira/browse/GERONIMO-558?page=comments#action_58252 ] toby cabot commented on GERONIMO-558: - Wow! Log a bug, drink a couple of beers, come back, bug is fixed. Thanks David! > "distribute" doesn't deploy web apps > > > Key: GERONIMO-558 > URL: http://issues.apache.org/jira/browse/GERONIMO-558 > Project: Apache Geronimo > Type: Bug > Components: deployment > Versions: 1.0-M4 > Environment: fedora core 2 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) > svn revision 148920. > Reporter: toby cabot > Assignee: David Jencks > Fix For: 1.0-M4 > Attachments: distribute-workaround-patch.txt > > when I deploy webapps using the online deployer things seem to work OK but > when I use the offline "distribute" option I get: > [EMAIL PROTECTED]:~/try/hello-g6o$ java -jar ~/geronimo/bin/deployer.jar > --user system --password manager distribute build/g6o.ear > 16:37:13,253 INFO [ConfigurationManagerImpl] Loaded Configuration > geronimo.config:name="org/apache/geronimo/J2EEDeployer" > 16:37:13,812 INFO [Configuration] Started configuration > org/apache/geronimo/J2EEDeployer > 16:37:14,036 INFO [SecurityServiceImpl] Security service started > 16:37:15,799 INFO [ConfigurationManagerImpl] Loaded Configuration > geronimo.config:name="org/apache/geronimo/Server" > 16:37:15,846 INFO [ConfigurationManagerImpl] Loaded Configuration > geronimo.config:name="org/apache/geronimo/System" > 16:37:15,970 INFO [Configuration] Started configuration > org/apache/geronimo/System > 16:37:16,613 INFO [Configuration] Started configuration > org/apache/geronimo/Server > NOT DEPLOYING WEB SERVICE CLASS g6o.servlet.Servlet > NOT DEPLOYING WEB SERVICE CLASS g6o.servlet.CLServlet > 16:37:17,857 INFO [Configuration] Stopping configuration > org/apache/geronimo/Server > 16:37:17,939 INFO [Configuration] Stopping configuration > org/apache/geronimo/System > 16:37:18,014 INFO [LocalConfigStore:config-store/] Installed configuration > g6o in location 20 > Distributed g6o > 16:37:18,049 INFO [Configuration] Stopping configuration > org/apache/geronimo/DeployerSystem > 16:37:18,089 INFO [Kernel] Starting kernel shutdown > 16:37:18,125 INFO [Kernel] Kernel shutdown complete > When I start the server the servlets don't start. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-558) "distribute" doesn't deploy web apps
[ http://issues.apache.org/jira/browse/GERONIMO-558?page=history ] toby cabot updated GERONIMO-558: Attachment: distribute-workaround-patch.txt this patch works for me. i doubt it's a real fix, but if anyone needs a workaround this might help. > "distribute" doesn't deploy web apps > > > Key: GERONIMO-558 > URL: http://issues.apache.org/jira/browse/GERONIMO-558 > Project: Apache Geronimo > Type: Bug > Components: deployment > Versions: 1.0-M4 > Environment: fedora core 2 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) > svn revision 148920. > Reporter: toby cabot > Assignee: David Jencks > Attachments: distribute-workaround-patch.txt > > when I deploy webapps using the online deployer things seem to work OK but > when I use the offline "distribute" option I get: > [EMAIL PROTECTED]:~/try/hello-g6o$ java -jar ~/geronimo/bin/deployer.jar > --user system --password manager distribute build/g6o.ear > 16:37:13,253 INFO [ConfigurationManagerImpl] Loaded Configuration > geronimo.config:name="org/apache/geronimo/J2EEDeployer" > 16:37:13,812 INFO [Configuration] Started configuration > org/apache/geronimo/J2EEDeployer > 16:37:14,036 INFO [SecurityServiceImpl] Security service started > 16:37:15,799 INFO [ConfigurationManagerImpl] Loaded Configuration > geronimo.config:name="org/apache/geronimo/Server" > 16:37:15,846 INFO [ConfigurationManagerImpl] Loaded Configuration > geronimo.config:name="org/apache/geronimo/System" > 16:37:15,970 INFO [Configuration] Started configuration > org/apache/geronimo/System > 16:37:16,613 INFO [Configuration] Started configuration > org/apache/geronimo/Server > NOT DEPLOYING WEB SERVICE CLASS g6o.servlet.Servlet > NOT DEPLOYING WEB SERVICE CLASS g6o.servlet.CLServlet > 16:37:17,857 INFO [Configuration] Stopping configuration > org/apache/geronimo/Server > 16:37:17,939 INFO [Configuration] Stopping configuration > org/apache/geronimo/System > 16:37:18,014 INFO [LocalConfigStore:config-store/] Installed configuration > g6o in location 20 > Distributed g6o > 16:37:18,049 INFO [Configuration] Stopping configuration > org/apache/geronimo/DeployerSystem > 16:37:18,089 INFO [Kernel] Starting kernel shutdown > 16:37:18,125 INFO [Kernel] Kernel shutdown complete > When I start the server the servlets don't start. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-558) "distribute" doesn't deploy web apps
"distribute" doesn't deploy web apps Key: GERONIMO-558 URL: http://issues.apache.org/jira/browse/GERONIMO-558 Project: Apache Geronimo Type: Bug Components: deployment Versions: 1.0-M4 Environment: fedora core 2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) svn revision 148920. Reporter: toby cabot when I deploy webapps using the online deployer things seem to work OK but when I use the offline "distribute" option I get: [EMAIL PROTECTED]:~/try/hello-g6o$ java -jar ~/geronimo/bin/deployer.jar --user system --password manager distribute build/g6o.ear 16:37:13,253 INFO [ConfigurationManagerImpl] Loaded Configuration geronimo.config:name="org/apache/geronimo/J2EEDeployer" 16:37:13,812 INFO [Configuration] Started configuration org/apache/geronimo/J2EEDeployer 16:37:14,036 INFO [SecurityServiceImpl] Security service started 16:37:15,799 INFO [ConfigurationManagerImpl] Loaded Configuration geronimo.config:name="org/apache/geronimo/Server" 16:37:15,846 INFO [ConfigurationManagerImpl] Loaded Configuration geronimo.config:name="org/apache/geronimo/System" 16:37:15,970 INFO [Configuration] Started configuration org/apache/geronimo/System 16:37:16,613 INFO [Configuration] Started configuration org/apache/geronimo/Server NOT DEPLOYING WEB SERVICE CLASS g6o.servlet.Servlet NOT DEPLOYING WEB SERVICE CLASS g6o.servlet.CLServlet 16:37:17,857 INFO [Configuration] Stopping configuration org/apache/geronimo/Server 16:37:17,939 INFO [Configuration] Stopping configuration org/apache/geronimo/System 16:37:18,014 INFO [LocalConfigStore:config-store/] Installed configuration g6o in location 20 Distributed g6o 16:37:18,049 INFO [Configuration] Stopping configuration org/apache/geronimo/DeployerSystem 16:37:18,089 INFO [Kernel] Starting kernel shutdown 16:37:18,125 INFO [Kernel] Kernel shutdown complete When I start the server the servlets don't start. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-539) ClassCastException at shutdown
ClassCastException at shutdown -- Key: GERONIMO-539 URL: http://issues.apache.org/jira/browse/GERONIMO-539 Project: Apache Geronimo Type: Bug Components: security Versions: 1.0-M4 Environment: fedora core 2 java 1.4.2 geronimo svn At revision 124458. Reporter: toby cabot Priority: Minor after a clean rebuild of the server, if you start it up and then hit ctrl-c to shut it down you get a stack trace. Not a big deal, just a little shocking. 17:21:06,521 ERROR Shutdown Thread [org.apache.geronimo.gbean.runtime.GBeanInstanceState] Error while stopping: objectName="geronimo.security:type=LoginConfiguration" java.lang.ClassCastException at org.apache.geronimo.security.jaas.GeronimoLoginConfiguration.doStop(GeronimoLoginConfiguration.java:135) at org.apache.geronimo.gbean.runtime.GBeanInstance$GBeanLifecycleCallback.doStop(GBeanInstance.java:796) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop(GBeanInstanceState.java:387) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:205) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:483) at org.apache.geronimo.gbean.runtime.GBeanInstance$11.invoke(GBeanInstance.java:992) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:684) at org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:302) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:197) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:483) at org.apache.geronimo.kernel.Kernel.stopGBean(Kernel.java:347) at org.apache.geronimo.kernel.config.ConfigurationManagerImpl.doStop(ConfigurationManagerImpl.java:221) at org.apache.geronimo.gbean.runtime.GBeanInstance$GBeanLifecycleCallback.doStop(GBeanInstance.java:796) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop(GBeanInstanceState.java:387) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:205) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:483) at org.apache.geronimo.kernel.Kernel.shutdownConfigManager(Kernel.java:527) at org.apache.geronimo.kernel.Kernel.shutdown(Kernel.java:491) at org.apache.geronimo.system.main.Daemon$1.run(Daemon.java:122) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-535) handle fully-qualified paths in ServerInfo.resolvePath()
[ http://issues.apache.org/jira/browse/GERONIMO-535?page=history ] toby cabot updated GERONIMO-535: Attachment: ServerInfo-test-patch.txt Jacek, thanks for looking at this. I tried applying your patch and the first hunk failed - I wonder if it's because svn seems to unset the version macros before doing the diff, perhaps this confuses patch. I've uploaded a patch that creates a unit test for ServerInfo. I haven't tried it on Windows but it works on Linux. > handle fully-qualified paths in ServerInfo.resolvePath() > > > Key: GERONIMO-535 > URL: http://issues.apache.org/jira/browse/GERONIMO-535 > Project: Apache Geronimo > Type: Improvement > Components: core > Versions: 1.0-M4 > Environment: fedora core 2 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) > geronimo svn Revision: 123724 > Reporter: toby cabot > Assignee: Jacek Laskowski > Attachments: ServerInfo-test-patch.txt, absolute-file.patch, > absolute-file.patch, absolute-file.patch > > It would be useful to me (and hopefully others) to be able to specify > fully-qualified pathnames in configuration files. For example, if we want to > integrate Geronimo with Linux systems we'll want to write logs into > /var/log/geronimo or thereabouts. I noticed that when I tried to use > fully-qualified paths in configuration files they were resolved relative to > Geronimo's home directory anyway. This patch changes ServerInfo so that if a > filename begins with a "/" it's treated as a fully-qualified path, and if it > doesn't it's resolved relative to Geronimo's home. > Please note that I haven't tried this on a Windows system, so I'm not sure > what the effect is. It works great on Linux. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-535) handle fully-qualified paths in ServerInfo.resolvePath()
[ http://nagoya.apache.org/jira/browse/GERONIMO-535?page=history ] toby cabot updated GERONIMO-535: Attachment: absolute-file.patch Dain, thanks for the comment, your code works on Linux too, so I'm attaching a new patch using it. > handle fully-qualified paths in ServerInfo.resolvePath() > > > Key: GERONIMO-535 > URL: http://nagoya.apache.org/jira/browse/GERONIMO-535 > Project: Apache Geronimo > Type: Improvement > Components: core > Versions: 1.0-M4 > Environment: fedora core 2 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) > geronimo svn Revision: 123724 > Reporter: toby cabot > Attachments: absolute-file.patch, absolute-file.patch > > It would be useful to me (and hopefully others) to be able to specify > fully-qualified pathnames in configuration files. For example, if we want to > integrate Geronimo with Linux systems we'll want to write logs into > /var/log/geronimo or thereabouts. I noticed that when I tried to use > fully-qualified paths in configuration files they were resolved relative to > Geronimo's home directory anyway. This patch changes ServerInfo so that if a > filename begins with a "/" it's treated as a fully-qualified path, and if it > doesn't it's resolved relative to Geronimo's home. > Please note that I haven't tried this on a Windows system, so I'm not sure > what the effect is. It works great on Linux. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-535) handle fully-qualified paths in ServerInfo.resolvePath()
[ http://nagoya.apache.org/jira/browse/GERONIMO-535?page=history ] toby cabot updated GERONIMO-535: Attachment: absolute-file.patch > handle fully-qualified paths in ServerInfo.resolvePath() > > > Key: GERONIMO-535 > URL: http://nagoya.apache.org/jira/browse/GERONIMO-535 > Project: Apache Geronimo > Type: Improvement > Components: core > Versions: 1.0-M4 > Environment: fedora core 2 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) > geronimo svn Revision: 123724 > Reporter: toby cabot > Attachments: absolute-file.patch > > It would be useful to me (and hopefully others) to be able to specify > fully-qualified pathnames in configuration files. For example, if we want to > integrate Geronimo with Linux systems we'll want to write logs into > /var/log/geronimo or thereabouts. I noticed that when I tried to use > fully-qualified paths in configuration files they were resolved relative to > Geronimo's home directory anyway. This patch changes ServerInfo so that if a > filename begins with a "/" it's treated as a fully-qualified path, and if it > doesn't it's resolved relative to Geronimo's home. > Please note that I haven't tried this on a Windows system, so I'm not sure > what the effect is. It works great on Linux. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-535) handle fully-qualified paths in ServerInfo.resolvePath()
handle fully-qualified paths in ServerInfo.resolvePath() - Key: GERONIMO-535 URL: http://nagoya.apache.org/jira/browse/GERONIMO-535 Project: Apache Geronimo Type: Improvement Components: core Versions: 1.0-M4 Environment: fedora core 2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) geronimo svn Revision: 123724 Reporter: toby cabot Attachments: absolute-file.patch It would be useful to me (and hopefully others) to be able to specify fully-qualified pathnames in configuration files. For example, if we want to integrate Geronimo with Linux systems we'll want to write logs into /var/log/geronimo or thereabouts. I noticed that when I tried to use fully-qualified paths in configuration files they were resolved relative to Geronimo's home directory anyway. This patch changes ServerInfo so that if a filename begins with a "/" it's treated as a fully-qualified path, and if it doesn't it's resolved relative to Geronimo's home. Please note that I haven't tried this on a Windows system, so I'm not sure what the effect is. It works great on Linux. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-534) ejb deployment causes NoClassDefFoundError
ejb deployment causes NoClassDefFoundError -- Key: GERONIMO-534 URL: http://nagoya.apache.org/jira/browse/GERONIMO-534 Project: Apache Geronimo Type: Bug Components: deployment Versions: 1.0-M4 Environment: fedora core 2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) geronimo code At revision 123657, openejb cvs updated 2004-12-29 Reporter: toby cabot Deployment of a simple stateless session EJB (either online or offline) yields a "java.lang.NoClassDefFoundError: javax/wsdl/WSDLException". [EMAIL PROTECTED]:~/try/hello-g6o$ java -jar ~/geronimo/bin/deployer.jar deploy build/g6o-ejb.jar Username: system Password: manager Deployment failed Server reports: javax.management.remote.JMXServerErrorException: Error thrown during invocation org.apache.geronimo.kernel.InternalKernelException: javax.management.remote.JMXServerErrorException: Error thrown during invocation at org.apache.geronimo.kernel.jmx.KernelDelegate.invoke(KernelDelegate.java:232) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:95) at java.lang.Thread.run(Thread.java:534) Caused by: javax.management.remote.JMXServerErrorException: Error thrown during invocation at mx4j.remote.rmi.RMIConnectionSubjectInvoker.chain(RMIConnectionSubjectInvoker.java:103) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.access$000(RMIConnectionSubjectInvoker.java:32) at mx4j.remote.rmi.RMIConnectionSubjectInvoker$1.run(RMIConnectionSubjectInvoker.java:89) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:500) at mx4j.remote.MX4JRemoteUtils.subjectInvoke(MX4JRemoteUtils.java:151) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.subjectInvoke(RMIConnectionSubjectInvoker.java:85) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.invoke(RMIConnectionSubjectInvoker.java:79) at $Proxy0.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:224) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133) at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown Source) at mx4j.remote.rmi.ClientInvoker.invoke(ClientInvoker.java:210) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at mx4j.remote.ClientProxy.invoke(ClientProxy.java:34) at mx4j.remote.rmi.ClientUnmarshaller.chain(ClientUnmarshaller.java:67) at mx4j.remote.rmi.ClientUnmarshaller.invoke(ClientUnmarshaller.java:56) at $Proxy0.invoke(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at mx4j.remote.ClientProxy.invoke(ClientProxy.java:34) at mx4j.remote.rmi.ClientExceptionCatcher.invoke(ClientExceptionCatcher.java:42) at $Proxy0.invoke(Unknown Source) at org.apache.geronimo.kernel.jmx.KernelDelegate.invokeKernel(KernelDelegate.java:349) at org.apache.geronimo.kernel.jmx.KernelDelegate.invoke(KernelDelegate.java:228) ... 2 more Caused by: java.lang.NoClassDefFoundError: javax/wsdl/WSDLException at org.openejb.deployment.SessionBuilder.addWSContainerGBean(SessionBuilder.java:159) at org.openejb.deployment.SessionBuilder.buildBeans(SessionBuilder.java:153)
[jira] Commented: (GERONIMO-307) servlet tries to lookup resource adapter: IllegalStateException
[ http://nagoya.apache.org/jira/browse/GERONIMO-307?page=comments#action_55374 ] toby cabot commented on GERONIMO-307: - David, Aaron, Thanks for your attention on this. The change from target-name to resource-link is indeed the fix, and the components are being brought up in the correct order, so I'm all set and please feel free to close this bug. Again, thanks to both of you. > servlet tries to lookup resource adapter: IllegalStateException > --- > > Key: GERONIMO-307 > URL: http://nagoya.apache.org/jira/browse/GERONIMO-307 > Project: Apache Geronimo > Type: Bug > Versions: 1.0-M2 > Environment: fedora core 2 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) > Reporter: toby cabot > > I'm trying to use a resource adapter in a web application. The > adapter is home-grown but I expect that the technique would be similar > for an off-the-shelf one. > My RA's connectiondefinition-instance name is "testCF" and if I use: > > > > web.xml: > > ra/CF > g6o.ra.ConnectionFactory > Application > > > > > geronimo-jetty.xml: > > ra/CF > testCF > > > > > ...I can deploy, and the server runs, but I get a NamingException in > the servlet init which I've attached as a postscript. The strange > part is that if I cut and paste the target name that the exception > message indicated was "not started" into the debug console "Filter > Output" box it shows up as running. Judging from the "name=testCF not > started" message in the stack trace perhaps there's an issue with the > order in which the components within the ear are being started? Can I > influence that order somehow? > > > > As an aside, this is a "soft" exception in that Geronimo keeps running > after it happens; even the servlet is running. If I do something to > cause a different error, i.e. try to look up an obviously bogus JNDI > name, then Geronimo will shut down. > > > > Thanks, > Toby > PS: stack trace: > javax.naming.NamingException: could not look up : env/ra/CF [Root exception > is java.lang.IllegalStateException: Proxy not returned. Target > +geronimo.server:J2EEServer=geronimo,j2eeType=JCAManagedConnectionFactory,name=testCF > not started] > at > org.apache.geronimo.naming.java.ReadOnlyContext.lookup(ReadOnlyContext.java:209) > at > org.apache.geronimo.naming.java.RootContext.lookup(RootContext.java:55) > at javax.naming.InitialContext.lookup(InitialContext.java:347) > at g6o.servlet.Servlet.init(Servlet.java:51) > at > org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:226) > at > org.mortbay.jetty.servlet.ServletHandler.initializeServlets(ServletHandler.java:390) > at > org.mortbay.jetty.servlet.WebApplicationHandler.initializeServlets(WebApplicationHandler.java:287) > at > org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext.java:421) > at > org.apache.geronimo.jetty.JettyWebAppContext.doStart(JettyWebAppContext.java:219) > at > org.apache.geronimo.gbean.jmx.GBeanMBean.doStart(GBeanMBean.java:593) > at > org.apache.geronimo.gbean.jmx.AbstractManagedObject.attemptFullStart(AbstractManagedObject.java:479) > at > org.apache.geronimo.gbean.jmx.SingleProxy.attemptFullStart(SingleProxy.java:154) > at > org.apache.geronimo.gbean.jmx.SingleProxy.addTarget(SingleProxy.java:119) > at > org.apache.geronimo.gbean.jmx.GBeanMBeanReference.handleNotification(GBeanMBeanReference.java:307) > at > mx4j.server.interceptor.NotificationListenerMBeanServerInterceptor$ListenerWrapper.handleNotification(NotificationListenerMBeanServerInterceptor.java:57) > at > javax.management.NotificationBroadcasterSupport.handleNotification(NotificationBroadcasterSupport.java:346) > at > javax.management.NotificationBroadcasterSupport.sendNotification(NotificationBroadcasterSupport.java:320) > at > org
[jira] Commented: (GERONIMO-307) servlet tries to lookup resource adapter: IllegalStateException
[ http://nagoya.apache.org/jira/browse/GERONIMO-307?page=comments#action_55373 ] toby cabot commented on GERONIMO-307: - I tried installing the modules not in an ear but one at a time. EJB and RA deployed and seem to run fine (i.e. they show up in the debug console as "running") but the web deployment failed. I can't say what the problem was since there wasn't any stack trace on the server side and the client side just says: Deployment failed Server reports: Error unmarshaling return; nested exception is: java.lang.ClassNotFoundException: org.apache.geronimo.j2ee.deployment.UnresolvedEJBRefException (no security manager: RMI class loader disabled) java.rmi.UnmarshalException: Error unmarshaling return; nested exception is: java.lang.ClassNotFoundException: org.apache.geronimo.j2ee.deployment.UnresolvedEJBRefException (no security manager: RMI class loader disabled) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:217) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133) at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown Source) at mx4j.remote.rmi.ClientInvoker.invoke(ClientInvoker.java:210) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at mx4j.remote.ClientProxy.invoke(ClientProxy.java:34) at mx4j.remote.rmi.ClientUnmarshaller.chain(ClientUnmarshaller.java:67) at mx4j.remote.rmi.ClientUnmarshaller.invoke(ClientUnmarshaller.java:56) at $Proxy0.invoke(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at mx4j.remote.ClientProxy.invoke(ClientProxy.java:34) at mx4j.remote.rmi.ClientExceptionCatcher.invoke(ClientExceptionCatcher.java:42) at $Proxy0.invoke(Unknown Source) at org.apache.geronimo.gbean.jmx.JMXOperationInvoker.invoke(JMXOperationInvoker.java:54) at org.apache.geronimo.gbean.jmx.CGLibMethodInterceptor.intercept(CGLibMethodInterceptor.java:112) at org.apache.geronimo.kernel.KernelMBean$$EnhancerByCGLIB$$66f64035.invoke() at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:95) at java.lang.Thread.run(Thread.java:534) Caused by: java.lang.ClassNotFoundException: org.apache.geronimo.j2ee.deployment.UnresolvedEJBRefException (no security manager: RMI class loader disabled) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:371) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165) at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:631) at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:257) at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:200) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1845) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1769) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:215) ... 23 more I tried putting geronimo-j2ee-builder-1.0-SNAPSHOT.jar on the deployer classpath but got the same error. > servlet tries to lookup resource adapter: IllegalStateException > --- > > Key: GERONIMO-307 > URL: http://nagoya.apache.org/jira/browse/GERONIMO-307 > Project: Apache Geronimo > Type: Bug > Versions: 1.0-M2 > Environment: fedora core 2 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) > Reporter: toby cabot > > I'm trying to use a resource adapter in a web application. The > adapter is home-grown but I expect that the technique would be similar > for an off-the-shelf one. > My RA's connectiondefinition-instance name is "testCF" and if I use: >
[jira] Commented: (GERONIMO-307) servlet tries to lookup resource adapter: IllegalStateException
[ http://nagoya.apache.org/jira/browse/GERONIMO-307?page=comments#action_55369 ] toby cabot commented on GERONIMO-307: - Aaron, Thanks for looking into this. I did a new build from recent svn and the error seems to be different. My connectiondefinition-instance/name is testCF which I think should be valid. That's also what's in my resource-ref/target-name and when I either try to deploy or distribute then bring up geronimo I get the following stack trace: javax.naming.NamingException: could not look up : env/ra/CF [Root exception is java.lang.IllegalArgumentException: Invalid object name in jmxRefAddr: testCF] at org.apache.geronimo.naming.java.ReadOnlyContext.lookup(ReadOnlyContext.java:209) at org.apache.geronimo.naming.java.RootContext.lookup(RootContext.java:55) at javax.naming.InitialContext.lookup(InitialContext.java:347) at g6o.servlet.Servlet.init(Servlet.java:52) at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:369) at org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:243) at org.mortbay.jetty.servlet.ServletHandler.initializeServlets(ServletHandler.java:447) at org.mortbay.jetty.servlet.WebApplicationHandler.initializeServlets(WebApplicationHandler.java:298) at org.mortbay.jetty.servlet.WebApplicationContext.doStart(WebApplicationContext.java:512) at org.apache.geronimo.jetty.JettyWebAppContext.doStart(JettyWebAppContext.java:244) at org.mortbay.util.Container.start(Container.java:72) at org.apache.geronimo.jetty.JettyWebAppContext.doStart(JettyWebAppContext.java:211) at org.apache.geronimo.gbean.jmx.GBeanMBean.doStart(GBeanMBean.java:616) at org.apache.geronimo.gbean.jmx.AbstractManagedObject.attemptFullStart(AbstractManagedObject.java:511) at org.apache.geronimo.gbean.jmx.AbstractManagedObject.start(AbstractManagedObject.java:305) at org.apache.geronimo.gbean.jmx.AbstractManagedObject.startRecursive(AbstractManagedObject.java:329) at org.apache.geronimo.gbean.jmx.GBeanMBean$11.invoke(GBeanMBean.java:1036) at org.apache.geronimo.gbean.jmx.GBeanMBeanOperation.invoke(GBeanMBeanOperation.java:142) at javax.naming.NamingException: could not look up : env/ra/CF [Root exception is java.lang.IllegalArgumentException: Invalid object name in jmxRefAddr: testCF] at org.apache.geronimo.naming.java.ReadOnlyContext.lookup(ReadOnlyContext.java:209) at org.apache.geronimo.naming.java.RootContext.lookup(RootContext.java:55) at javax.naming.InitialContext.lookup(InitialContext.java:347) at g6o.servlet.Servlet.init(Servlet.java:52) at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:369) at org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:243) at org.mortbay.jetty.servlet.ServletHandler.initializeServlets(ServletHandler.java:447) at org.mortbay.jetty.servlet.WebApplicationHandler.initializeServlets(WebApplicationHandler.java:298) at org.mortbay.jetty.servlet.WebApplicationContext.doStart(WebApplicationContext.java:512) at org.apache.geronimo.jetty.JettyWebAppContext.doStart(JettyWebAppContext.java:244) at org.mortbay.util.Container.start(Container.java:72) at org.apache.geronimo.jetty.JettyWebAppContext.doStart(JettyWebAppContext.java:211) at org.apache.geronimo.gbean.jmx.GBeanMBean.doStart(GBeanMBean.java:616) at org.apache.geronimo.gbean.jmx.AbstractManagedObject.attemptFullStart(AbstractManagedObject.java:511) at org.apache.geronimo.gbean.jmx.AbstractManagedObject.start(AbstractManagedObject.java:305) at org.apache.geronimo.gbean.jmx.AbstractManagedObject.startRecursive(AbstractManagedObject.java:329) at org.apache.geronimo.gbean.jmx.GBeanMBean$11.invoke(GBeanMBean.java:1036) at org.apache.geronimo.gbean.jmx.GBeanMBeanOperation.invoke(GBeanMBeanOperation.java:142) at org.apache.geronimo.gbean.jmx.GBeanMBean.invoke(GBeanMBean.java:844) at mx4j.server.interceptor.InvokerMBeanServerInterceptor.invoke(InvokerMBeanServerInterceptor.java:218) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121) at mx4j.server.interceptor.SecurityMBeanServerInterceptor.invoke(SecurityMBeanServerInterceptor.java:86) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121) at mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.invoke(ContextClassLoaderMBeanServerInterceptor.java:205) at mx4j.server.MX4JMBeanServer.invoke(MX4JMBeanServer.java:1079) at org.apache.geronimo.gbean.jmx.AbstractManaged
[jira] Commented: (GERONIMO-408) TM and active mark: Testing Build fails with InvalidConfigException caused by: org.objectweb.howl.log.LogClosedException
[ http://nagoya.apache.org/jira/browse/GERONIMO-408?page=comments#action_55063 ] toby cabot commented on GERONIMO-408: - Yup, Ralf's correct, it looks like GERONIMO-437 is a dupe of this bug. The only data I'd move over from that bug to this one is that if I copy howl-logger-0.1.7.jar over howl-logger-0.1.7-SNAPSHOT.jar (in the maven repository) then things work fine. > TM and active mark: Testing Build fails with InvalidConfigException caused > by: org.objectweb.howl.log.LogClosedException > > > Key: GERONIMO-408 > URL: http://nagoya.apache.org/jira/browse/GERONIMO-408 > Project: Apache Geronimo > Type: Bug > Components: buildsystem, transaction manager > Versions: 1.0-M3 > Environment: Maven v. 1.0 > java version "1.4.2_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04) > Java HotSpot(TM) Client VM (build 1.4.2_05-b04, mixed mode) > Microsoft Windows 2000 [Version 5.00.2195] > Reporter: Ralf Barkow > Priority: Blocker > Attachments: geronimo-DebugConsole.log, > geronimo-transaction_test-reports_errors.zip, geronimo.log.zip > > Does the TM set an active mark? > Testing the current build with > $ java -jar modules/assembly/target/geronimo-1.0-SNAPSHOT/bin/server.jar > org/apache/geronimo/DebugConsole > (...) > fails (see attachted log files). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-437) test/runtime failures with latest HOWL logger
[ http://nagoya.apache.org/jira/browse/GERONIMO-437?page=comments#action_55059 ] toby cabot commented on GERONIMO-437: - forgot to mention: if I run the build so that it doesn't run the unit tests then it succeeds but I get a similar stack trace when I start the server. > test/runtime failures with latest HOWL logger > - > > Key: GERONIMO-437 > URL: http://nagoya.apache.org/jira/browse/GERONIMO-437 > Project: Apache Geronimo > Type: Bug > Components: transaction manager > Versions: 1.0-M2 > Environment: java version "1.4.2_06" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) > Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode) > fedora core 2 and red hat 9 > Reporter: toby cabot > > I get build-time unit test failures with the latest version of > ~/.maven/repository/howl/jars/howl-logger-0.1.7-SNAPSHOT.jar. If I copy > howl-logger-0.1.7.jar over howl-logger-0.1.7-SNAPSHOT.jar then things work > fine. > build output is: > test:test: > [junit] Running org.apache.geronimo.transaction.log.HOWLLogTest > [junit] Tests run: 2, Failures: 0, Errors: 1, Time elapsed: 0.225 sec > [junit] [ERROR] TEST org.apache.geronimo.transaction.log.HOWLLogTest > FAILED > [junit] Running > org.apache.geronimo.transaction.context.TransactionContextManagerTest > [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.21 sec > [junit] Running org.apache.geronimo.transaction.manager.ProtocolTest > [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.084 sec > [junit] Running org.apache.geronimo.transaction.manager.XidImporterTest > [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.052 sec > [junit] Running > org.apache.geronimo.transaction.manager.MockLogRecoveryTest > [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.142 sec > [junit] Running > org.apache.geronimo.transaction.manager.HOWLLogRecoveryTest > [junit] Tests run: 5, Failures: 0, Errors: 5, Time elapsed: 0.153 sec > [junit] [ERROR] TEST > org.apache.geronimo.transaction.manager.HOWLLogRecoveryTest FAILED > [junit] Running org.apache.geronimo.transaction.manager.RecoveryTest > [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.046 sec > [junit] Running > org.apache.geronimo.transaction.TransactionManagerProxyTest > [junit] Tests run: 13, Failures: 0, Errors: 0, Time elapsed: 0.052 sec > > the contents of TEST-org.apache.geronimo.transaction.log.HOWLLogTest.txt are: > Testcase: > testTransactionLog(org.apache.geronimo.transaction.log.HOWLLogTest): > Caused an ERROR > org.objectweb.howl.log.InvalidLogKeyException: The initial mark [0] requested > for replay was not found in the log. > org.objectweb.howl.log.LogClosedException: > org.objectweb.howl.log.InvalidLogKeyException: The initial mark [0] requested > for replay was not found in the log. > at org.objectweb.howl.log.xa.XALogger.open(XALogger.java:858) > at org.apache.geronimo.transaction.log.HOWLLog.doStart(HOWLLog.java:217) > at > org.apache.geronimo.transaction.log.HOWLLogTest.createTransactionLog(HOWLLogTest.java:67) > at > org.apache.geronimo.transaction.log.AbstractLogTest.testTransactionLog(AbstractLogTest.java:92) > at > org.apache.geronimo.transaction.log.AbstractLogTest.testTransactionLog(AbstractLogTest.java:70) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:232) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) > at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) > at > org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) > at > org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) > at com.werken.werkz.Goal.fire(Goal.java:639) > at com.werken.werkz.Goal.attain(Goal.java:575) > at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) > at com.werken.werkz.Goal.attain(Goal.java:573) > at com.werken.werkz.Goal.attainPrecursors
[jira] Created: (GERONIMO-437) test/runtime failures with latest HOWL logger
test/runtime failures with latest HOWL logger - Key: GERONIMO-437 URL: http://nagoya.apache.org/jira/browse/GERONIMO-437 Project: Apache Geronimo Type: Bug Components: transaction manager Versions: 1.0-M2 Environment: java version "1.4.2_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode) fedora core 2 and red hat 9 Reporter: toby cabot I get build-time unit test failures with the latest version of ~/.maven/repository/howl/jars/howl-logger-0.1.7-SNAPSHOT.jar. If I copy howl-logger-0.1.7.jar over howl-logger-0.1.7-SNAPSHOT.jar then things work fine. build output is: test:test: [junit] Running org.apache.geronimo.transaction.log.HOWLLogTest [junit] Tests run: 2, Failures: 0, Errors: 1, Time elapsed: 0.225 sec [junit] [ERROR] TEST org.apache.geronimo.transaction.log.HOWLLogTest FAILED [junit] Running org.apache.geronimo.transaction.context.TransactionContextManagerTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.21 sec [junit] Running org.apache.geronimo.transaction.manager.ProtocolTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.084 sec [junit] Running org.apache.geronimo.transaction.manager.XidImporterTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.052 sec [junit] Running org.apache.geronimo.transaction.manager.MockLogRecoveryTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.142 sec [junit] Running org.apache.geronimo.transaction.manager.HOWLLogRecoveryTest [junit] Tests run: 5, Failures: 0, Errors: 5, Time elapsed: 0.153 sec [junit] [ERROR] TEST org.apache.geronimo.transaction.manager.HOWLLogRecoveryTest FAILED [junit] Running org.apache.geronimo.transaction.manager.RecoveryTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.046 sec [junit] Running org.apache.geronimo.transaction.TransactionManagerProxyTest [junit] Tests run: 13, Failures: 0, Errors: 0, Time elapsed: 0.052 sec the contents of TEST-org.apache.geronimo.transaction.log.HOWLLogTest.txt are: Testcase: testTransactionLog(org.apache.geronimo.transaction.log.HOWLLogTest): Caused an ERROR org.objectweb.howl.log.InvalidLogKeyException: The initial mark [0] requested for replay was not found in the log. org.objectweb.howl.log.LogClosedException: org.objectweb.howl.log.InvalidLogKeyException: The initial mark [0] requested for replay was not found in the log. at org.objectweb.howl.log.xa.XALogger.open(XALogger.java:858) at org.apache.geronimo.transaction.log.HOWLLog.doStart(HOWLLog.java:217) at org.apache.geronimo.transaction.log.HOWLLogTest.createTransactionLog(HOWLLogTest.java:67) at org.apache.geronimo.transaction.log.AbstractLogTest.testTransactionLog(AbstractLogTest.java:92) at org.apache.geronimo.transaction.log.AbstractLogTest.testTransactionLog(AbstractLogTest.java:70) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:232) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) at com.werken.werkz.Goal.attain(Goal.java:573) at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) at com.werken.werkz.Goal.attain(Goal.java:573) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.M
[jira] Updated: (GERONIMO-264) exceptions being swallowed at startup
[ http://nagoya.apache.org/jira/browse/GERONIMO-264?page=history ] toby cabot updated GERONIMO-264: Attachment: Daemon-56609-diff.txt here's an updated patch which merges with version 56609 of Daemon.java. While this is a trivial change in terms of code, it makes a big difference in usability, especially for new users. Without the patch, exceptions appear out of order which makes it harder to see what caused what. I think that this would be a worthwhile improvement for M3. > exceptions being swallowed at startup > - > > Key: GERONIMO-264 > URL: http://nagoya.apache.org/jira/browse/GERONIMO-264 > Project: Apache Geronimo > Type: Improvement > Components: deployment > Versions: 1.0-M2 > Environment: fedora core 2 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) > Reporter: toby cabot > Assignee: Dain Sundstrom > Priority: Minor > Attachments: Daemon-1_9-diff.txt, Daemon-56609-diff.txt, daemon-log.diff, > daemon-log.diff, log.txt > > some exceptions that are thrown during startup are swallowed and don't show > up in the logs. > i'm at the 'monkey and typewriter' stage of the geronimo learning curve so > i'm a good randomness injector. i had a problem where geronimo would try to > start up and then go directly to shutdown for no apparent reason. actually, > i think i've had a few: > 15:50:17,290 DEBUG [GBeanMBean] geronimo.config:name="skeleton/RA" State > changed from stopped to starting > 15:50:17,292 DEBUG [Configuration] ClassPath for skeleton/RA resolved to > [file:/home/tcabot/try/incubator-geronimo/target/config-store/8/connector/skeleton-ra.jar] > ra test setting configParameter to NewStringValue > 15:50:17,737 DEBUG [SpreadManagedConnectionFactory] > BaseManagedConnectionFactory() > 15:50:17,737 DEBUG [SpreadManagedConnectionFactory] > SpreadManagedConnectionFactory() > 15:50:18,425 DEBUG [GBeanMBean] geronimo.config:name="skeleton/RA" State > changed from starting to failed > 15:50:18,426 INFO [Kernel] Starting kernel shutdown > i'll include a patch that logs the problem in the catch clause in > Configuration.doStart(). There might be better places to do this, but as > long as it gets done *somewhere* i'm happy. > regards, > toby -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
