[jira] Assigned: (GERONIMO-3925) Monitoring agent should use JAXB to do XML manipulation
[ https://issues.apache.org/jira/browse/GERONIMO-3925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen reassigned GERONIMO-3925: -- Assignee: Viet Hung Nguyen Monitoring agent should use JAXB to do XML manipulation --- Key: GERONIMO-3925 URL: https://issues.apache.org/jira/browse/GERONIMO-3925 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1.1, 2.2 Reporter: Erik B. Craig Assignee: Viet Hung Nguyen xmlbeans is currently used to write out the xml in the monitoring agent. JAXB should be used to manipulation XML. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
How is Geronimo different from Jboss?
Hi lists, I have been using jboss for 2 yrs and i now trying out Geronimo. I have read that jboss and Geronimo are both Java EE compliant. So what are the difference in jboss and Geroimo in terms of performance, usability etc? What are the things that geronimo have where jboss do not have? Thanks in advance -- View this message in context: http://www.nabble.com/How-is-Geronimo-different-from-Jboss--tp16173233s134p16173233.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[jira] Updated: (GERONIMO-3912) Get version 2.0 migration sample apps checked in from wiki and cleaned up
[ https://issues.apache.org/jira/browse/GERONIMO-3912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik B. Craig updated GERONIMO-3912: Component/s: sample apps Get version 2.0 migration sample apps checked in from wiki and cleaned up -- Key: GERONIMO-3912 URL: https://issues.apache.org/jira/browse/GERONIMO-3912 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: sample apps Affects Versions: 1.1.x Reporter: Erik B. Craig Assignee: Erik B. Craig LICENCE.txt, NOTICE.txt, and ASF license headers need to be added, as well as all line endings converted to unix format and tabs converted to spaces. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3911) Get version 1.1 migration sample apps checked in from wiki and cleaned up
[ https://issues.apache.org/jira/browse/GERONIMO-3911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik B. Craig updated GERONIMO-3911: Component/s: sample apps Get version 1.1 migration sample apps checked in from wiki and cleaned up -- Key: GERONIMO-3911 URL: https://issues.apache.org/jira/browse/GERONIMO-3911 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: sample apps Affects Versions: 1.1.x Reporter: Erik B. Craig Assignee: Erik B. Craig LICENCE.txt, NOTICE.txt, and ASF license headers need to be added, as well as all line endings converted to unix format and tabs converted to spaces. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3910) Rename classes, remove IBM references
[ https://issues.apache.org/jira/browse/GERONIMO-3910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580687#action_12580687 ] Erik B. Craig commented on GERONIMO-3910: - Committed revision 639180 - migration-servlets is verified good and with acceptable class names. Rename classes, remove IBM references - Key: GERONIMO-3910 URL: https://issues.apache.org/jira/browse/GERONIMO-3910 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: sample apps Affects Versions: 1.x Reporter: Erik B. Craig Assignee: Erik B. Craig Priority: Critical In the migration sample apps from the 1.0 branch, there are classes named com.ibm.x. These need to be renamed to o.a.g -- 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=12580690#action_12580690 ] David Jencks commented on GERONIMO-3354: More configuration of openejb in rev 639186. Right now needs openejb trunk or 3.1-SNAPSHOT which is not set in root pom. App from 3783 demonstrates NamedXAResource is getting used but doesn't work yet... 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 Tomcat 2.1 clustering - application deployment problems
Hello Vamsi, If the applications display distinct numbers, then the nodes do not see each other. I think this is a problem with multicasting. Could you please confirm that you have uncommented the last line of etc/rc.d/start-server,default.groovy which sets the system property java.net.preferIPv4Stack? Without this property set to true, multicasting fails at least on Mac OS X and maybe FC. If this property is already set, then I suggest you to check that multicasting is working ok on your box. Thanks, Gianny On 20/03/2008, at 4:08 AM, Vamsavardhana Reddy wrote: Hi Gianny, I observe that the sample application does not run as expected when I try the clustering scenario on FedoraCore. Application running on each node displays its own set of numbers starting from 1 with the background color of the squares being the node.name set at startup. I observed the same behavior with G Jetty 2.1 and G Tomcat 2.1 distros. What is to be done differently on Linux? ++Vamsi \
Re: Geronimo Tomcat 2.1 clustering - application deployment problems
Gianny, I notice in the Java System Info portlet that java.net.preferIPv4Stack is set to true in both the server instances. I am using bin/geronimo.sh to start the server. It must be something to do with multicast then. ++Vamsi On Thu, Mar 20, 2008 at 2:24 PM, Gianny Damour [EMAIL PROTECTED] wrote: Hello Vamsi, If the applications display distinct numbers, then the nodes do not see each other. I think this is a problem with multicasting. Could you please confirm that you have uncommented the last line of etc/rc.d/start-server,default.groovy which sets the system property java.net.preferIPv4Stack? Without this property set to true, multicasting fails at least on Mac OS X and maybe FC. If this property is already set, then I suggest you to check that multicasting is working ok on your box. Thanks, Gianny On 20/03/2008, at 4:08 AM, Vamsavardhana Reddy wrote: Hi Gianny, I observe that the sample application does not run as expected when I try the clustering scenario on FedoraCore. Application running on each node displays its own set of numbers starting from 1 with the background color of the squares being the node.name set at startup. I observed the same behavior with G Jetty 2.1 and G Tomcat 2.1 distros. What is to be done differently on Linux? ++Vamsi \
[jira] Created: (GERONIMO-3933) Getting an Exception while creating JMS deployment plan through console.
Getting an Exception while creating JMS deployment plan through console. Key: GERONIMO-3933 URL: https://issues.apache.org/jira/browse/GERONIMO-3933 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.1 Environment: Apache Geronimo 2.1 on WindowsXP with Mozilla FireFox Browser while using admin console Reporter: Phani Balaji Madgula Priority: Minor Fix For: 2.1.1 Hi I am using AG2.1 for creating deploying a JMS resource plan using admin console. I am using WinXP SP2. First I tried to create the plan using IE 7 but hit the problem mentioned in the JIRA --GERONIMO-3599. Then I switched to FireFox and I was able to get past the error. However after adding a ConnectionFactory a Destination, when I click on the Show Deployment plan, I get the following error as below ** java.lang.IllegalArgumentException: can't parse argument number rarURL at java.text.MessageFormat.makeFormat(MessageFormat.java:1350) at java.text.MessageFormat.applyPattern(MessageFormat.java:470) at org.apache.taglibs.standard.tag.common.fmt.MessageSupport.doEndTag(MessageSupport.java:199) at jsp.WEB_002dINF.view.jmswizard.plan_jsp._jspx_meth_fmt_005fmessage_005f6(plan_jsp.java:673) at jsp.WEB_002dINF.view.jmswizard.plan_jsp._jspService(plan_jsp.java:169) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481) at org.apache.pluto.internal.impl.PortletRequestDispatcherImpl.include(PortletRequestDispatcherImpl.java:106) at org.apache.geronimo.console.MultiPagePortlet.doView(MultiPagePortlet.java:151) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:208) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481) at org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167) at org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101) at org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:173) at org.apache.pluto.driver.tags.PortletTag.doStartTag(PortletTag.java:152) at jsp.WEB_002dINF.themes.portlet_002dskin_jsp._jspService(portlet_002dskin_jsp.java:87) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481) at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:968) at jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspx_meth_c_005fforEach_005f0(default_002dtheme_jsp.java:196) at jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspService(default_002dtheme_jsp.java:101) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at
Changing notification Scheme for Geronimo in JIRA to commits?
Hi, I wonder what's your opinion on changing the notification scheme in jira to send jira notifications to [EMAIL PROTECTED] I usually look at jira report and (try to) match it to appropriate svn changes that requires me switching between dev@ and commits@ back and forth. I know I could filter out jira notifications and place them in put your favorite mail folder here, but if most of us do this let's fix the issue rather than work it around. I think the email flood might frighten many potential developers (but it could be their best way to contribute to stay up-to-date too). Just thought I'd ask others for their views. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
jndi-name of legacy ejbs
Hi, When you are using ejb 2.1 you had to actually specify the jndi-name/local-jndi-name in the openejb-jar.xml. I believe that that name was used if you wanted to do a remote lookup etc. How was this used for local lookups? Were the ejbs available in the application specific jndi context with the local-jndi-name? I am not sure whether this was how it was supposed to work? Currently I believe we are actually ignoring those names and constructing jndi names based on the same strategy we use for ejb3. Am I right about this? If so isn't this a bug that breaks backward compatibility? As long as we use ejb-refs there won't be any problem currently but if you try to access from a remote client the jndi name used will be different. Regards Manu
Re: Geronimo Tomcat 2.1 clustering - application deployment problems
Gianny, It was a mutlicast problem. After I turned the firewall off (service iptables stop), the sample app ran as expected. ++Vamsi On Thu, Mar 20, 2008 at 2:24 PM, Gianny Damour [EMAIL PROTECTED] wrote: Hello Vamsi, If the applications display distinct numbers, then the nodes do not see each other. I think this is a problem with multicasting. Could you please confirm that you have uncommented the last line of etc/rc.d/start-server,default.groovy which sets the system property java.net.preferIPv4Stack? Without this property set to true, multicasting fails at least on Mac OS X and maybe FC. If this property is already set, then I suggest you to check that multicasting is working ok on your box. Thanks, Gianny On 20/03/2008, at 4:08 AM, Vamsavardhana Reddy wrote: Hi Gianny, I observe that the sample application does not run as expected when I try the clustering scenario on FedoraCore. Application running on each node displays its own set of numbers starting from 1 with the background color of the squares being the node.name set at startup. I observed the same behavior with G Jetty 2.1 and G Tomcat 2.1 distros. What is to be done differently on Linux? ++Vamsi \
Re: timeout for geronimo/start-server
Ok. I guess it's not working as expected then. It just shuts down the server after the x number of seconds (when running in foreground or background). Jarek On Thu, Mar 20, 2008 at 1:32 AM, Jason Dillon [EMAIL PROTECTED] wrote: Its the time the server must have started up, when using the -- background option. --jason On Mar 20, 2008, at 1:58 AM, Jarek Gawor wrote: The geronimo/start-server command has a timeout option: -t (--timeout) N Specify the timeout for the server process in seconds. What is this timeout for exactly? The time in which the server must start up in (that is, the command fails if the server does not start in X seconds) or the time for long to run the server (that is, run the server for x seconds, and after x seconds shut it down)? Jarek
Re: javamail 1.4-SNAPSHOT and a Geronimo 2.1.1 release
Joe Bohn wrote: 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 I think Rick is tied up with other things at the moment. I'll try my hand at getting a geronimo-javamail 1.4 release out (it will be good practice for 2.1.1). Please speak up if there is anything that we should consider before starting a release. Joe
2.1.1 release status
It was originally my intention to branch tomorrow in prep for a 2.1.1 release - creating branches/2.1.1 and changing the version on branches/2.1 to 2.1.2-SNAPSHOT. However, there are a number of items still yet to be resolved so e not yet ready to branch: - Moving to OpenEJB 3.0 - The previous vote on 3.0 was canceled - awaiting a new release candidate. - Eliminating geronimo-javamail SNAPSHOT dependency by either releasing a geronimo-javamail 1.4 or reverting to 1.3. I'll see if I can help out with releasing geronimo-javamail 1.4. - Possible release of activemq 4.1.2. - Several JIRAs that were identified for this release including: GERONIMO-3354 (related to the openejb activemq upgrades) GERONIMO-3781 GERONIMO-3837 (need to clarify if there is anything remaining here) GERONIMO-3850 3851 - Plan creator fixes Detailed status is here: http://cwiki.apache.org/GMOxPMGT/geronimo-211-release-work-items-status.html My guess is that it will be at least another week before we are ready to branch. Thanks for being patient. Please continue to be exercise extreme care when working on the branches/2.1 (as all of you have been doing). Thanks, Joe
[jira] Created: (GERONIMO-3934) geronimo/start-server --timeout option does not work as expected
geronimo/start-server --timeout option does not work as expected Key: GERONIMO-3934 URL: https://issues.apache.org/jira/browse/GERONIMO-3934 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 The --timeout option specifies the time in which the server must start up in. However, it looks like the timeout causes the server to shutdown after the given number of seconds even if the server started up successfully. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3925) Monitoring agent should use JAXB to do XML manipulation
[ https://issues.apache.org/jira/browse/GERONIMO-3925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580785#action_12580785 ] Viet Hung Nguyen commented on GERONIMO-3925: Committed revision 639303 for trunk. Monitoring agent should use JAXB to do XML manipulation --- Key: GERONIMO-3925 URL: https://issues.apache.org/jira/browse/GERONIMO-3925 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1.1, 2.2 Reporter: Erik B. Craig Assignee: Viet Hung Nguyen xmlbeans is currently used to write out the xml in the monitoring agent. JAXB should be used to manipulation XML. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3925) Monitoring agent should use JAXB to do XML manipulation
[ https://issues.apache.org/jira/browse/GERONIMO-3925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen updated GERONIMO-3925: --- Patch Info: [Patch Available] Affects Version/s: (was: 2.2) Monitoring agent should use JAXB to do XML manipulation --- Key: GERONIMO-3925 URL: https://issues.apache.org/jira/browse/GERONIMO-3925 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1.1 Reporter: Erik B. Craig Assignee: Viet Hung Nguyen xmlbeans is currently used to write out the xml in the monitoring agent. JAXB should be used to manipulation XML. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3935) start-server command fails to parse arguments correctly
start-server command fails to parse arguments correctly --- Key: GERONIMO-3935 URL: https://issues.apache.org/jira/browse/GERONIMO-3935 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 bin/start-server command fails with a ProcessingException on some parameters that require arguments. For example: bin/start-server -l log Generates: org.apache.geronimo.gshell.clp.ProcessingException: Option -l (--logfile) takes an operand at org.apache.geronimo.gshell.clp.CommandLineProcessor$ParametersImpl.get(CommandLineProcessor.java:208) at org.apache.geronimo.gshell.clp.handler.FileHandler.handle(FileHandler.java:44) at org.apache.geronimo.gshell.clp.CommandLineProcessor.process(CommandLineProcessor.java:277) at org.apache.geronimo.gshell.command.CommandSupport.execute(CommandSupport.java:88) at org.apache.geronimo.gshell.plugin.PlexusCommandWrapper.execute(PlexusCommandWrapper.java:71) at org.apache.geronimo.gshell.DefaultCommandExecutor.execute(DefaultCommandExecutor.java:209) at org.apache.geronimo.gshell.ExecutingVisitor.visit(ExecutingVisitor.java:96) at org.apache.geronimo.gshell.parser.ASTExpression.jjtAccept(ASTExpression.java:17) at org.apache.geronimo.gshell.parser.SimpleNode.childrenAccept(SimpleNode.java:57) at org.apache.geronimo.gshell.ExecutingVisitor.visit(ExecutingVisitor.java:79) at org.apache.geronimo.gshell.parser.ASTCommandLine.jjtAccept(ASTCommandLine.java:17) at org.apache.geronimo.gshell.DefaultCommandLineBuilder$1.execute(DefaultCommandLineBuilder.java:95) at org.apache.geronimo.gshell.DefaultCommandExecutor.execute(DefaultCommandExecutor.java:86) This also applies to stop-server command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: jndi-name of legacy ejbs
On Mar 20, 2008, at 2:46 AM, Manu George wrote: Hi, When you are using ejb 2.1 you had to actually specify the jndi-name/local-jndi-name in the openejb-jar.xml. I believe that that name was used if you wanted to do a remote lookup etc. How was this used for local lookups? Were the ejbs available in the application specific jndi context with the local-jndi-name? I am not sure whether this was how it was supposed to work? if you are talking about openejb 2.x, then the jndi-name and local- jndi-name are completely ignored for the java:comp context. You have to specify what you want your ejb-ref to point to by a combination of ejb-links in the DD and plan, automatic matchirng rules, setting up the module/plugin/configuration tree, and explicitly specifying the target gbean. The [local]jndi names were used to bind to the corba naming service and to bind to the non-j2ee openejb remote context that can be used for non-j2ee clients. I don't recall what the local-jndi-names were used for. Currently I believe we are actually ignoring those names and constructing jndi names based on the same strategy we use for ejb3. Am I right about this? If so isn't this a bug that breaks backward compatibility? As long as we use ejb-refs there won't be any problem currently but if you try to access from a remote client the jndi name used will be different. I'm not sure what is happening now :-) thanks david jencks Regards Manu
Re: javamail 1.4-SNAPSHOT and a Geronimo 2.1.1 release
On Mar 20, 2008, at 7:22 AM, Joe Bohn wrote: Joe Bohn wrote: 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 I think Rick is tied up with other things at the moment. I'll try my hand at getting a geronimo-javamail 1.4 release out (it will be good practice for 2.1.1). Please speak up if there is anything that we should consider before starting a release. Changing the parent to genesis-1.4 and making sure the release plugin will work for it. Also making sure there's an at least minimal generated site. Let me know if you want advice, help, or me to do the conversion. thanks david jencks Joe
[jira] Commented: (GERONIMO-3934) geronimo/start-server --timeout option does not work as expected
[
https://issues.apache.org/jira/browse/GERONIMO-3934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580821#action_12580821
]
Jarek Gawor commented on GERONIMO-3934:
---
The important bit of code is the following:
if (timeout 0) {
log.info(Timeout after: ${timeout} seconds)
node.setAttribute('timeout', ${timeout * 1000})
}
That sets the timeout on the Ant Java task which explains why the --timeout
option behavior.
We can remove the piece of code but we still need a way to shutdown the server
in case it didn't start in time. And I'm not sure how to shutdown the server
process started via Ant.
Another way to make timeout option work right is to rewrite the
StartServerCommand to use ProcessBuilder API directly to start the server
process instead of Ant. But that's a bigger job.
geronimo/start-server --timeout option does not work as expected
Key: GERONIMO-3934
URL: https://issues.apache.org/jira/browse/GERONIMO-3934
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
The --timeout option specifies the time in which the server must start up in.
However, it looks like the timeout causes the server to shutdown after the
given number of seconds even if the server started up successfully.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: timeout for geronimo/start-server
Jason, I opened a bug on this issue (https://issues.apache.org/jira/browse/GERONIMO-3934) and another problem with gshell argument parsing (https://issues.apache.org/jira/browse/GERONIMO-3935). I would appreciate if you could comment on them. The argument parsing error seems more serious and would be good to have a fix for it in 2.1.1. Jarek On Thu, Mar 20, 2008 at 10:20 AM, Jarek Gawor [EMAIL PROTECTED] wrote: Ok. I guess it's not working as expected then. It just shuts down the server after the x number of seconds (when running in foreground or background). Jarek On Thu, Mar 20, 2008 at 1:32 AM, Jason Dillon [EMAIL PROTECTED] wrote: Its the time the server must have started up, when using the -- background option. --jason On Mar 20, 2008, at 1:58 AM, Jarek Gawor wrote: The geronimo/start-server command has a timeout option: -t (--timeout) N Specify the timeout for the server process in seconds. What is this timeout for exactly? The time in which the server must start up in (that is, the command fails if the server does not start in X seconds) or the time for long to run the server (that is, run the server for x seconds, and after x seconds shut it down)? Jarek
[jira] Updated: (GERONIMO-3935) start-server command fails to parse arguments correctly
[ https://issues.apache.org/jira/browse/GERONIMO-3935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-3935: -- Attachment: GERONIMO-3935.patch Added a patch that seems to fix the parsing issue. start-server command fails to parse arguments correctly --- Key: GERONIMO-3935 URL: https://issues.apache.org/jira/browse/GERONIMO-3935 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 Attachments: GERONIMO-3935.patch bin/start-server command fails with a ProcessingException on some parameters that require arguments. For example: bin/start-server -l log Generates: org.apache.geronimo.gshell.clp.ProcessingException: Option -l (--logfile) takes an operand at org.apache.geronimo.gshell.clp.CommandLineProcessor$ParametersImpl.get(CommandLineProcessor.java:208) at org.apache.geronimo.gshell.clp.handler.FileHandler.handle(FileHandler.java:44) at org.apache.geronimo.gshell.clp.CommandLineProcessor.process(CommandLineProcessor.java:277) at org.apache.geronimo.gshell.command.CommandSupport.execute(CommandSupport.java:88) at org.apache.geronimo.gshell.plugin.PlexusCommandWrapper.execute(PlexusCommandWrapper.java:71) at org.apache.geronimo.gshell.DefaultCommandExecutor.execute(DefaultCommandExecutor.java:209) at org.apache.geronimo.gshell.ExecutingVisitor.visit(ExecutingVisitor.java:96) at org.apache.geronimo.gshell.parser.ASTExpression.jjtAccept(ASTExpression.java:17) at org.apache.geronimo.gshell.parser.SimpleNode.childrenAccept(SimpleNode.java:57) at org.apache.geronimo.gshell.ExecutingVisitor.visit(ExecutingVisitor.java:79) at org.apache.geronimo.gshell.parser.ASTCommandLine.jjtAccept(ASTCommandLine.java:17) at org.apache.geronimo.gshell.DefaultCommandLineBuilder$1.execute(DefaultCommandLineBuilder.java:95) at org.apache.geronimo.gshell.DefaultCommandExecutor.execute(DefaultCommandExecutor.java:86) This also applies to stop-server command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: How is Geronimo different from Jboss?
Last time I checked JBoss was not Java EE 5 certified so it likely wont support all the bell and whistles from the spec. Cheers! Hernan newbie-gero wrote: Hi lists, I have been using jboss for 2 yrs and i now trying out Geronimo. I have read that jboss and Geronimo are both Java EE compliant. So what are the difference in jboss and Geroimo in terms of performance, usability etc? What are the things that geronimo have where jboss do not have? Thanks in advance
[jira] Updated: (GERONIMO-3935) start-server command fails to parse arguments correctly
[ https://issues.apache.org/jira/browse/GERONIMO-3935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-3935: -- Attachment: GERONIMO-3935.2.patch Actually, this patch might work better as it handles spaces in arguments. start-server command fails to parse arguments correctly --- Key: GERONIMO-3935 URL: https://issues.apache.org/jira/browse/GERONIMO-3935 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 Attachments: GERONIMO-3935.2.patch, GERONIMO-3935.patch bin/start-server command fails with a ProcessingException on some parameters that require arguments. For example: bin/start-server -l log Generates: org.apache.geronimo.gshell.clp.ProcessingException: Option -l (--logfile) takes an operand at org.apache.geronimo.gshell.clp.CommandLineProcessor$ParametersImpl.get(CommandLineProcessor.java:208) at org.apache.geronimo.gshell.clp.handler.FileHandler.handle(FileHandler.java:44) at org.apache.geronimo.gshell.clp.CommandLineProcessor.process(CommandLineProcessor.java:277) at org.apache.geronimo.gshell.command.CommandSupport.execute(CommandSupport.java:88) at org.apache.geronimo.gshell.plugin.PlexusCommandWrapper.execute(PlexusCommandWrapper.java:71) at org.apache.geronimo.gshell.DefaultCommandExecutor.execute(DefaultCommandExecutor.java:209) at org.apache.geronimo.gshell.ExecutingVisitor.visit(ExecutingVisitor.java:96) at org.apache.geronimo.gshell.parser.ASTExpression.jjtAccept(ASTExpression.java:17) at org.apache.geronimo.gshell.parser.SimpleNode.childrenAccept(SimpleNode.java:57) at org.apache.geronimo.gshell.ExecutingVisitor.visit(ExecutingVisitor.java:79) at org.apache.geronimo.gshell.parser.ASTCommandLine.jjtAccept(ASTCommandLine.java:17) at org.apache.geronimo.gshell.DefaultCommandLineBuilder$1.execute(DefaultCommandLineBuilder.java:95) at org.apache.geronimo.gshell.DefaultCommandExecutor.execute(DefaultCommandExecutor.java:86) This also applies to stop-server command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: How is Geronimo different from Jboss?
Hi, thanks for the information. It is quite informative. i like do some checks on the jboss and geronimo performance. Maybe we can discuss on that issues once i get some information Thanks Ch Praveena wrote: Hi, Very happy to see you with the lists. Even I was with the same work since few days in Evaluation of different application servers. But I am new to both Jboss and Geronimo too. You can go with this attachment delivering few points with my documentation. Let us discuss with some more points. Hope you will help me some how as you seemed to have few years experience in working with Jboss. I am sure that the document is not completed.. It will be build periodically. It was updated 15 days back. On 20/03/2008, newbie-gero [EMAIL PROTECTED] wrote: Hi lists, I have been using jboss for 2 yrs and i now trying out Geronimo. I have read that jboss and Geronimo are both Java EE compliant. So what are the difference in jboss and Geroimo in terms of performance, usability etc? What are the things that geronimo have where jboss do not have? Thanks in advance -- View this message in context: http://www.nabble.com/How-is-Geronimo-different-from-Jboss--tp16173233s134p16173233.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com. -- Regards, Praveena Chalamcharla, Securview -- View this message in context: http://www.nabble.com/How-is-Geronimo-different-from-Jboss--tp16173233s134p16184177.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[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=12580856#action_12580856 ] Vasily Zakharov commented on GERONIMO-3354: --- By the way, SPECjAppServer2004 is also affected by this problem. 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.
What are the ways to check Geronimo performance?
Hi lists, i have read up about the Geronimo and it seems to be a very good application server. However i like to check the performance of Geronimo. So i like to ask all of you what are the ways to check for the scalability, invocation speed, how much it can handle multi threaded functions, the transport speed. Therefore i like to know what are the test tools i can use or implement or how to go about it. Do any of you have done these before? Thanks in advance -- View this message in context: http://www.nabble.com/What-are-the-ways-to-check-Geronimo-performance--tp16184525s134p16184525.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: What are the ways to check Geronimo performance?
On Mar 20, 2008, at 1:28 PM, newbie-gero wrote: Hi lists, i have read up about the Geronimo and it seems to be a very good application server. However i like to check the performance of Geronimo. So i like to ask all of you what are the ways to check for the scalability, invocation speed, how much it can handle multi threaded functions, the transport speed. Therefore i like to know what are the test tools i can use or implement or how to go about it. Do any of you have done these before? You can find some Geronimo performance measurements as follows: Geronimo 1.1 data is here -- http://people.apache.org/~hogstrom/Geronimo-1.1.1-PerformanceReport.pdf Geronimo 2.0 data is here -- http://people.apache.org/~hogstrom/performance/geronimo/2.0/Geronimo2.0.2PerformanceReport-v01draft.pdf --kevan
Re: Problem when Geronimo Tomcat 2.1 server is started using start-server
Vamsi, Can you open a bug on this? I also see the same problem on Windows. I tested this a bit and it looks like a problem in WindowsTerminal in JLine somewhere. As a workaround, you can start gshell with -T false option and then control-c worked fine while running the server in foreground. Jarek On Mon, Feb 25, 2008 at 11:29 AM, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: On Windows XP, if I start a Geronimo Tomcat 2.1 server using bin\start-server from a command prompt, I am noticing that the server can not be shutdown using Control+C. So, I am using Admin Console to shutdown the server. But it does not return to command prompt unless I kill the java process from Windows Task Manager. Has anyone else came across this problem? Is there a JIRA for this? Any insight into what is happening? ++Vamsi
Re: What are the ways to check Geronimo performance?
On Mar 20, 2008, at 10:28 AM, newbie-gero wrote: Hi lists, i have read up about the Geronimo and it seems to be a very good application server. However i like to check the performance of Geronimo. So i like to ask all of you what are the ways to check for the scalability, invocation speed, how much it can handle multi threaded functions, the transport speed. Therefore i like to know what are the test tools i can use or implement or how to go about it. Do any of you have done these before? Well, Matt Hogstrom did a lot of work along these lines but he's not very active at the moment. We have a benchmarking application called daytrader that can be used to test a lot of functionality. However IMO it is rather difficult to get useful comparative information between app servers without an enormous amount of work and hardware. Basically with tuning any well-known app server goes pretty darn fast, and in any particular benchmarketing study usually the one that the organization that does the study is more familiar with wins due to better tuning. I think the main use of apps like this is to pinpoint specific performance bottlenecks and provide a relatively controlled environment to try out solutions for them. some of the things you are likely to need to get meaningful results: one or more real servers (multiprocessor multicore) lots of client machines a c-based test harness (Matt couldn't find a java based test harness that could keep up with the server) Kevan's provided links to a couple of Matt's reports. At one time geronimo 2.x had severe performance problems looking up Datasources in jndi, but this has been fixed. I'm not sure if the latest report is before or after this fix. thanks david jencks Thanks in advance -- View this message in context: http://www.nabble.com/What-are-the- ways-to-check-Geronimo-performance--tp16184525s134p16184525.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: What are the ways to check Geronimo performance?
djencks wrote: On Mar 20, 2008, at 10:28 AM, newbie-gero wrote: Hi lists, i have read up about the Geronimo and it seems to be a very good application server. However i like to check the performance of Geronimo. So i like to ask all of you what are the ways to check for the scalability, invocation speed, how much it can handle multi threaded functions, the transport speed. Therefore i like to know what are the test tools i can use or implement or how to go about it. Do any of you have done these before? Well, Matt Hogstrom did a lot of work along these lines but he's not very active at the moment. We have a benchmarking application called daytrader that can be used to test a lot of functionality. However IMO it is rather difficult to get useful comparative information between app servers without an enormous amount of work and hardware. Basically with tuning any well-known app server goes pretty darn fast, and in any particular benchmarketing study usually the one that the organization that does the study is more familiar with wins due to better tuning. I think the main use of apps like this is to pinpoint specific performance bottlenecks and provide a relatively controlled environment to try out solutions for them. some of the things you are likely to need to get meaningful results: one or more real servers (multiprocessor multicore) lots of client machines a c-based test harness (Matt couldn't find a java based test harness that could keep up with the server) Kevan's provided links to a couple of Matt's reports. At one time geronimo 2.x had severe performance problems looking up Datasources in jndi, but this has been fixed. I'm not sure if the latest report is before or after this fix. thanks david jencks Hi, i have read up the reports. And yes, they are very informative and i do get an idea on what are the tests that need to be done. However i like to ask what are the tools to get those graphs on the performance of Geronimo because i like to write up a proposal for geronimo and i like to present live data on the performance of Geronimo. Thanks newbie Thanks in advance -- View this message in context: http://www.nabble.com/What-are-the- ways-to-check-Geronimo-performance--tp16184525s134p16184525.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/What-are-the-ways-to-check-Geronimo-performance--tp16184525s134p16186619.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[BUILD] branches/2.1: Failed for Revision: 639386
Geronimo Revision: 639386 built with tests included See the full build-1400.log file at http://geronimo.apache.org/maven/server/binaries/2.1/20080320/build-1400.log Download the binaries from http://geronimo.apache.org/maven/server/binaries/2.1/20080320 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 33 minutes 15 seconds [INFO] Finished at: Thu Mar 20 14:57:12 EDT 2008 [INFO] Final Memory: 301M/1007M [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/2.1/20080320/logs-1400-tomcat/test.log Assembly: jetty = See the full test.log file at http://geronimo.apache.org/maven/server/binaries/2.1/20080320/logs-1400-jetty/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 72.131 sec FAILURE! Samples: branches/2.1 = Log: http://geronimo.apache.org/maven/server/binaries/2.1/20080320/samples-1400.log Build status: FAILED
[jira] Updated: (GERONIMO-3876) Allow configuring JMX over SSL
[ https://issues.apache.org/jira/browse/GERONIMO-3876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-3876: -- Attachment: GERONIMO-3876-B.patch GERONIMO-3876-B.patch: Start the JMX server asynchronously when SSL is configured. Allow configuring JMX over SSL -- Key: GERONIMO-3876 URL: https://issues.apache.org/jira/browse/GERONIMO-3876 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: management, security Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.1, 2.2 Attachments: GERONIMO-3876-B.patch, GERONIMO-3876.patch Currently JMX connections to Geronimo or non-SSL and Geronimo does not provide configuring SSL for JMX connections. It may be useful to provide configuration for JMX connections over SSL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
GERONIMO-3876: Allow configuring JMX over SSL
I am working on providing configuration of JMX over SSL. Here is a situation I have run into and I want others inputs. I want to use Keystore GBean to configure the keystore and truststore required by the connector. Here is the part that I am sure of. org.apache.geronimo.jmxremoting.JMXConnector GBean needs the following additional attributes and references to specify the SSL configuration: 1. sslEnabled : true/false 2. algorithm : Default/SunX509/IBMX509 3. secureProtocol: SSL/TLS 4. keyStore 5. keyAlias 6. trustStore 7. clientAuth : true/false 8. keystoreManager : A reference to keystore manager. Here are some of the approaches and the problems I have run into. Approach-A) The JMXConnector GBean is right now in j2ee-security configuration. Unless the keystore GBeans are started before the JMXConnector GBean, it will not work as expected. The order in which keystore GBeans appear in the plan also seems to matter. Currently Keystore GBean(s) are in server-security-config. Either the keystore GBeans should be moved to j2ee-security or the JMXConnector needs to be moved to server-security-config. Approach-B) Have a reference collection listener listen to the Keystore GBeans being added. In this case, the JMX Server will have to be started in the listener class. The problem with this approach is that the JMXConnector.doStart() can not wait for the listener class to start the JMX server. So, the JMX server will be started only after the JMXConnector.doStart() has completed. If the JMX server startup fails in the collection listener, there is no way to make JMXConnector GBean to fail at startup (as it has already started successfully!!). Another problem is that if the configured keystore does not exist, the collection listener will never know about it and JMX server will not start. Both the patches are attached in the JIRA. Please comment on these two approaches and suggest any improvements that I may have missed out.
[jira] Updated: (GERONIMO-3806) CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB jar
[
https://issues.apache.org/jira/browse/GERONIMO-3806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
toby cabot updated GERONIMO-3806:
-
Attachment: GERONIMO-3806-2.0.2.patch
Hi Manu, thanks for giving this your attention.
I tried your patch and it had the same problem as the old code, i.e. it
displayed the spurious warnings. The problem appears to be that a resource ref
might be resolved after you've added its name to unresolvedRefs.
I modified your patch so it applies to 2.0.2 (which is what I'm using) and
added a line to take the name out of unresolvedRefs if we find it later. That
works for my application. I also added back the debug line that I found useful
in looking for the problem.
Thanks!
Toby
CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB
jar
-
Key: GERONIMO-3806
URL: https://issues.apache.org/jira/browse/GERONIMO-3806
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 2.0.2, 2.1, 2.1.1, 2.2
Environment: Windows XP SP2
Reporter: toby cabot
Assignee: toby cabot
Priority: Minor
Fix For: 2.1.1, 2.2
Attachments: GERONIMO-3806-2.0.2.patch, GERONIMO-3806_r638814.patch
During deployment of one of my EJB jar files in my EAR, I get the following
WARN messages:
{code}
14:29:37,425 WARN [AdminObjectRefBuilder] Failed to build reference to Admin
object reference [jms/UnsequencedDestination, jms/MailQueue,
jms/InboundEventQueue, jms/OutboundQueue, jms/SystemQueue, jms/ActionQueue,
jms/SequencedDestination, jms/InboundIntegrationQueue,
jms/OutboundEventQueue] defined in plan file, reason - corresponding entry in
deployment descriptor missing.
14:29:37,440 WARN [ResourceRefBuilder] Failed to build reference to resource
reference [jms/ConnectionFactory, jms/QueueConnectionFactory,
mail/MailSession, jms/TopicConnectionFactory] defined in plan file, reason -
corresponding entry in deployment descriptor missing.
{code}
This occurs at the point in the following point in the stack:
{code}
AdminObjectRefBuilder.buildNaming(XmlObject, XmlObject, Module, Map) line: 160
{code}
The specDD that is passed in is a XML fragment for a specific session bean.
However, the plan that is passed in contains all the resource-ref and
resource-env-ref elements in the openejb-jar.xml plan. Therefore, the
refMap variable does not get completely emptied out, since the specific
session bean will only contain a subset of the resource-env-refs that are
defined in the plan.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3806) CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB jar
[
https://issues.apache.org/jira/browse/GERONIMO-3806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
toby cabot updated GERONIMO-3806:
-
Attachment: (was: bug3806-patch.txt)
CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB
jar
-
Key: GERONIMO-3806
URL: https://issues.apache.org/jira/browse/GERONIMO-3806
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 2.0.2, 2.1, 2.1.1, 2.2
Environment: Windows XP SP2
Reporter: toby cabot
Assignee: toby cabot
Priority: Minor
Fix For: 2.1.1, 2.2
Attachments: GERONIMO-3806-2.0.2.patch, GERONIMO-3806_r638814.patch
During deployment of one of my EJB jar files in my EAR, I get the following
WARN messages:
{code}
14:29:37,425 WARN [AdminObjectRefBuilder] Failed to build reference to Admin
object reference [jms/UnsequencedDestination, jms/MailQueue,
jms/InboundEventQueue, jms/OutboundQueue, jms/SystemQueue, jms/ActionQueue,
jms/SequencedDestination, jms/InboundIntegrationQueue,
jms/OutboundEventQueue] defined in plan file, reason - corresponding entry in
deployment descriptor missing.
14:29:37,440 WARN [ResourceRefBuilder] Failed to build reference to resource
reference [jms/ConnectionFactory, jms/QueueConnectionFactory,
mail/MailSession, jms/TopicConnectionFactory] defined in plan file, reason -
corresponding entry in deployment descriptor missing.
{code}
This occurs at the point in the following point in the stack:
{code}
AdminObjectRefBuilder.buildNaming(XmlObject, XmlObject, Module, Map) line: 160
{code}
The specDD that is passed in is a XML fragment for a specific session bean.
However, the plan that is passed in contains all the resource-ref and
resource-env-ref elements in the openejb-jar.xml plan. Therefore, the
refMap variable does not get completely emptied out, since the specific
session bean will only contain a subset of the resource-env-refs that are
defined in the plan.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: svn commit: r639435 - in /geronimo/server/branches/2.1: framework/configs/offline-deployer/src/main/plan/ framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/logging/log4j/
Donald,
I'm not sure about this. 1) There is a compile problem in
JvmVendor.java, 2) I don't think Log4jService.java should hard-code
some JDK name. It should get the proper name from JvmVendor class,
e.g. JvmVendor.getJavaVendor() or something. 3) I'm not sure about
SystemProperties being extended to support three JVM-specific
properties (btw, the sun properties handling is confusing since it
assumes that bSun = !bIBM !bApache but that's just means 'other').
I think we should leave the SystemProperties as it was and provide
some other way to support arbitrary number and type of the JVMs. For
example, we could have a JVM-specific implementation of the
SystemProperties gbean that would only set the properties when the
given JVM is detected.
Jarek
On Thu, Mar 20, 2008 at 4:09 PM, [EMAIL PROTECTED] wrote:
Author: dwoods
Date: Thu Mar 20 13:09:03 2008
New Revision: 639435
URL: http://svn.apache.org/viewvc?rev=639435view=rev
Log:
GERONIMO-3900 Add runtime support for non-Sun JVMs
Added:
geronimo/server/branches/2.1/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/properties/JvmVendor.java
(with props)
Modified:
geronimo/server/branches/2.1/framework/configs/offline-deployer/src/main/plan/plan.xml
geronimo/server/branches/2.1/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/logging/log4j/Log4jService.java
geronimo/server/branches/2.1/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/properties/SystemProperties.java
geronimo/server/branches/2.1/plugins/client/client/src/main/plan/plan.xml
geronimo/server/branches/2.1/plugins/j2ee/j2ee-server/src/main/plan/plan.xml
Modified:
geronimo/server/branches/2.1/framework/configs/offline-deployer/src/main/plan/plan.xml
URL:
http://svn.apache.org/viewvc/geronimo/server/branches/2.1/framework/configs/offline-deployer/src/main/plan/plan.xml?rev=639435r1=639434r2=639435view=diff
==
---
geronimo/server/branches/2.1/framework/configs/offline-deployer/src/main/plan/plan.xml
(original)
+++
geronimo/server/branches/2.1/framework/configs/offline-deployer/src/main/plan/plan.xml
Thu Mar 20 13:09:03 2008
@@ -31,7 +31,16 @@
!-- System Properties --
gbean name=OfflineDeployerProperties
class=org.apache.geronimo.system.properties.SystemProperties
attribute name=systemProperties
-
org.apache.geronimo.deployment.util.DeploymentUtil.jarUrlRewrite=true
+
org.apache.geronimo.deployment.util.DeploymentUtil.jarUrlRewrite=true
/attribute
+ attribute name=sunSystemProperties
+ java.security.Provider=SUN
+ /attribute
+ attribute name=ibmSystemProperties
+ java.security.Provider=IBMCertPath
+ /attribute
+ attribute name=apacheSystemProperties
+ java.naming.factory.url.pkgs=org.apache.harmony.jndi.provider
+ /attribute
/gbean
/module
Modified:
geronimo/server/branches/2.1/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/logging/log4j/Log4jService.java
URL:
http://svn.apache.org/viewvc/geronimo/server/branches/2.1/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/logging/log4j/Log4jService.java?rev=639435r1=639434r2=639435view=diff
==
---
geronimo/server/branches/2.1/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/logging/log4j/Log4jService.java
(original)
+++
geronimo/server/branches/2.1/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/logging/log4j/Log4jService.java
Thu Mar 20 13:09:03 2008
@@ -51,6 +51,7 @@
import org.apache.geronimo.kernel.log.GeronimoLogFactory;
import org.apache.geronimo.kernel.log.GeronimoLogging;
import org.apache.geronimo.system.logging.SystemLog;
+import org.apache.geronimo.system.properties.JvmVendor;
import org.apache.geronimo.system.serverinfo.DirectoryUtils;
import org.apache.geronimo.system.serverinfo.ServerConstants;
import org.apache.geronimo.system.serverinfo.ServerInfo;
@@ -632,7 +633,11 @@
, refreshPeriodSeconds= + this.refreshPeriod);
log.info(Runtime Information:);
log.info( Install Directory = +
DirectoryUtils.getGeronimoInstallDirectory().toString());
- log.info( JVM in use = + System.getProperty(java.vendor) +
Java + System.getProperty(java.version));
+ if (JvmVendor.isIBMHybrid()) {
+ log.info( JVM in use = IBM Hybrid Java +
System.getProperty(java.version));
+ } else {
+ log.info( JVM in use = +
System.getProperty(java.vendor) + Java +
System.getProperty(java.version));
+ }
Re: GERONIMO-3876: Allow configuring JMX over SSL
On Mar 20, 2008, at 1:48 PM, Vamsavardhana Reddy wrote: I am working on providing configuration of JMX over SSL. Here is a situation I have run into and I want others inputs. I want to use Keystore GBean to configure the keystore and truststore required by the connector. Here is the part that I am sure of. org.apache.geronimo.jmxremoting.JMXConnector GBean needs the following additional attributes and references to specify the SSL configuration: 1. sslEnabled : true/false 2. algorithm : Default/SunX509/IBMX509 3. secureProtocol: SSL/TLS 4. keyStore 5. keyAlias 6. trustStore 7. clientAuth : true/false 8. keystoreManager : A reference to keystore manager. Here are some of the approaches and the problems I have run into. Approach-A) The JMXConnector GBean is right now in j2ee-security configuration. Unless the keystore GBeans are started before the JMXConnector GBean, it will not work as expected. The order in which keystore GBeans appear in the plan also seems to matter. Currently Keystore GBean(s) are in server-security-config. Either the keystore GBeans should be moved to j2ee-security or the JMXConnector needs to be moved to server-security-config. IMO moving the keystore gbeans to j2ee-security is a bad idea, the whole point of server-security-config was to put all the stuff you'd want to change in a real installation in server-security-config while leaving the stuff you probably don't want to change in j2ee- security. Moving the jmx gbean to server-security-config would be ok but make setting up a new server-security-config more error-prone (if you left out the jmx gbean) Approach-B) Have a reference collection listener listen to the Keystore GBeans being added. In this case, the JMX Server will have to be started in the listener class. The problem with this approach is that the JMXConnector.doStart() can not wait for the listener class to start the JMX server. So, the JMX server will be started only after the JMXConnector.doStart() has completed. If the JMX server startup fails in the collection listener, there is no way to make JMXConnector GBean to fail at startup (as it has already started successfully!!). Another problem is that if the configured keystore does not exist, the collection listener will never know about it and JMX server will not start. Both the patches are attached in the JIRA. Please comment on these two approaches and suggest any improvements that I may have missed out. Approach-C) Use the gbean impl from (A) and introduce a third security plugin depending on server-security-config that has the gbean config in it. That way when you replace server-security-config with an actually usable security setup for your server you don't need to remember to include a jmx gbean. This also makes it easier to hide geronimo from jmx by not including or starting this plugin. I personally don't have a strong preference between these 3 options.
Re: svn commit: r639435 - in /geronimo/server/branches/2.1: framework/configs/offline-deployer/src/main/plan/ framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/logging/log4j/
1) Fixed in Rev639504. Sorry, I got a interrupt before my local build hit it. 2) Done. Thanks for the review and feedback. 3) Unfortunately, I'm not sure if this would be possible, given the unique checks we have to perform for some of the IBM JVMs, which are hybrid packages of the Sun JVM + IBM extensions on Sun and HP-UX. There could be some other checks that are required, if someone has a iSeries or zSeries to test upon. Also, the Apache Harmony support is not complete, but the apacheSystemProperties will be detected and applied correctly if supplied, based on the Harmony 5.0M5 build. -Donald Jarek Gawor wrote: Donald, I'm not sure about this. 1) There is a compile problem in JvmVendor.java, 2) I don't think Log4jService.java should hard-code some JDK name. It should get the proper name from JvmVendor class, e.g. JvmVendor.getJavaVendor() or something. 3) I'm not sure about SystemProperties being extended to support three JVM-specific properties (btw, the sun properties handling is confusing since it assumes that bSun = !bIBM !bApache but that's just means 'other'). I think we should leave the SystemProperties as it was and provide some other way to support arbitrary number and type of the JVMs. For example, we could have a JVM-specific implementation of the SystemProperties gbean that would only set the properties when the given JVM is detected. Jarek On Thu, Mar 20, 2008 at 4:09 PM, [EMAIL PROTECTED] wrote: Author: dwoods Date: Thu Mar 20 13:09:03 2008 New Revision: 639435 URL: http://svn.apache.org/viewvc?rev=639435view=rev Log: GERONIMO-3900 Add runtime support for non-Sun JVMs Added: geronimo/server/branches/2.1/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/properties/JvmVendor.java (with props) Modified: geronimo/server/branches/2.1/framework/configs/offline-deployer/src/main/plan/plan.xml geronimo/server/branches/2.1/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/logging/log4j/Log4jService.java geronimo/server/branches/2.1/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/properties/SystemProperties.java geronimo/server/branches/2.1/plugins/client/client/src/main/plan/plan.xml geronimo/server/branches/2.1/plugins/j2ee/j2ee-server/src/main/plan/plan.xml Modified: geronimo/server/branches/2.1/framework/configs/offline-deployer/src/main/plan/plan.xml URL: http://svn.apache.org/viewvc/geronimo/server/branches/2.1/framework/configs/offline-deployer/src/main/plan/plan.xml?rev=639435r1=639434r2=639435view=diff == --- geronimo/server/branches/2.1/framework/configs/offline-deployer/src/main/plan/plan.xml (original) +++ geronimo/server/branches/2.1/framework/configs/offline-deployer/src/main/plan/plan.xml Thu Mar 20 13:09:03 2008 @@ -31,7 +31,16 @@ !-- System Properties -- gbean name=OfflineDeployerProperties class=org.apache.geronimo.system.properties.SystemProperties attribute name=systemProperties - org.apache.geronimo.deployment.util.DeploymentUtil.jarUrlRewrite=true + org.apache.geronimo.deployment.util.DeploymentUtil.jarUrlRewrite=true /attribute + attribute name=sunSystemProperties + java.security.Provider=SUN + /attribute + attribute name=ibmSystemProperties + java.security.Provider=IBMCertPath + /attribute + attribute name=apacheSystemProperties + java.naming.factory.url.pkgs=org.apache.harmony.jndi.provider + /attribute /gbean /module Modified: geronimo/server/branches/2.1/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/logging/log4j/Log4jService.java URL: http://svn.apache.org/viewvc/geronimo/server/branches/2.1/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/logging/log4j/Log4jService.java?rev=639435r1=639434r2=639435view=diff == --- geronimo/server/branches/2.1/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/logging/log4j/Log4jService.java (original) +++ geronimo/server/branches/2.1/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/logging/log4j/Log4jService.java Thu Mar 20 13:09:03 2008 @@ -51,6 +51,7 @@ import org.apache.geronimo.kernel.log.GeronimoLogFactory; import org.apache.geronimo.kernel.log.GeronimoLogging; import org.apache.geronimo.system.logging.SystemLog; +import org.apache.geronimo.system.properties.JvmVendor; import org.apache.geronimo.system.serverinfo.DirectoryUtils; import org.apache.geronimo.system.serverinfo.ServerConstants; import org.apache.geronimo.system.serverinfo.ServerInfo; @@ -632,7 +633,11 @@ , refreshPeriodSeconds= + this.refreshPeriod);
Re: Geronimo 2.1 working on Harmony
I just added some JVM vendor specific support under GERONIMO-3900 in branches/2.1 (and will add it to trunk tomorrow), which will allow you to provide Harmony specific system properties via the apacheSystemProperties attribute on the SystemProperties GBean. -Donald Vasily Zakharov wrote: Step two is to figure out how to recognize the vm in groovy and run some code or a script depending on the vm. The harmony vm could set some system properties to override the appropriate variable values in config-substitutions.properties. Here's what we have now: java.runtime.name=Apache Harmony java.runtime.version=1.5.0 java.vendor.url=http://harmony.apache.org java.vendor=Apache Software Foundation java.vm.name=DRLVM java.vm.vendor=Apache Software Foundation Or you mean we should include some Geronimo-specific properties to Harmony default environment? Vasily smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r639303 - in /geronimo/server/trunk/plugins/monitoring/agent-jar: ./ src/main/java/org/apache/geronimo/monitoring/snapshot/ src/xsd/
[EMAIL PROTECTED] wrote:
Author: viet
Date: Thu Mar 20 07:56:56 2008
New Revision: 639303
URL: http://svn.apache.org/viewvc?rev=639303view=rev
Log:
Fix for Geronimo-3925. Uses JAXB to manipulate XML.
Added:
geronimo/server/trunk/plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/ObjectFactory.java
(with props)
geronimo/server/trunk/plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/SnapshotConfig.java
(with props)
geronimo/server/trunk/plugins/monitoring/agent-jar/src/xsd/
geronimo/server/trunk/plugins/monitoring/agent-jar/src/xsd/SnapshotConfig.xsd
(with props)
Modified:
geronimo/server/trunk/plugins/monitoring/agent-jar/pom.xml
geronimo/server/trunk/plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/SnapshotConfigXMLBuilder.java
Modified: geronimo/server/trunk/plugins/monitoring/agent-jar/pom.xml
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/monitoring/agent-jar/pom.xml?rev=639303r1=639302r2=639303view=diff
==
--- geronimo/server/trunk/plugins/monitoring/agent-jar/pom.xml (original)
+++ geronimo/server/trunk/plugins/monitoring/agent-jar/pom.xml Thu Mar 20
07:56:56 2008
@@ -53,6 +53,18 @@
artifactIdgeronimo-j2ee-management_1.1_spec/artifactId
scopeprovided/scope
/dependency
+
+dependency
+groupIdjavax.xml.bind/groupId
+artifactIdjaxb-api/artifactId
+version2.0/version
Can you remove the explicit version and use the one set by
trunk/server/pom.xml?
+exclusions
+exclusion
+groupIdjavax.xml.bind/groupId
+artifactIdjsr173_api/artifactId
+/exclusion
+/exclusions
+/dependency
/dependencies
/project
Added:
geronimo/server/trunk/plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/ObjectFactory.java
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/ObjectFactory.java?rev=639303view=auto
==
---
geronimo/server/trunk/plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/ObjectFactory.java
(added)
+++
geronimo/server/trunk/plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/ObjectFactory.java
Thu Mar 20 07:56:56 2008
@@ -0,0 +1,57 @@
+//
+// This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, v2.0-b26-ea3
+// See a href=http://java.sun.com/xml/jaxb;http://java.sun.com/xml/jaxb/a
+// Any modifications to this file will be lost upon recompilation of the source schema.
+// Generated on: 2008.03.18 at 12:52:02 AM GMT-05:00
+//
+
+
+package org.apache.geronimo.monitoring.snapshot;
+
+import javax.xml.bind.annotation.XmlRegistry;
+import org.apache.geronimo.monitoring.snapshot.SnapshotConfig;
+import org.apache.geronimo.monitoring.snapshot.SnapshotConfig.Mbeans;
+
+
+/**
+ * This object contains factory methods for each
+ * Java content interface and Java element interface
+ * generated in the org.apache.geronimo package.
+ * pAn ObjectFactory allows you to programatically
+ * construct new instances of the Java representation
+ * for XML content. The Java representation of XML
+ * content can consist of schema derived interfaces
+ * and classes representing the binding of schema
+ * type definitions, element declarations and model
+ * groups. Factory methods for each of these are
+ * provided in this class.
+ *
+ */
[EMAIL PROTECTED]
+public class ObjectFactory {
+
+
+/**
+ * Create a new ObjectFactory that can be used to create new instances of
schema derived classes for package: org.apache.geronimo
+ *
+ */
+public ObjectFactory() {
+}
+
+/**
+ * Create an instance of [EMAIL PROTECTED] Mbeans }
+ *
+ */
+public Mbeans createSnapshotConfigMbeans() {
+return new Mbeans();
+}
+
+/**
+ * Create an instance of [EMAIL PROTECTED] SnapshotConfig }
+ *
+ */
+public SnapshotConfig createSnapshotConfig() {
+return new SnapshotConfig();
+}
+
+}
Propchange:
geronimo/server/trunk/plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/ObjectFactory.java
--
svn:eol-style = native
Propchange:
geronimo/server/trunk/plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/ObjectFactory.java
--
svn:keywords = Date Revision
Propchange:
Re: What are the ways to check Geronimo performance?
On 21/03/2008, at 4:53 AM, David Jencks wrote: On Mar 20, 2008, at 10:28 AM, newbie-gero wrote: Hi lists, i have read up about the Geronimo and it seems to be a very good application server. However i like to check the performance of Geronimo. So i like to ask all of you what are the ways to check for the scalability, invocation speed, how much it can handle multi threaded functions, the transport speed. Therefore i like to know what are the test tools i can use or implement or how to go about it. Do any of you have done these before? Well, Matt Hogstrom did a lot of work along these lines but he's not very active at the moment. We have a benchmarking application called daytrader that can be used to test a lot of functionality. However IMO it is rather difficult to get useful comparative information between app servers without an enormous amount of work and hardware. Basically with tuning any well-known app server goes pretty darn fast, and in any particular benchmarketing study usually the one that the organization that does the study is more familiar with wins due to better tuning. I think the main use of apps like this is to pinpoint specific performance bottlenecks and provide a relatively controlled environment to try out solutions for them. some of the things you are likely to need to get meaningful results: one or more real servers (multiprocessor multicore) lots of client machines a c-based test harness (Matt couldn't find a java based test harness that could keep up with the server) FWIW, you may want to give a try to tsung, http://tsung.erlang- projects.org/. It is implemented in Erlang and, hence, can simulate a ludicrously large number of clients from a single host. Thanks, Gianny Kevan's provided links to a couple of Matt's reports. At one time geronimo 2.x had severe performance problems looking up Datasources in jndi, but this has been fixed. I'm not sure if the latest report is before or after this fix. thanks david jencks Thanks in advance -- View this message in context: http://www.nabble.com/What-are-the- ways-to-check-Geronimo-performance--tp16184525s134p16184525.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: svn commit: r639479 - in /geronimo/samples/branches/2.1/samples/inventory: inventory-ear/src/main/resources/META-INF/geronimo-application.xml inventory-war/src/main/webapp/WEB-INF/geronimo-web.xml
Hernan,
In case I missed it, can you also merge these changes to trunk?
Thanks,
Jarek
On Thu, Mar 20, 2008 at 6:04 PM, [EMAIL PROTECTED] wrote:
Author: hcunico
Date: Thu Mar 20 15:04:49 2008
New Revision: 639479
URL: http://svn.apache.org/viewvc?rev=639479view=rev
Log:
updated target name spaces in dep plans.
Modified:
geronimo/samples/branches/2.1/samples/inventory/inventory-ear/src/main/resources/META-INF/geronimo-application.xml
geronimo/samples/branches/2.1/samples/inventory/inventory-war/src/main/webapp/WEB-INF/geronimo-web.xml
Modified:
geronimo/samples/branches/2.1/samples/inventory/inventory-ear/src/main/resources/META-INF/geronimo-application.xml
URL:
http://svn.apache.org/viewvc/geronimo/samples/branches/2.1/samples/inventory/inventory-ear/src/main/resources/META-INF/geronimo-application.xml?rev=639479r1=639478r2=639479view=diff
==
---
geronimo/samples/branches/2.1/samples/inventory/inventory-ear/src/main/resources/META-INF/geronimo-application.xml
(original)
+++
geronimo/samples/branches/2.1/samples/inventory/inventory-ear/src/main/resources/META-INF/geronimo-application.xml
Thu Mar 20 15:04:49 2008
@@ -20,9 +20,9 @@
!-- $Rev: 497879 $ $Date: 2007-01-19 12:11:01 -0500 (Fri, 19 Jan 2007) $
--
-application xmlns=http://geronimo.apache.org/xml/ns/j2ee/application-1.1;
+application xmlns=http://geronimo.apache.org/xml/ns/j2ee/application-2.0;
-dep:environment
xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.1;
+dep:environment
xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.2;
dep:moduleId
dep:groupId${pom.groupId}/dep:groupId
dep:artifactId${pom.artifactId}/dep:artifactId
Modified:
geronimo/samples/branches/2.1/samples/inventory/inventory-war/src/main/webapp/WEB-INF/geronimo-web.xml
URL:
http://svn.apache.org/viewvc/geronimo/samples/branches/2.1/samples/inventory/inventory-war/src/main/webapp/WEB-INF/geronimo-web.xml?rev=639479r1=639478r2=639479view=diff
==
---
geronimo/samples/branches/2.1/samples/inventory/inventory-war/src/main/webapp/WEB-INF/geronimo-web.xml
(original)
+++
geronimo/samples/branches/2.1/samples/inventory/inventory-war/src/main/webapp/WEB-INF/geronimo-web.xml
Thu Mar 20 15:04:49 2008
@@ -18,7 +18,7 @@
under the License.
--
web-app
- xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-1.1;
+ xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1;
environment
moduleId
[jira] Assigned: (GERONIMO-3806) CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB jar
[
https://issues.apache.org/jira/browse/GERONIMO-3806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
toby cabot reassigned GERONIMO-3806:
Assignee: Manu T George (was: toby cabot)
CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB
jar
-
Key: GERONIMO-3806
URL: https://issues.apache.org/jira/browse/GERONIMO-3806
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 2.0.2, 2.1, 2.1.1, 2.2
Environment: Windows XP SP2
Reporter: toby cabot
Assignee: Manu T George
Priority: Minor
Fix For: 2.1.1, 2.2
Attachments: GERONIMO-3806-2.0.2.patch, GERONIMO-3806_r638814.patch
During deployment of one of my EJB jar files in my EAR, I get the following
WARN messages:
{code}
14:29:37,425 WARN [AdminObjectRefBuilder] Failed to build reference to Admin
object reference [jms/UnsequencedDestination, jms/MailQueue,
jms/InboundEventQueue, jms/OutboundQueue, jms/SystemQueue, jms/ActionQueue,
jms/SequencedDestination, jms/InboundIntegrationQueue,
jms/OutboundEventQueue] defined in plan file, reason - corresponding entry in
deployment descriptor missing.
14:29:37,440 WARN [ResourceRefBuilder] Failed to build reference to resource
reference [jms/ConnectionFactory, jms/QueueConnectionFactory,
mail/MailSession, jms/TopicConnectionFactory] defined in plan file, reason -
corresponding entry in deployment descriptor missing.
{code}
This occurs at the point in the following point in the stack:
{code}
AdminObjectRefBuilder.buildNaming(XmlObject, XmlObject, Module, Map) line: 160
{code}
The specDD that is passed in is a XML fragment for a specific session bean.
However, the plan that is passed in contains all the resource-ref and
resource-env-ref elements in the openejb-jar.xml plan. Therefore, the
refMap variable does not get completely emptied out, since the specific
session bean will only contain a subset of the resource-env-refs that are
defined in the plan.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: svn commit: r639303 - in /geronimo/server/trunk/plugins/monitoring/agent-jar: ./ src/main/java/org/apache/geronimo/monitoring/snapshot/ src/xsd/
Donald Woods wrote: snip + +dependency +groupIdjavax.xml.bind/groupId +artifactIdjaxb-api/artifactId +version2.0/version Can you remove the explicit version and use the one set by trunk/server/pom.xml? snip Good catch Donald ... thanks for reviewing the commits. Joe
Re: svn commit: r639303 - in /geronimo/server/trunk/plugins/monitoring/agent-jar: ./ src/main/java/org/apache/geronimo/monitoring/snapshot/ src/xsd/
Thanks Donald, I took out the version tag and inserted
scopeprovided/scope.
--Viet
On Thu, Mar 20, 2008 at 8:35 PM, Donald Woods [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Author: viet
Date: Thu Mar 20 07:56:56 2008
New Revision: 639303
URL: http://svn.apache.org/viewvc?rev=639303view=rev
Log:
Fix for Geronimo-3925. Uses JAXB to manipulate XML.
Added:
geronimo/server/trunk/plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/ObjectFactory.java
(with props)
geronimo/server/trunk/plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/SnapshotConfig.java
(with props)
geronimo/server/trunk/plugins/monitoring/agent-jar/src/xsd/
geronimo/server/trunk/plugins/monitoring/agent-jar/src/xsd/SnapshotConfig.xsd
(with props)
Modified:
geronimo/server/trunk/plugins/monitoring/agent-jar/pom.xml
geronimo/server/trunk/plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/SnapshotConfigXMLBuilder.java
Modified: geronimo/server/trunk/plugins/monitoring/agent-jar/pom.xml
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/monitoring/agent-jar/pom.xml?rev=639303r1=639302r2=639303view=diff
==
--- geronimo/server/trunk/plugins/monitoring/agent-jar/pom.xml (original)
+++ geronimo/server/trunk/plugins/monitoring/agent-jar/pom.xml Thu Mar 20
07:56:56 2008
@@ -53,6 +53,18 @@
artifactIdgeronimo-j2ee-management_1.1_spec/artifactId
scopeprovided/scope
/dependency
+
+dependency
+groupIdjavax.xml.bind/groupId
+artifactIdjaxb-api/artifactId
+version2.0/version
Can you remove the explicit version and use the one set by
trunk/server/pom.xml?
+exclusions
+exclusion
+groupIdjavax.xml.bind/groupId
+artifactIdjsr173_api/artifactId
+/exclusion
+/exclusions
+/dependency
/dependencies
/project
Added:
geronimo/server/trunk/plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/ObjectFactory.java
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/ObjectFactory.java?rev=639303view=auto
==
---
geronimo/server/trunk/plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/ObjectFactory.java
(added)
+++
geronimo/server/trunk/plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/ObjectFactory.java
Thu Mar 20 07:56:56 2008
@@ -0,0 +1,57 @@
+//
+// This file was generated by the JavaTM Architecture for XML
Binding(JAXB) Reference Implementation, v2.0-b26-ea3
+// See a
href=http://java.sun.com/xml/jaxb;http://java.sun.com/xml/jaxb/a
+// Any modifications to this file will be lost upon recompilation of the
source schema.
+// Generated on: 2008.03.18 at 12:52:02 AM GMT-05:00
+//
+
+
+package org.apache.geronimo.monitoring.snapshot;
+
+import javax.xml.bind.annotation.XmlRegistry;
+import org.apache.geronimo.monitoring.snapshot.SnapshotConfig;
+import org.apache.geronimo.monitoring.snapshot.SnapshotConfig.Mbeans;
+
+
+/**
+ * This object contains factory methods for each
+ * Java content interface and Java element interface
+ * generated in the org.apache.geronimo package.
+ * pAn ObjectFactory allows you to programatically
+ * construct new instances of the Java representation
+ * for XML content. The Java representation of XML
+ * content can consist of schema derived interfaces
+ * and classes representing the binding of schema
+ * type definitions, element declarations and model
+ * groups. Factory methods for each of these are
+ * provided in this class.
+ *
+ */
[EMAIL PROTECTED]
+public class ObjectFactory {
+
+
+/**
+ * Create a new ObjectFactory that can be used to create new
instances of schema derived classes for package: org.apache.geronimo
+ *
+ */
+public ObjectFactory() {
+}
+
+/**
+ * Create an instance of [EMAIL PROTECTED] Mbeans }
+ *
+ */
+public Mbeans createSnapshotConfigMbeans() {
+return new Mbeans();
+}
+
+/**
+ * Create an instance of [EMAIL PROTECTED] SnapshotConfig }
+ *
+ */
+public SnapshotConfig createSnapshotConfig() {
+return new SnapshotConfig();
+}
+
+}
Propchange:
[jira] Commented: (GERONIMO-3934) geronimo/start-server --timeout option does not work as expected
[ https://issues.apache.org/jira/browse/GERONIMO-3934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581005#action_12581005 ] Jason Dillon commented on GERONIMO-3934: I was mistaken, --verifyTimeout is for the verify bits and --timeout is for the process, meant to kill the server after a set time, used for tests to ensure that the server stops after some time. geronimo/start-server --timeout option does not work as expected Key: GERONIMO-3934 URL: https://issues.apache.org/jira/browse/GERONIMO-3934 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 The --timeout option specifies the time in which the server must start up in. However, it looks like the timeout causes the server to shutdown after the given number of seconds even if the server started up successfully. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
