[BUILD] trunk: Failed for Revision: 776574
Geronimo Revision: 776574 built with tests included See the full build-0300.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20090520/build-0300.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/trunk/20090520 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 45 minutes 12 seconds [INFO] Finished at: Wed May 20 03:48:29 EDT 2009 [INFO] Final Memory: 438M/1014M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20090520/logs-0300-tomcat/test.log Booting Geronimo Kernel (in Java 1.5.0_12)... Module 1/75 org.apache.geronimo.framework/j2ee-system/2.2-SNAPSHOT/car started in .000s Module 2/75 org.apache.geronimo.framework/jee-specs/2.2-SNAPSHOT/car started in .000s Module 3/75 org.apache.geronimo.framework/xmlbeans/2.2-SNAPSHOT/car started in .000s Module 4/75 org.apache.geronimo.framework/rmi-naming/2.2-SNAPSHOT/car 2009-05-20 03:52:14,831 WARN [RMIRegistryService] RMI Registry failed 2009-05-20 03:52:14,833 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.framework/rmi-naming/2.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.framework/rmi-naming/2.2-SNAPSHOT/car,j2eeType=GBean,name=RMIRegistry java.rmi.server.ExportException: Port already in use: 1099; nested exception is: java.net.BindException: Address already in use at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:249) at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:184) at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:382) at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:116) at sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:180) at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:92) at sun.rmi.registry.RegistryImpl.init(RegistryImpl.java:68) at java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:222) at org.apache.geronimo.kernel.rmi.RMIRegistryService.doStart(RMIRegistryService.java:72) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:948) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:269) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:103) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:125) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:538) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:377) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:456) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:190) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:546) 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:585) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:815) 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$$e04437ce.startConfiguration(generated) at org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:161) at org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:78) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main
Re: Possible for G to directly consume a Tomcat server config w/o changes?
On May 19, 2009, at 8:17 PM, Lin Sun wrote: I am not a tomcat expert either... :-) I think we could also try the following approach: 1. figure out how to read tomcat server.xml like you described. Tomcat is using 2. at the G server startup, transform data in tomcat server.xml into G config.xml, if there is change to server.xml since last time server started. I think coming up for the mapping could be hard as configuring some features like valve or cluster requires documentation, time and experience. Also, there could be some functions/configurations in server.xml that we don't support in G yet. I'm not sure about this idea. It seems really contrary to how most of geronimo works where we take some kind of plan and more or less freeze the configuration while pre-deploying it into a pretty much immutable plugin. I'm not convinced that accepting a new kind of plan for a few gbeans requires adding this continual redeploy functionality to geronimo. 3. During G startup, G can just build the embedded tomcat server by reading data from config.xml, like what it is doing today. config.xml doesn't have to contain any info on the tomcat server except that it ought to be started, i.e. listing the plugin. The gbean configurations are all serialized in the plugin. I'd generally prefer it if we dropped the ability to add gbeans to a plugin via config.xml. AFAIK, server.xml doesn't contain any app info. I agree that this is a very big change and requires a lot of testing to make sure things are not regressed. Adding this new namespace driven builder is entirely new functionality so there is not really any chance of regressions unless we decide to deploy the standard tomcat server this way, which is certainly not necessary to adding the feature. So, to me the only problems are actually writing the deployer and making sure it at least sort of works. thanks david jencks Lin On Tue, May 19, 2009 at 6:09 PM, David Jencks david_jen...@yahoo.com wrote: I'm not enough of a tomcat expert to know exactly what information a server.xml contains so I'm not quite sure how much the following makes sense. I think I would approach this by building a namespace aware builder that can interpret documents following the server.xml schema and construct the entire tomcat server from it. In other words, instead of starting with our current tomcat6 plugin, the builder would construct a replacement for it from the server.xml. If server.xml contains info on apps that are deployed in the tomcat instance, this could perhaps hook into or extend the current TomcatModuleBuilder to also set up plugins for each web app involved. The first part here might not be too hard. IMO if we treat the server.xml as a geronimo plan that would be acceptable. I'd recommend trying jaxb rather than using xmlbeans. I don't know how practical this would turn out to be but it's worth starting with. I personally think this is too large an addition to plan to get into 2.2. However if a motivated person shows up with something working before we solve the other problems I think we could consider it. 2.2 is already so much later than we had planned I don't want to hold it up for any new features after the other problems have been solved. thanks david jencks Lin On Mon, May 18, 2009 at 3:49 PM, Bill Stoddard wgstodd...@gmail.com wrote: I know G can't consume tomcat configs today, but is this a feature that could be developed for G 2.2? Say I have an application successfully deployed and running under Tomcat.. wouldn't it be nice if I were able to drop the tomcat server config into a Geronimo-Tomcat assembly, start the server, deploy the app and be up and running in seconds. I'm talking about a seamless, zero effort/ zero touch migration from Tomcat to a Geronimo-Tomcat assembly. Is it possible? If not, what simplifying assumptions could be made to 'mostly' achieve a zero-touch migration? What are the primary challenges with consuming a tomcat config unchanged with a G-Tomcat assembly? Same Q's apply for Jetty... what's 'doable' with-in reason? Thanks, Bill
International characters trouble with a servlet-based webservice
I use a servlet-based webservice deployed into geronimo 2.1.4. The service client runs is Axis2.1.4. The problem is: Umlauts (characters like ä, ü, ö) are coming wrong coded at the Websevice. Incoming messages at the webservice side are in ContentType text/xml; charset=UTF-8. Is there a solutions for this trouble? -- View this message in context: http://www.nabble.com/International-characters-trouble-with-a-servlet-based-webservice-tp23630408s134p23630408.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[jira] Created: (GERONIMO-4637) Need documents on how to replace default file realm in Geronimo
Need documents on how to replace default file realm in Geronimo --- Key: GERONIMO-4637 URL: https://issues.apache.org/jira/browse/GERONIMO-4637 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: documentation Affects Versions: 2.2 Reporter: Chi Runhua Priority: Minor The default security realm is of properties files in Geronimo. While Geronimo supports another 2 types of security realm such as SQL and LDAP. It would be nice if we have tutorials on how to replace the default one with SQL or LDAP realms. Jeff C -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4503) PlanCreator threw exception with .war
[ https://issues.apache.org/jira/browse/GERONIMO-4503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang reassigned GERONIMO-4503: -- Assignee: Rex Wang PlanCreator threw exception with .war - Key: GERONIMO-4503 URL: https://issues.apache.org/jira/browse/GERONIMO-4503 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: PlanCreator Affects Versions: 2.2 Environment: WinXP+Sun Java1.6.0+ Geronimo v2.2 Build0107 Reporter: Chi Runhua Assignee: Rex Wang Priority: Blocker Fix For: 2.2 Attachments: WebAppJDBCAccess.war A simple WebAppJDBCAccess.war without a geronimo deployment plan, so I tried to create one using wizard from v2.2 , but failed with HTTP 500 error. Exception throwed from command line as followed: Note: Tried the same .war on Geronimo v2.1.3+Java1.6, everything works fine. ++ 2009-01-09 15:14:22,000 ERROR [[PlanCreator]] Servlet.service() for servlet PlanCreator threw exception java.lang.ClassNotFoundException: org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager in classloader org.apache.geronimo.plugins/plancreator-console-tomcat/2.2-SNAPSHOT/car at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadOptimizedClass(MultiParentClassLoader.java:413) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:255) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClassInternal(Unknown Source) at org.apache.geronimo.console.configcreator.JSR88_Util.createApplicationInfo(JSR88_Util.java:71) at org.apache.geronimo.console.configcreator.GetArchiveHandler.actionAfterView(GetArchiveHandler.java:70) at org.apache.geronimo.console.MultiPagePortlet.processAction(MultiPagePortlet.java:114) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:145) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:535) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:472) at org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167) at org.apache.pluto.core.DefaultPortletInvokerService.action(DefaultPortletInvokerService.java:85) at org.apache.pluto.core.PortletContainerImpl.doAction(PortletContainerImpl.java:219) at org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:121) at org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:167) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:406) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) at
[jira] Created: (GERONIMO-4638) ForwardData held by GenericForwardServlet will be invalid after the target application is restarted
ForwardData held by GenericForwardServlet will be invalid after the target application is restarted --- Key: GERONIMO-4638 URL: https://issues.apache.org/jira/browse/GERONIMO-4638 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.1.5, 2.2 Environment: JDK 1.5.0 Windows XP Pro Reporter: Ivan Priority: Minor 2009-05-20 17:57:53,062 ERROR [[context-forward]] Servlet.service() for servlet context-forward threw exception java.lang.NullPointerException at org.apache.geronimo.console.servlet.GenericForwardServlet.doPost(GenericForwardServlet.java:147) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.geronimo.console.filter.XSSXSRFFilter.doFilter(XSSXSRFFilter.java:125) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:406) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:810) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4070) Plugin installer fails to install after previous attempt of a plugin has failed.
[ https://issues.apache.org/jira/browse/GERONIMO-4070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Jiang reassigned GERONIMO-4070: - Assignee: Shawn Jiang (was: Joseph Leong) Plugin installer fails to install after previous attempt of a plugin has failed. Key: GERONIMO-4070 URL: https://issues.apache.org/jira/browse/GERONIMO-4070 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Environment: Ubuntu 7.10, Firefox Reporter: Joseph Leong Assignee: Shawn Jiang When the plugin installer fails installing a plugin.. for whatever reason.. missing dependency/file etc.. the following attempt to install another plugin will be unsuccessful because it tries to load/start the configuration that failed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4070) Plugin installer fails to install after previous attempt of a plugin has failed.
[ https://issues.apache.org/jira/browse/GERONIMO-4070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Jiang updated GERONIMO-4070: -- Attachment: G4070_21.patch Patch for 2.1 branch. tested with geronimo 2.1.4 release. Plugin installer fails to install after previous attempt of a plugin has failed. Key: GERONIMO-4070 URL: https://issues.apache.org/jira/browse/GERONIMO-4070 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Environment: Ubuntu 7.10, Firefox Reporter: Joseph Leong Assignee: Shawn Jiang Attachments: G4070_21.patch When the plugin installer fails installing a plugin.. for whatever reason.. missing dependency/file etc.. the following attempt to install another plugin will be unsuccessful because it tries to load/start the configuration that failed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4070) Plugin installer fails to install after previous attempt of a plugin has failed.
[ https://issues.apache.org/jira/browse/GERONIMO-4070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Jiang updated GERONIMO-4070: -- Attachment: G4070_trunk.patch Patch for trunk. tested with latest 2.2. snapshot build. Plugin installer fails to install after previous attempt of a plugin has failed. Key: GERONIMO-4070 URL: https://issues.apache.org/jira/browse/GERONIMO-4070 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Environment: Ubuntu 7.10, Firefox Reporter: Joseph Leong Assignee: Shawn Jiang Attachments: G4070_21.patch, G4070_trunk.patch When the plugin installer fails installing a plugin.. for whatever reason.. missing dependency/file etc.. the following attempt to install another plugin will be unsuccessful because it tries to load/start the configuration that failed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4070) Plugin installer fails to install after previous attempt of a plugin has failed.
[ https://issues.apache.org/jira/browse/GERONIMO-4070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Jiang updated GERONIMO-4070: -- Patch Info: [Patch Available] Plugin installer fails to install after previous attempt of a plugin has failed. Key: GERONIMO-4070 URL: https://issues.apache.org/jira/browse/GERONIMO-4070 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Environment: Ubuntu 7.10, Firefox Reporter: Joseph Leong Assignee: Shawn Jiang Attachments: G4070_21.patch, G4070_trunk.patch When the plugin installer fails installing a plugin.. for whatever reason.. missing dependency/file etc.. the following attempt to install another plugin will be unsuccessful because it tries to load/start the configuration that failed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4503) PlanCreator threw exception with .war
[ https://issues.apache.org/jira/browse/GERONIMO-4503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang updated GERONIMO-4503: --- Attachment: GERONIMO-4503.patch GERONIMO-4503.patch can resolve this. Could anyone help commit this? -Rex PlanCreator threw exception with .war - Key: GERONIMO-4503 URL: https://issues.apache.org/jira/browse/GERONIMO-4503 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: PlanCreator Affects Versions: 2.2 Environment: WinXP+Sun Java1.6.0+ Geronimo v2.2 Build0107 Reporter: Chi Runhua Assignee: Rex Wang Priority: Blocker Fix For: 2.2 Attachments: GERONIMO-4503.patch, WebAppJDBCAccess.war A simple WebAppJDBCAccess.war without a geronimo deployment plan, so I tried to create one using wizard from v2.2 , but failed with HTTP 500 error. Exception throwed from command line as followed: Note: Tried the same .war on Geronimo v2.1.3+Java1.6, everything works fine. ++ 2009-01-09 15:14:22,000 ERROR [[PlanCreator]] Servlet.service() for servlet PlanCreator threw exception java.lang.ClassNotFoundException: org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager in classloader org.apache.geronimo.plugins/plancreator-console-tomcat/2.2-SNAPSHOT/car at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadOptimizedClass(MultiParentClassLoader.java:413) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:255) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClassInternal(Unknown Source) at org.apache.geronimo.console.configcreator.JSR88_Util.createApplicationInfo(JSR88_Util.java:71) at org.apache.geronimo.console.configcreator.GetArchiveHandler.actionAfterView(GetArchiveHandler.java:70) at org.apache.geronimo.console.MultiPagePortlet.processAction(MultiPagePortlet.java:114) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:145) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:535) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:472) at org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167) at org.apache.pluto.core.DefaultPortletInvokerService.action(DefaultPortletInvokerService.java:85) at org.apache.pluto.core.PortletContainerImpl.doAction(PortletContainerImpl.java:219) at org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:121) at org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:167) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:406) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at
[BUILD] trunk: Failed for Revision: 776672
Geronimo Revision: 776672 built with tests included See the full build-0900.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20090520/build-0900.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/trunk/20090520 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 40 minutes 21 seconds [INFO] Finished at: Wed May 20 09:43:27 EDT 2009 [INFO] Final Memory: 408M/1009M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20090520/logs-0900-tomcat/test.log Booting Geronimo Kernel (in Java 1.5.0_12)... Module 1/75 org.apache.geronimo.framework/j2ee-system/2.2-SNAPSHOT/car started in .000s Module 2/75 org.apache.geronimo.framework/jee-specs/2.2-SNAPSHOT/car started in .000s Module 3/75 org.apache.geronimo.framework/xmlbeans/2.2-SNAPSHOT/car started in .000s Module 4/75 org.apache.geronimo.framework/rmi-naming/2.2-SNAPSHOT/car 2009-05-20 09:47:53,450 WARN [RMIRegistryService] RMI Registry failed 2009-05-20 09:47:53,452 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.framework/rmi-naming/2.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.framework/rmi-naming/2.2-SNAPSHOT/car,j2eeType=GBean,name=RMIRegistry java.rmi.server.ExportException: Port already in use: 1099; nested exception is: java.net.BindException: Address already in use at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:249) at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:184) at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:382) at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:116) at sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:180) at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:92) at sun.rmi.registry.RegistryImpl.init(RegistryImpl.java:68) at java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:222) at org.apache.geronimo.kernel.rmi.RMIRegistryService.doStart(RMIRegistryService.java:72) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:948) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:269) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:103) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:125) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:538) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:377) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:456) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:190) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:546) 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:585) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:815) 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$$23df5cd5.startConfiguration(generated) at org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:161) at org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:78) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main
[jira] Assigned: (GERONIMO-3599) Unable to create new JMS Resource group through console in IE7
[ https://issues.apache.org/jira/browse/GERONIMO-3599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan reassigned GERONIMO-3599: -- Assignee: Ivan (was: Shawn Jiang) Unable to create new JMS Resource group through console in IE7 -- Key: GERONIMO-3599 URL: https://issues.apache.org/jira/browse/GERONIMO-3599 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.0.1, 2.1.4 Environment: WIN XP Reporter: Anish Pathadan Assignee: Ivan Fix For: 2.2 Attachments: GERONIMO-3599-better.patch, GERONIMO-3599.patch I am not able to create a new JMS Resouce group through console. I am getting cannot display the page error after entering the Q name and physical name and then pressing next. The following is the url http://localhost:8080/console/portal/services/services_jms/_ps_services_jms_row1_col1_p1/normal/_pm_services_jms_row1_col1_p1/view/_ac_services_jms_row1_col1_p1/AC/_st_services_jms_row1_col1_p1/normal/_md_services_jms_row1_col1_p1/view/_pid/services_jms_row1_col1_p1 The problem only comes with Internet Explorer 7. Best Regards, Anish Pathadan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3599) Unable to create new JMS Resource group through console in IE7
[ https://issues.apache.org/jira/browse/GERONIMO-3599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12711157#action_12711157 ] Ivan commented on GERONIMO-3599: This issue has been existed for long time, and currently I could not see that MS will solve this issue in the new IE version, The only disadvantage for the latest solution is that once the filter is active for long url, the back button of the browser will not work. But comparing to the error page, I guess that it should be acceptable. If no objection, I will commit the latest patch ! Unable to create new JMS Resource group through console in IE7 -- Key: GERONIMO-3599 URL: https://issues.apache.org/jira/browse/GERONIMO-3599 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.0.1, 2.1.4 Environment: WIN XP Reporter: Anish Pathadan Assignee: Shawn Jiang Fix For: 2.2 Attachments: GERONIMO-3599-better.patch, GERONIMO-3599.patch I am not able to create a new JMS Resouce group through console. I am getting cannot display the page error after entering the Q name and physical name and then pressing next. The following is the url http://localhost:8080/console/portal/services/services_jms/_ps_services_jms_row1_col1_p1/normal/_pm_services_jms_row1_col1_p1/view/_ac_services_jms_row1_col1_p1/AC/_st_services_jms_row1_col1_p1/normal/_md_services_jms_row1_col1_p1/view/_pid/services_jms_row1_col1_p1 The problem only comes with Internet Explorer 7. Best Regards, Anish Pathadan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Possible for G to directly consume a Tomcat server config w/o changes?
One example that we did this is with the config-substitution property file where we allow users to specify configuration and the server reads the config-substitution property file during the startup of the server. If we more or less freeze the configuration, wouldn't this (reading data from server.xml and build the tomcat plugin) have to be done at the build time when we build the geronimo plugin for tomcat using maven2?I think the user would want to do this at runtime where the geronimo server is already prebuilt. On Wed, May 20, 2009 at 3:16 AM, David Jencks david_jen...@yahoo.com wrote: I'm not sure about this idea. It seems really contrary to how most of geronimo works where we take some kind of plan and more or less freeze the configuration while pre-deploying it into a pretty much immutable plugin. I'm not convinced that accepting a new kind of plan for a few gbeans requires adding this continual redeploy functionality to geronimo. 3. During G startup, G can just build the embedded tomcat server by reading data from config.xml, like what it is doing today. config.xml doesn't have to contain any info on the tomcat server except that it ought to be started, i.e. listing the plugin. The gbean configurations are all serialized in the plugin. I'd generally prefer it if we dropped the ability to add gbeans to a plugin via config.xml. Again, this may be something that I don't understand well. If we don't configure it in config.xml, how do we allow users to drop in their tomcat server.xml without rebuilding the tomcat plugin? AFAIK, server.xml doesn't contain any app info. I agree that this is a very big change and requires a lot of testing to make sure things are not regressed. Adding this new namespace driven builder is entirely new functionality so there is not really any chance of regressions unless we decide to deploy the standard tomcat server this way, which is certainly not necessary to adding the feature. So, to me the only problems are actually writing the deployer and making sure it at least sort of works. To me, anything that has been changed needs to be tested somehow :) Regarding writing the deployer, I assume you meant the ability for G to deploy tomcat ready web archives. I think this can involve a large number of work, basically, we have to be able to generate geronimo-web.xml for the user's web archives, and deploy the web archive using the generated geronimo-web.xml file. Lin
Re: Possible for G to directly consume a Tomcat server config w/o changes?
I guess that what David means is that writing a deployer for server.xml, then in the builder class, construct those tomcat server gbeans, and add those gbeans to the tomcat plugin section in the config.xml. So that we could imitate a totally same tomcat environment for those tomcat-ready applications. Right ? Ivan 2009/5/20 Lin Sun linsun@gmail.com One example that we did this is with the config-substitution property file where we allow users to specify configuration and the server reads the config-substitution property file during the startup of the server. If we more or less freeze the configuration, wouldn't this (reading data from server.xml and build the tomcat plugin) have to be done at the build time when we build the geronimo plugin for tomcat using maven2?I think the user would want to do this at runtime where the geronimo server is already prebuilt. On Wed, May 20, 2009 at 3:16 AM, David Jencks david_jen...@yahoo.com wrote: I'm not sure about this idea. It seems really contrary to how most of geronimo works where we take some kind of plan and more or less freeze the configuration while pre-deploying it into a pretty much immutable plugin. I'm not convinced that accepting a new kind of plan for a few gbeans requires adding this continual redeploy functionality to geronimo. 3. During G startup, G can just build the embedded tomcat server by reading data from config.xml, like what it is doing today. config.xml doesn't have to contain any info on the tomcat server except that it ought to be started, i.e. listing the plugin. The gbean configurations are all serialized in the plugin. I'd generally prefer it if we dropped the ability to add gbeans to a plugin via config.xml. Again, this may be something that I don't understand well. If we don't configure it in config.xml, how do we allow users to drop in their tomcat server.xml without rebuilding the tomcat plugin? AFAIK, server.xml doesn't contain any app info. I agree that this is a very big change and requires a lot of testing to make sure things are not regressed. Adding this new namespace driven builder is entirely new functionality so there is not really any chance of regressions unless we decide to deploy the standard tomcat server this way, which is certainly not necessary to adding the feature. So, to me the only problems are actually writing the deployer and making sure it at least sort of works. To me, anything that has been changed needs to be tested somehow :) Regarding writing the deployer, I assume you meant the ability for G to deploy tomcat ready web archives. I think this can involve a large number of work, basically, we have to be able to generate geronimo-web.xml for the user's web archives, and deploy the web archive using the generated geronimo-web.xml file. Lin -- Ivan
[jira] Commented: (GERONIMO-4633) extra semicolon in code.
[ https://issues.apache.org/jira/browse/GERONIMO-4633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12711174#action_12711174 ] Ivan commented on GERONIMO-4633: commit the changes to revision: 776717, thanks Shawn for the patch ! extra semicolon in code. Key: GERONIMO-4633 URL: https://issues.apache.org/jira/browse/GERONIMO-4633 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.2 Environment: xp + sun jdk 1.5 Reporter: Shawn Jiang Priority: Trivial Fix For: 2.2 Attachments: extra_semicolon.patch, extra_semicolon_more.patch extra semicolon in code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Thinking about a 2.2 release
+1 on both Jetty 7 as default and 2.2 branch creation. -Jack 2009/5/20 David Jencks david_jen...@yahoo.com I've moved the jetty7 integration from my sandbox into trunk. It's always built but not used by default. To use jetty7 rather than jetty6 run maven with -Djetty=jetty7 or change the commenting in the root pom to !--jettyjetty6/jetty-- jettyjetty7/jetty The Jaspic implementation seems to be working pretty well with the tck. At this point I'd like to branch 2.2 off and integration the classloading stuff I did in my framework sandbox. I don't really anticipate any more large-scale changes to 2.2, just fixes for various issues such as the mdb problems. Alternatively I could create a branch of all of geronimo to play more with classloading. However I'd rather this stuff was in the bright light of trunk development. I'd also like to switch to using jetty7 by default. Comments? thanks david jencks On Apr 21, 2009, at 11:50 PM, David Jencks wrote: On Apr 15, 2009, at 10:42 PM, David Jencks wrote: On Apr 15, 2009, at 10:33 PM, Jack Cai wrote: I agree that a 2.2 release would be nice to do to push out things already in trunk, before our users wait for too long. :-) I'm reviewing the list of planned features [1] and current status [2] of 2.2. The latter [2] is more up-to-date. It would be good to make clear the areas that need some more work, so that people like me can jump in and help. Currently the major development items I see - 1. TCK, need a committer to do the job 2. MDB problems mentioned above 3. JMS portlets update mentioned above 4. Farm/cluster management (do we still want this in 2.2?) What's the problem with (4)? I've been assuming that the classloader work Gianny and I have been working on in my sandbox would get into 2.2. At the moment I think I have the classloader framework more or less working and I'm going through the plugins working on setting up the required jar dependencies. Only some of them can be derived from maven dependencies. This is turning out to be a somewhat slow process. I finally got the server to run with the one-classloader-per-jar setup. After struggling with this for a couple of weeks and seeing the difficultly of correctly configuring classloaders I don't think we should put this into 2.2. For one thing classloading seems to be pretty slow: it takes about 55 seconds to start the jetty-jee5 server. At the moment I think a reasonable strategy would be to: 1. branch 2.2 off of trunk now 2. merge in the classloader work from my sandbox framework and local copy 3. upgrade trunk version to 3.0-SNAPSHOT 4. work on using osgi classloading instead of our homegrown solution. For 2.2 it would be nice to get jaspi officially OK and in. We finally got the tck from sun. I haven't looked at it yet to try to figure out how hard it will be to adapt to our tck setup or to run. If we can get it in we can probably also get the jetty 7 integration in. Doing this before (1) might be a good idea. thanks david jencks thanks david jencks And of course there are also testing and doc work. Please complement and elaborate if necessary. [1] http://cwiki.apache.org/GMOxPMGT/geronimo-22-release-roadmap.html [2] http://cwiki.apache.org/GMOxPMGT/geronimo-22-release-status.html - Jack 2009/4/16 Kevan Miller kevan.mil...@gmail.com On Apr 15, 2009, at 11:29 AM, David Jencks wrote: On Apr 15, 2009, at 8:23 AM, Donald Woods wrote: Should we try reverting trunk (2.2) to use the same levels of OpenEJB and Axis as in the recent 2.1.4 release, to see how close we would be to a release that passes the TCK? That way, ActiveMQ 5.3-SNAPSHOT would be the major difference left to resolve for a 2.2 release I think it would be more worthwhile to look into what is going wrong with the mdbs. David Blevins doesn't think any mdb-related openejb code changed and ActiveMQ broke at least one other thing since the last time mdbs worked well. I agree. FYI, I tried to get TCK fired up, but am having some issues. David, have your run tck recently? Let's discuss on tck mailing list... What's the status of JMS resources and the Admin Console? Seem to recall some missing function... --kevan
Re: [blueprint] itests failing with NoClassDefFoundError
On May 19, 2009, at 5:22 PM, David Blevins wrote: Would love to know what the magic settings.xml data is and if there's some way to get it into the root pom.xml. Still need the right settings. I'm fine picking through your settings.xml (minus passwords) if you're unsure what the magic settings are. -David
Re: [blueprint] itests failing with NoClassDefFoundError
Is your pom in ~/.m2/repository without any other location defined in ~/.m2/settings.xml ? 2009/5/20 David Blevins david.blev...@visi.com: On May 19, 2009, at 5:22 PM, David Blevins wrote: Would love to know what the magic settings.xml data is and if there's some way to get it into the root pom.xml. Still need the right settings. I'm fine picking through your settings.xml (minus passwords) if you're unsure what the magic settings are. -David -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [blueprint] itests failing with NoClassDefFoundError
Is your m2 repository in ~/.m2/repository without any other location defined in ~/.m2/settings.xml ? It seems pax-exam is broken and only support the local repository in the default location. If you do that, it should build just fine. 2009/5/20 David Blevins david.blev...@visi.com: On May 19, 2009, at 5:22 PM, David Blevins wrote: Would love to know what the magic settings.xml data is and if there's some way to get it into the root pom.xml. Still need the right settings. I'm fine picking through your settings.xml (minus passwords) if you're unsure what the magic settings are. -David -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Closed: (GERONIMO-4639) NPE in MultiPoolConnectionInterceptor
[ https://issues.apache.org/jira/browse/GERONIMO-4639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-4639. -- Resolution: Fixed This is a component -- versions do not match in jira. rev 776751 in trunk and 2.1 Replaced equals method with what idea generates -- more if statements and less run on. NPE in MultiPoolConnectionInterceptor - Key: GERONIMO-4639 URL: https://issues.apache.org/jira/browse/GERONIMO-4639 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: connector Reporter: David Jencks Assignee: David Jencks Bert Nor reports an NPE in MultiPoolConnectionInterceptor line 193 in an equals method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Possible for G to directly consume a Tomcat server config w/o changes?
On May 20, 2009, at 7:44 AM, Ivan wrote: I guess that what David means is that writing a deployer for server.xml, then in the builder class, construct those tomcat server gbeans, and add those gbeans to the tomcat plugin section in the config.xml. So that we could imitate a totally same tomcat environment for those tomcat-ready applications. Not exactly. Right now we supply one preconfigured tomcat server in the tomcat plugin. You can deploy more if you want, and your app can choose which one to use with the (IIRC) web-container element in its plan. You can also use artifact-aliases to get one you deploy to replace the standard one. I'm suggesting writing a builder, maybe tomcat-server-builder, for server.xml files that produces plugins that are similar to the tomcat plugin. What happens to these plugins is a separate question. I'd assume most people would want to replace the supplied tomcat plugin with the one built out of their server.xml file but this is not an essential part of what I'm suggesting. thanks david jencks Right ? Ivan 2009/5/20 Lin Sun linsun@gmail.com One example that we did this is with the config-substitution property file where we allow users to specify configuration and the server reads the config-substitution property file during the startup of the server. If we more or less freeze the configuration, wouldn't this (reading data from server.xml and build the tomcat plugin) have to be done at the build time when we build the geronimo plugin for tomcat using maven2?I think the user would want to do this at runtime where the geronimo server is already prebuilt. On Wed, May 20, 2009 at 3:16 AM, David Jencks david_jen...@yahoo.com wrote: I'm not sure about this idea. It seems really contrary to how most of geronimo works where we take some kind of plan and more or less freeze the configuration while pre-deploying it into a pretty much immutable plugin. I'm not convinced that accepting a new kind of plan for a few gbeans requires adding this continual redeploy functionality to geronimo. 3. During G startup, G can just build the embedded tomcat server by reading data from config.xml, like what it is doing today. config.xml doesn't have to contain any info on the tomcat server except that it ought to be started, i.e. listing the plugin. The gbean configurations are all serialized in the plugin. I'd generally prefer it if we dropped the ability to add gbeans to a plugin via config.xml. Again, this may be something that I don't understand well. If we don't configure it in config.xml, how do we allow users to drop in their tomcat server.xml without rebuilding the tomcat plugin? AFAIK, server.xml doesn't contain any app info. I agree that this is a very big change and requires a lot of testing to make sure things are not regressed. Adding this new namespace driven builder is entirely new functionality so there is not really any chance of regressions unless we decide to deploy the standard tomcat server this way, which is certainly not necessary to adding the feature. So, to me the only problems are actually writing the deployer and making sure it at least sort of works. To me, anything that has been changed needs to be tested somehow :) Regarding writing the deployer, I assume you meant the ability for G to deploy tomcat ready web archives. I think this can involve a large number of work, basically, we have to be able to generate geronimo-web.xml for the user's web archives, and deploy the web archive using the generated geronimo-web.xml file. Lin -- Ivan
Re: [jira] Commented: (XBEAN-109) org.apache.xbean.classloader.JarFileClassLoader can not handle pathnames with containing spaces
On May 20, 2009, at 7:18 AM, Ivan (JIRA) wrote: [ https://issues.apache.org/jira/browse/XBEAN-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12711154 #action_12711154 ] Ivan commented on XBEAN-109: Hi, just find that for XBean JIRAs, there is no resolve action. So for these JIRAs, shall I need to start a RTC view, then commit the patch files ? no, just close the issue. If you can figure out how to get the workflow to be the same as in geronimo, even better. thanks david jencks org.apache.xbean.classloader.JarFileClassLoader can not handle pathnames with containing spaces Key: XBEAN-109 URL: https://issues.apache.org/jira/browse/XBEAN-109 Project: XBean Issue Type: Bug Components: classloader Environment: jdk1.6, Windows 2000 Latest version from SVN Reporter: Ingo Bormann Assignee: Ivan Attachments: xbean.diff A lot of classes in the package org.apache.xbean.classloader use File.toURL() instead of File.toURI().toURL(). File.toURL() is deprecated and does not work on windows with pathnames containing spaces. If a pathname contains spaces then File.toURL() does not convert spaces correctly. Javadoc recommends to use File.toURI().toURL() instead. I have a patched version where this is fixed for the full package org.apache.xbean.classloader. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Thinking about a 2.2 release
Both ideas sound okay to me, as I would also like to start looking at pulling OpenJPA 2 into trunk for EE 6... Only suggestion, would be to start a new discussion thread with a clear subject of something like Branching 2.2 in xx days to catch everyone's attention. -Donald David Jencks wrote: I've moved the jetty7 integration from my sandbox into trunk. It's always built but not used by default. To use jetty7 rather than jetty6 run maven with -Djetty=jetty7 or change the commenting in the root pom to !--jettyjetty6/jetty-- jettyjetty7/jetty The Jaspic implementation seems to be working pretty well with the tck. At this point I'd like to branch 2.2 off and integration the classloading stuff I did in my framework sandbox. I don't really anticipate any more large-scale changes to 2.2, just fixes for various issues such as the mdb problems. Alternatively I could create a branch of all of geronimo to play more with classloading. However I'd rather this stuff was in the bright light of trunk development. I'd also like to switch to using jetty7 by default. Comments? thanks david jencks On Apr 21, 2009, at 11:50 PM, David Jencks wrote: On Apr 15, 2009, at 10:42 PM, David Jencks wrote: On Apr 15, 2009, at 10:33 PM, Jack Cai wrote: I agree that a 2.2 release would be nice to do to push out things already in trunk, before our users wait for too long. :-) I'm reviewing the list of planned features [1] and current status [2] of 2.2. The latter [2] is more up-to-date. It would be good to make clear the areas that need some more work, so that people like me can jump in and help. Currently the major development items I see - 1. TCK, need a committer to do the job 2. MDB problems mentioned above 3. JMS portlets update mentioned above 4. Farm/cluster management (do we still want this in 2.2?) What's the problem with (4)? I've been assuming that the classloader work Gianny and I have been working on in my sandbox would get into 2.2. At the moment I think I have the classloader framework more or less working and I'm going through the plugins working on setting up the required jar dependencies. Only some of them can be derived from maven dependencies. This is turning out to be a somewhat slow process. I finally got the server to run with the one-classloader-per-jar setup. After struggling with this for a couple of weeks and seeing the difficultly of correctly configuring classloaders I don't think we should put this into 2.2. For one thing classloading seems to be pretty slow: it takes about 55 seconds to start the jetty-jee5 server. At the moment I think a reasonable strategy would be to: 1. branch 2.2 off of trunk now 2. merge in the classloader work from my sandbox framework and local copy 3. upgrade trunk version to 3.0-SNAPSHOT 4. work on using osgi classloading instead of our homegrown solution. For 2.2 it would be nice to get jaspi officially OK and in. We finally got the tck from sun. I haven't looked at it yet to try to figure out how hard it will be to adapt to our tck setup or to run. If we can get it in we can probably also get the jetty 7 integration in. Doing this before (1) might be a good idea. thanks david jencks thanks david jencks And of course there are also testing and doc work. Please complement and elaborate if necessary. [1] http://cwiki.apache.org/GMOxPMGT/geronimo-22-release-roadmap.html [2] http://cwiki.apache.org/GMOxPMGT/geronimo-22-release-status.html - Jack 2009/4/16 Kevan Miller kevan.mil...@gmail.com mailto:kevan.mil...@gmail.com On Apr 15, 2009, at 11:29 AM, David Jencks wrote: On Apr 15, 2009, at 8:23 AM, Donald Woods wrote: Should we try reverting trunk (2.2) to use the same levels of OpenEJB and Axis as in the recent 2.1.4 release, to see how close we would be to a release that passes the TCK? That way, ActiveMQ 5.3-SNAPSHOT would be the major difference left to resolve for a 2.2 release I think it would be more worthwhile to look into what is going wrong with the mdbs. David Blevins doesn't think any mdb-related openejb code changed and ActiveMQ broke at least one other thing since the last time mdbs worked well. I agree. FYI, I tried to get TCK fired up, but am having some issues. David, have your run tck recently? Let's discuss on tck mailing list... What's the status of JMS resources and the Admin Console? Seem to recall some missing function... --kevan
Re: Possible for G to directly consume a Tomcat server config w/o changes?
Agree that we won't contain this in G 2.2, but it might be a candidate feature for futher release like JEE6 Web Profile. Importing Tomcat server configs is relatively easier than importing Tomcat applications. If we consider an application which uses Struts, Hibernate, Spring, AXIS2 etc. (which is quite common), things becomes much complex. Still, doable, but not a trivial work. -Jack 2009/5/20 Ivan xhh...@gmail.com I guess that what David means is that writing a deployer for server.xml, then in the builder class, construct those tomcat server gbeans, and add those gbeans to the tomcat plugin section in the config.xml. So that we could imitate a totally same tomcat environment for those tomcat-ready applications. Right ? Ivan 2009/5/20 Lin Sun linsun@gmail.com One example that we did this is with the config-substitution property file where we allow users to specify configuration and the server reads the config-substitution property file during the startup of the server. If we more or less freeze the configuration, wouldn't this (reading data from server.xml and build the tomcat plugin) have to be done at the build time when we build the geronimo plugin for tomcat using maven2?I think the user would want to do this at runtime where the geronimo server is already prebuilt. On Wed, May 20, 2009 at 3:16 AM, David Jencks david_jen...@yahoo.com wrote: I'm not sure about this idea. It seems really contrary to how most of geronimo works where we take some kind of plan and more or less freeze the configuration while pre-deploying it into a pretty much immutable plugin. I'm not convinced that accepting a new kind of plan for a few gbeans requires adding this continual redeploy functionality to geronimo. 3. During G startup, G can just build the embedded tomcat server by reading data from config.xml, like what it is doing today. config.xml doesn't have to contain any info on the tomcat server except that it ought to be started, i.e. listing the plugin. The gbean configurations are all serialized in the plugin. I'd generally prefer it if we dropped the ability to add gbeans to a plugin via config.xml. Again, this may be something that I don't understand well. If we don't configure it in config.xml, how do we allow users to drop in their tomcat server.xml without rebuilding the tomcat plugin? AFAIK, server.xml doesn't contain any app info. I agree that this is a very big change and requires a lot of testing to make sure things are not regressed. Adding this new namespace driven builder is entirely new functionality so there is not really any chance of regressions unless we decide to deploy the standard tomcat server this way, which is certainly not necessary to adding the feature. So, to me the only problems are actually writing the deployer and making sure it at least sort of works. To me, anything that has been changed needs to be tested somehow :) Regarding writing the deployer, I assume you meant the ability for G to deploy tomcat ready web archives. I think this can involve a large number of work, basically, we have to be able to generate geronimo-web.xml for the user's web archives, and deploy the web archive using the generated geronimo-web.xml file. Lin -- Ivan
[jira] Created: (GERONIMO-4639) NPE in MultiPoolConnectionInterceptor
NPE in MultiPoolConnectionInterceptor - Key: GERONIMO-4639 URL: https://issues.apache.org/jira/browse/GERONIMO-4639 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: connector Reporter: David Jencks Assignee: David Jencks Bert Nor reports an NPE in MultiPoolConnectionInterceptor line 193 in an equals method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4553) Admin console does not show error when creating duplicate security realm
[ https://issues.apache.org/jira/browse/GERONIMO-4553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12711206#action_12711206 ] Ashish Jain commented on GERONIMO-4553: --- This error can be avoided if the duplicate realm is not started. However there are some issues involved 1) We need to copy the realm and deploy it manually using Deploy New or may be the command line tool 2) An entry for the newly created realm is not reflected in config.xml if the realm is only deployed and not started. I guess this can be addressed in a JIRA if we feel it is an issues. I think the realm entry should come up in config.xml with load=false. User will have to perform few manual steps 1) He will have to edit the config.xml and add load=false for geronimo-admin gbean in server-security-config 2) Remove load=false for the duplicate realm. 3) edit artifact-aliases.properties. The utility is that user can always revert back the configuration in case there are any issues with the duplicate realm. All the above steps can be suggested to the user when he inputs the name of the realm and moves to the next section. Please suggest if this is how we may want to address this situation Admin console does not show error when creating duplicate security realm Key: GERONIMO-4553 URL: https://issues.apache.org/jira/browse/GERONIMO-4553 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, security Affects Versions: 2.1.4, 2.2 Reporter: David Jencks Fix For: 2.1.5, 2.2 If you create a security realm with a duplicate name (such as geronimo-admin) using the admin console, everything appears to work in the ui however the command line console shows the error: 2009-02-24 09:47:11,123 ERROR [ProxyCollection] Listener threw exception java.lang.IllegalArgumentException: ConfigurationEntry named: geronimo-admin already registered at org.apache.geronimo.security.jaas.GeronimoLoginConfiguration.addConfiguration(GeronimoLoginConfiguration.java:112) at org.apache.geronimo.security.jaas.GeronimoLoginConfiguration.memberAdded(GeronimoLoginConfiguration.java:97) at org.apache.geronimo.gbean.runtime.ProxyCollection.addTarget(ProxyCollection.java:102) at org.apache.geronimo.gbean.runtime.GBeanCollectionReference.targetAdded(GBeanCollectionReference.java:96) at org.apache.geronimo.gbean.runtime.GBeanCollectionReference.addTarget(GBeanCollectionReference.java:180) at org.apache.geronimo.gbean.runtime.GBeanCollectionReference$1.running(GBeanCollectionReference.java:110) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:175) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:253) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:295) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:103) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:524) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:110) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:145) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:119) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:175) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:253) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:295) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:103) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:524) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:110) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:145) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:119) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:175) at
Re: International characters trouble with a servlet-based webservice
Which side is sending the wrong coded characters? Client, or the web service? BTW, please move this kind of questions in the geronimo user mailing list. -Jack 2009/5/20 andyhan a.luben...@gmx.de I use a servlet-based webservice deployed into geronimo 2.1.4. The service client runs is Axis2.1.4. The problem is: Umlauts (characters like ä, ü, ö) are coming wrong coded at the Websevice. Incoming messages at the webservice side are in ContentType text/xml; charset=UTF-8. Is there a solutions for this trouble? -- View this message in context: http://www.nabble.com/International-characters-trouble-with-a-servlet-based-webservice-tp23630408s134p23630408.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: [blueprint] itests failing with NoClassDefFoundError
On May 20, 2009, at 11:20 AM, Guillaume Nodet wrote: Is your m2 repository in ~/.m2/repository without any other location defined in ~/.m2/settings.xml ? It seems pax-exam is broken and only support the local repository in the default location. If you do that, it should build just fine. Ok, understood this sentence, Do you use the default m2 repository ? That may be the problem to imply using the default repo was the problem. Which lead me to still wonder what was the right approach. Not sure what bad state I had in ~/.m2/repository that caused things to fail when I tried with all default settings but trying with a clean repo at ~/.m2/repository vs. -Dmaven.repo.local=tmprepo finally works. -David 2009/5/20 David Blevins david.blev...@visi.com: On May 19, 2009, at 5:22 PM, David Blevins wrote: Would love to know what the magic settings.xml data is and if there's some way to get it into the root pom.xml. Still need the right settings. I'm fine picking through your settings.xml (minus passwords) if you're unsure what the magic settings are. -David -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [blueprint] itests failing with NoClassDefFoundError
I've fixed the issue, though your script does not work. The following one seems to work ok: #!/bin/bash TMP=/tmp/$USER-$RANDOM mkdir $TMP cd $TMP svn -q co http://svn.apache.org/repos/asf/geronimo/sandbox/blueprint cd blueprint mvn -v mvn --settings /dev/null clean install -Dmaven.repo.local=$TMP/repo 2009/5/20 David Blevins david.blev...@visi.com: On May 20, 2009, at 11:20 AM, Guillaume Nodet wrote: Is your m2 repository in ~/.m2/repository without any other location defined in ~/.m2/settings.xml ? It seems pax-exam is broken and only support the local repository in the default location. If you do that, it should build just fine. Ok, understood this sentence, Do you use the default m2 repository ? That may be the problem to imply using the default repo was the problem. Which lead me to still wonder what was the right approach. Not sure what bad state I had in ~/.m2/repository that caused things to fail when I tried with all default settings but trying with a clean repo at ~/.m2/repository vs. -Dmaven.repo.local=tmprepo finally works. -David 2009/5/20 David Blevins david.blev...@visi.com: On May 19, 2009, at 5:22 PM, David Blevins wrote: Would love to know what the magic settings.xml data is and if there's some way to get it into the root pom.xml. Still need the right settings. I'm fine picking through your settings.xml (minus passwords) if you're unsure what the magic settings are. -David -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Commented: (GERONIMO-4637) Need documents on how to replace default file realm in Geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-4637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12711400#action_12711400 ] David Jencks commented on GERONIMO-4637: There are some very basic comments here: http://cwiki.apache.org/GMOxDOC22/basic-hints-on-security-configuration.html I actually went through the process of doing this for IIRC one of my apachecon eu 2009 talks. There might be some details in the slides. Need documents on how to replace default file realm in Geronimo --- Key: GERONIMO-4637 URL: https://issues.apache.org/jira/browse/GERONIMO-4637 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: documentation Affects Versions: 2.2 Reporter: Chi Runhua Priority: Minor The default security realm is of properties files in Geronimo. While Geronimo supports another 2 types of security realm such as SQL and LDAP. It would be nice if we have tutorials on how to replace the default one with SQL or LDAP realms. Jeff C -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4636) Database Pools portlet needs update to import from the latest Jboss and Weblogic server
[ https://issues.apache.org/jira/browse/GERONIMO-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12711455#action_12711455 ] Rex Wang commented on GERONIMO-4636: It is strange that I tried it both on 2.1.5-snapshot and 2.2-snapshot build, these links on both builds become invalid with the following errors: HTTP Status 400 - XSSXSRFFilter blocked HttpServletRequest due to invalid URI content. type Status report message XSSXSRFFilter blocked HttpServletRequest due to invalid URI content. description The request sent by the client was syntactically incorrect (XSSXSRFFilter blocked HttpServletRequest due to invalid URI content.). does the two links still work for you? -Rex Database Pools portlet needs update to import from the latest Jboss and Weblogic server --- Key: GERONIMO-4636 URL: https://issues.apache.org/jira/browse/GERONIMO-4636 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1.5, 2.2 Environment: None Reporter: Chi Runhua The latest Jboss AS server is v5.1.0 and Weblogic server is v10.3. But the wizards on the portlet are still for Jboss 4 and Weblogic 8.1, would it be nice to update the portlet? Jeff C -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4503) PlanCreator threw exception with .war
[ https://issues.apache.org/jira/browse/GERONIMO-4503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang updated GERONIMO-4503: --- Attachment: GERONIMO-4503-updated.patch The updated patch contains the fixes with Jetty, which forgot in the former one. Please use this, thanks. -Rex PlanCreator threw exception with .war - Key: GERONIMO-4503 URL: https://issues.apache.org/jira/browse/GERONIMO-4503 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: PlanCreator Affects Versions: 2.2 Environment: WinXP+Sun Java1.6.0+ Geronimo v2.2 Build0107 Reporter: Chi Runhua Assignee: Rex Wang Priority: Blocker Fix For: 2.2 Attachments: GERONIMO-4503-updated.patch, GERONIMO-4503.patch, WebAppJDBCAccess.war A simple WebAppJDBCAccess.war without a geronimo deployment plan, so I tried to create one using wizard from v2.2 , but failed with HTTP 500 error. Exception throwed from command line as followed: Note: Tried the same .war on Geronimo v2.1.3+Java1.6, everything works fine. ++ 2009-01-09 15:14:22,000 ERROR [[PlanCreator]] Servlet.service() for servlet PlanCreator threw exception java.lang.ClassNotFoundException: org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager in classloader org.apache.geronimo.plugins/plancreator-console-tomcat/2.2-SNAPSHOT/car at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadOptimizedClass(MultiParentClassLoader.java:413) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:255) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClassInternal(Unknown Source) at org.apache.geronimo.console.configcreator.JSR88_Util.createApplicationInfo(JSR88_Util.java:71) at org.apache.geronimo.console.configcreator.GetArchiveHandler.actionAfterView(GetArchiveHandler.java:70) at org.apache.geronimo.console.MultiPagePortlet.processAction(MultiPagePortlet.java:114) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:145) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:535) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:472) at org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167) at org.apache.pluto.core.DefaultPortletInvokerService.action(DefaultPortletInvokerService.java:85) at org.apache.pluto.core.PortletContainerImpl.doAction(PortletContainerImpl.java:219) at org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:121) at org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:167) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:406) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568) at
[jira] Resolved: (GERONIMO-3599) Unable to create new JMS Resource group through console in IE7
[ https://issues.apache.org/jira/browse/GERONIMO-3599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan resolved GERONIMO-3599. Resolution: Fixed Commit changes to trunk at revision: 776955, 2.1.5 snapshot at revision: 776959 I ommit the changes of changing the cache size, for it is only needed while the session timeout and the long url occurs at the same time, it maybe very rarely, and I am not sure whether it would broke other components. Unable to create new JMS Resource group through console in IE7 -- Key: GERONIMO-3599 URL: https://issues.apache.org/jira/browse/GERONIMO-3599 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.0.1, 2.1.4 Environment: WIN XP Reporter: Anish Pathadan Assignee: Ivan Fix For: 2.2 Attachments: GERONIMO-3599-better.patch, GERONIMO-3599.patch I am not able to create a new JMS Resouce group through console. I am getting cannot display the page error after entering the Q name and physical name and then pressing next. The following is the url http://localhost:8080/console/portal/services/services_jms/_ps_services_jms_row1_col1_p1/normal/_pm_services_jms_row1_col1_p1/view/_ac_services_jms_row1_col1_p1/AC/_st_services_jms_row1_col1_p1/normal/_md_services_jms_row1_col1_p1/view/_pid/services_jms_row1_col1_p1 The problem only comes with Internet Explorer 7. Best Regards, Anish Pathadan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (XBEAN-109) org.apache.xbean.classloader.JarFileClassLoader can not handle pathnames with containing spaces
[ https://issues.apache.org/jira/browse/XBEAN-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan reassigned XBEAN-109: -- Assignee: Ivan org.apache.xbean.classloader.JarFileClassLoader can not handle pathnames with containing spaces Key: XBEAN-109 URL: https://issues.apache.org/jira/browse/XBEAN-109 Project: XBean Issue Type: Bug Components: classloader Environment: jdk1.6, Windows 2000 Latest version from SVN Reporter: Ingo Bormann Assignee: Ivan Attachments: xbean.diff A lot of classes in the package org.apache.xbean.classloader use File.toURL() instead of File.toURI().toURL(). File.toURL() is deprecated and does not work on windows with pathnames containing spaces. If a pathname contains spaces then File.toURL() does not convert spaces correctly. Javadoc recommends to use File.toURI().toURL() instead. I have a patched version where this is fixed for the full package org.apache.xbean.classloader. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (XBEAN-109) org.apache.xbean.classloader.JarFileClassLoader can not handle pathnames with containing spaces
[ https://issues.apache.org/jira/browse/XBEAN-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12711152#action_12711152 ] Ivan commented on XBEAN-109: Merge the patch to XBean trunk at rev 776705. Thanks Ingo Bormann for the patch ! org.apache.xbean.classloader.JarFileClassLoader can not handle pathnames with containing spaces Key: XBEAN-109 URL: https://issues.apache.org/jira/browse/XBEAN-109 Project: XBean Issue Type: Bug Components: classloader Environment: jdk1.6, Windows 2000 Latest version from SVN Reporter: Ingo Bormann Assignee: Ivan Attachments: xbean.diff A lot of classes in the package org.apache.xbean.classloader use File.toURL() instead of File.toURI().toURL(). File.toURL() is deprecated and does not work on windows with pathnames containing spaces. If a pathname contains spaces then File.toURL() does not convert spaces correctly. Javadoc recommends to use File.toURI().toURL() instead. I have a patched version where this is fixed for the full package org.apache.xbean.classloader. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (XBEAN-109) org.apache.xbean.classloader.JarFileClassLoader can not handle pathnames with containing spaces
[ https://issues.apache.org/jira/browse/XBEAN-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12711154#action_12711154 ] Ivan commented on XBEAN-109: Hi, just find that for XBean JIRAs, there is no resolve action. So for these JIRAs, shall I need to start a RTC view, then commit the patch files ? org.apache.xbean.classloader.JarFileClassLoader can not handle pathnames with containing spaces Key: XBEAN-109 URL: https://issues.apache.org/jira/browse/XBEAN-109 Project: XBean Issue Type: Bug Components: classloader Environment: jdk1.6, Windows 2000 Latest version from SVN Reporter: Ingo Bormann Assignee: Ivan Attachments: xbean.diff A lot of classes in the package org.apache.xbean.classloader use File.toURL() instead of File.toURI().toURL(). File.toURL() is deprecated and does not work on windows with pathnames containing spaces. If a pathname contains spaces then File.toURL() does not convert spaces correctly. Javadoc recommends to use File.toURI().toURL() instead. I have a patched version where this is fixed for the full package org.apache.xbean.classloader. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
