[jira] Commented: (GERONIMO-3907) Persistence Exception is not visible/lost for client.
[ https://issues.apache.org/jira/browse/GERONIMO-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579739#action_12579739 ] David Jencks commented on GERONIMO-3907: Prospective fix committed to openejb in rev 638225. Can you check that this fixes this problem? Persistence Exception is not visible/lost for client. -- Key: GERONIMO-3907 URL: https://issues.apache.org/jira/browse/GERONIMO-3907 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: persistence Affects Versions: 2.0.2, 2.1 Environment: Linux, Windows Reporter: Ralf Baumhof Assignee: David Jencks Priority: Blocker Original Estimate: 0.08h Remaining Estimate: 0.08h I am trying an insert on a table. The Entity class is wrong annotated, one column was renamed in the table. Then the following situation occurs. The call to persist(entity) is successfully, no exception is thrown. On leaving the ejb container and returning to tomact a commit is performed (it's a managed datasource, so container performs commit). This leads to the insert on database. This insert fails, a rollback is performed. On return to the JSF bean no exception can be seen by the bean. In the same class i have got a query method. If i replace the call to persist with the call to the query method everything works ok. The exception is thrown and is visible at the client site. This is the geronimo console output. The last line comes from the JSB bean which reports a successful insert. 11:58:04,390 WARN [Transaction] Unexpected exception from beforeCompletion; transaction will roll back openjpa-1.0.1-r420667:592145 fatal general error org.apache.openjpa.persistence.PersistenceException: The transaction has been rolled back. See the nested exceptions for details on the errors that occurred. at org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2107) at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1954) at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1852) at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1770) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:514) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:499) at org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400) at org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:257) at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:245) at org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:141) at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:75) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:233) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165) at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217) at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy75.anlegenBenutzer(Unknown Source) at de.nrw.hagen.ggrz.benutzer.controler.BenutzerControler.anlegenBenutzer(BenutzerControler.java:44) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.el.parser.AstValue.invoke(AstValue.java:131) at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276) at org.apache.jasper.el.JspMethodExpression.invoke(JspMethodExpression.java:68) at javax.faces.component._MethodExpressionToMethodBinding.invoke(_MethodExpressionToMethodBinding.java:75) at org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:54) at javax.faces.component.UICommand.broadcast(UICommand.java:121) at
[jira] Assigned: (GERONIMO-3907) Persistence Exception is not visible/lost for client.
[ https://issues.apache.org/jira/browse/GERONIMO-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks reassigned GERONIMO-3907: -- Assignee: David Jencks Persistence Exception is not visible/lost for client. -- Key: GERONIMO-3907 URL: https://issues.apache.org/jira/browse/GERONIMO-3907 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: persistence Affects Versions: 2.0.2, 2.1 Environment: Linux, Windows Reporter: Ralf Baumhof Assignee: David Jencks Priority: Blocker Original Estimate: 0.08h Remaining Estimate: 0.08h I am trying an insert on a table. The Entity class is wrong annotated, one column was renamed in the table. Then the following situation occurs. The call to persist(entity) is successfully, no exception is thrown. On leaving the ejb container and returning to tomact a commit is performed (it's a managed datasource, so container performs commit). This leads to the insert on database. This insert fails, a rollback is performed. On return to the JSF bean no exception can be seen by the bean. In the same class i have got a query method. If i replace the call to persist with the call to the query method everything works ok. The exception is thrown and is visible at the client site. This is the geronimo console output. The last line comes from the JSB bean which reports a successful insert. 11:58:04,390 WARN [Transaction] Unexpected exception from beforeCompletion; transaction will roll back openjpa-1.0.1-r420667:592145 fatal general error org.apache.openjpa.persistence.PersistenceException: The transaction has been rolled back. See the nested exceptions for details on the errors that occurred. at org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2107) at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1954) at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1852) at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1770) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:514) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:499) at org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400) at org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:257) at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:245) at org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:141) at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:75) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:233) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165) at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217) at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy75.anlegenBenutzer(Unknown Source) at de.nrw.hagen.ggrz.benutzer.controler.BenutzerControler.anlegenBenutzer(BenutzerControler.java:44) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.el.parser.AstValue.invoke(AstValue.java:131) at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276) at org.apache.jasper.el.JspMethodExpression.invoke(JspMethodExpression.java:68) at javax.faces.component._MethodExpressionToMethodBinding.invoke(_MethodExpressionToMethodBinding.java:75) at org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:54) at javax.faces.component.UICommand.broadcast(UICommand.java:121) at javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:292) at javax.faces.component.UIViewRoot.process(UIViewRoot.java:209)
[jira] Commented: (GERONIMO-3928) Exception on stopping server after sending a non persistent message
[ https://issues.apache.org/jira/browse/GERONIMO-3928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579740#action_12579740 ] David Jencks commented on GERONIMO-3928: Is there any incorrect behavior or is there just an annoying stack trace? Exception on stopping server after sending a non persistent message --- Key: GERONIMO-3928 URL: https://issues.apache.org/jira/browse/GERONIMO-3928 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ Reporter: Anish Pathadan Fix For: 2.2 Attachments: sendMessage.war Hi, I am getting the following exception on stopping the server after sending a non persistent message to a queue. I have attached a test case for this. Steps to reproduce the issue:- 1).Deploy the attached sendMessage.war 2).Access http://localhost:8080/sendMessage/SendMessage to send a non persistent message. 3).Stop the server using Ctrl-C Following is the stack trace 07:39:08,828 WARN [ActiveMQManagedConnection] Connection failed: javax.jms.JMSE xception: java.io.EOFException 07:39:08,843 WARN [GeronimoConnectionEventListener] connectionErrorOccurred cal led with null javax.jms.JMSException: java.io.EOFException at org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSuppo rt.java:46) at org.apache.activemq.ActiveMQConnection.onAsyncException(ActiveMQConne ction.java:1519) at org.apache.activemq.ActiveMQConnection.onException(ActiveMQConnection .java:1535) at org.apache.activemq.transport.TransportFilter.onException(TransportFi lter.java:96) at org.apache.activemq.transport.ResponseCorrelator.onException(Response Correlator.java:114) at org.apache.activemq.transport.TransportFilter.onException(TransportFi lter.java:96) at org.apache.activemq.transport.TransportFilter.onException(TransportFi lter.java:96) at org.apache.activemq.transport.WireFormatNegotiator.onException(WireFo rmatNegotiator.java:147) at org.apache.activemq.transport.InactivityMonitor.onException(Inactivit yMonitor.java:150) at org.apache.activemq.transport.TransportSupport.onException(TransportS upport.java:97) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java: 150) at java.lang.Thread.run(Thread.java:595) Caused by: java.io.EOFException at java.io.DataInputStream.readInt(DataInputStream.java:358) at org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat. java:267) at org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTranspo rt.java:156) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java: 136) ... 1 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3928) Exception on stopping server after sending a non persistent message
[ https://issues.apache.org/jira/browse/GERONIMO-3928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579745#action_12579745 ] Anish Pathadan commented on GERONIMO-3928: -- There is no incorrect behaviour as far as I could observe.I had send some non persistant messages and restarted the server.After restart the messages are no more in the queue.It works as expected. Only annoying thing is the exception on stopping the server. Exception on stopping server after sending a non persistent message --- Key: GERONIMO-3928 URL: https://issues.apache.org/jira/browse/GERONIMO-3928 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ Reporter: Anish Pathadan Fix For: 2.2 Attachments: sendMessage.war Hi, I am getting the following exception on stopping the server after sending a non persistent message to a queue. I have attached a test case for this. Steps to reproduce the issue:- 1).Deploy the attached sendMessage.war 2).Access http://localhost:8080/sendMessage/SendMessage to send a non persistent message. 3).Stop the server using Ctrl-C Following is the stack trace 07:39:08,828 WARN [ActiveMQManagedConnection] Connection failed: javax.jms.JMSE xception: java.io.EOFException 07:39:08,843 WARN [GeronimoConnectionEventListener] connectionErrorOccurred cal led with null javax.jms.JMSException: java.io.EOFException at org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSuppo rt.java:46) at org.apache.activemq.ActiveMQConnection.onAsyncException(ActiveMQConne ction.java:1519) at org.apache.activemq.ActiveMQConnection.onException(ActiveMQConnection .java:1535) at org.apache.activemq.transport.TransportFilter.onException(TransportFi lter.java:96) at org.apache.activemq.transport.ResponseCorrelator.onException(Response Correlator.java:114) at org.apache.activemq.transport.TransportFilter.onException(TransportFi lter.java:96) at org.apache.activemq.transport.TransportFilter.onException(TransportFi lter.java:96) at org.apache.activemq.transport.WireFormatNegotiator.onException(WireFo rmatNegotiator.java:147) at org.apache.activemq.transport.InactivityMonitor.onException(Inactivit yMonitor.java:150) at org.apache.activemq.transport.TransportSupport.onException(TransportS upport.java:97) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java: 150) at java.lang.Thread.run(Thread.java:595) Caused by: java.io.EOFException at java.io.DataInputStream.readInt(DataInputStream.java:358) at org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat. java:267) at org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTranspo rt.java:156) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java: 136) ... 1 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Exception starting org.apache.geronimo.configs/wadi-clustering/2.0.2/car in Geronimo Jetty 2.0.2
Upon starting the org.apache.geronimo.configs/wadi-clustering/2.0.2/car in Geronimo Jetty 2.0.2 distribution, I got an NCDFE error. Has anyone hit this error? Stack trace is given below. 12:13:38,750 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: bstractName=org.apache.geronimo.configs /wadi-clustering/2.0.2/car?ServiceModule=org.apache.geronimo.configs /wadi-clustering/2.0.2/car,j2eeType=GBean,name=DefaultDispatcherHolder java.lang.NoClassDefFoundError: EDU/oswego/cs/dl/util/concurrent/TimeoutExceptio n at org.apache.geronimo.clustering.wadi.TribesDispatcherHolder.doStart(Tr ibesDispatcherHolder.java:69) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance (GBeanI nstance.java:996) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:268) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start (GBeanInsta nceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(G BeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive (GBeanI nstance.java:553) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean (Basi cKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguratio nGBeans(ConfigurationUtil.java:448) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(Ke rnelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:530) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:511) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastCla ssByCGLIB$$ce77a924.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethod Invoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperatio n.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance. java:830) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke( RawInvoker.java:5 7) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke (RawOperat ionInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept (Pro xyMethodInterceptor.java:96) at org.apache.geronimo.kernel.config.EditableConfigurationManager$$Enhan cerByCGLIB$$2c64bbf.startConfiguration(generated) at org.apache.geronimo.console.configmanager.ConfigManagerPortlet.proces sAction(ConfigManagerPortlet.java:208) 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:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java :153) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java :487 ) at org.apache.geronimo.jetty6.InternalJettyServletHolder.handle (Internal JettyServletHolder.java:65) at org.mortbay.jetty.servlet.ServletHandler.handle( ServletHandler.java:3 62) at org.mortbay.jetty.security.SecurityHandler.handle( SecurityHandler.jav a:216) at org.apache.geronimo.jetty6.handler.JettySecurityHandler.handle (JettyS ecurityHandler.java:114) at org.mortbay.jetty.servlet.SessionHandler.handle( SessionHandler.java:1 81) at org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle(Th readClassloaderHandler.java:46) at org.apache.geronimo.jetty6.handler.InstanceContextHandler.handle (Inst anceContextHandler.java:67) at org.apache.geronimo.jetty6.handler.UserTransactionHandler.handle (User TransactionHandler.java:48) at org.mortbay.jetty.handler.ContextHandler.handle( ContextHandler.java:7 12) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java :405) at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:192) 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:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at
Geronimo Tomcat 2.1 clustering - application deployment problems
I have attempted the steps from http://cwiki.apache.org/GMOxDEV/clustering-configuration-for-jetty.html with Geronimo Tomcat 2.1. even though *org.apache.geronimo.configs/jetty6-clustering-builder-wadi//car *is running, deploying the sample application resulted in an error given below: xml problem for web app . org.apache.geronimo.common.DeploymentException: xml problem for web app . at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.getTomcatWebApp(TomcatModuleBuilder.java:314) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.createModule(TomcatModuleBuilder.java:207) at org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.createModule(AbstractWebModuleBuilder.java:179) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.createModule(SwitchingModuleBuilder.java:94) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:307) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:226) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:133) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61) at java.lang.Thread.run(Thread.java:595) Caused by: org.apache.xmlbeans.XmlException: Invalid deployment descriptor: errors: error: cvc-complex-type.2.4a: Expected elements '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/application-2.0 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.2 [EMAIL PROTECTED]://java.sun.com/xml/ns/persistence' instead of '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1' here Descriptor: xml-fragment xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.2; xmlns:tom=http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1; dep:environment dep:moduleId dep:groupIdorg.codehaus.wadi/dep:groupId dep:artifactIdwadi-webapp/dep:artifactId dep:version2.0M3-SNAPSHOT/dep:version dep:typewar/dep:type /dep:moduleId /dep:environment tom:clustering-wadi/ /xml-fragment at org.apache.geronimo.deployment.xmlbeans.XmlBeansUtil.validateDD(XmlBeansUtil.java:187) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.getTomcatWebApp(TomcatModuleBuilder.java:308) ... 17 more The deployment plan I am using is: ?xml version=1.0 encoding=UTF-8? web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.2; environment moduleId groupIdorg.codehaus.wadi/groupId artifactIdwadi-webapp/artifactId version2.0M3-SNAPSHOT/version typewar/type /moduleId /environment clustering-wadi/ /web-app
Geronimo Jetty 2.1 clustering - Testing clustering
I have attempted the steps from http://cwiki.apache.org/GMOxDEV/clustering-configuration-for-jetty.html with Geronimo Jetty 2.1. I was able to get a cluster with two nodes running and deploy the sample application too. But, when I access http://localhost:8090/wadi-webapp-2.0M3-20070121.115809-5/index.jsp , the page does not show any numbers in the boxes as shown in the article. What am I doing wrong?
Re: Geronimo Tomcat 2.1 clustering - application deployment problems
Hello, This is a problem with the deployment descriptor. You name of the clustering substitution group element is tomcat-clustering-wadi for tomcat and not clustering-wadi. As a matter of fact, I have on my to- do list a task to refactor substitution group element builders for Tomcat, Jetty and OpenEJB so that all of them offer the same external structure to end-users. Here is an updated DD: ?xml version=1.0 encoding=UTF-8? web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.2; environment moduleId groupIdorg.codehaus.wadi/groupId artifactIdwadi-webapp/artifactId version2.0M3-SNAPSHOT/version typewar/type /moduleId /environment tomcat-clustering-wadi/ -- this is the correct element name to use for tomcat. /web-app Thanks, Gianny On 18/03/2008, at 9:57 PM, Vamsavardhana Reddy wrote: I have attempted the steps from http://cwiki.apache.org/GMOxDEV/ clustering-configuration-for-jetty.html with Geronimo Tomcat 2.1. even though org.apache.geronimo.configs/jetty6-clustering-builder- wadi//car is running, deploying the sample application resulted in an error given below: error: cvc-complex-type.2.4a: Expected elements 'context- [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 work- [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/application-2.0 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 cross- [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/ tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/ tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/ web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/ j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/ j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/ j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]:// geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]:// geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]:// geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]:// geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]:// geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]:// geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]:// geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]:// geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]:// geronimo.apache.org/xml/ns/deployment-1.2 [EMAIL PROTECTED]:// java.sun.com/xml/ns/persistence' instead of '[EMAIL PROTECTED]:// geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1' here The deployment plan I am using is: ?xml version=1.0 encoding=UTF-8? web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web/ tomcat-1.2 environment moduleId groupIdorg.codehaus.wadi/groupId artifactIdwadi-webapp/artifactId version2.0M3-SNAPSHOT/version typewar/type /moduleId /environment clustering-wadi/ /web-app
[jira] Commented: (GERONIMO-3843) Plan creator fails to create plan and to deploy
[ https://issues.apache.org/jira/browse/GERONIMO-3843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579826#action_12579826 ] Shiva Kumar H R commented on GERONIMO-3843: --- Plan Creator is calling following piece of code: DeploymentFactory factory = new DeploymentFactoryWithKernel(PortletManager.getKernel()); DeploymentManager deploymentManager = factory.getDeploymentManager(deployer:geronimo:jmx, null, null); DeploymentConfiguration deploymentConfiguration = deploymentManager.createConfiguration(webDeployable); The last one - call to JMXDeploymentManager.createConfiguration() is resulting in following error: ERROR [DisplayPlanHandler] No configurer for module type: war registered javax.enterprise.deploy.spi.exceptions.InvalidModuleException: No configurer for module type: war registered at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createConfiguration(JMXDeploymentManager.java:311) at org.apache.geronimo.console.configcreator.JSR88_Util.createDeploymentPlan(JSR88_Util.java:300) This error happens only with Jetty and works correctly with Tomcat. Plan creator fails to create plan and to deploy --- Key: GERONIMO-3843 URL: https://issues.apache.org/jira/browse/GERONIMO-3843 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.1 Environment: Geronimo 2.1 - Jetty distribution. Reporter: Hernan Cunico Assignee: Shiva Kumar H R Fix For: 2.1.1 The plan creator fails to create the deployment plan and consequently to deploy the app in the Jetty distribution. This feature works OK in Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Geronimo Jetty 2.1 clustering - Testing clustering
Hi, There was a typo in the way node2 was started. It used to be: geronimo/start-server -D node.name=node2 -G server.name=yellow -b It should actually be: geronimo/start-server -D node.name=yellow -G server.name=node2 -b Though, I am not sure that this can explain the problem. What does the page show? FWIW, I have just set-up a two node cluster and it works fine. Thanks, Gianny On 18/03/2008, at 10:13 PM, Vamsavardhana Reddy wrote: I have attempted the steps from http://cwiki.apache.org/GMOxDEV/ clustering-configuration-for-jetty.html with Geronimo Jetty 2.1. I was able to get a cluster with two nodes running and deploy the sample application too. But, when I access http://localhost:8090/ wadi-webapp-2.0M3-20070121.115809-5/index.jsp , the page does not show any numbers in the boxes as shown in the article. What am I doing wrong?
[jira] Commented: (GERONIMO-3354) Exception thrown by MDB involved in XA transaction
[ https://issues.apache.org/jira/browse/GERONIMO-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579833#action_12579833 ] Donald Woods commented on GERONIMO-3354: Can you also apply AMQ-1438 to their 4.1 branch, as we have had a couple users hit this one, too. Exception thrown by MDB involved in XA transaction -- Key: GERONIMO-3354 URL: https://issues.apache.org/jira/browse/GERONIMO-3354 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ, OpenEJB, transaction manager Affects Versions: 2.0, 2.0.x, 2.1 Environment: Geronimo 2.0 (tomcat) build from 07/24 (http://people.apache.org/~prasad/binaries/20070724/) DayTrader 1.2 or 2.0 (any runtime mode) with asyn order processing enabled Reporter: Christopher James Blythe Assignee: David Jencks Priority: Critical Fix For: 2.0.x, 2.1.1 The async order processing in DayTrader uses the TradeBrokerMDB to handle complete order operations whenever a buy or sell is performed. When these transactions are executed, the transaction appears to complete; however, the following exception is written to the console and log file. According to Jencks, this seems to indicate that the tx info is not being written to the transaction log. 22:59:18,421 ERROR [Transaction] Please correct the integration and supply a NamedXAResource java.lang.IllegalStateException : Cannot log transactions as [EMAIL PROTECTED] is not a NamedXAResource. at org.apache.geronimo.transaction.manager.TransactionImpl$TransactionBranch.getResourceName(TransactionImpl.java :697) at org.apache.geronimo.transaction.log.HOWLLog.prepare(HOWLLog.java:254) at org.apache.geronimo.transaction.log.HOWLLog$$FastClassByCGLIB$$7315be2e.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke (FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:830) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept (ProxyMethodInterceptor.java:96) at org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$ba0af455.prepare(generated) at org.apache.geronimo.transaction.manager.TransactionImpl.internalPrepare(TransactionImpl.java :444) at org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:316) at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:238) at org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:139) at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:75) at org.apache.openejb.core.mdb.MdbContainer.afterDelivery (MdbContainer.java:375) at org.apache.openejb.core.mdb.EndpointHandler.afterDelivery(EndpointHandler.java:274) at org.apache.openejb.core.mdb.EndpointHandler.invoke(EndpointHandler.java:164) at $Proxy36.afterDelivery(Unknown Source) at org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.afterDelivery(MessageEndpointProxy.java:126) at org.apache.activemq.ra.MessageEndpointProxy.afterDelivery(MessageEndpointProxy.java:65) at org.apache.activemq.ra.ServerSessionImpl.afterDelivery(ServerSessionImpl.java:216) at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:751) at org.apache.activemq.ra.ServerSessionImpl.run( ServerSessionImpl.java:165) at org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.java:290) at org.apache.geronimo.connector.work.pool.NamedRunnable.run(NamedRunnable.java:32) at org.apache.geronimo.pool.ThreadPool$1.run (ThreadPool.java:201) at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:331) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:801) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Geronimo Jetty 2.1 clustering - Testing clustering
Hi, Also, I just deployed a new 2.0-SNAPSHOT which defines a context-root and use standard (versus delta) replication. You may want to grab it as the context root is less cryptic with this latest version. Thanks, Gianny On 19/03/2008, at 12:08 AM, Gianny Damour wrote: Hi, There was a typo in the way node2 was started. It used to be: geronimo/start-server -D node.name=node2 -G server.name=yellow -b It should actually be: geronimo/start-server -D node.name=yellow -G server.name=node2 -b Though, I am not sure that this can explain the problem. What does the page show? FWIW, I have just set-up a two node cluster and it works fine. Thanks, Gianny On 18/03/2008, at 10:13 PM, Vamsavardhana Reddy wrote: I have attempted the steps from http://cwiki.apache.org/GMOxDEV/ clustering-configuration-for-jetty.html with Geronimo Jetty 2.1. I was able to get a cluster with two nodes running and deploy the sample application too. But, when I access http://localhost:8090/ wadi-webapp-2.0M3-20070121.115809-5/index.jsp , the page does not show any numbers in the boxes as shown in the article. What am I doing wrong?
Re: Exception starting org.apache.geronimo.configs/wadi-clustering/2.0.2/car in Geronimo Jetty 2.0.2
Hello, Nope. It seems wadi-clustering dependencies have been cleaned up too much for the 2.0.2 distribution. I do not think there is an easy work- around, except the issue or a 2.0.3 wadi-clustering configuration with the right runtime dependencies. Thanks, Gianny On 18/03/2008, at 9:42 PM, Vamsavardhana Reddy wrote: Upon starting the org.apache.geronimo.configs/wadi-clustering/2.0.2/ car in Geronimo Jetty 2.0.2 distribution, I got an NCDFE error. Has anyone hit this error? Stack trace is given below. 12:13:38,750 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: bstractName=org.apache.geronimo.configs/wadi-clustering/2.0.2/car? ServiceModule=org.apache.geronimo.configs/wadi-clustering/2.0.2/ car,j2eeType=GBean,name=DefaultDispatcherHolder java.lang.NoClassDefFoundError: EDU/oswego/cs/dl/util/concurrent/ TimeoutExceptio n at org.apache.geronimo.clustering.wadi.TribesDispatcherHolder.doStart(Tr ibesDispatcherHolder.java:69) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI nstance.java:996) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:268) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(G BeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanI nstance.java:553) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(Basi cKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguratio nGBeans(ConfigurationUtil.java:448) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(Ke rnelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:530) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:511) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastCla ssByCGLIB$$ce77a924.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod Invoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperatio n.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance. java:830) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke (RawInvoker.java:5 7) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperat ionInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(Pro xyMethodInterceptor.java:96) at org.apache.geronimo.kernel.config.EditableConfigurationManager$$Enhan cerByCGLIB$$2c64bbf.startConfiguration(generated) at org.apache.geronimo.console.configmanager.ConfigManagerPortlet.proces sAction(ConfigManagerPortlet.java:208) 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: 693) at javax.servlet.http.HttpServlet.service(HttpServlet.java: 806) at org.apache.pluto.core.PortletServlet.service (PortletServlet.java:153) at org.mortbay.jetty.servlet.ServletHolder.handle (ServletHolder.java:487 ) at org.apache.geronimo.jetty6.InternalJettyServletHolder.handle(Internal JettyServletHolder.java:65) at org.mortbay.jetty.servlet.ServletHandler.handle (ServletHandler.java:3 62) at org.mortbay.jetty.security.SecurityHandler.handle (SecurityHandler.jav a:216) at org.apache.geronimo.jetty6.handler.JettySecurityHandler.handle(JettyS ecurityHandler.java:114) at org.mortbay.jetty.servlet.SessionHandler.handle (SessionHandler.java:1 81) at org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle(Th readClassloaderHandler.java:46) at org.apache.geronimo.jetty6.handler.InstanceContextHandler.handle(Inst anceContextHandler.java:67) at org.apache.geronimo.jetty6.handler.UserTransactionHandler.handle(User TransactionHandler.java:48) at org.mortbay.jetty.handler.ContextHandler.handle (ContextHandler.java:7 12) at org.mortbay.jetty.webapp.WebAppContext.handle (WebAppContext.java:405) at org.mortbay.jetty.servlet.Dispatcher.include (Dispatcher.java:192) 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
Re: Fw: [VOTE]: Pluto 1.1.5 Release
Donald Woods wrote: Should we investigate the below release for trunk and a future 2.1.2 release? We need to replace what we are currently using with something official. The code that we used to build our private pluto image was formerly the Pluto trunk which had a version 1.2.0-SNAPSHOT. That trunk was abandoned and some content from it was integrated with the 1.1.* branch along with the JSR 286 support. Hopefully, they pulled along the spring based portal driver from the old trunk upon which we are dependent. The only way to find out is to start to dig in and give it a shot. Joe
[jira] Closed: (GERONIMO-3923) Login established without tomcat notification
[ https://issues.apache.org/jira/browse/GERONIMO-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralf Baumhof closed GERONIMO-3923. -- Resolution: Invalid Works as designed Login established without tomcat notification - Key: GERONIMO-3923 URL: https://issues.apache.org/jira/browse/GERONIMO-3923 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0.2, 2.1 Environment: Windows, Linux Reporter: Ralf Baumhof Assignee: David Jencks I have set up a security realm (sql realm). In web.xml tomcat is advised to keep a watch an all pages lying in directory /pages. I use a form login. If the login form is designed to use j_security_check action, the servlet authentication works. The first try to access a page in /pages/* area leads to the login form and after successful login the page is diplayed. However, the application has strong security impacts, so we would prefer to use a JSF backing bean which performs a LoginContext method for login to geronimo. This also works. The login succeeds and i get a principal. But the application is not logged in at tomcat webcontainer. It's not possible to access the pages in /pages/* area. Is this a bug or a feature What must be done if one want's to use the LoginContext way??? According to the geronimo wiki i suggest that it should work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: geronimo-web.xml for geronimo 2.0.1
Hi Remya, here are a couple of tips for understanding the deployment plans Schema documentation for geronimo-web.xml http://geronimo.apache.org/schemas-2.1/docs/geronimo-web-2.0.1.xsd.html If you want to try Geronimo 2.1 (which I would encourage you to do so) you can give a shot to the deployment plan wizard (http://cwiki.apache.org/GMOxDOC21/deployment-plan-wizard.html ). It will create a deployment plan for you at deployment time, if you are using annotations it's even easier! Back to your specific quesitons, environment, moduleId and artifactId. These are how you uniquely identify your application (or any other resource) within Geronimo. moduleId encloses groupId, artifactId, version and type. These ultimately identify the resource in the repository. moduleId is defined within the environment tag which also encloses the dependencies your application may have. For instance a database connection pool, you'd be adding that dependency there, all enclosed within the appropriate dependenciesdependency tags. The deployment plan wizard link I included above provides more examples on this. The deployment plans documentation is still in progress for Geronimo 2.1 ( http://cwiki.apache.org/GMOxDOC21/deployment-plans.html ), you may still find useful docs from previous releases with more details on the plans ( http://cwiki.apache.org/GMOxDOC12/geronimo-webxml.html ) HTH Cheers! Hernan remya wrote: I am a beginner with Geronimo and would like to know the different steps that needs to be followed while writing my first geronimo-web.xml While I was searching for some samples on the net, I came across several elements in geronimo-web.xml, which was quite confusing to me, like environment, moduleId and artifactId. I had mentioned context-root for my application, but is that alone not enough for my application to be deployed and run? Please do help me in this regard with a suitable reply. Thanks Remya
DeployManager in G-Jetty says No configurer for module type: war registered
I am calling below code from within PlanCreator: DeploymentFactory factory = new DeploymentFactoryWithKernel( PortletManager.getKernel()); DeploymentManager deploymentManager = factory.getDeploymentManager(deployer:geronimo:inVM, null, null); DeploymentConfiguration deploymentConfiguration = deploymentManager.createConfiguration(webDeployable); And this is failing in Geronimo-Jetty by saying (the same code however works in Geronimo-Tomcat): ERROR [DisplayPlanHandler] No configurer for module type: war registered javax.enterprise.deploy.spi.exceptions.InvalidModuleException: No configurer for module type: war registered at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createConfiguration (JMXDeploymentManager.java:311) at org.apache.geronimo.console.configcreator.JSR88_Util.createDeploymentPlan (JSR88_Util.java:300) Am I missing some configuration? -- Thanks, Shiva
Re: DeployManager in G-Jetty says No configurer for module type: war registered
On Mar 18, 2008, at 6:58 AM, Shiva Kumar H R wrote: I am calling below code from within PlanCreator: DeploymentFactory factory = new DeploymentFactoryWithKernel (PortletManager.getKernel()); DeploymentManager deploymentManager = factory.getDeploymentManager(deployer:geronimo:inVM, null, null); DeploymentConfiguration deploymentConfiguration = deploymentManager.createConfiguration(webDeployable); And this is failing in Geronimo-Jetty by saying (the same code however works in Geronimo-Tomcat): ERROR [DisplayPlanHandler] No configurer for module type: war registered javax.enterprise.deploy.spi.exceptions.InvalidModuleException: No configurer for module type: war registered at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createC onfiguration(JMXDeploymentManager.java:311) at org.apache.geronimo.console.configcreator.JSR88_Util.createDeploymentP lan(JSR88_Util.java:300) Am I missing some configuration? which g version? AFAIK this stuff is never tested so we might have left something out inadvertently. I would look into the configurations started in the jsr88 configuration and figure out if they are started in either of the big servers or if not if the gbeans there are present somewhere else as well. hope this helps... david jencks -- Thanks, Shiva
[jira] Created: (GERONIMO-3929) Load server implementation classes and it's libraries using a private classloader
Load server implementation classes and it's libraries using a private classloader - Key: GERONIMO-3929 URL: https://issues.apache.org/jira/browse/GERONIMO-3929 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: kernel Affects Versions: 2.1.1, 2.2 Reporter: syvalta Currectly lots of geronimo-internal libraries (asm, cglib, commons-logging, log4j etc.) are visible to the applications. This causes problems with version mismatches, if the application includes different version of the same jar. The most elegant solution would be to have only the spec jars visible to the application, and the actual implementation (and its libraries) loaded by a private classloader, which would be a distinct child of the spec-classloader, and thus not visible to the applications. In my knowledge this kind of strategy is implemented at least in Glassfish. I know there are workarounds to hide classes or use inverse classloading, but it would be nice to be able to deploy as many applications as possible without any additional tweaking. And if every application server would do that, things would be so much easier... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Geronimo Tomcat 2.1 clustering - application deployment problems
Thanks Gianny. I will try with the new DD and get back if there is any problem. ++Vamsi On Tue, Mar 18, 2008 at 6:11 PM, Gianny Damour [EMAIL PROTECTED] wrote: Hello, This is a problem with the deployment descriptor. You name of the clustering substitution group element is tomcat-clustering-wadi for tomcat and not clustering-wadi. As a matter of fact, I have on my to- do list a task to refactor substitution group element builders for Tomcat, Jetty and OpenEJB so that all of them offer the same external structure to end-users. Here is an updated DD: ?xml version=1.0 encoding=UTF-8? web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.2; environment moduleId groupIdorg.codehaus.wadi/groupId artifactIdwadi-webapp/artifactId version2.0M3-SNAPSHOT/version typewar/type /moduleId /environment tomcat-clustering-wadi/ -- this is the correct element name to use for tomcat. /web-app Thanks, Gianny On 18/03/2008, at 9:57 PM, Vamsavardhana Reddy wrote: I have attempted the steps from http://cwiki.apache.org/GMOxDEV/ clustering-configuration-for-jetty.html with Geronimo Tomcat 2.1. even though org.apache.geronimo.configs/jetty6-clustering-builder- wadi//car is running, deploying the sample application resulted in an error given below: error: cvc-complex-type.2.4a: Expected elements 'context- [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 work- [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/application-2.0 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 cross- [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/ tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/ tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/ web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/ j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/ j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/ j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]:// geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]:// geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]:// geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]:// geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]:// geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]:// geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]:// geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]:// geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]:// geronimo.apache.org/xml/ns/deployment-1.2 [EMAIL PROTECTED]:// java.sun.com/xml/ns/persistence' instead of '[EMAIL PROTECTED]:// geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1' here The deployment plan I am using is: ?xml version=1.0 encoding=UTF-8? web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web/ tomcat-1.2 environment moduleId groupIdorg.codehaus.wadi/groupId artifactIdwadi-webapp/artifactId version2.0M3-SNAPSHOT/version typewar/type /moduleId /environment clustering-wadi/ /web-app
[jira] Commented: (GERONIMO-3921) getContextRoot() returns forward slash rather than empty string for apps deployed to root context
[ https://issues.apache.org/jira/browse/GERONIMO-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579917#action_12579917 ] Donald Woods commented on GERONIMO-3921: Committed to branches/2.0 as Rev638438 getContextRoot() returns forward slash rather than empty string for apps deployed to root context - Key: GERONIMO-3921 URL: https://issues.apache.org/jira/browse/GERONIMO-3921 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1, 2.1.1, 2.2 Reporter: Jay D. McHugh Assignee: Jay D. McHugh An app deployed to the root context should have returned by getContextRoot() - On Tomcat, we are returning /. dcherk wrote: I am deploying my war file into the root context with the following deployment plan: -- web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-2.0; xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.2; xmlns:naming=http://geronimo.apache.org/xml/ns/naming-1.2; xmlns:security=http://geronimo.apache.org/xml/ns/security-1.2; ... context-root/context-root ... /web-app -- The application starts up properly, and responds on http://localhost, as expected. However, when I examine request.getContextPath(), I get a forward slash: /. This is incorrect, as far as I can tell. According to the API (http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServletRequest.html#getContextPath()): -- For servlets in the default (root) context, this method [HttpServletRequest.html.getContextPath()] returns . -- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r638053 - in /geronimo/server/trunk/plugins: ./ derby/ derby/src/ derby/src/main/ derby/src/main/plan/ system-database/geronimo-derby/ system-database/geronimo-timer/ system-database/s
Generally the contents of plugins are groups of plugins rather than sincle plugins. Wouldn't this be more appropriate inside system- database? Also, I'm pretty sure geronimo-timer is obsolete with openejb3. It would be great if someone would check and delete it if it isn't used anywhere. thanks david jencks On Mar 17, 2008, at 1:13 PM, [EMAIL PROTECTED] wrote: Author: dwoods Date: Mon Mar 17 13:13:46 2008 New Revision: 638053 URL: http://svn.apache.org/viewvc?rev=638053view=rev Log: GERONIMO-3926 Add a Derby config/plugin for easier inclusion of Derby jars without a system-database depend Added: geronimo/server/trunk/plugins/derby/ geronimo/server/trunk/plugins/derby/LICENSE.txt (with props) geronimo/server/trunk/plugins/derby/NOTICE.txt (with props) geronimo/server/trunk/plugins/derby/pom.xml (with props) geronimo/server/trunk/plugins/derby/src/ geronimo/server/trunk/plugins/derby/src/main/ geronimo/server/trunk/plugins/derby/src/main/plan/ geronimo/server/trunk/plugins/derby/src/main/plan/plan.xml (with props) Modified: geronimo/server/trunk/plugins/pom.xml geronimo/server/trunk/plugins/system-database/geronimo-derby/ pom.xml geronimo/server/trunk/plugins/system-database/geronimo-timer/ pom.xml geronimo/server/trunk/plugins/system-database/system-database/ pom.xml Added: geronimo/server/trunk/plugins/derby/LICENSE.txt URL: http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/ derby/LICENSE.txt?rev=638053view=auto == --- geronimo/server/trunk/plugins/derby/LICENSE.txt (added) +++ geronimo/server/trunk/plugins/derby/LICENSE.txt Mon Mar 17 13:13:46 2008 @@ -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
Cant find geronimo adapter v2.1 when install GEP with WTP
Hi lists, i have install the eclipse into my machine by following these steps 1. Download and unzip the eclipse classic version into this path /home/red/eclipse 2. Download the WTP tools and unzip and install in /home/red/eclipse 3. Next i run the eclipse. Now i trying to install the GEP with the WTP by doing this: 1. Add a new server 2. Trying to find the server adapter by click on the 'Download additional server adapters' 3. In the list i cannot find the Geronimo server adaptor v2.1 I am using geronimo version 2.1. can i use the version 2.1 adapter? i have upload the picture of the server adapter listed in eclipse. Thanks in advance http://www.nabble.com/file/p16125735/serverAdapter.jpg serverAdapter.jpg -- View this message in context: http://www.nabble.com/Cant-find-geronimo-adapter-v2.1-when-install-GEP-with-WTP-tp16125735s134p16125735.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: DeployManager in G-Jetty says No configurer for module type: war registered
Summarizing IRC discussion with DJencks below: 1) In extracted server: var/config/jsr88-configurer-config.xml lists a bunch of modules including module name=org.apache.geronimo.configs /jsr88-war-configurer/2.2-SNAPSHOT/car/ 2) In source tree: \plugins\j2ee\jsr88-war-configurer's plan.xml - it only has one GBean gbean name=WARConfigurer class= org.apache.geronimo.web.deployment.WARConfigurer/ 3) tomcat6-deployer's plan.xml has gbean name=Tomcat6WARConfigurer class=org.apache.geronimo.web.deployment.WARConfigurer/ 4) However jetty6-deployer's plan.xml doesn't have that WARConfigurer gbean, and that is the missing configuration. -- Thanks, Shiva On Tue, Mar 18, 2008 at 9:07 PM, David Jencks [EMAIL PROTECTED] wrote: On Mar 18, 2008, at 6:58 AM, Shiva Kumar H R wrote: I am calling below code from within PlanCreator: DeploymentFactory factory = new DeploymentFactoryWithKernel (PortletManager.getKernel()); DeploymentManager deploymentManager = factory.getDeploymentManager(deployer:geronimo:inVM, null, null); DeploymentConfiguration deploymentConfiguration = deploymentManager.createConfiguration(webDeployable); And this is failing in Geronimo-Jetty by saying (the same code however works in Geronimo-Tomcat): ERROR [DisplayPlanHandler] No configurer for module type: war registered javax.enterprise.deploy.spi.exceptions.InvalidModuleException: No configurer for module type: war registered at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createC onfiguration(JMXDeploymentManager.java:311) at org.apache.geronimo.console.configcreator.JSR88_Util.createDeploymentP lan(JSR88_Util.java:300) Am I missing some configuration? which g version? AFAIK this stuff is never tested so we might have left something out inadvertently. I would look into the configurations started in the jsr88 configuration and figure out if they are started in either of the big servers or if not if the gbeans there are present somewhere else as well. hope this helps... david jencks -- Thanks, Shiva
[jira] Resolved: (GERONIMO-3843) Plan creator fails to create plan and to deploy
[ https://issues.apache.org/jira/browse/GERONIMO-3843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R resolved GERONIMO-3843. --- Resolution: Fixed Plan creator fails to create plan and to deploy --- Key: GERONIMO-3843 URL: https://issues.apache.org/jira/browse/GERONIMO-3843 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.1 Environment: Geronimo 2.1 - Jetty distribution. Reporter: Hernan Cunico Assignee: Shiva Kumar H R Fix For: 2.1.1 The plan creator fails to create the deployment plan and consequently to deploy the app in the Jetty distribution. This feature works OK in Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3843) Plan creator fails to create plan and to deploy
[ https://issues.apache.org/jira/browse/GERONIMO-3843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579955#action_12579955 ] Shiva Kumar H R commented on GERONIMO-3843: --- As hinted by David Jencks, this turned out to be a missing gbean for org.apache.geronimo.web.deployment.WARConfigurer in jetty6-deployer. Completed: At revision: 638475 Plan creator fails to create plan and to deploy --- Key: GERONIMO-3843 URL: https://issues.apache.org/jira/browse/GERONIMO-3843 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.1 Environment: Geronimo 2.1 - Jetty distribution. Reporter: Hernan Cunico Assignee: Shiva Kumar H R Fix For: 2.1.1 The plan creator fails to create the deployment plan and consequently to deploy the app in the Jetty distribution. This feature works OK in Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: geronimo-web.xml for geronimo 2.0.1
Thanks a lot for the reply! But, while creating our application, I am afraid we didn't follow such a directory structure that is required by the environment, moduleId and artifactId. So, using some values for these tags, provide with errors in the deployment or while running the application. It is an already existing application in tomcat, and we are planning to rebuild it into Geronimo 2.0. Can you suggest what may help me here? Thanks Remya Hernan Cunico wrote: Hi Remya, here are a couple of tips for understanding the deployment plans Schema documentation for geronimo-web.xml http://geronimo.apache.org/schemas-2.1/docs/geronimo-web-2.0.1.xsd.html If you want to try Geronimo 2.1 (which I would encourage you to do so) you can give a shot to the deployment plan wizard (http://cwiki.apache.org/GMOxDOC21/deployment-plan-wizard.html ). It will create a deployment plan for you at deployment time, if you are using annotations it's even easier! Back to your specific quesitons, environment, moduleId and artifactId. These are how you uniquely identify your application (or any other resource) within Geronimo. moduleId encloses groupId, artifactId, version and type. These ultimately identify the resource in the repository. moduleId is defined within the environment tag which also encloses the dependencies your application may have. For instance a database connection pool, you'd be adding that dependency there, all enclosed within the appropriate dependenciesdependency tags. The deployment plan wizard link I included above provides more examples on this. The deployment plans documentation is still in progress for Geronimo 2.1 ( http://cwiki.apache.org/GMOxDOC21/deployment-plans.html ), you may still find useful docs from previous releases with more details on the plans ( http://cwiki.apache.org/GMOxDOC12/geronimo-webxml.html ) HTH Cheers! Hernan remya wrote: I am a beginner with Geronimo and would like to know the different steps that needs to be followed while writing my first geronimo-web.xml While I was searching for some samples on the net, I came across several elements in geronimo-web.xml, which was quite confusing to me, like environment, moduleId and artifactId. I had mentioned context-root for my application, but is that alone not enough for my application to be deployed and run? Please do help me in this regard with a suitable reply. Thanks Remya -- View this message in context: http://www.nabble.com/geronimo-web.xml-for-geronimo-2.0.1-tp16111044s134p16127284.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[jira] Commented: (GERONIMO-3843) Plan creator fails to create plan and to deploy
[ https://issues.apache.org/jira/browse/GERONIMO-3843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579967#action_12579967 ] Joe Bohn commented on GERONIMO-3843: Shiva, Can you integrate this fix back into branches/2.1 so that it makes it into 2.1.1? Thanks, Joe Plan creator fails to create plan and to deploy --- Key: GERONIMO-3843 URL: https://issues.apache.org/jira/browse/GERONIMO-3843 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.1 Environment: Geronimo 2.1 - Jetty distribution. Reporter: Hernan Cunico Assignee: Shiva Kumar H R Fix For: 2.1.1 The plan creator fails to create the deployment plan and consequently to deploy the app in the Jetty distribution. This feature works OK in Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3906) start-server uses hard-coded credentials that cannot be overridden
[ https://issues.apache.org/jira/browse/GERONIMO-3906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor reassigned GERONIMO-3906: - Assignee: Jarek Gawor start-server uses hard-coded credentials that cannot be overridden -- Key: GERONIMO-3906 URL: https://issues.apache.org/jira/browse/GERONIMO-3906 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Jarek Gawor Assignee: Jarek Gawor Fix For: 2.1.1, 2.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3858) start-server.bat fails to start server if there is a space in the path
[ https://issues.apache.org/jira/browse/GERONIMO-3858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579976#action_12579976 ] Joe Bohn commented on GERONIMO-3858: Given that this appears to be an ant issue that is not yet available in a released Ant version I'm going to remove this from the must fix list for Geronimo 2.1.1. Hopefully Ant will release the fix and we'll pick it up in a future Geronimo release. start-server.bat fails to start server if there is a space in the path -- Key: GERONIMO-3858 URL: https://issues.apache.org/jira/browse/GERONIMO-3858 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.1, 2.1.1, 2.2 Environment: Windows XP Reporter: YunFeng Ma start-server.bat fails to start server if there is a space in the install path, but startup.bat works fine. Looks like it's an Ant bug. H:\myf\Apache Geronimo\binstart-server.bat --- constituent[0]: file:/H:/myf/Apache Geronimo/etc/ constituent[1]: file:/H:/myf/Apache Geronimo/lib/gshell/geronimo-commands-2.1-SN APSHOT.jar constituent[2]: file:/H:/myf/Apache Geronimo/repository/org/apache/ant/ant/1.7.0 /ant-1.7.0.jar constituent[3]: file:/H:/myf/Apache Geronimo/repository/org/apache/ant/ant-launc her/1.7.0/ant-launcher-1.7.0.jar constituent[4]: file:/H:/myf/Apache Geronimo/repository/org/apache/geronimo/gshe ll/gshell-cli/1.0-alpha-1-SNAPSHOT/gshell-cli-1.0-alpha-1-SNAPSHOT.jar constituent[5]: file:/H:/myf/Apache Geronimo/repository/org/apache/geronimo/gshe ll/gshell-embeddable/1.0-alpha-1-SNAPSHOT/gshell-embeddable-1.0-alpha-1-SNAPSHOT .jar constituent[6]: file:/H:/myf/Apache Geronimo/repository/org/apache/geronimo/gshe ll/remote/gshell-remote-client/1.0-alpha-1-SNAPSHOT/gshell-remote-client-1.0-alp ha-1-SNAPSHOT.jar constituent[7]: file:/H:/myf/Apache Geronimo/repository/org/apache/geronimo/gshe ll/remote/gshell-remote-common/1.0-alpha-1-SNAPSHOT/gshell-remote-common-1.0-alp ha-1-SNAPSHOT.jar constituent[8]: file:/H:/myf/Apache Geronimo/repository/org/apache/geronimo/gshe ll/remote/gshell-remote-server/1.0-alpha-1-SNAPSHOT/gshell-remote-server-1.0-alp ha-1-SNAPSHOT.jar constituent[9]: file:/H:/myf/Apache Geronimo/repository/org/apache/geronimo/gshe ll/gshell-whisper/1.0-alpha-1-SNAPSHOT/gshell-whisper-1.0-alpha-1-SNAPSHOT.jar constituent[10]: file:/H:/myf/Apache Geronimo/repository/org/apache/mina/mina-co re/1.1.2/mina-core-1.1.2.jar constituent[11]: file:/H:/myf/Apache Geronimo/repository/org/apache/mina/mina-fi lter-ssl/1.1.2/mina-filter-ssl-1.1.2.jar constituent[12]: file:/H:/myf/Apache Geronimo/repository/org/codehaus/groovy/gro ovy-all/1.1-rc-1/groovy-all-1.1-rc-1.jar constituent[13]: file:/H:/myf/Apache Geronimo/repository/org/slf4j/slf4j-log4j12 /1.4.3/slf4j-log4j12-1.4.3.jar constituent[14]: file:/H:/myf/Apache Geronimo/repository/org/slf4j/jcl104-over-s lf4j/1.4.3/jcl104-over-slf4j-1.4.3.jar constituent[15]: file:/H:/myf/Apache Geronimo/lib/geronimo-kernel-2.1-SNAPSHOT.j ar constituent[16]: file:/H:/myf/Apache Geronimo/lib/log4j-1.2.14.jar constituent[17]: file:/H:/myf/Apache Geronimo/lib/cglib-nodep-2.1_3.jar constituent[18]: file:/H:/myf/Apache Geronimo/repository/org/apache/geronimo/spe cs/geronimo-javaee-deployment_1.1MR3_spec/1.0/geronimo-javaee-deployment_1.1MR3_ spec-1.0.jar constituent[19]: file:/H:/myf/Apache Geronimo/repository/org/apache/geronimo/mod ules/geronimo-cli/2.1-SNAPSHOT/geronimo-cli-2.1-SNAPSHOT.jar constituent[20]: file:/H:/myf/Apache Geronimo/repository/org/apache/geronimo/mod ules/geronimo-deploy-config/2.1-SNAPSHOT/geronimo-deploy-config-2.1-SNAPSHOT.jar constituent[21]: file:/H:/myf/Apache Geronimo/repository/org/apache/geronimo/mod ules/geronimo-deploy-jsr88/2.1-SNAPSHOT/geronimo-deploy-jsr88-2.1-SNAPSHOT.jar constituent[22]: file:/H:/myf/Apache Geronimo/repository/org/apache/geronimo/mod ules/geronimo-deploy-tool/2.1-SNAPSHOT/geronimo-deploy-tool-2.1-SNAPSHOT.jar constituent[23]: file:/H:/myf/Apache Geronimo/repository/org/apache/geronimo/mod ules/geronimo-system/2.1-SNAPSHOT/geronimo-system-2.1-SNAPSHOT.jar constituent[24]: file:/H:/myf/Apache Geronimo/repository/org/apache/geronimo/mod ules/geronimo-plugin/2.1-SNAPSHOT/geronimo-plugin-2.1-SNAPSHOT.jar constituent[25]: file:/H:/myf/Apache Geronimo/repository/org/apache/geronimo/mod ules/geronimo-common/2.1-SNAPSHOT/geronimo-common-2.1-SNAPSHOT.jar constituent[26]: file:/H:/myf/Apache Geronimo/repository/org/codehaus/plexus/ple xus-archiver/1.0-alpha-7/plexus-archiver-1.0-alpha-7.jar constituent[27]: file:/H:/myf/Apache Geronimo/repository/org/codehaus/plexus/ple
Re: start-server command and default user credentials
Anymore more thoughts on this issue? If not, I guess I'll just add options for specifying the username, password and port number as a temporary solution to get this fixed for the 2.1.1 release. Jarek On Mon, Mar 17, 2008 at 11:01 AM, Jarek Gawor [EMAIL PROTECTED] wrote: On Sat, Mar 15, 2008 at 12:28 AM, Jason Dillon [EMAIL PROTECTED] wrote: On Mar 15, 2008, at 12:34 AM, Donald Woods wrote: Jarek Gawor wrote: Jason, I thought TCK was using the maven plugin to start the server. I'm not proposing to change that. But even if start-server command is used by TCK, I don't think that alone should dictate how the command should behave. I'm thinking what happens if you start any command in the background in a regular shell or even use geronimo.sh run or The --background option is not intended to behave like a shells operator... and some daemons do fork right away and return while the child continues, but other more robust daemons fork, then wait for the child to become booted, then return, so that any error status can be returned to the invoking shell for handling. IMO this is how Geronimo should behave... Adding a --wait or --nowait option might be useful, though I'd really like to solve the username/passwd problem... I think we need any anonymous way to query the status... Whether to poll and how to poll are two separate issues to me. I agree that we do need a way to anonymously query the status but I don't think we need to query the status in the normal/default case in the first place. When executing a script we'll need to know the status of the server and polling will be necessary but when starting the server in foreground polling is unnecessary. Jarek
[jira] Commented: (GERONIMO-3843) Plan creator fails to create plan and to deploy
[ https://issues.apache.org/jira/browse/GERONIMO-3843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579987#action_12579987 ] Shiva Kumar H R commented on GERONIMO-3843: --- Oh! thanks for pointing out (I had wrongly assumed that 2.1.1 will be branched out of trunk). Will do this first thing tomorrow. Thanks, Shiva Plan creator fails to create plan and to deploy --- Key: GERONIMO-3843 URL: https://issues.apache.org/jira/browse/GERONIMO-3843 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.1 Environment: Geronimo 2.1 - Jetty distribution. Reporter: Hernan Cunico Assignee: Shiva Kumar H R Fix For: 2.1.1 The plan creator fails to create the deployment plan and consequently to deploy the app in the Jetty distribution. This feature works OK in Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r638053 - in /geronimo/server/trunk/plugins: ./ derby/ derby/src/ derby/src/main/ derby/src/main/plan/ system-database/geronimo-derby/ system-database/geronimo-timer/ system-database/s
Was just following how plugins/spring was created, which is just a collection of Spring depends for the console and WADI. I started with it in under system-database, but decided against that as it really wouldn't be a child of the system-database POM, but system-database should have it as a depend... As far as geronimo-timer, it is still as a depend in the following - plugins/system-database/system-database/pom.xml plugins/openejb/geronimo-openejb/pom.xml plugins/openejb/openejb/pom.xml plugins/corba/geronimo-corba/pom.xml -Donald David Jencks wrote: Generally the contents of plugins are groups of plugins rather than sincle plugins. Wouldn't this be more appropriate inside system-database? Also, I'm pretty sure geronimo-timer is obsolete with openejb3. It would be great if someone would check and delete it if it isn't used anywhere. thanks david jencks On Mar 17, 2008, at 1:13 PM, [EMAIL PROTECTED] wrote: Author: dwoods Date: Mon Mar 17 13:13:46 2008 New Revision: 638053 URL: http://svn.apache.org/viewvc?rev=638053view=rev Log: GERONIMO-3926 Add a Derby config/plugin for easier inclusion of Derby jars without a system-database depend Added: geronimo/server/trunk/plugins/derby/ geronimo/server/trunk/plugins/derby/LICENSE.txt (with props) geronimo/server/trunk/plugins/derby/NOTICE.txt (with props) geronimo/server/trunk/plugins/derby/pom.xml (with props) geronimo/server/trunk/plugins/derby/src/ geronimo/server/trunk/plugins/derby/src/main/ geronimo/server/trunk/plugins/derby/src/main/plan/ geronimo/server/trunk/plugins/derby/src/main/plan/plan.xml (with props) Modified: geronimo/server/trunk/plugins/pom.xml geronimo/server/trunk/plugins/system-database/geronimo-derby/pom.xml geronimo/server/trunk/plugins/system-database/geronimo-timer/pom.xml geronimo/server/trunk/plugins/system-database/system-database/pom.xml Added: geronimo/server/trunk/plugins/derby/LICENSE.txt URL: http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/derby/LICENSE.txt?rev=638053view=auto == --- geronimo/server/trunk/plugins/derby/LICENSE.txt (added) +++ geronimo/server/trunk/plugins/derby/LICENSE.txt Mon Mar 17 13:13:46 2008 @@ -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
[jira] Commented: (GERONIMO-3921) getContextRoot() returns forward slash rather than empty string for apps deployed to root context
[ https://issues.apache.org/jira/browse/GERONIMO-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579991#action_12579991 ] Jay D. McHugh commented on GERONIMO-3921: - Jarek, I just checked the Jetty 'wrapper' around the getContext method and it does not have the same check for the first character not being a '/'. So it _should_ be functioning correctly. getContextRoot() returns forward slash rather than empty string for apps deployed to root context - Key: GERONIMO-3921 URL: https://issues.apache.org/jira/browse/GERONIMO-3921 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1, 2.1.1, 2.2 Reporter: Jay D. McHugh Assignee: Jay D. McHugh An app deployed to the root context should have returned by getContextRoot() - On Tomcat, we are returning /. dcherk wrote: I am deploying my war file into the root context with the following deployment plan: -- web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-2.0; xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.2; xmlns:naming=http://geronimo.apache.org/xml/ns/naming-1.2; xmlns:security=http://geronimo.apache.org/xml/ns/security-1.2; ... context-root/context-root ... /web-app -- The application starts up properly, and responds on http://localhost, as expected. However, when I examine request.getContextPath(), I get a forward slash: /. This is incorrect, as far as I can tell. According to the API (http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServletRequest.html#getContextPath()): -- For servlets in the default (root) context, this method [HttpServletRequest.html.getContextPath()] returns . -- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3843) Plan creator fails to create plan and to deploy
[ https://issues.apache.org/jira/browse/GERONIMO-3843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods closed GERONIMO-3843. -- Plan creator fails to create plan and to deploy --- Key: GERONIMO-3843 URL: https://issues.apache.org/jira/browse/GERONIMO-3843 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.1, 2.1.1, 2.2 Environment: Geronimo 2.1 - Jetty distribution. Reporter: Hernan Cunico Assignee: Shiva Kumar H R Fix For: 2.1.1, 2.2 The plan creator fails to create the deployment plan and consequently to deploy the app in the Jetty distribution. This feature works OK in Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3843) Plan creator fails to create plan and to deploy
[ https://issues.apache.org/jira/browse/GERONIMO-3843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-3843: --- Affects Version/s: 2.2 2.1.1 Fix Version/s: 2.2 Merged into branches/2.1 as Rev638499 Plan creator fails to create plan and to deploy --- Key: GERONIMO-3843 URL: https://issues.apache.org/jira/browse/GERONIMO-3843 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.1, 2.1.1, 2.2 Environment: Geronimo 2.1 - Jetty distribution. Reporter: Hernan Cunico Assignee: Shiva Kumar H R Fix For: 2.1.1, 2.2 The plan creator fails to create the deployment plan and consequently to deploy the app in the Jetty distribution. This feature works OK in Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: start-server command and default user credentials
Agree -Donald Jarek Gawor wrote: On Sat, Mar 15, 2008 at 12:28 AM, Jason Dillon [EMAIL PROTECTED] wrote: On Mar 15, 2008, at 12:34 AM, Donald Woods wrote: Jarek Gawor wrote: Jason, I thought TCK was using the maven plugin to start the server. I'm not proposing to change that. But even if start-server command is used by TCK, I don't think that alone should dictate how the command should behave. I'm thinking what happens if you start any command in the background in a regular shell or even use geronimo.sh run or The --background option is not intended to behave like a shells operator... and some daemons do fork right away and return while the child continues, but other more robust daemons fork, then wait for the child to become booted, then return, so that any error status can be returned to the invoking shell for handling. IMO this is how Geronimo should behave... Adding a --wait or --nowait option might be useful, though I'd really like to solve the username/passwd problem... I think we need any anonymous way to query the status... Whether to poll and how to poll are two separate issues to me. I agree that we do need a way to anonymously query the status but I don't think we need to query the status in the normal/default case in the first place. When executing a script we'll need to know the status of the server and polling will be necessary but when starting the server in foreground polling is unnecessary. Jarek smime.p7s Description: S/MIME Cryptographic Signature
Re: start-server command and default user credentials
I like the more secure option of requiring a uid/pwd, than potential exposing unwanted data to attackers -Donald Jarek Gawor wrote: Anymore more thoughts on this issue? If not, I guess I'll just add options for specifying the username, password and port number as a temporary solution to get this fixed for the 2.1.1 release. Jarek On Mon, Mar 17, 2008 at 11:01 AM, Jarek Gawor [EMAIL PROTECTED] wrote: On Sat, Mar 15, 2008 at 12:28 AM, Jason Dillon [EMAIL PROTECTED] wrote: On Mar 15, 2008, at 12:34 AM, Donald Woods wrote: Jarek Gawor wrote: Jason, I thought TCK was using the maven plugin to start the server. I'm not proposing to change that. But even if start-server command is used by TCK, I don't think that alone should dictate how the command should behave. I'm thinking what happens if you start any command in the background in a regular shell or even use geronimo.sh run or The --background option is not intended to behave like a shells operator... and some daemons do fork right away and return while the child continues, but other more robust daemons fork, then wait for the child to become booted, then return, so that any error status can be returned to the invoking shell for handling. IMO this is how Geronimo should behave... Adding a --wait or --nowait option might be useful, though I'd really like to solve the username/passwd problem... I think we need any anonymous way to query the status... Whether to poll and how to poll are two separate issues to me. I agree that we do need a way to anonymously query the status but I don't think we need to query the status in the normal/default case in the first place. When executing a script we'll need to know the status of the server and polling will be necessary but when starting the server in foreground polling is unnecessary. Jarek smime.p7s Description: S/MIME Cryptographic Signature
[jira] Resolved: (GERONIMO-3921) getContextRoot() returns forward slash rather than empty string for apps deployed to root context
[ https://issues.apache.org/jira/browse/GERONIMO-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods resolved GERONIMO-3921. Resolution: Fixed Fix Version/s: 2.2 2.1.1 2.0.x getContextRoot() returns forward slash rather than empty string for apps deployed to root context - Key: GERONIMO-3921 URL: https://issues.apache.org/jira/browse/GERONIMO-3921 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1, 2.1.1, 2.2 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Fix For: 2.0.x, 2.1.1, 2.2 An app deployed to the root context should have returned by getContextRoot() - On Tomcat, we are returning /. dcherk wrote: I am deploying my war file into the root context with the following deployment plan: -- web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-2.0; xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.2; xmlns:naming=http://geronimo.apache.org/xml/ns/naming-1.2; xmlns:security=http://geronimo.apache.org/xml/ns/security-1.2; ... context-root/context-root ... /web-app -- The application starts up properly, and responds on http://localhost, as expected. However, when I examine request.getContextPath(), I get a forward slash: /. This is incorrect, as far as I can tell. According to the API (http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServletRequest.html#getContextPath()): -- For servlets in the default (root) context, this method [HttpServletRequest.html.getContextPath()] returns . -- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: geronimo-web.xml for geronimo 2.0.1
can you be more specific or provide the deployment plan you are having the issue with? Cheers! Hernan remya wrote: Thanks a lot for the reply! But, while creating our application, I am afraid we didn't follow such a directory structure that is required by the environment, moduleId and artifactId. So, using some values for these tags, provide with errors in the deployment or while running the application. It is an already existing application in tomcat, and we are planning to rebuild it into Geronimo 2.0. Can you suggest what may help me here? Thanks Remya Hernan Cunico wrote: Hi Remya, here are a couple of tips for understanding the deployment plans Schema documentation for geronimo-web.xml http://geronimo.apache.org/schemas-2.1/docs/geronimo-web-2.0.1.xsd.html If you want to try Geronimo 2.1 (which I would encourage you to do so) you can give a shot to the deployment plan wizard (http://cwiki.apache.org/GMOxDOC21/deployment-plan-wizard.html ). It will create a deployment plan for you at deployment time, if you are using annotations it's even easier! Back to your specific quesitons, environment, moduleId and artifactId. These are how you uniquely identify your application (or any other resource) within Geronimo. moduleId encloses groupId, artifactId, version and type. These ultimately identify the resource in the repository. moduleId is defined within the environment tag which also encloses the dependencies your application may have. For instance a database connection pool, you'd be adding that dependency there, all enclosed within the appropriate dependenciesdependency tags. The deployment plan wizard link I included above provides more examples on this. The deployment plans documentation is still in progress for Geronimo 2.1 ( http://cwiki.apache.org/GMOxDOC21/deployment-plans.html ), you may still find useful docs from previous releases with more details on the plans ( http://cwiki.apache.org/GMOxDOC12/geronimo-webxml.html ) HTH Cheers! Hernan remya wrote: I am a beginner with Geronimo and would like to know the different steps that needs to be followed while writing my first geronimo-web.xml While I was searching for some samples on the net, I came across several elements in geronimo-web.xml, which was quite confusing to me, like environment, moduleId and artifactId. I had mentioned context-root for my application, but is that alone not enough for my application to be deployed and run? Please do help me in this regard with a suitable reply. Thanks Remya
Re: svn commit: r638053 - in /geronimo/server/trunk/plugins: ./ derby/ derby/src/ derby/src/main/ derby/src/main/plan/ system-database/geronimo-derby/ system-database/geronimo-timer/ system-database/s
On Mar 18, 2008, at 11:37 AM, Donald Woods wrote: Was just following how plugins/spring was created, which is just a collection of Spring depends for the console and WADI. I started with it in under system-database, but decided against that as it really wouldn't be a child of the system-database POM, but system- database should have it as a depend... I think all the stuff that uses derby is under system-database. I'd be fine with renaming plugins/system-database to plugins/derby- support, any maybe the system-database plugin to system-database-derby. Spring is used in more places... As far as geronimo-timer, it is still as a depend in the following - plugins/system-database/system-database/pom.xml plugins/openejb/geronimo-openejb/pom.xml plugins/openejb/openejb/pom.xml plugins/corba/geronimo-corba/pom.xml Just because there are dependencies and stray gbeans in system- database doesn't mean it's actually used by the ejb timer. thanks david jencks -Donald David Jencks wrote: Generally the contents of plugins are groups of plugins rather than sincle plugins. Wouldn't this be more appropriate inside system-database? Also, I'm pretty sure geronimo-timer is obsolete with openejb3. It would be great if someone would check and delete it if it isn't used anywhere. thanks david jencks On Mar 17, 2008, at 1:13 PM, [EMAIL PROTECTED] wrote: Author: dwoods Date: Mon Mar 17 13:13:46 2008 New Revision: 638053 URL: http://svn.apache.org/viewvc?rev=638053view=rev Log: GERONIMO-3926 Add a Derby config/plugin for easier inclusion of Derby jars without a system-database depend Added: geronimo/server/trunk/plugins/derby/ geronimo/server/trunk/plugins/derby/LICENSE.txt (with props) geronimo/server/trunk/plugins/derby/NOTICE.txt (with props) geronimo/server/trunk/plugins/derby/pom.xml (with props) geronimo/server/trunk/plugins/derby/src/ geronimo/server/trunk/plugins/derby/src/main/ geronimo/server/trunk/plugins/derby/src/main/plan/ geronimo/server/trunk/plugins/derby/src/main/plan/plan.xml (with props) Modified: geronimo/server/trunk/plugins/pom.xml geronimo/server/trunk/plugins/system-database/geronimo-derby/ pom.xml geronimo/server/trunk/plugins/system-database/geronimo-timer/ pom.xml geronimo/server/trunk/plugins/system-database/system-database/ pom.xml Added: geronimo/server/trunk/plugins/derby/LICENSE.txt URL: http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/ derby/LICENSE.txt?rev=638053view=auto == --- geronimo/server/trunk/plugins/derby/LICENSE.txt (added) +++ geronimo/server/trunk/plugins/derby/LICENSE.txt Mon Mar 17 13:13:46 2008 @@ -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
Re: geronimo-web.xml for geronimo 2.0.1
And please move this discussion to the user list. thanks david jencks On Mar 18, 2008, at 12:33 PM, Hernan Cunico wrote: can you be more specific or provide the deployment plan you are having the issue with? Cheers! Hernan remya wrote: Thanks a lot for the reply! But, while creating our application, I am afraid we didn't follow such a directory structure that is required by the environment, moduleId and artifactId. So, using some values for these tags, provide with errors in the deployment or while running the application. It is an already existing application in tomcat, and we are planning to rebuild it into Geronimo 2.0. Can you suggest what may help me here? Thanks Remya Hernan Cunico wrote: Hi Remya, here are a couple of tips for understanding the deployment plans Schema documentation for geronimo-web.xml http://geronimo.apache.org/schemas-2.1/docs/geronimo- web-2.0.1.xsd.html If you want to try Geronimo 2.1 (which I would encourage you to do so) you can give a shot to the deployment plan wizard (http://cwiki.apache.org/GMOxDOC21/deployment-plan-wizard.html ). It will create a deployment plan for you at deployment time, if you are using annotations it's even easier! Back to your specific quesitons, environment, moduleId and artifactId. These are how you uniquely identify your application (or any other resource) within Geronimo. moduleId encloses groupId, artifactId, version and type. These ultimately identify the resource in the repository. moduleId is defined within the environment tag which also encloses the dependencies your application may have. For instance a database connection pool, you'd be adding that dependency there, all enclosed within the appropriate dependenciesdependency tags. The deployment plan wizard link I included above provides more examples on this. The deployment plans documentation is still in progress for Geronimo 2.1 ( http://cwiki.apache.org/GMOxDOC21/deployment-plans.html ), you may still find useful docs from previous releases with more details on the plans ( http://cwiki.apache.org/GMOxDOC12/geronimo-webxml.html ) HTH Cheers! Hernan remya wrote: I am a beginner with Geronimo and would like to know the different steps that needs to be followed while writing my first geronimo-web.xml While I was searching for some samples on the net, I came across several elements in geronimo-web.xml, which was quite confusing to me, like environment, moduleId and artifactId. I had mentioned context-root for my application, but is that alone not enough for my application to be deployed and run? Please do help me in this regard with a suitable reply. Thanks Remya
[jira] Commented: (GERONIMO-3902) start-server, default.groovy in etc/rc.d overrides -Xmx value when starting server using gshell
[ https://issues.apache.org/jira/browse/GERONIMO-3902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580054#action_12580054 ] Joe Bohn commented on GERONIMO-3902: Does everyone agree that this is a reasonable change? I'd prefer it if you could override individual options rather than this being an all or nothing deal ... but perhaps that is better than what we have now. Opinions? As pointed out we should check the other commands as part of this change and ensure that they are consistent in the treatment of overrides. start-server, default.groovy in etc/rc.d overrides -Xmx value when starting server using gshell --- Key: GERONIMO-3902 URL: https://issues.apache.org/jira/browse/GERONIMO-3902 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Jason Warner Assignee: Jason Warner Fix For: 2.1.1, 2.2 Attachments: Geronimo-3902.patch The start-server, default.groovy file is included in etc/rc.d directory and contains a command to set the max heap size for geronimo when starting through gshell. This file overrides any max heap size values that are set via the command line causing issues when starting the server with non-default max heap values. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3902) start-server, default.groovy in etc/rc.d overrides -Xmx value when starting server using gshell
[ https://issues.apache.org/jira/browse/GERONIMO-3902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580059#action_12580059 ] Jason Warner commented on GERONIMO-3902: Joe, I just did a quick scan through the rest of the commands and it looks like StartClientCommand.java uses it in the same manner that StartServerCommand.java does. I suggest that this change be made to that file as well and will post a patch shortly for that. In regards to checking individual options, I agree that that is an ideal approach but the same effect can also be accomplished within the rc.d groovy file if a user chose to do so, and I wanted to make as few changes as possible to the command groovy files. start-server, default.groovy in etc/rc.d overrides -Xmx value when starting server using gshell --- Key: GERONIMO-3902 URL: https://issues.apache.org/jira/browse/GERONIMO-3902 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Jason Warner Assignee: Jason Warner Fix For: 2.1.1, 2.2 Attachments: Geronimo-3902.patch The start-server, default.groovy file is included in etc/rc.d directory and contains a command to set the max heap size for geronimo when starting through gshell. This file overrides any max heap size values that are set via the command line causing issues when starting the server with non-default max heap values. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
javamail 1.4-SNAPSHOT and a Geronimo 2.1.1 release
Rick (or anybody else that is involved with javamail). It looks like Geronimo 2.1.1-SNAPSHOT is currently dependent upon javamail 1.4-SNAPSHOT. We need to remove that snapshot dependency if we're going to get a 2.1.1 release out the door. Do you think we could get a javamail 1.4 release out in time for Geronimo 2.1.1 release (hopefully in a week or so). Joe
[BUILD] trunk: Failed for Revision: 638508
Geronimo Revision: 638508 built with tests included See the full build-1500.log file at http://geronimo.apache.org/maven/server/binaries/trunk/20080318/build-1500.log Download the binaries from http://geronimo.apache.org/maven/server/binaries/trunk/20080318 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 31 minutes 21 seconds [INFO] Finished at: Tue Mar 18 15:36:35 EDT 2008 [INFO] Final Memory: 312M/1002M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://geronimo.apache.org/maven/server/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://geronimo.apache.org/maven/server/binaries/trunk/20080318/logs-1500-tomcat/test.log Assembly: jetty = See the full test.log file at http://geronimo.apache.org/maven/server/binaries/trunk/20080318/logs-1500-jetty/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 70.541 sec FAILURE! Samples: trunk = Log: http://geronimo.apache.org/maven/server/binaries/trunk/20080318/samples-1500.log Build status: FAILED
[jira] Updated: (GERONIMO-3902) start-server, default.groovy in etc/rc.d overrides -Xmx value when starting server using gshell
[ https://issues.apache.org/jira/browse/GERONIMO-3902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner updated GERONIMO-3902: --- Attachment: Geronimo-3902-IncludesStartClient.patch This patch makes the changes in both StartServerCommand.groovy and StartClientCommand.groovy. start-server, default.groovy in etc/rc.d overrides -Xmx value when starting server using gshell --- Key: GERONIMO-3902 URL: https://issues.apache.org/jira/browse/GERONIMO-3902 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Jason Warner Assignee: Jason Warner Fix For: 2.1.1, 2.2 Attachments: Geronimo-3902-IncludesStartClient.patch, Geronimo-3902.patch The start-server, default.groovy file is included in etc/rc.d directory and contains a command to set the max heap size for geronimo when starting through gshell. This file overrides any max heap size values that are set via the command line causing issues when starting the server with non-default max heap values. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3856) Assemble a Server Confirmation Page
[ https://issues.apache.org/jira/browse/GERONIMO-3856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-3856: --- Attachment: GERONIMO-3856.patch Patch Available! 1) At minimum the user should provide an artifact id otherwise assembly named --bin.tar.gz will be created. The portlet should check for empty artifact id. Soln: Javascript check provided to ensure artifact id is filled. 2) If no plugins are selected and 'assemble' button is pressed a nasty exception will be displayed. The portlet should check if at least one plugin was selected. Soln: Javascript check provided to ensure at least one plugin is checked. 3) On the confirmation screen and on Windows the server path location will contain / and \. For example c:\geronimo/var/temp/foo.tar.gz. Soln: OS Detection. Depending if OS was window's setup the initial assembly path as well as relativepath with correct slash format. Assemble a Server Confirmation Page --- Key: GERONIMO-3856 URL: https://issues.apache.org/jira/browse/GERONIMO-3856 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Joseph Leong Assignee: Joseph Leong Priority: Minor Attachments: GERONIMO-3856.patch Improvements for the Assemble a Server Confirmation Page 1) At minimum the user should provide an artifact id otherwise assembly named --bin.tar.gz will be created. The portlet should check for empty artifact id. 2) If no plugins are selected and 'assemble' button is pressed a nasty exception will be displayed. The portlet should check if at least one plugin was selected. 3) On the confirmation screen and on Windows the server path location will contain / and \. For example c:\geronimo/var/temp/foo.tar.gz. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3856) Assemble a Server Confirmation Page
[ https://issues.apache.org/jira/browse/GERONIMO-3856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-3856: --- Patch Info: [Patch Available] Assemble a Server Confirmation Page --- Key: GERONIMO-3856 URL: https://issues.apache.org/jira/browse/GERONIMO-3856 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Joseph Leong Assignee: Joseph Leong Priority: Minor Attachments: GERONIMO-3856.patch Improvements for the Assemble a Server Confirmation Page 1) At minimum the user should provide an artifact id otherwise assembly named --bin.tar.gz will be created. The portlet should check for empty artifact id. 2) If no plugins are selected and 'assemble' button is pressed a nasty exception will be displayed. The portlet should check if at least one plugin was selected. 3) On the confirmation screen and on Windows the server path location will contain / and \. For example c:\geronimo/var/temp/foo.tar.gz. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3483) Redeploy should start any dependent configurations it stops.
[ https://issues.apache.org/jira/browse/GERONIMO-3483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bohn updated GERONIMO-3483: --- Fix Version/s: (was: 2.1.1) (was: 2.0.x) 2.2 Redeploy should start any dependent configurations it stops. Key: GERONIMO-3483 URL: https://issues.apache.org/jira/browse/GERONIMO-3483 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0.1, 2.0.x, 2.1, 2.1.1 Reporter: Vamsavardhana Reddy Fix For: 2.2 When a configuration is redeployed, any dependent configurations stopped are not automatically restarted after redeploy step. The user will have to manually start the stopped configs. It will be useful if the deployer starts all the configurations it stopped during redeploy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3408) Clean up deployer login code in ServerConnection
[ https://issues.apache.org/jira/browse/GERONIMO-3408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bohn updated GERONIMO-3408: --- Patch Info: [Patch Available] Marked that there is a patch but I'll take Kevan's word that the patch is dated. Is this still a valid issue? If not, please cancel. If it is still valid can we get an updated patch? I'm wondering if this needs to be a candidate for 2.1.1 (as indicated in the fix releases at the moment). Clean up deployer login code in ServerConnection Key: GERONIMO-3408 URL: https://issues.apache.org/jira/browse/GERONIMO-3408 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0, 2.0.x, 2.1 Reporter: Ted Kirby Assignee: Donald Woods Fix For: 2.0.x, 2.1.1 Attachments: G3408.patch Currently, the normal login path of the deploy command is a two-pass approach, where an exception is thrown in the first pass. I am cleaning this up and removing what looks like old code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2622) Implement PolicyContextHandlerSOAPMessage
[ https://issues.apache.org/jira/browse/GERONIMO-2622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580119#action_12580119 ] Joe Bohn commented on GERONIMO-2622: Any info on this one David? Is this something that needs to be in 2.1.1? It looks like it's been around quite a while. Is it still valid? Implement PolicyContextHandlerSOAPMessage - Key: GERONIMO-2622 URL: https://issues.apache.org/jira/browse/GERONIMO-2622 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0-M5, 2.0, 2.0.1, 2.0.2, 2.1 Reporter: David Jencks Assignee: David Jencks Priority: Critical Fix For: 2.1.1 I just discoverd PolicyContextHandlerSOAPMessage is not yet implemented! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2340) Network Listener state not persisted across server startups
[ https://issues.apache.org/jira/browse/GERONIMO-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580121#action_12580121 ] Joe Bohn commented on GERONIMO-2340: Donald, Since you are currently the assignee ... is there any movement on this issue or any chance we will address it in 2.1.1 (as currently indicated in the fix release)? I doubt it will be resolved in 2.1.1 given that we haven't reached consensus on a fix so perhaps it should move to 2.2. Network Listener state not persisted across server startups --- Key: GERONIMO-2340 URL: https://issues.apache.org/jira/browse/GERONIMO-2340 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1.1, 2.0.x, 2.1 Environment: Win XP, Geronimo 1.1.1-SNAPSHOT Reporter: Vamsavardhana Reddy Assignee: Donald Woods Fix For: 2.0.x, 2.1.1 I have stopped the HTTPS and AJP Network Listeners thru Web Servers portlet. Upon restarting the server, these stopped listeners have started automatically. Happens with both Jetty and Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3902) start-server, default.groovy in etc/rc.d overrides -Xmx value when starting server using gshell
[ https://issues.apache.org/jira/browse/GERONIMO-3902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580123#action_12580123 ] Donald Woods commented on GERONIMO-3902: Seems like a good compromise for now. Allowing users to override options, even if its all or nothing, is better than requiring hand editing of files (thinking debug and java service wrappers here) start-server, default.groovy in etc/rc.d overrides -Xmx value when starting server using gshell --- Key: GERONIMO-3902 URL: https://issues.apache.org/jira/browse/GERONIMO-3902 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Jason Warner Assignee: Jason Warner Fix For: 2.1.1, 2.2 Attachments: Geronimo-3902-IncludesStartClient.patch, Geronimo-3902.patch The start-server, default.groovy file is included in etc/rc.d directory and contains a command to set the max heap size for geronimo when starting through gshell. This file overrides any max heap size values that are set via the command line causing issues when starting the server with non-default max heap values. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3408) Clean up deployer login code in ServerConnection
[ https://issues.apache.org/jira/browse/GERONIMO-3408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580125#action_12580125 ] Donald Woods commented on GERONIMO-3408: I'll take another look at it and either commit or cancel it. Clean up deployer login code in ServerConnection Key: GERONIMO-3408 URL: https://issues.apache.org/jira/browse/GERONIMO-3408 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0, 2.0.x, 2.1 Reporter: Ted Kirby Assignee: Donald Woods Fix For: 2.0.x, 2.1.1 Attachments: G3408.patch Currently, the normal login path of the deploy command is a two-pass approach, where an exception is thrown in the first pass. I am cleaning this up and removing what looks like old code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2246) Why resource-env-ref:admin-object-module?
[ https://issues.apache.org/jira/browse/GERONIMO-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580126#action_12580126 ] Joe Bohn commented on GERONIMO-2246: Should we move this along to 2.2 given that we have more critical issues for 2.1.1? Is it still a concern? Why resource-env-ref:admin-object-module? - Key: GERONIMO-2246 URL: https://issues.apache.org/jira/browse/GERONIMO-2246 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: connector, deployment Affects Versions: 1.1, 2.0.x, 2.1, 2.1.1 Reporter: Aaron Mulder Assignee: David Jencks Fix For: 2.0.x, 2.1.1 When mapping resource-env-refs (or a message-destination), It doesn't seem like admin-object-module is necessary. It can be provided alongside admin-object-name in order to narrow the search down to a specific module within an EAR (the current EAR or any EAR in the dependency graph that has a module with that name). However, if you need to specify a module, you can just use: pattern modulejms.rar/module namefoo/name /pattern Instead of using admin-object-module and admin-object-name. It doesn't seem like this redundancy gets us anything, so I'd rather remove admin-object-module and make admin-object-link work like any other resource/EJB link (name only -- use pattern for more complex stuff). If we proceed, I don't think we necessarily want to remove it in 1.1.x (breaking backward compatibility with 1.1.0) -- we can remove it in 1.2 and remove message-destination-link at the same time. David J, could you comment? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3783) MessageDrivenBean delivery problem
[ https://issues.apache.org/jira/browse/GERONIMO-3783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bohn updated GERONIMO-3783: --- Fix Version/s: 2.2 2.1.1 MessageDrivenBean delivery problem -- Key: GERONIMO-3783 URL: https://issues.apache.org/jira/browse/GERONIMO-3783 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ Affects Versions: 2.1 Environment: Windows XP Professional, 2GB ram, Java6SE, Geronimo 2.1-snapshot (2008-01-02) Reporter: Tomasz Mazan Assignee: David Jencks Priority: Critical Fix For: 2.1.1, 2.2 Attachments: mdb-issue.zip MessageDrivenBean that listens on the Queue receive (and process) some messages and then stop receiving any new message until next module's restart. After restart a few next messages are delivered to MDB, and it stops again. Some additional information I put here http://www.nabble.com/Strange-plug-with-delivering-messages-to-MDB-td14923100s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3354) Exception thrown by MDB involved in XA transaction
[ https://issues.apache.org/jira/browse/GERONIMO-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580185#action_12580185 ] David Jencks commented on GERONIMO-3354: We need to turn on the openejb NamedXAResource wrapping. in trunk I try to do this in rev 638653. Need testing maybe the app from GERONIMO-3783 will work. Not applied to branches/2.1 yet. Donald -re AMQ 1438, I need to understand this patch better before applying it. Exception thrown by MDB involved in XA transaction -- Key: GERONIMO-3354 URL: https://issues.apache.org/jira/browse/GERONIMO-3354 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ, OpenEJB, transaction manager Affects Versions: 2.0, 2.0.x, 2.1 Environment: Geronimo 2.0 (tomcat) build from 07/24 (http://people.apache.org/~prasad/binaries/20070724/) DayTrader 1.2 or 2.0 (any runtime mode) with asyn order processing enabled Reporter: Christopher James Blythe Assignee: David Jencks Priority: Critical Fix For: 2.0.x, 2.1.1 The async order processing in DayTrader uses the TradeBrokerMDB to handle complete order operations whenever a buy or sell is performed. When these transactions are executed, the transaction appears to complete; however, the following exception is written to the console and log file. According to Jencks, this seems to indicate that the tx info is not being written to the transaction log. 22:59:18,421 ERROR [Transaction] Please correct the integration and supply a NamedXAResource java.lang.IllegalStateException : Cannot log transactions as [EMAIL PROTECTED] is not a NamedXAResource. at org.apache.geronimo.transaction.manager.TransactionImpl$TransactionBranch.getResourceName(TransactionImpl.java :697) at org.apache.geronimo.transaction.log.HOWLLog.prepare(HOWLLog.java:254) at org.apache.geronimo.transaction.log.HOWLLog$$FastClassByCGLIB$$7315be2e.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke (FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:830) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept (ProxyMethodInterceptor.java:96) at org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$ba0af455.prepare(generated) at org.apache.geronimo.transaction.manager.TransactionImpl.internalPrepare(TransactionImpl.java :444) at org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:316) at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:238) at org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:139) at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:75) at org.apache.openejb.core.mdb.MdbContainer.afterDelivery (MdbContainer.java:375) at org.apache.openejb.core.mdb.EndpointHandler.afterDelivery(EndpointHandler.java:274) at org.apache.openejb.core.mdb.EndpointHandler.invoke(EndpointHandler.java:164) at $Proxy36.afterDelivery(Unknown Source) at org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.afterDelivery(MessageEndpointProxy.java:126) at org.apache.activemq.ra.MessageEndpointProxy.afterDelivery(MessageEndpointProxy.java:65) at org.apache.activemq.ra.ServerSessionImpl.afterDelivery(ServerSessionImpl.java:216) at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:751) at org.apache.activemq.ra.ServerSessionImpl.run( ServerSessionImpl.java:165) at org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.java:290) at org.apache.geronimo.connector.work.pool.NamedRunnable.run(NamedRunnable.java:32) at org.apache.geronimo.pool.ThreadPool$1.run (ThreadPool.java:201) at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:331) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:801) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r638573 - in /geronimo/server/branches/2.1: plugins/system-database/sysdb-console-jetty/src/main/plan/plan.xml plugins/system-database/sysdb-console-tomcat/src/main/plan/plan.xml pom.x
Could you please undo this? Despite anything that may have been published (by me even, in the past), there is no local db2 adapter. You can run the xa one in local transaction mode but this one doesn't actually work. thanks david jencks On Mar 18, 2008, at 2:15 PM, [EMAIL PROTECTED] wrote: Author: dwoods Date: Tue Mar 18 14:15:53 2008 New Revision: 638573 URL: http://svn.apache.org/viewvc?rev=638573view=rev Log: added missing tranql-connector-db2-local Modified: geronimo/server/branches/2.1/plugins/system-database/sysdb- console-jetty/src/main/plan/plan.xml geronimo/server/branches/2.1/plugins/system-database/sysdb- console-tomcat/src/main/plan/plan.xml geronimo/server/branches/2.1/pom.xml Modified: geronimo/server/branches/2.1/plugins/system-database/ sysdb-console-jetty/src/main/plan/plan.xml URL: http://svn.apache.org/viewvc/geronimo/server/branches/2.1/ plugins/system-database/sysdb-console-jetty/src/main/plan/plan.xml? rev=638573r1=638572r2=638573view=diff == --- geronimo/server/branches/2.1/plugins/system-database/sysdb- console-jetty/src/main/plan/plan.xml (original) +++ geronimo/server/branches/2.1/plugins/system-database/sysdb- console-jetty/src/main/plan/plan.xml Tue Mar 18 14:15:53 2008 @@ -91,12 +91,20 @@ attribute name=RARNameorg.tranql/tranql-connector-ra// rar/attribute /gbean gbean name=Database2 class=org.apache.geronimo.console.databasemanager.wizard.DatabaseDriv erGBean -attribute name=nameDB2/attribute +attribute name=nameDB2 XA/attribute attribute name=URLPrototypenull/attribute attribute name=driverClassNamenull/attribute attribute name=defaultPort0/attribute attribute name=specifictrue/attribute attribute name=RARNameorg.tranql/tranql-connector-db2- xa//rar/attribute +/gbean +gbean name=Database2a class=org.apache.geronimo.console.databasemanager.wizard.DatabaseDriv erGBean +attribute name=nameDB2/attribute +attribute name=URLPrototypenull/attribute +attribute name=driverClassNamenull/attribute +attribute name=defaultPort0/attribute +attribute name=specifictrue/attribute +attribute name=RARNameorg.tranql/tranql-connector-db2- local//rar/attribute /gbean gbean name=Database3 class=org.apache.geronimo.console.databasemanager.wizard.DatabaseDriv erGBean attribute name=nameDB2 (DataDirect)/attribute Modified: geronimo/server/branches/2.1/plugins/system-database/ sysdb-console-tomcat/src/main/plan/plan.xml URL: http://svn.apache.org/viewvc/geronimo/server/branches/2.1/ plugins/system-database/sysdb-console-tomcat/src/main/plan/plan.xml? rev=638573r1=638572r2=638573view=diff == --- geronimo/server/branches/2.1/plugins/system-database/sysdb- console-tomcat/src/main/plan/plan.xml (original) +++ geronimo/server/branches/2.1/plugins/system-database/sysdb- console-tomcat/src/main/plan/plan.xml Tue Mar 18 14:15:53 2008 @@ -92,12 +92,20 @@ attribute name=RARNameorg.tranql/tranql-connector-ra// rar/attribute /gbean gbean name=Database2 class=org.apache.geronimo.console.databasemanager.wizard.DatabaseDriv erGBean -attribute name=nameDB2/attribute +attribute name=nameDB2 XA/attribute attribute name=URLPrototypenull/attribute attribute name=driverClassNamenull/attribute attribute name=defaultPort0/attribute attribute name=specifictrue/attribute attribute name=RARNameorg.tranql/tranql-connector-db2- xa//rar/attribute +/gbean +gbean name=Database2a class=org.apache.geronimo.console.databasemanager.wizard.DatabaseDriv erGBean +attribute name=nameDB2/attribute +attribute name=URLPrototypenull/attribute +attribute name=driverClassNamenull/attribute +attribute name=defaultPort0/attribute +attribute name=specifictrue/attribute +attribute name=RARNameorg.tranql/tranql-connector-db2- local//rar/attribute /gbean gbean name=Database3 class=org.apache.geronimo.console.databasemanager.wizard.DatabaseDriv erGBean attribute name=nameDB2 (DataDirect)/attribute Modified: geronimo/server/branches/2.1/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/branches/2.1/ pom.xml?rev=638573r1=638572r2=638573view=diff == --- geronimo/server/branches/2.1/pom.xml (original) +++ geronimo/server/branches/2.1/pom.xml Tue Mar 18 14:15:53 2008 @@ -938,6 +938,13 @@ dependency groupIdorg.tranql/groupId +artifactIdtranql-connector-db2-local/artifactId +version1.1/version +typerar/type +/dependency + +dependency +
[jira] Assigned: (GERONIMODEVTOOLS-313) JAXB classes for SVN
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell reassigned GERONIMODEVTOOLS-313: -- Assignee: Tim McConnell (was: YunFeng Ma) JAXB classes for SVN Key: GERONIMODEVTOOLS-313 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-313 Project: Geronimo-Devtools Issue Type: Sub-task Reporter: Tim McConnell Assignee: Tim McConnell -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Cant find geronimo adapter v2.1 when install GEP with WTP
Hi newbie-gero, Unfortunately, the GEP 2.1.x that corresponds to the recently-released Geronimo 2.1 server. However, there is an unstable version that you can download from the site below. Keep in mind though that the operative word is unstable. We would be interested though with any problems and/or comments you have concerning the GEP. Also, the 2.1.x version of the GEP should be released in the next week or so. Thanks very much for your interest in Geronimo. - http://people.apache.org/dist/geronimo/eclipse/unstable/2.1.0/ newbie-gero wrote: Hi lists, i have install the eclipse into my machine by following these steps 1. Download and unzip the eclipse classic version into this path /home/red/eclipse 2. Download the WTP tools and unzip and install in /home/red/eclipse 3. Next i run the eclipse. Now i trying to install the GEP with the WTP by doing this: 1. Add a new server 2. Trying to find the server adapter by click on the 'Download additional server adapters' 3. In the list i cannot find the Geronimo server adaptor v2.1 I am using geronimo version 2.1. can i use the version 2.1 adapter? i have upload the picture of the server adapter listed in eclipse. Thanks in advance http://www.nabble.com/file/p16125735/serverAdapter.jpg serverAdapter.jpg -- Thanks, Tim McConnell
[jira] Created: (GERONIMO-3930) IllegalArgumentException reading Transaction Log
IllegalArgumentException reading Transaction Log Key: GERONIMO-3930 URL: https://issues.apache.org/jira/browse/GERONIMO-3930 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.1, 2.0.x, 2.1.1, 2.2 Reporter: Kevan Miller Priority: Critical Fix For: 2.0.x, 2.1.1, 2.2 Beniamin has reported the following problem on [EMAIL PROTECTED] After processing 20k request to my webservice whose are translated to ~120k XA transactions (postgres + jms) Geronimo hangs up and does not respond on requests via HTTP, request to JMS engine (from HermesJMS) and ignores tries to shutdown server. I stopped Geronimo with kill -9 and tried to start it again and got exception: Module 11/69 org.apache.geronimo.configs/activemq-ra/2.1-SNAPSHOT/car 10:22:15,325 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/transaction/2.1-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/transaction/2.1-SNAPSHOT/car,j2eeType=TransactionLog,name=HOWLTransactionLog java.lang.IllegalArgumentException: Negative position at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:613) at org.objectweb.howl.log.BlockLogBuffer.read(BlockLogBuffer.java:412) at org.objectweb.howl.log.LogFileManager.read(LogFileManager.java:641) at org.objectweb.howl.log.LogBufferManager.replay(LogBufferManager.java:869) at org.objectweb.howl.log.Logger.replay(Logger.java:396) at org.objectweb.howl.log.xa.XALogger.open(XALogger.java:897) at org.apache.geronimo.transaction.log.HOWLLog.doStart(HOWLLog.java:224) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:996) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:539) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:553) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:448) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:534) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$5ebee84a.startConfiguration(generated) at org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:156) at org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:78) at
[jira] Commented: (GERONIMO-3930) IllegalArgumentException reading Transaction Log
[ https://issues.apache.org/jira/browse/GERONIMO-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580215#action_12580215 ] Kevan Miller commented on GERONIMO-3930: I suspect that we're allowing the transaction log file to become too large. See this HOWL bug report for a bit more information -- http://forge.objectweb.org/tracker/index.php?func=detailaid=306425group_id=92atid=100092 The default HOWL configuration is defined in the following HOWLTransactionLog GBean in ~/geronimo/server/branches/2.1/plugins/connector/transaction/src/main/plan/plan.xml: gbean name=HOWLTransactionLog class=org.apache.geronimo.transaction.log.HOWLLogGBean attribute name=bufferClassNameorg.objectweb.howl.log.BlockLogBuffer/attribute attribute name=bufferSizeKBytes32/attribute attribute name=checksumEnabledtrue/attribute attribute name=adler32Checksumtrue/attribute attribute name=flushSleepTimeMilliseconds50/attribute attribute name=logFileDirvar/txlog/attribute attribute name=logFileExtlog/attribute attribute name=logFileNamehowl/attribute attribute name=maxBlocksPerFile-1/attribute attribute name=maxBuffers0/attribute attribute name=maxLogFiles2/attribute attribute name=minBuffers4/attribute attribute name=threadsWaitingForceThreshold-1/attribute reference name=XidFactory nameXidFactory/name /reference reference name=ServerInfo nameServerInfo/name /reference /gbean The maxBlocksPerFile setting is the cause of this problem, I suspect. Configuring to a more reasonable value (i.e. 65534 with a buffer size of 32k), should keep the logfile size below Integer.MAX_VALUE. Note that you can't dynamically change this setting. HOWL won't let the server start, if it detects that the current maxBlocksPerFile doesn't match the old setting in the howl log files. You'll have to delete the old howl log files. Adding the following to your config.xml will override the default maxBlocksPerFile setting: module name=org.apache.geronimo.configs/transaction/2.1/car gbean name=HOWLTransactionLog attribute name=maxBlocksPerFile65534/attribute /gbean /module I'm going to wait to hear that this fixes the problem, before changing our default behavior. IllegalArgumentException reading Transaction Log Key: GERONIMO-3930 URL: https://issues.apache.org/jira/browse/GERONIMO-3930 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0.x, 2.1, 2.1.1, 2.2 Reporter: Kevan Miller Priority: Critical Fix For: 2.0.x, 2.1.1, 2.2 Beniamin has reported the following problem on [EMAIL PROTECTED] After processing 20k request to my webservice whose are translated to ~120k XA transactions (postgres + jms) Geronimo hangs up and does not respond on requests via HTTP, request to JMS engine (from HermesJMS) and ignores tries to shutdown server. I stopped Geronimo with kill -9 and tried to start it again and got exception: Module 11/69 org.apache.geronimo.configs/activemq-ra/2.1-SNAPSHOT/car 10:22:15,325 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/transaction/2.1-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/transaction/2.1-SNAPSHOT/car,j2eeType=TransactionLog,name=HOWLTransactionLog java.lang.IllegalArgumentException: Negative position at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:613) at org.objectweb.howl.log.BlockLogBuffer.read(BlockLogBuffer.java:412) at org.objectweb.howl.log.LogFileManager.read(LogFileManager.java:641) at org.objectweb.howl.log.LogBufferManager.replay(LogBufferManager.java:869) at org.objectweb.howl.log.Logger.replay(Logger.java:396) at org.objectweb.howl.log.xa.XALogger.open(XALogger.java:897) at org.apache.geronimo.transaction.log.HOWLLog.doStart(HOWLLog.java:224) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:996) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:539) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) at
Re: svn commit: r638573 - in /geronimo/server/branches/2.1: plugins/system-database/sysdb-console-jetty/src/main/plan/plan.xml plugins/system-database/sysdb-console-tomcat/src/main/plan/plan.xml pom.x
Done. Thanks for keeping an eye on the commits -Donald David Jencks wrote: Could you please undo this? Despite anything that may have been published (by me even, in the past), there is no local db2 adapter. You can run the xa one in local transaction mode but this one doesn't actually work. thanks david jencks On Mar 18, 2008, at 2:15 PM, [EMAIL PROTECTED] wrote: Author: dwoods Date: Tue Mar 18 14:15:53 2008 New Revision: 638573 URL: http://svn.apache.org/viewvc?rev=638573view=rev Log: added missing tranql-connector-db2-local Modified: geronimo/server/branches/2.1/plugins/system-database/sysdb-console-jetty/src/main/plan/plan.xml geronimo/server/branches/2.1/plugins/system-database/sysdb-console-tomcat/src/main/plan/plan.xml geronimo/server/branches/2.1/pom.xml Modified: geronimo/server/branches/2.1/plugins/system-database/sysdb-console-jetty/src/main/plan/plan.xml URL: http://svn.apache.org/viewvc/geronimo/server/branches/2.1/plugins/system-database/sysdb-console-jetty/src/main/plan/plan.xml?rev=638573r1=638572r2=638573view=diff == --- geronimo/server/branches/2.1/plugins/system-database/sysdb-console-jetty/src/main/plan/plan.xml (original) +++ geronimo/server/branches/2.1/plugins/system-database/sysdb-console-jetty/src/main/plan/plan.xml Tue Mar 18 14:15:53 2008 @@ -91,12 +91,20 @@ attribute name=RARNameorg.tranql/tranql-connector-ra//rar/attribute /gbean gbean name=Database2 class=org.apache.geronimo.console.databasemanager.wizard.DatabaseDriverGBean -attribute name=nameDB2/attribute +attribute name=nameDB2 XA/attribute attribute name=URLPrototypenull/attribute attribute name=driverClassNamenull/attribute attribute name=defaultPort0/attribute attribute name=specifictrue/attribute attribute name=RARNameorg.tranql/tranql-connector-db2-xa//rar/attribute +/gbean +gbean name=Database2a class=org.apache.geronimo.console.databasemanager.wizard.DatabaseDriverGBean +attribute name=nameDB2/attribute +attribute name=URLPrototypenull/attribute +attribute name=driverClassNamenull/attribute +attribute name=defaultPort0/attribute +attribute name=specifictrue/attribute +attribute name=RARNameorg.tranql/tranql-connector-db2-local//rar/attribute /gbean gbean name=Database3 class=org.apache.geronimo.console.databasemanager.wizard.DatabaseDriverGBean attribute name=nameDB2 (DataDirect)/attribute Modified: geronimo/server/branches/2.1/plugins/system-database/sysdb-console-tomcat/src/main/plan/plan.xml URL: http://svn.apache.org/viewvc/geronimo/server/branches/2.1/plugins/system-database/sysdb-console-tomcat/src/main/plan/plan.xml?rev=638573r1=638572r2=638573view=diff == --- geronimo/server/branches/2.1/plugins/system-database/sysdb-console-tomcat/src/main/plan/plan.xml (original) +++ geronimo/server/branches/2.1/plugins/system-database/sysdb-console-tomcat/src/main/plan/plan.xml Tue Mar 18 14:15:53 2008 @@ -92,12 +92,20 @@ attribute name=RARNameorg.tranql/tranql-connector-ra//rar/attribute /gbean gbean name=Database2 class=org.apache.geronimo.console.databasemanager.wizard.DatabaseDriverGBean -attribute name=nameDB2/attribute +attribute name=nameDB2 XA/attribute attribute name=URLPrototypenull/attribute attribute name=driverClassNamenull/attribute attribute name=defaultPort0/attribute attribute name=specifictrue/attribute attribute name=RARNameorg.tranql/tranql-connector-db2-xa//rar/attribute +/gbean +gbean name=Database2a class=org.apache.geronimo.console.databasemanager.wizard.DatabaseDriverGBean +attribute name=nameDB2/attribute +attribute name=URLPrototypenull/attribute +attribute name=driverClassNamenull/attribute +attribute name=defaultPort0/attribute +attribute name=specifictrue/attribute +attribute name=RARNameorg.tranql/tranql-connector-db2-local//rar/attribute /gbean gbean name=Database3 class=org.apache.geronimo.console.databasemanager.wizard.DatabaseDriverGBean attribute name=nameDB2 (DataDirect)/attribute Modified: geronimo/server/branches/2.1/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/branches/2.1/pom.xml?rev=638573r1=638572r2=638573view=diff == --- geronimo/server/branches/2.1/pom.xml (original) +++ geronimo/server/branches/2.1/pom.xml Tue Mar 18 14:15:53 2008 @@ -938,6 +938,13 @@ dependency groupIdorg.tranql/groupId +artifactIdtranql-connector-db2-local/artifactId +version1.1/version +
Re: Geronimo Jetty 2.1 clustering - Testing clustering
On Tue, Mar 18, 2008 at 6:38 PM, Gianny Damour [EMAIL PROTECTED] wrote: Hi, There was a typo in the way node2 was started. It used to be: geronimo/start-server -D node.name=node2 -G server.name=yellow -b It should actually be: geronimo/start-server -D node.name=yellow -G server.name=node2 -b I could figure this part as the server.name has to match the directory names created under geronimo_home for additional server instances. Though, I am not sure that this can explain the problem. What does the page show? The page shows a grid with nine boxes filled in red. The smaller squares inside are filled in black and does not display any numbers whereas the picture in http://cwiki.apache.org/GMOxDEV/clustering-configuration-for-jetty.htmlshows the smaller squares containing number 1. FWIW, I have just set-up a two node cluster and it works fine. Thanks, Gianny On 18/03/2008, at 10:13 PM, Vamsavardhana Reddy wrote: I have attempted the steps from http://cwiki.apache.org/GMOxDEV/ clustering-configuration-for-jetty.html with Geronimo Jetty 2.1. I was able to get a cluster with two nodes running and deploy the sample application too. But, when I access http://localhost:8090/ wadi-webapp-2.0M3-20070121.115809-5/index.jsp , the page does not show any numbers in the boxes as shown in the article. What am I doing wrong?
[jira] Assigned: (GERONIMO-3856) Assemble a Server Confirmation Page
[ https://issues.apache.org/jira/browse/GERONIMO-3856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor reassigned GERONIMO-3856: - Assignee: Jarek Gawor (was: Joseph Leong) Assemble a Server Confirmation Page --- Key: GERONIMO-3856 URL: https://issues.apache.org/jira/browse/GERONIMO-3856 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Joseph Leong Assignee: Jarek Gawor Priority: Minor Attachments: GERONIMO-3856.patch Improvements for the Assemble a Server Confirmation Page 1) At minimum the user should provide an artifact id otherwise assembly named --bin.tar.gz will be created. The portlet should check for empty artifact id. 2) If no plugins are selected and 'assemble' button is pressed a nasty exception will be displayed. The portlet should check if at least one plugin was selected. 3) On the confirmation screen and on Windows the server path location will contain / and \. For example c:\geronimo/var/temp/foo.tar.gz. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
