[jira] Closed: (GERONIMO-2944) Replace ancient ActiveIO usage in geronimo-security module
[
https://issues.apache.org/jira/browse/GERONIMO-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevan Miller closed GERONIMO-2944.
--
Resolution: Fixed
Fix Version/s: 2.0
Removed activeio and concurrent + plus a bit of additional cleanup.
Replace ancient ActiveIO usage in geronimo-security module
--
Key: GERONIMO-2944
URL: https://issues.apache.org/jira/browse/GERONIMO-2944
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: security
Affects Versions: 1.2, 2.0-M5
Reporter: Jason Dillon
Assignee: Kevan Miller
Fix For: 2.0
The {{geronimo-security}} module uses an ancient version of ActiveIO,
{{2.0-r118}}, which contains APIs which are no longer included in newer
versions of ActiveIO.
This code should be re-written to either remove the dependence on ActiveIO or
to use new ActiveIO API's so that the server does not need to include
{{activeio:activeio:2.0-r118}} and {{concurrent:concurrent:1.3.4}} (which is
a dependency of this version of ActiveIO.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: 3.1 Release?
+1 i think Dain already proposed that and there was on objections... 2007/7/27, David Blevins [EMAIL PROTECTED]: What do you guys think of doing a 3.1 release? Need non-snapshot versions of at least xbean-reflect and xbean-finder for OpenEJB/ Geronimo coming up real soon. -David -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/
[jira] Created: (GERONIMO-3359) naming builders are invoked twice
naming builders are invoked twice - Key: GERONIMO-3359 URL: https://issues.apache.org/jira/browse/GERONIMO-3359 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0 Reporter: Jarek Gawor I have a simple web.xml with one service-ref entry. However, I'm seeing that the code that creates the service ref is called twice with the same information. From the configuration and the code it looks like MyFacesModuleBuilderExtension.addGBeans() and JspModuleBuilderExtension.addGBeans() methods call namingBuilders.buildNaming(webApp, jettyWebApp, webModule, buildingContext);. But for web applications, AbstractWebModuleBuilder.configureBasicWebModuleAttributes() already does that. Not sure if this is by design or a mistake. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: KEYS ?
+1 Jason Dillon wrote: Should keys move up to a peer to the STATUS file too? Seems these are project global, not specific to the server bits... --jason smime.p7s Description: S/MIME Cryptographic Signature
Re: Tomcat connectors
Filip Hanik - Dev Lists wrote: so there is no need to dabble with the auto select, personally I don't think its very usable feature, since the APR SSL connector has different attributes than the Java SSL connector and the auto select wouldn't work in that scenario anyway. Great to hear...Ill add that connector in then ;-) Jeff
Re: [DISCUSS] Adding a Tech Preview portlet group in Admin Console in G 2.0
Sounds good! A tech preview with all these new goodies would be great, it will definitively drag users' attention, and if we hook them to their own wiki pages it would be even greater. Depending on the number of portlets we have (or may have) we may actually want to create a separate Tech Preview space in Confluence. Do we have a rough idea how many would fall into this bag? Cheers! Hernan Prasad Kashyap wrote: I kinda like the idea. Each such portlet should have a link to it's own wiki page which will allow user feedback. I wonder if we can even take it one further, by having a wiki page for some of our existing heavy-weight portlets (eg. wizards). The user can blog their feedbacks which do not necessarily fall under the scope of a JIRA. The wiki can be made to send comments to the dev-list automatically. Currently we do not have a closed loop for our users to provide feedbacks. Feedbacks provided on the lists are usually lost. This will improve the usability of our console. Cheers Prasad On 7/26/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: How about adding a Tech Preview portlet group in Admin Console in G 2.0 where we can include the portlets (for e.g., the Create Plan portlet Shiva is working on. See https://issues.apache.org/jira/browse/GERONIMO-3254) for which user feedback will play a great role in improving those further. Once we decide on whether to retain those or not, we can either move them out to a different group or remove them from Admin Console accordingly. Vamsi
[jira] Closed: (GERONIMODEVTOOLS-178) Deadlock! while stopping Geronimo server from within Eclipse
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods closed GERONIMODEVTOOLS-178. - Resolution: Fixed Fix Version/s: 2.0 Committed revision 560256. Thanks for the patch. Deadlock! while stopping Geronimo server from within Eclipse Key: GERONIMODEVTOOLS-178 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-178 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 1.2.0, 1.2.1, 2.0 Reporter: Shiva Kumar H R Assignee: Donald Woods Fix For: 2.0 Attachments: deadlockFix.patch, TestDeadlock.war An interesting deadlock scenario! Here are the steps to reproduce: 1. From within Eclipse start Geronimo server (say 2.0) 2. Deploy attached WAR 3. Access deployed servlet with url http://localhost:8080/TestDeadlock/Test; 4. From within Eclipse invoke Stop server You will see that Stop never returns and Eclipse freezes to respond. 5. Manually kill server process and Eclipse will resume. Here is what is happening: 1. When user invokes Stop on Geronimo server from within Eclipse, Geronimo Eclipse Plug-in invokes stopKernel() in the main Eclipse thread itself. (org.apache.geronimo.st.core.GeronimoServerBehaviourDelegate.java::stop()) 2. Server receives the shutdown call, and invokes the deployed WAR's servlet.destroy method, which in turn opens a big text file and starts printing the contents to standard output. 3. All the output buffers overflow because the main thread is the one that should push them to the console view at the end but it is blocked. 4. All the print operations on the server side are blocked waiting for somebody to read the output buffer. The shutdown call will never return. 5. The main Eclipse thread will never print the messages because it waits for the shutdown call to return. Here is one solution thought of: The Geronimo Eclipse plug-in should make the shutdown call in a worker thread not in the main Eclipse thread. In this case the main thread will be able to display all the messages triggered by the shutdown call and everything will work just fine. Attached patch implements this. Please see this also: http://www.eclipse.org/webtools/wst/api/org/eclipse/wst/server/core/model/ServerBehaviourDelegate.html#stop(boolean) It recommends that the plug-in should return from the ServerBehaviourDelegate.stop() method quickly and use the server listener to notify shutdown progress. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-178) Deadlock! while stopping Geronimo server from within Eclipse
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R updated GERONIMODEVTOOLS-178: - Attachment: deadlockFix.patch Deadlock! while stopping Geronimo server from within Eclipse Key: GERONIMODEVTOOLS-178 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-178 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 1.2.0, 1.2.1, 2.0 Reporter: Shiva Kumar H R Attachments: deadlockFix.patch, TestDeadlock.war An interesting deadlock scenario! Here are the steps to reproduce: 1. From within Eclipse start Geronimo server (say 2.0) 2. Deploy attached WAR 3. Access deployed servlet with url http://localhost:8080/TestDeadlock/Test; 4. From within Eclipse invoke Stop server You will see that Stop never returns and Eclipse freezes to respond. 5. Manually kill server process and Eclipse will resume. Here is what is happening: 1. When user invokes Stop on Geronimo server from within Eclipse, Geronimo Eclipse Plug-in invokes stopKernel() in the main Eclipse thread itself. (org.apache.geronimo.st.core.GeronimoServerBehaviourDelegate.java::stop()) 2. Server receives the shutdown call, and invokes the deployed WAR's servlet.destroy method, which in turn opens a big text file and starts printing the contents to standard output. 3. All the output buffers overflow because the main thread is the one that should push them to the console view at the end but it is blocked. 4. All the print operations on the server side are blocked waiting for somebody to read the output buffer. The shutdown call will never return. 5. The main Eclipse thread will never print the messages because it waits for the shutdown call to return. Here is one solution thought of: The Geronimo Eclipse plug-in should make the shutdown call in a worker thread not in the main Eclipse thread. In this case the main thread will be able to display all the messages triggered by the shutdown call and everything will work just fine. Attached patch implements this. Please see this also: http://www.eclipse.org/webtools/wst/api/org/eclipse/wst/server/core/model/ServerBehaviourDelegate.html#stop(boolean) It recommends that the plug-in should return from the ServerBehaviourDelegate.stop() method quickly and use the server listener to notify shutdown progress. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMODEVTOOLS-178) Deadlock! while stopping Geronimo server from within Eclipse
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned GERONIMODEVTOOLS-178: - Assignee: Donald Woods Deadlock! while stopping Geronimo server from within Eclipse Key: GERONIMODEVTOOLS-178 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-178 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 1.2.0, 1.2.1, 2.0 Reporter: Shiva Kumar H R Assignee: Donald Woods Attachments: deadlockFix.patch, TestDeadlock.war An interesting deadlock scenario! Here are the steps to reproduce: 1. From within Eclipse start Geronimo server (say 2.0) 2. Deploy attached WAR 3. Access deployed servlet with url http://localhost:8080/TestDeadlock/Test; 4. From within Eclipse invoke Stop server You will see that Stop never returns and Eclipse freezes to respond. 5. Manually kill server process and Eclipse will resume. Here is what is happening: 1. When user invokes Stop on Geronimo server from within Eclipse, Geronimo Eclipse Plug-in invokes stopKernel() in the main Eclipse thread itself. (org.apache.geronimo.st.core.GeronimoServerBehaviourDelegate.java::stop()) 2. Server receives the shutdown call, and invokes the deployed WAR's servlet.destroy method, which in turn opens a big text file and starts printing the contents to standard output. 3. All the output buffers overflow because the main thread is the one that should push them to the console view at the end but it is blocked. 4. All the print operations on the server side are blocked waiting for somebody to read the output buffer. The shutdown call will never return. 5. The main Eclipse thread will never print the messages because it waits for the shutdown call to return. Here is one solution thought of: The Geronimo Eclipse plug-in should make the shutdown call in a worker thread not in the main Eclipse thread. In this case the main thread will be able to display all the messages triggered by the shutdown call and everything will work just fine. Attached patch implements this. Please see this also: http://www.eclipse.org/webtools/wst/api/org/eclipse/wst/server/core/model/ServerBehaviourDelegate.html#stop(boolean) It recommends that the plug-in should return from the ServerBehaviourDelegate.stop() method quickly and use the server listener to notify shutdown progress. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: KEYS ?
+1 Jacek On 7/27/07, Jason Dillon [EMAIL PROTECTED] wrote: Should keys move up to a peer to the STATUS file too? Seems these are project global, not specific to the server bits... --jason -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: KEYS ?
+1 to move. Vamsi On 7/27/07, Jason Dillon [EMAIL PROTECTED] wrote: Should keys move up to a peer to the STATUS file too? Seems these are project global, not specific to the server bits... --jason
[jira] Created: (GERONIMODEVTOOLS-178) Deadlock! while stopping Geronimo server from within Eclipse
Deadlock! while stopping Geronimo server from within Eclipse Key: GERONIMODEVTOOLS-178 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-178 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 1.2.0, 1.2.1, 2.0 Reporter: Shiva Kumar H R An interesting deadlock scenario! Here are the steps to reproduce: 1. From within Eclipse start Geronimo server (say 2.0) 2. Deploy attached WAR 3. Access deployed servlet with url http://localhost:8080/TestDeadlock/Test; 4. From within Eclipse invoke Stop server You will see that Stop never returns and Eclipse freezes to respond. 5. Manually kill server process and Eclipse will resume. Here is what is happening: 1. When user invokes Stop on Geronimo server from within Eclipse, Geronimo Eclipse Plug-in invokes stopKernel() in the main Eclipse thread itself. (org.apache.geronimo.st.core.GeronimoServerBehaviourDelegate.java::stop()) 2. Server receives the shutdown call, and invokes the deployed WAR's servlet.destroy method, which in turn opens a big text file and starts printing the contents to standard output. 3. All the output buffers overflow because the main thread is the one that should push them to the console view at the end but it is blocked. 4. All the print operations on the server side are blocked waiting for somebody to read the output buffer. The shutdown call will never return. 5. The main Eclipse thread will never print the messages because it waits for the shutdown call to return. Here is one solution thought of: The Geronimo Eclipse plug-in should make the shutdown call in a worker thread not in the main Eclipse thread. In this case the main thread will be able to display all the messages triggered by the shutdown call and everything will work just fine. Attached patch implements this. Please see this also: http://www.eclipse.org/webtools/wst/api/org/eclipse/wst/server/core/model/ServerBehaviourDelegate.html#stop(boolean) It recommends that the plug-in should return from the ServerBehaviourDelegate.stop() method quickly and use the server listener to notify shutdown progress. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-178) Deadlock! while stopping Geronimo server from within Eclipse
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R updated GERONIMODEVTOOLS-178: - Attachment: TestDeadlock.war Deadlock! while stopping Geronimo server from within Eclipse Key: GERONIMODEVTOOLS-178 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-178 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 1.2.0, 1.2.1, 2.0 Reporter: Shiva Kumar H R Attachments: TestDeadlock.war An interesting deadlock scenario! Here are the steps to reproduce: 1. From within Eclipse start Geronimo server (say 2.0) 2. Deploy attached WAR 3. Access deployed servlet with url http://localhost:8080/TestDeadlock/Test; 4. From within Eclipse invoke Stop server You will see that Stop never returns and Eclipse freezes to respond. 5. Manually kill server process and Eclipse will resume. Here is what is happening: 1. When user invokes Stop on Geronimo server from within Eclipse, Geronimo Eclipse Plug-in invokes stopKernel() in the main Eclipse thread itself. (org.apache.geronimo.st.core.GeronimoServerBehaviourDelegate.java::stop()) 2. Server receives the shutdown call, and invokes the deployed WAR's servlet.destroy method, which in turn opens a big text file and starts printing the contents to standard output. 3. All the output buffers overflow because the main thread is the one that should push them to the console view at the end but it is blocked. 4. All the print operations on the server side are blocked waiting for somebody to read the output buffer. The shutdown call will never return. 5. The main Eclipse thread will never print the messages because it waits for the shutdown call to return. Here is one solution thought of: The Geronimo Eclipse plug-in should make the shutdown call in a worker thread not in the main Eclipse thread. In this case the main thread will be able to display all the messages triggered by the shutdown call and everything will work just fine. Attached patch implements this. Please see this also: http://www.eclipse.org/webtools/wst/api/org/eclipse/wst/server/core/model/ServerBehaviourDelegate.html#stop(boolean) It recommends that the plug-in should return from the ServerBehaviourDelegate.stop() method quickly and use the server listener to notify shutdown progress. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Adding a Tech Preview portlet group in Admin Console in G 2.0
I am excited ;-) with the opportunity that is opening up for my new portlet to get included in G2.0. I will see if I can wrap up auto-handling of security configuration for web-apps by Monday. - Shiva On 7/27/07, Hernan Cunico [EMAIL PROTECTED] wrote: Sounds good! A tech preview with all these new goodies would be great, it will definitively drag users' attention, and if we hook them to their own wiki pages it would be even greater. Depending on the number of portlets we have (or may have) we may actually want to create a separate Tech Preview space in Confluence. Do we have a rough idea how many would fall into this bag? Cheers! Hernan Prasad Kashyap wrote: I kinda like the idea. Each such portlet should have a link to it's own wiki page which will allow user feedback. I wonder if we can even take it one further, by having a wiki page for some of our existing heavy-weight portlets (eg. wizards). The user can blog their feedbacks which do not necessarily fall under the scope of a JIRA. The wiki can be made to send comments to the dev-list automatically. Currently we do not have a closed loop for our users to provide feedbacks. Feedbacks provided on the lists are usually lost. This will improve the usability of our console. Cheers Prasad On 7/26/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: How about adding a Tech Preview portlet group in Admin Console in G 2.0 where we can include the portlets (for e.g., the Create Plan portlet Shiva is working on. See https://issues.apache.org/jira/browse/GERONIMO-3254) for which user feedback will play a great role in improving those further. Once we decide on whether to retain those or not, we can either move them out to a different group or remove them from Admin Console accordingly. Vamsi
[jira] Assigned: (GERONIMO-2028) Plugin export errors don't stop process, but cause it to fail much later
[ https://issues.apache.org/jira/browse/GERONIMO-2028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned GERONIMO-2028: -- Assignee: Donald Woods Plugin export errors don't stop process, but cause it to fail much later Key: GERONIMO-2028 URL: https://issues.apache.org/jira/browse/GERONIMO-2028 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Plugins Affects Versions: 1.1 Reporter: Aaron Mulder Assignee: Donald Woods Fix For: 1.x, 2.0 When exporting a plugin, if there are any errors loading the existing XML document, the console goes on to the export screen and just renders it entirely empty (including the module ID). It should instead produce an error message. To reproduce, edit repository/geronimo/welcome-jetty/1.1-SNAPSHOT/welcome-jetty-1.1-SNAPSHOT.car/META-INF/geronimo-plugin.xml to make it invalid, go to the console, select the plugins screen, pick geronimo/welcome-jetty/* as the configuration to export, and click the export button. You presently get a screen with a bunch of blank text fields, and should instead get an error message / page. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-1786) JMS Listeners for protocols activeio, peer and openwire fail to start
[ https://issues.apache.org/jira/browse/GERONIMO-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned GERONIMO-1786: -- Assignee: Donald Woods JMS Listeners for protocols activeio, peer and openwire fail to start - Key: GERONIMO-1786 URL: https://issues.apache.org/jira/browse/GERONIMO-1786 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ, console Affects Versions: 1.0, 1.1, 1.1.1, 1.2 Environment: Geronimo 1.0.0 Reporter: Donald Woods Assignee: Donald Woods Fix For: 2.0 Even though addition of JMS Listeners for activeio, peer and openwire protocols is successful, the listeners fail to start with the following exceptions. activeio --- java.lang.NoSuchMethodError: org.activeio.ChannelFactory: method bindAsynchChannel(Ljava/net/URI;)Lorg/activeio/AsynchChannelServer; not found openwire --- javax.jms.JMSException: Could not load protocol: openwire. Reason: java.lang.ClassNotFoundException: org.activemq.transport.openwire.OpenWireTransportServerChannelFactory peer --- javax.jms.JMSException: Could not load protocol: peer. Reason: java.lang.ClassNotFoundException: org.activemq.transport.peer.PeerTransportServerChannelFactory Stack trace of the same. 192: 14:17:49,499 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: objectName=geronimo.server:J2EEApplication=null,J2EEModule=geronimo/activemq-broker/1.0/car,J2EEServer=geronimo,br oker=ActiveMQ,j2eeType=JMSConnector,name=ActiveMQ.activeio.0.0.0.0.12340-aio 193: java.lang.NoSuchMethodError: org.activeio.ChannelFactory: method bindAsynchChannel(Ljava/net/URI;)Lorg/activeio/AsynchChannelServer; not found 194: at org.activemq.transport.activeio.ActiveIOTransportServerChannelFactory.createAsynchChannelServer(ActiveIOTranspo rtServerChannelFactory.java:60) 195: at org.activemq.transport.activeio.ActiveIOTransportServerChannelFactory.create(ActiveIOTransportServerChannelFact ory.java:49) 196: at org.activemq.transport.TransportServerChannelProvider.create(TransportServerChannelProvider.java:45) 197: at org.activemq.broker.impl.BrokerConnectorImpl.createTransportServerChannel(BrokerConnectorImpl.java:425) 198: at org.activemq.broker.impl.BrokerConnectorImpl.init(BrokerConnectorImpl.java:69) 199: at org.activemq.gbean.ActiveMQConnectorGBean.createBrokerConnector(ActiveMQConnectorGBean.java:161) 200: at org.activemq.gbean.ActiveMQConnectorGBean.doStart(ActiveMQConnectorGBean.java:129) 201: at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java(Compiled Code)) 202: at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) 203: at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) 204: at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132) 205: at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537) 206: at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208) 207: at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java :365) 208: at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) 209: at org.activemq.gbean.ActiveMQConnector$$EnhancerByCGLIB$$2b4c85ae.startRecursive(generated) 210: at org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:79) 211: at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) 212: at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) 213: at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) 214: at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) 215: at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) 216: at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) 217: at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) 218: at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) 219: at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) 220: at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) 221: at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) 222: at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) 223: at
[jira] Assigned: (GERONIMO-3127) ERROR [DriverDownloader] Unable to download driver properties
[ https://issues.apache.org/jira/browse/GERONIMO-3127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned GERONIMO-3127: -- Assignee: Donald Woods ERROR [DriverDownloader] Unable to download driver properties - Key: GERONIMO-3127 URL: https://issues.apache.org/jira/browse/GERONIMO-3127 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 2.0-M5, 2.0-M6 Environment: Window 2K, Jre 6. firefox Reporter: nrkkalyan Assignee: Donald Woods Fix For: 2.0 When we try to download driver in the 2 step of creating Database pool we are getting the following error * Geronimo Application Server started 11:19:32,396 ERROR [DriverDownloader] Unable to download driver properties java.net.UnknownHostException: geronimo.apache.org at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177) at java.net.Socket.connect(Socket.java:516) at java.net.Socket.connect(Socket.java:466) at sun.net.NetworkClient.doConnect(NetworkClient.java:157) at sun.net.www.http.HttpClient.openServer(HttpClient.java:365) at sun.net.www.http.HttpClient.openServer(HttpClient.java:477) at sun.net.www.http.HttpClient.init(HttpClient.java:214) at sun.net.www.http.HttpClient.New(HttpClient.java:287) at sun.net.www.http.HttpClient.New(HttpClient.java:299) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:796) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:748) at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:673) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:917) at java.net.URL.openStream(URL.java:1007) at org.apache.geronimo.console.databasemanager.wizard.DriverDownloader.readDriverFile(DriverDownloader.java:57) at org.apache.geronimo.console.databasemanager.wizard.DriverDownloader.loadDriverInfo(DriverDownloader.java:70) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.getDriverInfo(DatabasePoolPortlet.java:206) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.renderDownload(DatabasePoolPortlet.java:765) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.doView(DatabasePoolPortlet.java:672) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) 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:687) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvokerImpl.java:73) at org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:119) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPortlet(PortletContainerWrapperImpl.java:70) at org.apache.pluto.portalImpl.aggregation.PortletFragment.service(PortletFragment.java:168) at jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(ColumnFragment_jsp.java:70) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) 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:687) at
[jira] Assigned: (GERONIMO-3127) ERROR [DriverDownloader] Unable to download driver properties
[ https://issues.apache.org/jira/browse/GERONIMO-3127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned GERONIMO-3127: -- Assignee: Donald Woods (was: David Blevins) ERROR [DriverDownloader] Unable to download driver properties - Key: GERONIMO-3127 URL: https://issues.apache.org/jira/browse/GERONIMO-3127 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 2.0-M5, 2.0-M6 Environment: Window 2K, Jre 6. firefox Reporter: nrkkalyan Assignee: Donald Woods Fix For: 2.0 When we try to download driver in the 2 step of creating Database pool we are getting the following error * Geronimo Application Server started 11:19:32,396 ERROR [DriverDownloader] Unable to download driver properties java.net.UnknownHostException: geronimo.apache.org at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177) at java.net.Socket.connect(Socket.java:516) at java.net.Socket.connect(Socket.java:466) at sun.net.NetworkClient.doConnect(NetworkClient.java:157) at sun.net.www.http.HttpClient.openServer(HttpClient.java:365) at sun.net.www.http.HttpClient.openServer(HttpClient.java:477) at sun.net.www.http.HttpClient.init(HttpClient.java:214) at sun.net.www.http.HttpClient.New(HttpClient.java:287) at sun.net.www.http.HttpClient.New(HttpClient.java:299) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:796) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:748) at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:673) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:917) at java.net.URL.openStream(URL.java:1007) at org.apache.geronimo.console.databasemanager.wizard.DriverDownloader.readDriverFile(DriverDownloader.java:57) at org.apache.geronimo.console.databasemanager.wizard.DriverDownloader.loadDriverInfo(DriverDownloader.java:70) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.getDriverInfo(DatabasePoolPortlet.java:206) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.renderDownload(DatabasePoolPortlet.java:765) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.doView(DatabasePoolPortlet.java:672) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) 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:687) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvokerImpl.java:73) at org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:119) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPortlet(PortletContainerWrapperImpl.java:70) at org.apache.pluto.portalImpl.aggregation.PortletFragment.service(PortletFragment.java:168) at jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(ColumnFragment_jsp.java:70) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) 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:687) at
[jira] Assigned: (GERONIMO-3208) In-place deployment fails when renaming file
[
https://issues.apache.org/jira/browse/GERONIMO-3208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donald Woods reassigned GERONIMO-3208:
--
Assignee: Donald Woods
In-place deployment fails when renaming file
Key: GERONIMO-3208
URL: https://issues.apache.org/jira/browse/GERONIMO-3208
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 2.0-M6
Environment: Windows XP SP2
Reporter: Aman Nanner
Assignee: Donald Woods
Priority: Blocker
Fix For: 2.0
Attachments: inplace-deployment-fails.ear.zip
I am using the latest SNAPSHOT of Geronimo.
I was trying to deploy my custom application with Geronimo using in-place
deployment, but it would fail with a ZipException and an Access denied
message at the following line:
{code}
System Thread [RMI TCP Connection(189)-192.168.12.66] (Suspended (breakpoint
at line 127 in InPlaceResourceContext))
InPlaceResourceContext.flush() line: 127
EARContext(DeploymentContext).flush() line: 428
TomcatModuleBuilder(AbstractWebModuleBuilder).installModule(JarFile,
EARContext, Module, Collection, ConfigurationStore, Collection) line: 312
AbstractWebModuleBuilder$$FastClassByCGLIB$$8523248f.invoke(int,
Object, Object[]) line: not available
{code}
So I tried creating a small EAR file for testing purposes, and deployment of
it also failed but at a different point:
{code}
[java] Error: Unable to distribute testing.ear: Problem closing war
context
[java] Cannot rename file
[java]
D:\Development\mx0706\build\geronimo\maintenix\testing.ear\testing.war
[java] to
[java]
D:\Development\mx0706\build\geronimo\maintenix\testing.ear\testing.war.saved
{code}
This failed at line 121 in the {{InPlaceResourceContext}} class. I've
attached the sample EAR file that was causing me this problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3127) ERROR [DriverDownloader] Unable to download driver properties
[ https://issues.apache.org/jira/browse/GERONIMO-3127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-3127: --- Reassigned wrong bug, assigning this one back to me to look at... ERROR [DriverDownloader] Unable to download driver properties - Key: GERONIMO-3127 URL: https://issues.apache.org/jira/browse/GERONIMO-3127 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 2.0-M5, 2.0-M6 Environment: Window 2K, Jre 6. firefox Reporter: nrkkalyan Assignee: Donald Woods Fix For: 2.0 When we try to download driver in the 2 step of creating Database pool we are getting the following error * Geronimo Application Server started 11:19:32,396 ERROR [DriverDownloader] Unable to download driver properties java.net.UnknownHostException: geronimo.apache.org at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177) at java.net.Socket.connect(Socket.java:516) at java.net.Socket.connect(Socket.java:466) at sun.net.NetworkClient.doConnect(NetworkClient.java:157) at sun.net.www.http.HttpClient.openServer(HttpClient.java:365) at sun.net.www.http.HttpClient.openServer(HttpClient.java:477) at sun.net.www.http.HttpClient.init(HttpClient.java:214) at sun.net.www.http.HttpClient.New(HttpClient.java:287) at sun.net.www.http.HttpClient.New(HttpClient.java:299) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:796) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:748) at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:673) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:917) at java.net.URL.openStream(URL.java:1007) at org.apache.geronimo.console.databasemanager.wizard.DriverDownloader.readDriverFile(DriverDownloader.java:57) at org.apache.geronimo.console.databasemanager.wizard.DriverDownloader.loadDriverInfo(DriverDownloader.java:70) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.getDriverInfo(DatabasePoolPortlet.java:206) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.renderDownload(DatabasePoolPortlet.java:765) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.doView(DatabasePoolPortlet.java:672) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) 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:687) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvokerImpl.java:73) at org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:119) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPortlet(PortletContainerWrapperImpl.java:70) at org.apache.pluto.portalImpl.aggregation.PortletFragment.service(PortletFragment.java:168) at jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(ColumnFragment_jsp.java:70) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) 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:687) at
[jira] Assigned: (GERONIMO-2884) JNDI Name Not Correct
[ https://issues.apache.org/jira/browse/GERONIMO-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned GERONIMO-2884: -- Assignee: David Blevins The nabble thread looked like you knew how to fix this and was going to get into 2.0-M3. JNDI Name Not Correct - Key: GERONIMO-2884 URL: https://issues.apache.org/jira/browse/GERONIMO-2884 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Environment: Linux Reporter: Tom Purcell Assignee: David Blevins Fix For: 2.0 I was asked to open this issue by David Blevins following this Nabble exchange: http://www.nabble.com/InitialContext-JNDI-Lookup-tf3273209s2756.html The issue is that the JNDI entry under which an ejb's remote business interface is registered is constructed as: deploymentId/BeanNameBussinessRemote instead of ejb.jar file name/BeanNameBussinessRemote this results in an entry that looks like this: geronimo-deploymentUtil5840.tmpdir/ConferenceCallSchedulerBeanBusinessRemote The main problem with this is that the number part of the deployment id (5840 in the above) will be different on each redeploy making it difficult for a client app to find. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3127) ERROR [DriverDownloader] Unable to download driver properties
[ https://issues.apache.org/jira/browse/GERONIMO-3127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned GERONIMO-3127: -- Assignee: David Blevins (was: Donald Woods) The nabble thread looked like you knew how to fix this and was going to get into 2.0-M3. ERROR [DriverDownloader] Unable to download driver properties - Key: GERONIMO-3127 URL: https://issues.apache.org/jira/browse/GERONIMO-3127 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 2.0-M5, 2.0-M6 Environment: Window 2K, Jre 6. firefox Reporter: nrkkalyan Assignee: David Blevins Fix For: 2.0 When we try to download driver in the 2 step of creating Database pool we are getting the following error * Geronimo Application Server started 11:19:32,396 ERROR [DriverDownloader] Unable to download driver properties java.net.UnknownHostException: geronimo.apache.org at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177) at java.net.Socket.connect(Socket.java:516) at java.net.Socket.connect(Socket.java:466) at sun.net.NetworkClient.doConnect(NetworkClient.java:157) at sun.net.www.http.HttpClient.openServer(HttpClient.java:365) at sun.net.www.http.HttpClient.openServer(HttpClient.java:477) at sun.net.www.http.HttpClient.init(HttpClient.java:214) at sun.net.www.http.HttpClient.New(HttpClient.java:287) at sun.net.www.http.HttpClient.New(HttpClient.java:299) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:796) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:748) at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:673) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:917) at java.net.URL.openStream(URL.java:1007) at org.apache.geronimo.console.databasemanager.wizard.DriverDownloader.readDriverFile(DriverDownloader.java:57) at org.apache.geronimo.console.databasemanager.wizard.DriverDownloader.loadDriverInfo(DriverDownloader.java:70) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.getDriverInfo(DatabasePoolPortlet.java:206) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.renderDownload(DatabasePoolPortlet.java:765) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.doView(DatabasePoolPortlet.java:672) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) 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:687) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvokerImpl.java:73) at org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:119) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPortlet(PortletContainerWrapperImpl.java:70) at org.apache.pluto.portalImpl.aggregation.PortletFragment.service(PortletFragment.java:168) at jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(ColumnFragment_jsp.java:70) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) 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
[jira] Commented: (GERONIMO-2737) Server shutdown time has increased significantly because of ActiveMQ v4
[ https://issues.apache.org/jira/browse/GERONIMO-2737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516063 ] Donald Woods commented on GERONIMO-2737: The stomp and tcp connectors are still taking 5 secs. each to shutdown - 13:31:33,046 DEBUG [GBeanInstanceState] GBeanInstanceState for: org.apache.geronimo.configs/rmi-naming/2.0-SNAPSHOT/car?configurationName=org.apache.geronimo.configs/rmi-naming/2.0-SNAPSHOT/car State changed from running to stopping 13:31:33,046 DEBUG [GBeanInstanceState] GBeanInstanceState for: org.apache.geronimo.configs/rmi-naming/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/rmi-naming/2.0-SNAPSHOT/car,j2eeType=GBean,name=MBeanServerReference State changed from running to stopping 13:31:33,062 DEBUG [GBeanInstanceState] GBeanInstanceState for: org.apache.geronimo.configs/activemq-broker/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/activemq-broker/2.0-SNAPSHOT/car,j2eeType=JMSServer,name=ActiveMQ State changed from running to stopping 13:31:33,062 DEBUG [GBeanInstanceState] GBeanInstanceState for: org.apache.geronimo.configs/activemq-broker/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/activemq-broker/2.0-SNAPSHOT/car,j2eeType=JMSConnector,name=ActiveMQ.stomp.default State changed from running to stopping 13:31:37,812 INFO [TransportConnector] Connector stomp://0.0.0.0:61613 Stopped 13:31:37,812 DEBUG [GBeanInstanceState] GBeanInstanceState for: org.apache.geronimo.configs/activemq-broker/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/activemq-broker/2.0-SNAPSHOT/car,j2eeType=JMSConnector,name=ActiveMQ.stomp.default State changed from stopping to stopped 13:31:37,812 DEBUG [GBeanInstanceState] GBeanInstanceState for: org.apache.geronimo.configs/activemq-broker/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/activemq-broker/2.0-SNAPSHOT/car,j2eeType=JMSConnector,name=ActiveMQ.tcp.default State changed from running to stopping 13:31:42,875 INFO [TransportConnector] Connector tcp://0.0.0.0:61616 Stopped 13:31:49,671 DEBUG [GBeanInstanceState] GBeanInstanceState for: org.apache.geronimo.configs/activemq-broker/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/activemq-broker/2.0-SNAPSHOT/car,j2eeType=JMSConnector,name=ActiveMQ.tcp.default State changed from stopping to stopped 13:31:49,687 INFO [BrokerService] ActiveMQ Message Broker (localhost, ID:drwoods-4618-1185557336031-1:0) is shutting down 13:31:49,687 INFO [TransportConnector] Connector stomp://0.0.0.0:61613 Stopped 13:31:49,687 INFO [TransportConnector] Connector tcp://0.0.0.0:61616 Stopped 13:31:49,687 DEBUG [JournalPersistenceAdapter] Waking for checkpoint to complete. 13:31:49,687 DEBUG [JournalPersistenceAdapter] Checkpoint started. 13:31:49,687 DEBUG [JournalPersistenceAdapter] Checkpoint done. 13:31:49,718 INFO [BrokerService] ActiveMQ JMS Message Broker (localhost, ID:drwoods-4618-1185557336031-1:0) stopped Server shutdown time has increased significantly because of ActiveMQ v4 --- Key: GERONIMO-2737 URL: https://issues.apache.org/jira/browse/GERONIMO-2737 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ, startup/shutdown Affects Versions: 2.0-M2 Environment: Tomcat6 JEE5 assembly from 2.0 trunk Rev496565 on Core Duo system w/ WinXP and logging set to DEBUG level Reporter: Donald Woods Fix For: 2.0 Server shutdowns (either Ctrl+C or with shutdown script) is taking a lot longer in 2.0 than it did in 1.1.1. The ActiveMQ.stomp.default and ActiveMQ.tcp.default gbeans are taking 11 secs. to shutdown, while everything else only takes 5 secs. - 15:13:29,921 DEBUG [BasicKernel] Starting kernel shutdown . . . 15:13:30,390 DEBUG [GBeanInstanceState] GBeanInstanceState for: org.apache.geronimo.configs/activemq-broker/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/activemq-broker/2.0-SNAPSHOT/car,j2eeType=JMSServer,name=ActiveMQ State changed from running to stopping 15:13:30,390 DEBUG [GBeanInstanceState] GBeanInstanceState for: org.apache.geronimo.configs/activemq-broker/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/activemq-broker/2.0-SNAPSHOT/car,j2eeType=JMSConnector,name=ActiveMQ.stomp.default State changed from running to stopping 15:13:36,093 DEBUG [GBeanInstanceState] GBeanInstanceState for: org.apache.geronimo.configs/activemq-broker/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/activemq-broker/2.0-SNAPSHOT/car,j2eeType=JMSConnector,name=ActiveMQ.stomp.default State changed from stopping to stopped 15:13:36,093 DEBUG [GBeanInstanceState] GBeanInstanceState for:
[jira] Closed: (GERONIMO-2892) Undeploy locks files on Windows
[ https://issues.apache.org/jira/browse/GERONIMO-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasad Kashyap closed GERONIMO-2892. Resolution: Fixed verified and closed Undeploy locks files on Windows --- Key: GERONIMO-2892 URL: https://issues.apache.org/jira/browse/GERONIMO-2892 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M3, 2.0-M5 Environment: Windows XP. Reporter: Prasad Kashyap Priority: Blocker Fix For: Verification Required Attachments: simplewebapp0.war Upon undeploying an app, its entry in the config.xml is removed. However its files in the G repo are not cleaned up. When the same app is deployed again, it fails with the a Config already exists Exception. Trying to undelete the app's files from the G repo fails with a windows message that files are in use by an another process. http://www.nabble.com/Can-somebody-please-verify-that-undeploy-works-%28on-Windows%29---tf3269734.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3360) corba-marshall and corba-mytime tests failing
corba-marshall and corba-mytime tests failing
-
Key: GERONIMO-3360
URL: https://issues.apache.org/jira/browse/GERONIMO-3360
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: testsuite
Affects Versions: 2.0, 2.0.x, 2.1
Reporter: Prasad Kashyap
Assignee: Tim McConnell
Fix For: 2.0.x
exception in corba-marshall :
{code}
[INFO] [INFO] long passed to EJB: 1218738708599296309
[INFO] [WARNING] java.lang.Exception: long array test RemoteException:
[3675022138608874094, -4905270342012320510] java.rmi.RemoteException: null;
nested exception is:
[INFO] [WARNING]org.omg.CORBA.UNKNOWN: vmcid: 0x0 minor code: 0x0
completed: No
[INFO] [WARNING]at
org.apache.geronimo.testsuite.corba.marshal.JavaPrimitives.marshal(JavaPrimitives.java:415)
[INFO] [WARNING]at
org.apache.geronimo.testsuite.corba.marshal.MarshalEJBClient.main(MarshalEJBClient.java:43)
[INFO] [WARNING]at java.lang.reflect.Method.invoke(Method.java:585)
[INFO] [WARNING]at
org.apache.geronimo.client.AppClientContainer.main(AppClientContainer.java:185)
{code}
Exception in corba-mytime:
{code}
[WARNING] Deployer operation failed: start of
org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car failed
[WARNING] org.apache.geronimo.kernel.config.LifecycleException: start of
org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car failed
[WARNING] Caused by: org.apache.geronimo.kernel.config.InvalidConfigException:
Unknown start exception
[WARNING] at
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:514)
[WARNING] at
org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187)
[WARNING] at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:530)
[WARNING] ... 35 more
[WARNING] Caused by: org.apache.geronimo.gbean.InvalidConfigurationException:
Configuration org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car
failed to start due to the following reasons:
[WARNING] The service
EJBModule=corba-mytime-ejb-2.0-SNAPSHOT.jar,J2EEApplication=org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car,StatelessSessionBean=MyTime,j2eeType=TSSLink,name=IdentityTokenNoSecurity
did not start because
org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car?EJBModule=corba-mytime-ejb-2.0-SNAPSHOT.jar,J2EEApplication=org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car,j2eeType=CORBATSS,name=IdentityTokenNoSecurity
did not start.
[WARNING] The service
EJBModule=corba-mytime-ejb-2.0-SNAPSHOT.jar,J2EEApplication=org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car,j2eeType=CORBATSS,name=IdentityTokenNoSecurity
did not start because IDL:omg.org/PortableServer/POA/AdapterAlreadyExists:1.0
[WARNING]
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3199) Prefix ear name in deployment-id to make it unique
[ https://issues.apache.org/jira/browse/GERONIMO-3199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasad Kashyap updated GERONIMO-3199: - Fix Version/s: 2.0.x Prefix ear name in deployment-id to make it unique -- Key: GERONIMO-3199 URL: https://issues.apache.org/jira/browse/GERONIMO-3199 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.0-M5, 2.0-M6 Reporter: Prasad Kashyap Assignee: David Blevins Fix For: 2.0.x In 2.0-M3, when a bean was deployed, it's deployment-id was prefixed with geronimo-deploymentUtil9638.tmpdir Eg: deployment-id=geronimo-deploymentUtil9638.tmpdir/SimpleStatelessSession This ensured a unique ID even if beans from across apps had the same name. Now, the deployment-id is prefixed with the name of the jar to which the bean belongs to. Eg: deployment-id=ejb.jar/SimpleStatelessSession This eliminates the deployment of another app having a bean with the same name packaged in a same named jar. http://www.nabble.com/Naming-conflict-when-deploying-testsupport-EARs-tf3834600s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3314) (Sandbox) The Welcome portlet has an error in the way it renders the Common Console Actions table
[ https://issues.apache.org/jira/browse/GERONIMO-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bohn updated GERONIMO-3314: --- Summary: (Sandbox) The Welcome portlet has an error in the way it renders the Common Console Actions table (was: The Welcome portlet has an error in the way it renders the Common Console Actions table) (Sandbox) The Welcome portlet has an error in the way it renders the Common Console Actions table - Key: GERONIMO-3314 URL: https://issues.apache.org/jira/browse/GERONIMO-3314 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Environment: WindowsXP Reporter: Daniel Larsen Priority: Trivial Attachments: geronimo-3314.patch The Welcome portlet has an error in the way it renders the Common Console Actions table -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2315) On Editing a database pool by changing the database name and restarting it fails to startup
[ https://issues.apache.org/jira/browse/GERONIMO-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasad Kashyap closed GERONIMO-2315. Resolution: Fixed Assignee: Prasad Kashyap Verified and found to be working correctly. Please reopen if necessary. On Editing a database pool by changing the database name and restarting it fails to startup --- Key: GERONIMO-2315 URL: https://issues.apache.org/jira/browse/GERONIMO-2315 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1, 1.1.1 Environment: All Supported Platforms Reporter: Manu T George Assignee: Prasad Kashyap Fix For: Verification Required Suppose I create an embedded derby Datasource pointing to an embedded DB TestDB and deploy it.It works w/o any problem. Now from the console if i edit the datasorce to point to another db and restart it fails with the exception below 12:31:32,231 ERROR [Servlet] Exception caught: javax.portlet.PortletException: Exception at org.apache.geronimo.console.configmanager.ConfigManagerPortlet.proces sAction(ConfigManagerPortlet.java:107) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229 ) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp atcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD ispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis patcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvoke rImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvoke rImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletCon tainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processP ortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV alve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV alve.java:178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSu bjectValve.java:52) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica torBase.java:524) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve. invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(Gero nimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j ava:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j ava:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal ve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java: 541) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav a:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java :869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.p rocessConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpo int.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFol lowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP ool.java:684) at java.lang.Thread.run(Unknown Source) Caused by: org.apache.geronimo.kernel.config.LifecycleException: start of
Re: load balancing?
On 7/26/07, cui.hailin [EMAIL PROTECTED] wrote: in Apache ServiceMix Home Documentation Guides Clustering Please see my responses inline below: 1,load balancing of messages across servers/machines ? Multiple JMS consumers can be pointed at a single queue and compete for the consumption of messages providing load balancing functionality. This can allow multiple servicemix-jms consumers to compete for messages, sending them into flows through identical groups of components deployed on separate instances of ServiceMix. ServiceMix also provides the ability to create your own EndpointResolver and/or EndpointChooser. The EndpointResolver employs the strategy pattern for plugging in custom policies for resolving endpoints and uses an EndpointChooser to provide the actual endpoint selection policy. See the Javadocs for info: http://incubator.apache.org/servicemix/dist/servicemix-3.1-incubating/site/core/servicemix-core/apidocs/org/apache/servicemix/jbi/resolver/EndpointResolver.html http://incubator.apache.org/servicemix/dist/servicemix-3.1-incubating/site/core/servicemix-core/apidocs/org/apache/servicemix/jbi/resolver/EndpointChooser.html 2,high availability (HA) of services and fault tolerance (if a machine crashes, messages are automatically redelivered to another machine HA is provided by configuring ActiveMQ for this purpose. ServiceMix is built on top of the ActiveMQ message broker so all of the ActiveMQ HA features are available within ServiceMix. Most typically this involves configuring a network of brokers in a master/slave configuration. See the ActiveMQ docs for more info on this. 3,durability (persist messages to disk/database) to ensure they survive catastrophic hardware failure Again, this feature is provided by way of the ActiveMQ message broker and it's implementation of the JMS 1.1 spec. Persistent messaging is configured in ActiveMQ by default and is easy to reconfigure in a custom manner. BTW, this message should be on the servicemix-users list, so I'm CC'ing that list. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://activemq.org/ Apache ServiceMix - http://servicemix.org/ Castor - http://castor.org/
[jira] Closed: (SM-555) Improving reliability of servicemix-jms - servicemix looses messages when crashing
[ https://issues.apache.org/activemq/browse/SM-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Snyder closed SM-555. --- Improving reliability of servicemix-jms - servicemix looses messages when crashing --- Key: SM-555 URL: https://issues.apache.org/activemq/browse/SM-555 Project: ServiceMix Issue Type: Improvement Components: servicemix-jms Affects Versions: 3.0.1 Reporter: Klaus Alfert Assignee: Guillaume Nodet Priority: Critical Fix For: 3.2 ServiceMix can loose (incoming) messages during a crashing. The test-setup is simple: one process populates a queue, servicemix reads this queue and writes each message in a second queue, which is consumed by a second process. During this test servicemix is killed and restarted. My test results showed that some times some messages are lost. Looking in the source code reveals that reading from the queue is done with an AUTO_ACKNOWLEDGE, which implies that there is no dependency between doing an (implicit) commit on the queue and successful sending of a message to another JBI endpoint. Apparently, this can result in lost messages if servicemix crashes. I could possibly use the JCAProcessor, but then I need an external transaction manager. I suggest to extend the servicemix-jms binding component with the (configurable) ability to make the read of an input queue dependent on the successful NMR send. This would add more realiability to servicemix, if needed, payed with a (small) loss of effeciency for wating on receiving a DONE as MessageExchange status. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2210) Enable tests (geronimo-connector-builder :: **/Connector15DCBTest.java)
[
https://issues.apache.org/jira/browse/GERONIMO-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prasad Kashyap updated GERONIMO-2210:
-
Fix Version/s: (was: Verification Required)
2.0.x
As of today's build, this test still fails on 2.0
Enable tests (geronimo-connector-builder :: **/Connector15DCBTest.java)
---
Key: GERONIMO-2210
URL: https://issues.apache.org/jira/browse/GERONIMO-2210
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: connector
Affects Versions: 1.2
Reporter: Jason Dillon
Assignee: Anita Kulshreshtha
Fix For: 2.0.x
A few tests failed in non-obvious ways when run under the m2 build. Need
someone who knows these tests better to inspect, resolve and enable the test
(remove the test exclusions in the pom).
The test fails with (on the console):
{noformat}
Ignoring connectiondefinition-instance/config-setting ServerUrl (no matching
config-property in J2EE DD)
Ignoring connectiondefinition-instance/config-setting UserName (no matching
config-property in J2EE DD)
Ignoring connectiondefinition-instance/config-setting Password (no matching
config-property in J2EE DD)
Geronimo connector deployment plan has admin object with interface
'javax.jms.Queue' and class 'org.activemq.message.ActiveMQQueue' but the
ra.xml does not have a matching adminobject declared. Deleting this
adminobject from the Geronimo plan.
Geronimo connector deployment plan has admin object with interface
'javax.jms.Queue' and class 'org.activemq.message.ActiveMQQueue' but the
ra.xml does not have a matching adminobject declared. Deleting this
adminobject from the Geronimo plan.
Geronimo connector deployment plan has admin object with interface
'javax.jms.Topic' and class 'org.activemq.message.ActiveMQTopic' but the
ra.xml does not have a matching adminobject declared. Deleting this
adminobject from the Geronimo plan.
{noformat}
And in the surefire report:
{noformat}
---
Test set: org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest
---
Tests run: 4, Failures: 3, Errors: 1, Skipped: 0, Time elapsed: 1.488 sec
FAILURE!
testCreateDatabase(org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest)
Time elapsed: 0.66 sec ERROR!
java.lang.NullPointerException
at
org.apache.geronimo.connector.deployment.jsr88.ConnectionDefinition.configure(ConnectionDefinition.java:64)
at
org.apache.geronimo.connector.deployment.jsr88.ResourceAdapter.setConnectionDefinition(ResourceAdapter.java:111)
at
org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest.testCreateDatabase(Connector15DCBTest.java:114)
testWriteWithNulls(org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest)
Time elapsed: 0.046 sec FAILURE!
junit.framework.AssertionFailedError: expected:1 but was:0
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:201)
at junit.framework.Assert.assertEquals(Assert.java:207)
at
org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest.testWriteWithNulls(Connector15DCBTest.java:205)
testCreateJMSResource(org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest)
Time elapsed: 0.382 sec FAILURE!
junit.framework.AssertionFailedError: expected:7 but was:4
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:201)
at junit.framework.Assert.assertEquals(Assert.java:207)
at
org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest.testCreateJMSResource(Connector15DCBTest.java:355)
testLoadJMSResources(org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest)
Time elapsed: 0.38 sec FAILURE!
junit.framework.AssertionFailedError: expected:7 but was:4
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:201)
at junit.framework.Assert.assertEquals(Assert.java:207)
at
org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest.testLoadJMSResources(Connector15DCBTest.java:479)
{noformat}
--
This message is
[jira] Closed: (GERONIMO-3207) Created 2.0-M6 Branch
[ https://issues.apache.org/jira/browse/GERONIMO-3207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasad Kashyap closed GERONIMO-3207. Resolution: Fixed Created 2.0-M6 Branch - Key: GERONIMO-3207 URL: https://issues.apache.org/jira/browse/GERONIMO-3207 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Affects Versions: 2.0-M6 Environment: All Reporter: Matt Hogstrom Assignee: Matt Hogstrom Fix For: Verification Required Created new 2.0-M6 branch. svn cp https://svn.apache.org/repos/asf/geronimo/server/trunk https://svn.apache.org/repos/asf/geronimo/server/branches/2.0-M6 Committed revision 543874. hogstrom-2:~ hogstrom$ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JMS reliability : AUTO_ACKNOWLEDGE vs. CLIENT_ACKNOWLEDGE
On 7/18/07, samg [EMAIL PROTECTED] wrote: Hi folks, in my ongoing effort to not lose messages I've made another change to servicemix-jms : It seems to me that three of the four processors (standard/multiplexing consumer/provider combinations) can be trivially switched to CLIENT_ACKNOWLEDGE without any performance hit at all (they can all do the receive() and acknowledge() in one synchronous flow), so I've done so. I'm not using the MultiplexingConsumerProcessor, and it is the one complex case. This Issue : https://issues.apache.org/activemq/browse/SM-555 requests that it be added as an option, but perhaps it makes sense in these cases to just switch over to CLIENT_ACKNOWLEDGE? Let me know what you think. Thanks for pointing this out, Sam. This is actually fixed in the trunk (3.2-SNAPSHOT) in the new JmsConsumerEndpoint class as a configurable option via the setSessionAcknowledgeMode() method. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://activemq.org/ Apache ServiceMix - http://servicemix.org/ Castor - http://castor.org/
[jira] Resolved: (SM-555) Improving reliability of servicemix-jms - servicemix looses messages when crashing
[
https://issues.apache.org/activemq/browse/SM-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Snyder resolved SM-555.
-
Resolution: Fixed
Fix Version/s: 3.2
Assignee: Guillaume Nodet
Fixed in SM-537 via the {{JmsConsumerEndpoint.setSessionAcknowledgeMode()}}
method.
Improving reliability of servicemix-jms - servicemix looses messages when
crashing
---
Key: SM-555
URL: https://issues.apache.org/activemq/browse/SM-555
Project: ServiceMix
Issue Type: Improvement
Components: servicemix-jms
Affects Versions: 3.0.1
Reporter: Klaus Alfert
Assignee: Guillaume Nodet
Priority: Critical
Fix For: 3.2
ServiceMix can loose (incoming) messages during a crashing.
The test-setup is simple: one process populates a queue, servicemix reads
this queue and writes each message in a second queue, which is consumed by a
second process. During this test servicemix is killed and restarted.
My test results showed that some times some messages are lost. Looking in the
source code reveals that reading from the queue is done with an
AUTO_ACKNOWLEDGE, which implies that there is no dependency between doing an
(implicit) commit on the queue and successful sending of a message to another
JBI endpoint. Apparently, this can result in lost messages if servicemix
crashes. I could possibly use the JCAProcessor, but then I need an external
transaction manager.
I suggest to extend the servicemix-jms binding component with the
(configurable) ability to make the read of an input queue dependent on the
successful NMR send. This would add more realiability to servicemix, if
needed, payed with a (small) loss of effeciency for wating on receiving a
DONE as MessageExchange status.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3314) (Sandbox) The Welcome portlet images and links are broken
[ https://issues.apache.org/jira/browse/GERONIMO-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Larsen updated GERONIMO-3314: Description: (sandbox/portals) The Welcome and Keystore portlet images are broken due to this change: https://issues.apache.org/jira/browse/GERONIMO-3345 The 3 links under Common Console Actions are also routed to the wrong place. was:The Welcome portlet has an error in the way it renders the Common Console Actions table Summary: (Sandbox) The Welcome portlet images and links are broken (was: (Sandbox) The Welcome portlet has an error in the way it renders the Common Console Actions table) I will apply a new patch that fixes both of these. (The table issue was also fixed in GERONIMO-3345) (Sandbox) The Welcome portlet images and links are broken - Key: GERONIMO-3314 URL: https://issues.apache.org/jira/browse/GERONIMO-3314 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Environment: WindowsXP Reporter: Daniel Larsen Priority: Trivial Attachments: geronimo-3314.patch (sandbox/portals) The Welcome and Keystore portlet images are broken due to this change: https://issues.apache.org/jira/browse/GERONIMO-3345 The 3 links under Common Console Actions are also routed to the wrong place. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3314) (Sandbox) The Welcome portlet images and links are broken
[ https://issues.apache.org/jira/browse/GERONIMO-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Larsen updated GERONIMO-3314: Attachment: Geronimo-3314.patch (Sandbox) The Welcome portlet images and links are broken - Key: GERONIMO-3314 URL: https://issues.apache.org/jira/browse/GERONIMO-3314 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Environment: WindowsXP Reporter: Daniel Larsen Priority: Trivial Attachments: Geronimo-3314.patch (sandbox/portals) The Welcome and Keystore portlet images are broken due to this change: https://issues.apache.org/jira/browse/GERONIMO-3345 The 3 links under Common Console Actions are also routed to the wrong place. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3314) (Sandbox) The Welcome portlet images and links are broken
[ https://issues.apache.org/jira/browse/GERONIMO-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Larsen updated GERONIMO-3314: Attachment: (was: geronimo-3314.patch) (Sandbox) The Welcome portlet images and links are broken - Key: GERONIMO-3314 URL: https://issues.apache.org/jira/browse/GERONIMO-3314 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Environment: WindowsXP Reporter: Daniel Larsen Priority: Trivial Attachments: Geronimo-3314.patch (sandbox/portals) The Welcome and Keystore portlet images are broken due to this change: https://issues.apache.org/jira/browse/GERONIMO-3345 The 3 links under Common Console Actions are also routed to the wrong place. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: KEYS ?
What external references are you referring to? I believe that it does have symlink support, though I hardly ever use it. --jason On Jul 27, 2007, at 12:29 PM, Dain Sundstrom wrote: I think there are external references to this file, but I'm not sure how we should deal with them. Does svn have symlink support? -dain On Jul 26, 2007, at 3:52 PM, Jason Dillon wrote: Should keys move up to a peer to the STATUS file too? Seems these are project global, not specific to the server bits... --jason
Re: What to do with legacy EJB 2.1 code in DayTrader?
I'd like to see the 2.1 code kept around so we can compare base EJB performance against other servers. There is going to be legacy code for a long time and this tool is our only way to see how legacy code performs on our server. -dain On Jul 25, 2007, at 9:56 AM, Christopher Blythe wrote: All, Given Geronimo 2.0 and DayTrader 2.0's focus on Java EE 5, I was wondering if it made sense to remove the old EJB 2.1 code? To be quite honest, I am torn. One one side, it would be nice to have both the EJB 2.1 and 3.0 impls at the same time for comparison purposes. However, keeping the old stuff around seems to hide the fact that 3.0 is supposed to be easier to work with and develop. Here are some options along with my own arguments for each... 1) Remove the old EJB 2.1 modes and make DayTrader 2.0 EJB 3 only - highlights the advantages of EJB 3.0 (less DDs, etc.) - makes the packaging and various runtime modes less confusing - can use the DayTrader 1.2 code for comparisons between EJB 2.1 and 3.0 - EJB 2.1 mode never worked under load to begin with due to consistency issues 2) Leave 2.1 code in there for now and phase out in a DayTrader 2.X - comparisons can be done using a single ear - DT 2.x could be spun up immediately Now that I think about it, I think I'm swaying more towards option 1. However, given the time constraints to get 2.0 out the door, I'm not sure if 1 is realistic. Thoughts? Thanks... Chris -- I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may. - Tyler Durden
Re: KEYS ?
I think there are external references to this file, but I'm not sure how we should deal with them. Does svn have symlink support? -dain On Jul 26, 2007, at 3:52 PM, Jason Dillon wrote: Should keys move up to a peer to the STATUS file too? Seems these are project global, not specific to the server bits... --jason
[jira] Updated: (GERONIMO-3349) broken link in console when on the Apache HTTP page
[ https://issues.apache.org/jira/browse/GERONIMO-3349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen updated GERONIMO-3349: --- Attachment: geronimo-3349.patch for some reason the paths (containing ':' and '\') messes up the portlet. So I encoded these characters for this portlet. broken link in console when on the Apache HTTP page Key: GERONIMO-3349 URL: https://issues.apache.org/jira/browse/GERONIMO-3349 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Environment: windows xp Reporter: Viet Hung Nguyen Attachments: geronimo-3349.patch in the admin console, when running tomcat, if you click on 'Apache HTTP' and click on 'Get Started' you do not see anything render. Instead, it warns this at the commandline: WARN [AJPHandler] Found AJP listener on port 8009 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Transaction and Connector jars untied from g. kernel
Sweet! Thanks, -dain On Jul 24, 2007, at 6:00 PM, David Jencks wrote: see GERONIMO-3344. Following years of urging from activemq/jencks/servicemix and more recent urging from openejb I finally split off the tx and connector modules into bits that implement the functionality w/o geronimo fluff and geronimo integration jars. The functional bits are now under components/txmanager/trunk. I have server/trunk compiling and appearing to work on my local machine. If no one objects I'll commit my local changes to trunk later tonight so g 2.1-SNAPSHOT will be using the new jars. new jars have groupId org.apache.geronimo.components, and artifactIds geronimo-transaction and geronimo-connector, and version 2.0-SNAPSHOT. I'd really appreciate a review of the dir structure and poms from e.g. jdillon since I suspect a better structure may be possible. There is a dependency on the genesis 1.2-SNAPSHOT pom, this also is in g. trunk. if all goes well perhaps we can release the new jars in a day or two and then openejb can release without a dependency on geronimo server. thanks david jencks
Re: [DISCUSS] Adding a Tech Preview portlet group in Admin Console in G 2.0
On Jul 26, 2007, at 1:21 AM, Vamsavardhana Reddy wrote: How about adding a Tech Preview portlet group in Admin Console in G 2.0 where we can include the portlets (for e.g., the Create Plan portlet Shiva is working on. See https://issues.apache.org/ jira/browse/GERONIMO-3254) for which user feedback will play a great role in improving those further. Once we decide on whether to retain those or not, we can either move them out to a different group or remove them from Admin Console accordingly. Some of the new pluggable console support would have helped, here. But that's not going into 2.0. Personally, sounds like this should go into trunk, if it's not ready... Can still get good feedback... --kevan
[jira] Updated: (GERONIMO-3349) broken link in console when on the Apache HTTP page
[ https://issues.apache.org/jira/browse/GERONIMO-3349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-3349: --- Affects Version/s: 2.0-M6 Fix Version/s: 2.0 broken link in console when on the Apache HTTP page Key: GERONIMO-3349 URL: https://issues.apache.org/jira/browse/GERONIMO-3349 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.0-M6 Environment: windows xp Reporter: Viet Hung Nguyen Assignee: Donald Woods Fix For: 2.0 Attachments: geronimo-3349.patch in the admin console, when running tomcat, if you click on 'Apache HTTP' and click on 'Get Started' you do not see anything render. Instead, it warns this at the commandline: WARN [AJPHandler] Found AJP listener on port 8009 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2737) Server shutdown time has increased significantly because of ActiveMQ v4
[ https://issues.apache.org/jira/browse/GERONIMO-2737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-2737: --- Fix Version/s: (was: 2.0) 2.0.x Server shutdown time has increased significantly because of ActiveMQ v4 --- Key: GERONIMO-2737 URL: https://issues.apache.org/jira/browse/GERONIMO-2737 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ, startup/shutdown Affects Versions: 2.0-M2 Environment: Tomcat6 JEE5 assembly from 2.0 trunk Rev496565 on Core Duo system w/ WinXP and logging set to DEBUG level Reporter: Donald Woods Fix For: 2.0.x Server shutdowns (either Ctrl+C or with shutdown script) is taking a lot longer in 2.0 than it did in 1.1.1. The ActiveMQ.stomp.default and ActiveMQ.tcp.default gbeans are taking 11 secs. to shutdown, while everything else only takes 5 secs. - 15:13:29,921 DEBUG [BasicKernel] Starting kernel shutdown . . . 15:13:30,390 DEBUG [GBeanInstanceState] GBeanInstanceState for: org.apache.geronimo.configs/activemq-broker/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/activemq-broker/2.0-SNAPSHOT/car,j2eeType=JMSServer,name=ActiveMQ State changed from running to stopping 15:13:30,390 DEBUG [GBeanInstanceState] GBeanInstanceState for: org.apache.geronimo.configs/activemq-broker/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/activemq-broker/2.0-SNAPSHOT/car,j2eeType=JMSConnector,name=ActiveMQ.stomp.default State changed from running to stopping 15:13:36,093 DEBUG [GBeanInstanceState] GBeanInstanceState for: org.apache.geronimo.configs/activemq-broker/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/activemq-broker/2.0-SNAPSHOT/car,j2eeType=JMSConnector,name=ActiveMQ.stomp.default State changed from stopping to stopped 15:13:36,093 DEBUG [GBeanInstanceState] GBeanInstanceState for: org.apache.geronimo.configs/activemq-broker/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/activemq-broker/2.0-SNAPSHOT/car,j2eeType=JMSConnector,name=ActiveMQ.tcp.default State changed from running to stopping 15:13:41,125 DEBUG [GBeanInstanceState] GBeanInstanceState for: org.apache.geronimo.configs/activemq-broker/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/activemq-broker/2.0-SNAPSHOT/car,j2eeType=JMSConnector,name=ActiveMQ.tcp.default State changed from stopping to stopped . . . 15:13:46,265 DEBUG [BasicKernel] Kernel shutdown complete -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3349) broken link in console when on the Apache HTTP page
[ https://issues.apache.org/jira/browse/GERONIMO-3349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned GERONIMO-3349: -- Assignee: Donald Woods broken link in console when on the Apache HTTP page Key: GERONIMO-3349 URL: https://issues.apache.org/jira/browse/GERONIMO-3349 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.0-M6 Environment: windows xp Reporter: Viet Hung Nguyen Assignee: Donald Woods Fix For: 2.0 Attachments: geronimo-3349.patch in the admin console, when running tomcat, if you click on 'Apache HTTP' and click on 'Get Started' you do not see anything render. Instead, it warns this at the commandline: WARN [AJPHandler] Found AJP listener on port 8009 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r560387 - in /geronimo/components/txmanager/trunk: geronimo-connector/src/test/resources/ geronimo-connector/src/test/resources/META-INF/ geronimo-transaction/src/test/resources/ geron
Ya, thats good enough for now ;-) You should update the pom to make it strict = true now. --jason On Jul 27, 2007, at 2:23 PM, [EMAIL PROTECTED] wrote: Author: djencks Date: Fri Jul 27 14:23:10 2007 New Revision: 560387 URL: http://svn.apache.org/viewvc?view=revrev=560387 Log: GERONIMO-3344 brute force some legal files into the test jars Added: geronimo/components/txmanager/trunk/geronimo-connector/src/test/ resources/ geronimo/components/txmanager/trunk/geronimo-connector/src/test/ resources/META-INF/ geronimo/components/txmanager/trunk/geronimo-connector/src/test/ resources/META-INF/LICENSE.txt (with props) geronimo/components/txmanager/trunk/geronimo-connector/src/test/ resources/META-INF/NOTICE.txt (with props) geronimo/components/txmanager/trunk/geronimo-transaction/src/ test/resources/ geronimo/components/txmanager/trunk/geronimo-transaction/src/ test/resources/META-INF/ geronimo/components/txmanager/trunk/geronimo-transaction/src/ test/resources/META-INF/LICENSE.txt (with props) geronimo/components/txmanager/trunk/geronimo-transaction/src/ test/resources/META-INF/NOTICE.txt (with props) Added: geronimo/components/txmanager/trunk/geronimo-connector/src/ test/resources/META-INF/LICENSE.txt URL: http://svn.apache.org/viewvc/geronimo/components/txmanager/ trunk/geronimo-connector/src/test/resources/META-INF/LICENSE.txt? view=autorev=560387 == --- geronimo/components/txmanager/trunk/geronimo-connector/src/test/ resources/META-INF/LICENSE.txt (added) +++ geronimo/components/txmanager/trunk/geronimo-connector/src/test/ resources/META-INF/LICENSE.txt Fri Jul 27 14:23:10 2007 @@ -0,0 +1,203 @@ + + Apache License + Version 2.0, January 2004 +http://www.apache.org/licenses/ + + TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION + + 1. Definitions. + + License shall mean the terms and conditions for use, reproduction, + and distribution as defined by Sections 1 through 9 of this document. + + Licensor shall mean the copyright owner or entity authorized by + the copyright owner that is granting the License. + + Legal Entity shall mean the union of the acting entity and all + other entities that control, are controlled by, or are under common + control with that entity. For the purposes of this definition, + control means (i) the power, direct or indirect, to cause the + direction or management of such entity, whether by contract or + otherwise, or (ii) ownership of fifty percent (50%) or more of the + outstanding shares, or (iii) beneficial ownership of such entity. + + You (or Your) shall mean an individual or Legal Entity + exercising permissions granted by this License. + + Source form shall mean the preferred form for making modifications, + including but not limited to software source code, documentation + source, and configuration files. + + Object form shall mean any form resulting from mechanical + transformation or translation of a Source form, including but + not limited to compiled object code, generated documentation, + and conversions to other media types. + + Work shall mean the work of authorship, whether in Source or + Object form, made available under the License, as indicated by a + copyright notice that is included in or attached to the work + (an example is provided in the Appendix below). + + Derivative Works shall mean any work, whether in Source or Object + form, that is based on (or derived from) the Work and for which the + editorial revisions, annotations, elaborations, or other modifications + represent, as a whole, an original work of authorship. For the purposes + of this License, Derivative Works shall not include works that remain + separable from, or merely link (or bind by name) to the interfaces of, + the Work and Derivative Works thereof. + + Contribution shall mean any work of authorship, including + the original version of the Work and any modifications or additions + to that Work or Derivative Works thereof, that is intentionally + submitted to Licensor for inclusion in the Work by the copyright owner + or by an individual or Legal Entity authorized to submit on behalf of + the copyright owner. For the purposes of this definition, submitted + means any form of electronic, verbal, or written communication sent + to the Licensor or its representatives, including but not limited to + communication on electronic mailing lists, source code control systems, + and issue tracking systems that are managed by, or on behalf of, the + Licensor for the purpose of discussing and improving the
Re: Tomcat connectors
Ok..I added APR connectors... Jeff Filip Hanik - Dev Lists wrote: Jeff Genender wrote: Ok I added a whole bunch of new connectors in the o.a.g.t.connectors package. I am still working on APR - more notes to follow on this as its a little squirly since the Tomcat Connector somewhat chooses this automatically based on the existence of a native libraries. For the console we may wish to do a check on whether the native libs exist, and if so, present the APR connector. More on this in another email. not really, it works the same as the NIO connector selection, in server.xml if protocol=HTTP/1.1 and the java.library.path contains the TC native library (tcnative.dll or libtcnative.so) then APR is selected. however, the protocol attribute also takes a complete class name, like protocol=org.apache.coyote.http11.Http11Protocol -- java blocking connector protocol=org.apache.coyote.http11.Http11NioProtocol -- java non blocking connector protocol=org.apache.coyote.http11.Http11AprProtocol -- APR connector so there is no need to dabble with the auto select, personally I don't think its very usable feature, since the APR SSL connector has different attributes than the Java SSL connector and the auto select wouldn't work in that scenario anyway. Filip Here are the connectors we care about at the moment... AJP13ConnectorGBean - Implements AJP Http11ConnectorGBean - Implements blocking Http connector Https11ConnectorGBean - Implements blocking Https connector Http11NIOConnectorGBean - Implements non-blocking Http connector Https11NIOConnectorGBean - Implements non-blocking Https connector I have not wired them into the container and other GBeans yet...I want to clena them up and get any feedback before making the switch since this obviously will impact the console upon wiring them in. As a side note...I am not using any references to the WebManager or other interfaces we used that hooked into the console. We can re-add those if those are deemed necessary. Jeff Paul McMahan wrote: I agree NIO support would be great to have in 2.0, especially since its required for comet. Best wishes, Paul On Jul 23, 2007, at 2:42 PM, Jeff Genender wrote: Hi, I was going through some JIRAs and the Geronimo2.0 source and noticed it will be difficult at best to get the NIO connector and setting attributes on the APR connector for Tomcat due to its current implementation. I really think the ability to use these 2 connectors is very important for the 2.0 release and I would like to put these in. If there are no objections, I would like this to be a part of the 2.0 release. Jeff
[jira] Commented: (GERONIMO-3344) Split out non-kernel-dependent transaction and connector classes for use by openejb, jencks, etc etc.
[ https://issues.apache.org/jira/browse/GERONIMO-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516111 ] David Jencks commented on GERONIMO-3344: Openejb modified to use new jars in rev 560408. Ported to g. 2.0 branch in rev. 560411 Split out non-kernel-dependent transaction and connector classes for use by openejb, jencks, etc etc. - Key: GERONIMO-3344 URL: https://issues.apache.org/jira/browse/GERONIMO-3344 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: connector, transaction manager Affects Versions: 2.0-M6 Reporter: David Jencks Assignee: David Jencks Fix For: 2.0 Attachments: openejb-deps.patch.txt People have been asking for this for years wny not now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3344) Split out non-kernel-dependent transaction and connector classes for use by openejb, jencks, etc etc.
[ https://issues.apache.org/jira/browse/GERONIMO-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3344. -- Resolution: Fixed Fix Version/s: 2.0 I guess it's all ported everywhere I have control over it :-) Split out non-kernel-dependent transaction and connector classes for use by openejb, jencks, etc etc. - Key: GERONIMO-3344 URL: https://issues.apache.org/jira/browse/GERONIMO-3344 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: connector, transaction manager Affects Versions: 2.0-M6 Reporter: David Jencks Assignee: David Jencks Fix For: 2.0 Attachments: openejb-deps.patch.txt People have been asking for this for years wny not now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3348) java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder
[
https://issues.apache.org/jira/browse/GERONIMO-3348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516120
]
Kevan Miller commented on GERONIMO-3348:
First, the Invalid Deployment Descriptor error. WEB-INF/lib/bsf-2.3.0.jar
contains META-INF/tablib.tld. This tld contains the following:
short-nameBSF JSP Support/short-name. short-name is defined to be free of
white space. Take out the blank characters and there wouldn't be a problem.
The subsequent errors are being caused by conflicts between the version of
Spring contained within Geronimo and the version of Spring contained within the
proximity app. You can avoid these errors by using a geronimo deployment plan
and specifying either hidden-classes or inverse-classloading. However, this
seems like it will be a common error that Spring users will encounter. I wonder
if we should try to do a little better -- either include more Spring libraries
in our Geronimo distribution or automatically filter Spring classes (didn't we
do that previously?). I'm going to keep this jira open a bit longer. Would like
to hear what others think.
Oh. BTW, I get a different error during deployment on a current Geronimo
2.0-SNAPSHOT build:
20:48:33,834 WARN [DefaultNamespaceHandlerResolver] Ignoring namespace handler
[org.apache.xbean.spring.context.v2.XBeanNamespaceHandler]: problem with
handler class file or dependent class
java.lang.NoClassDefFoundError:
org/springframework/beans/factory/support/ReaderContext
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2328)
at java.lang.Class.getConstructor0(Class.java:2640)
at java.lang.Class.getDeclaredConstructor(Class.java:1953)
at
org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:60)
at
org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.initHandlerMappings(DefaultNamespaceHandlerResolver.java:122)
at
org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.init(DefaultNamespaceHandlerResolver.java:96)
at
org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.init(DefaultNamespaceHandlerResolver.java:82)
...
The proximity app seems to work just fine. It looks pretty slick...
java.lang.NoSuchMethodError in
org.springframework.context.i18n.LocaleContextHolder
---
Key: GERONIMO-3348
URL: https://issues.apache.org/jira/browse/GERONIMO-3348
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.0-M6
Environment: 2.6.18-gentoo-r2 #1 Sat Nov 11 03:36:37 EST 2006 i686
Pentium III (Katmai) GenuineIntel GNU/Linux
JDK-1.5.0.12
Reporter: Aleksandr Tarutin
When deploying and running [Proximity|http://proximity.abstracthorizon.org/]
it works without any problem in geronimo-1.1.1. But when the same application
is deployed to 2.0-M6 following exception is thrown:
{noformat}
15:57:53,267 INFO [DirectoryHotDeployer] Deploying proximity
15:57:56,690 WARN [JettyModuleBuilder] Web application . does not contain a
WEB-INF/geronimo-web.xml deployment plan. This may or may not be a problem,
depending on whether you have things like resource references that need to be
resolved. You can also give the deployer a separate deployment plan file on
the command line.
15:58:04,709 WARN [JspModuleBuilderExtension] Invalid transformed taglib
org.apache.xmlbeans.XmlException: Invalid deployment descriptor: errors:
jar:file:/opt/geronimo-jetty6-jee5-2.0-M6/repository/default/proximity/1185307073730/proximity-1185307073730.war/WEB-INF/lib/bsf-2.3.0.jar!/META-INF/taglib.tld:15:3:
error: cvc-datatype-valid.1.1: string value 'BSF JSP Support' does not match
pattern for tld-canonical-nameType in namespace
http://java.sun.com/xml/ns/javaee
Descriptor:
!--a tab library descriptor--
taglib xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd; version=2.1
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://java.sun.com/xml/ns/javaee;
!--after this the default space is
http://java.sun.com/j2ee/dtds/jsptaglibrary_1_2.dtd--
tlib-version2.0/tlib-version
short-nameBSF JSP Support/short-name
urihttp://jakarta.apache.org/taglibs//uri
tag
namescriptlet/name
tag-classorg.apache.taglibs.bsf.scriptlet/tag-class
body-contenttagdependent/body-content
attribute
namelanguage/name
requiredtrue/required
/attribute
/tag
tag
nameexpression/name
tag-classorg.apache.taglibs.bsf.expression/tag-class
body-contenttagdependent/body-content
attribute
namelanguage/name
[BUILD] 2.0: Failed for Revision: 560475
OpenEJB trunk at 560475
Geronimo Revision: 560475 built with tests skipped
See the full build-2300.log file at
http://people.apache.org/~prasad/binaries/20070727/build-2300.log
[INFO]
[INFO] Building Geronimo :: Naming
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Not compiling test sources
[INFO] [surefire:test]
[INFO] Tests are skipped.
[INFO] [jar:jar]
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-naming-2.0-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing
/home/prasad/geronimo/2.0/modules/geronimo-naming/target/geronimo-naming-2.0-SNAPSHOT.jar
to
/home/prasad/.m2/repository/org/apache/geronimo/modules/geronimo-naming/2.0-SNAPSHOT/geronimo-naming-2.0-SNAPSHOT.jar
[INFO]
[INFO] Building Geronimo :: Connector
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Not compiling test sources
[INFO] [surefire:test]
[INFO] Tests are skipped.
[INFO] [jar:jar]
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-connector-2.0-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing
/home/prasad/geronimo/2.0/modules/geronimo-connector/target/geronimo-connector-2.0-SNAPSHOT.jar
to
/home/prasad/.m2/repository/org/apache/geronimo/modules/geronimo-connector/2.0-SNAPSHOT/geronimo-connector-2.0-SNAPSHOT.jar
[INFO]
[INFO] Building Geronimo :: ActiveMQ
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
Downloading:
http://download.java.net/maven/1//commons-logging/jars/commons-logging-1.1.jar
[WARNING] Unable to get resource 'commons-logging:commons-logging:jar:1.1' from
repository java.net (http://download.java.net/maven/1/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//commons-logging/commons-logging/1.1/commons-logging-1.1.jar
[WARNING] Unable to get resource 'commons-logging:commons-logging:jar:1.1' from
repository apache-incubator
(http://people.apache.org/repo/m2-incubating-repository/)
Downloading:
http://ibiblio.org/maven2//commons-logging/commons-logging/1.1/commons-logging-1.1.jar
[WARNING] Unable to get resource 'commons-logging:commons-logging:jar:1.1' from
repository central (http://ibiblio.org/maven2/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository/commons-logging/commons-logging/1.1/commons-logging-1.1.jar
[WARNING] Unable to get resource 'commons-logging:commons-logging:jar:1.1' from
repository apache.incubating.releases
(http://people.apache.org/repo/m2-incubating-repository)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) commons-logging:commons-logging:jar:1.1
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=commons-logging
-DartifactId=commons-logging \
-Dversion=1.1 -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) org.apache.geronimo.modules:geronimo-activemq:jar:2.0-SNAPSHOT
2) org.apache.activemq:activeio-core:jar:3.0.0-incubator
3) commons-logging:commons-logging:jar:1.1
--
1 required artifact is missing.
for artifact:
org.apache.geronimo.modules:geronimo-activemq:jar:2.0-SNAPSHOT
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
java.net (http://download.java.net/maven/1/),
apache.snapshots (http
Re: [DISCUSS] Adding a Tech Preview portlet group in Admin Console in G 2.0
On 7/28/07, Kevan Miller [EMAIL PROTECTED] wrote: On Jul 26, 2007, at 1:21 AM, Vamsavardhana Reddy wrote: How about adding a Tech Preview portlet group in Admin Console in G 2.0where we can include the portlets (for e.g., the Create Plan portlet Shiva is working on. See https://issues.apache.org/jira/browse/GERONIMO-3254) for which user feedback will play a great role in improving those further. Once we decide on whether to retain those or not, we can either move them out to a different group or remove them from Admin Console accordingly. Some of the new pluggable console support would have helped, here. But that's not going into 2.0. Personally, sounds like this should go into trunk, if it's not ready... Can still get good feedback... --kevan The idea is that if these portlets go in as part of a release with binaries readily available for download, we have a better chance of getting more users to try the portlets and possibly provide some feedback too in the linked wiki pages. If it goes only into trunk, the users will still have to build the binaries from trunk, which they may not want to/may not succeed due to some reason or the other. Vamsi
