Re: [VOTE} ActiveMQ 4.0 M4 2nd Release Candidate
+1 On 16 Feb 2006, at 09:14, Hiram Chirino wrote: Hi Guys, The first release candidate could not be used as on official release of M4 since it did not contain the proper DISCLAIMER.txt files in the jar files. The problem has now been fixed, and I have rebuilt a new release candidate for M4. As a side effect this new build now includes many of the bug fixes that were thought were going to go into the M5 release (JIRA still needs to be updated). I've posted it here: http://people.apache.org/~chirino/incubator-activemq-4.0-M4/ I've tagged the source for that build as: https://svn.apache.org/repos/asf/incubator/activemq/tags/ activemq-4.0-M4/activemq/ Please take a moment and review/test the binaries. And remember, this is just a milestone. Please consult JIRA to see if a specific bug has been fixed in this build. [ ] +1 Release the binary as our milestone 4 [ ] -1 Veto the milestone release (provide specific comments) If this vote passes, then we can send it once again to the Incubator PMC for their blessing before the official release. Regards, Hiram James --- http://radio.weblogs.com/0112098/
Re: [VOTE} ActiveMQ 4.0 M4 2nd Release Candidate
Here's my +1 Regards, Hiram On Feb 16, 2006, at 4:14 AM, Hiram Chirino wrote: Hi Guys, The first release candidate could not be used as on official release of M4 since it did not contain the proper DISCLAIMER.txt files in the jar files. The problem has now been fixed, and I have rebuilt a new release candidate for M4. As a side effect this new build now includes many of the bug fixes that were thought were going to go into the M5 release (JIRA still needs to be updated). I've posted it here: http://people.apache.org/~chirino/incubator-activemq-4.0-M4/ I've tagged the source for that build as: https://svn.apache.org/repos/asf/incubator/activemq/tags/ activemq-4.0-M4/activemq/ Please take a moment and review/test the binaries. And remember, this is just a milestone. Please consult JIRA to see if a specific bug has been fixed in this build. [ ] +1 Release the binary as our milestone 4 [ ] -1 Veto the milestone release (provide specific comments) If this vote passes, then we can send it once again to the Incubator PMC for their blessing before the official release. Regards, Hiram
Re: Build Problem
Hi Li, There's also an option in maven where you can disable running the unit test. Execute the command in activemq home directory maven -Dmaven.test.skip=true. Can we also have a copy of the maven build log file? this may provide information why the test-reports are not generated. The log file can be created by adding additional statement in the build command. e.g maven build.log. Hope this helps, Fritz - Original Message - From: Li, Fan [EMAIL PROTECTED] To: activemq-dev@geronimo.apache.org Sent: Friday, February 17, 2006 5:08 AM Subject: RE: Build Problem I did not find any occurrence of '[ERROR]' in my activemq directory after a build fail, although there are some occurrence of 'ERROR', none of them was in one of the /target/test-reports/TEST-$name.txt files. My platform is RedHat Linux 7.2 Thanks Fan -Original Message- From: James Strachan [mailto:[EMAIL PROTECTED] Sent: Thursday, February 16, 2006 11:17 AM To: activemq-dev@geronimo.apache.org Subject: Re: Build Problem That indicates there were some JUnit test failures. We have some tests that fail on some platforms with timing issues; its amazingly hard to write highly asynchronous concurrent message based unit test cases that always work on every platform. If you seach for [ERROR] you'll find the actual tests that failed. Then if you look in target/test-reports/TEST-$name.txt (in the module thats being built) you'll find the output of the test case. If you could post those it'd really help us fix it. James On 2/16/06, Li, Fan [EMAIL PROTECTED] wrote: I have been trying to build the latest source code with maven 1.0.2 and kept getting build failure. This is the build for the latest SNAPSHOT. I am not sure if anyone had similar problem. BUILD FAILED File.. /home/fanli/.maven/cache/maven-multiproject-plugin-1.3.1 /plugin.jelly Element... maven:reactor Line.. 217 Column 9 Unable to obtain goal [test:test] -- /home/fanli/.maven/cache/maven-test-plugin- 1.6.2/plugin.jelly:181:54: fail There were test failures. Total time: 58 minutes 22 seconds Finished at: Thu Feb 16 09:49:19 PST 2006 Thanks Fan -- James --- http://radio.weblogs.com/0112098/
Re: problem building head
On Feb 16, 2006, at 7:15 AM, Conrad O'Dea wrote: Hi Kevan, things are going better now. My build is picking up the jar that was missing before and is progressing (albeit very slowly). Hi Conrad, That's great. FYI, most of us are using Maven 1.1-beta-2 -- it's much faster than 1.0.2. So, if you haven't already, try upgrading to 1.1- beta-2. --kevan thanks for the help Conrad On Wed, 2006-02-15 at 11:05 -0500, Kevan Miller wrote: On Feb 15, 2006, at 10:04 AM, Conrad O'Dea wrote: Hi there, I am having problems getting a build of Geronimo. I am following the instructions at: http://wiki.apache.org/geronimo/Building I've basically done the following (and several combinations thereof): % svn co https://svn.apache.org/repos/asf/geronimo/trunk geronimo % cd geronimo % maven m:fresh-checkout % maven new -Dmaven.test.skip=true -Dmaven.itest.skip=true and after a good healthy time of doing stuff it fails with: The build cannot continue because of the following unsatisfied dependency: geronimo-j2ee_1.4_spec-1.1-SNAPSHOT.jar I've also checked-out geronimo-specs and built it with 'mvn install' but this jar has not been built anywhere in that working copy or either ~/.maven or ~/.m2 repositories. Nor can I find it in the maven repository at http://cvs.apache.org/repository/geronimo-spec/jars/. Conrad, I just verified that geronimo-j2ee_1.4_spec-1.1-SNAPSHOT.jar was built and placed in my .maven repository. Can you svn update your specs and try again? FYI -- the spec jar was mistakenly deleted from the apache repo. I'm sure it will be back sometime soon. Also, I believe there was also a problem in the spec build which didn't put the jar in your .maven repo. I thought that had been fixed over the weekend... --kevan
Re: problem building head
2006/2/16, Kevan Miller [EMAIL PROTECTED]: Hi Conrad, That's great. FYI, most of us are using Maven 1.1-beta-2 -- it's much faster than 1.0.2. So, if you haven't already, try upgrading to 1.1- beta-2. It's listed as a prerequisity at Building wiki page (I changed it two or three days ago), so *if* Conrad has followed it carefully, he should be using it ;) --kevan Jacek -- Jacek Laskowski http://www.laskowski.org.pl
Re: svn commit: r378162 - in /geronimo/trunk/modules: core/src/java/org/apache/geronimo/core/service/ core/src/java/org/apache/geronimo/proxy/ security/src/java/org/apache/geronimo/security/remoting/j
David Blevins,trunk builds are getting junit failures in o.a.g.security. Since you're the most likely culprit, can you have a look? Here's a sample:09:48:20,928 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: objectName="geronimo.remoting:target=JaasLoginServiceRemotingServer"java.lang.NoClassDefFoundError: org/apache/geronimo/core/service/Interceptor at org.apache.geronimo.security.remoting.jmx.JaasLoginServiceRemotingServer.doStart(JaasLoginServiceRemotingServer.java:115) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:520) at org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:203) at org.apache.geronimo.security.AbstractTest.setUp(AbstractTest.java:104) at org.apache.geronimo.security.jaas.LoginKerberosNonGeronimoTest.setUp(LoginKerberosNonGeronimoTest.java:57) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:297) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:672) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:567)On Feb 16, 2006, at 12:07 AM, [EMAIL PROTECTED] wrote:core/service
Re: Geronimo documentation
Hi Mario, I believe we should wait until the customer moved Geronimo to production and they are satisfied with the results, then if they are willing to participate in a Case Studies / Success Stories section we could add an article with covering the following areas: - Customer - Service Provider - Business needs - Solution - Benefits I think these are the minimum we should address. It will not harm to probe the customer for willingness to participate, normally marketing and legal approvals take longer than expected, it is better to start earlier ;) Cheers! Hernan Mario Rübsam wrote: Hi, Hernan Cunico wrote: Hi All, do we have any Geronimo implementation on a customer that would be willing to participate in a Case Studies / Success Stories section. It would be great to add a section like this to the updated site. Cheers! Hernan we migrated one of our applications from JBoss to Geronimo 1.0 in the last weeks. It is currently in testing stage at the customer. If youre interested, I can ask if they willing to participate in a success story. What are the general conditions for the story? Regards, Mario Ruebsam
Re: JMS documentation
Hi Hiram, good point, the final article changed the scope from the original idea but the title never changed. I just updated it with your suggestion. The new updated link is: http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/Integrating+A+Third+Party+JMS+Provider Thanks for the feedback. Cheers! Hernan Hiram Chirino wrote: Hi Hernan, Great Job! I noticed that it did not really go into much detail on how to configure the JMS that ships with Geronimo! Wouldn't a better title for this article be Integrating A Third Party JMS Provider? Regards, Hiram On Feb 14, 2006, at 6:07 PM, Hernan Cunico wrote: Hi All, Here is the *Configure JMS* article updated, sorry it took so long :) http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/ Configure+JMS Cheers! Hernan
Re: problem building head
Hi Kevan, Jacek, On Thu, 2006-02-16 at 14:47 +0100, Jacek Laskowski wrote: 2006/2/16, Kevan Miller [EMAIL PROTECTED]: Hi Conrad, That's great. FYI, most of us are using Maven 1.1-beta-2 -- it's much faster than 1.0.2. So, if you haven't already, try upgrading to 1.1- beta-2. It's listed as a prerequisity at Building wiki page (I changed it two or three days ago), so *if* Conrad has followed it carefully, he should be using it ;) I was not using 1.1b2 but I am now and it is significantly faster. I have a build now :-) Thanks for the help. Conrad
Re: Multiple servers sharing the same repo and config store
On Feb 12, 2006, at 9:17 AM, Vincent Massol wrote: Hi David and everyone, Any progress on this? not yet, sorry. it is pretty easy, but I am tied up in the configid branch right now. david jencks Thanks -Vincent -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: lundi 30 janvier 2006 08:23 To: dev@geronimo.apache.org Subject: Multiple servers sharing the same repo and config store Many people have talked on and off about how to set up multiple servers sharing the same repository and config-store, but we haven't arrived at an agreed on way to do it. We have a prospective customer for this feature (Vincent Massol with Cargo) so I'd like to move beyond thinking about it in my head, discuss it, and have someone implement it. I believe any implementation will be more or less trivial, the hard part is figuring out what to do. I've only thought of ways to extend what we have now, rather than restructure anything or add big new capabilities. If someone sees a better way, please speak up. So, we have a ServerInfo gbean that knows where geronimo is located and can resolve absolute locations for other components. Then we have things like the repository and config store gbeans that typically are located outside the var dir and things like the logging framework, local attribute manager, derby, and tomcat, that typically keep stuff in the var directory. All or most of these start with the first configuration loaded so they can't have any attributes overridden by config.xml: in fact this file is read by one of the gbeans that we need to relocate. I've thought of two related solutions. Both of them involve giving ServerInfo knowledge of another path and another resolve method. One would be something like resolveVar and would normally resolve to geronimo_home/var. This would involve all the gbeans currently looking inside var having the var trimmed off the front of their paths and using the new resolveVar method. In this case we'd have different servers represented as e.g. var1 var2 var3 ... The other would give ServerInfo something like resolveServer which would normally resolve to geronimo_home. The gbeans looking inside var would keep their current paths and just call the new resolve method instead of the old one. In this case we'd have servers like var server1/var server2/var ... In either case I think starting geronimo with a command line argument pointing to the var directory is the only way to specify which server you want to run; the default would presumably be as now var. Several people have suggested putting an additional config-store into var for private use by a particular server. At the moment I think that providing a different config-store class that uses the new resolve method on server info would be the best way to do this. I'm not attached to these ideas but this is as far as my thinking has gone. Please comment. thanks david jencks
Re: mutiple WebServiceBuilder gbeans
sorry for the delay in replying On Feb 10, 2006, at 9:46 AM, Conrad O'Dea wrote: Hi David, On 10 Feb 2006, at 16:04, David Jencks wrote: in the current default configuration for Geronimo, there appears to be single WebServiceBuilder deployed which is the AxisBuilder. Is it possible to have a second builder of this type deployed? Is so what will happen when another Gbean (for example the Jetty or Tomcat deployer) invokes on it? Basically, I am looking for a way to deploy another WebServiceBuilder that can be used by the module deployers without having to update the plans for each, if possible. You won't be able to use it for ejb web services because the openejb web service implementation is hard coded to use axis. Is there any reason that the OpenEJB stuff must use Axis or could it be updated to be more flexible? I don't think there is any fundamental reason but right now it is coded that way and in the limited time I've been able to look at it I haven't seen how to disentangle it. David Blevins might have a better idea how to approach this. However, I think the POJO ws should be OK. I think the easiest solution is to write a plan for your WSB that gives it the same name as the axis one, and deploy the resulting configuration instead of the axis one. (I'm assuming you are working with trunk where we have separated the builders more than in 1.0) That's good know. I've been looking at the 1.0 tag but will move up to the trunk. You may also need to write suitable adapter servlets similar to JettyPOJOWebServiceHolder. There are probably lots of problems you will run into so please feel free to speak up, complain, etc etc Thanks for the info. I'm sure I'll be back :-) Looking forward to it ! thanks david jencks Conrad
[jira] Created: (GERONIMO-1634) NoClassDefFoundError from Derby Log Viewer
NoClassDefFoundError from Derby Log Viewer --- Key: GERONIMO-1634 URL: http://issues.apache.org/jira/browse/GERONIMO-1634 Project: Geronimo Type: Bug Components: console Versions: 1.1 Environment: windows XP happens on tomcat and jetty Reporter: Joe Bohn Fix For: 1.1 Changes that were introduced (by me :-( ) to eliminate unnecessary dependencies and reduce the size of the minimal assembly exposed places where dependencies were missing. This particular one is that the console configuration needs a dependency on geronimo.derby. This results in the following exception when attempting to view the derby logs: 13:51:55,441 ERROR [[DerbyLogViewer]] Servlet.service() for servlet DerbyLogViewer threw exception java.lang.NoClassDefFoundError at org.apache.geronimo.console.derbylogmanager.DerbyLogViewerPortlet.class$(DerbyLogViewerPortlet.java:60) at org.apache.geronimo.console.derbylogmanager.DerbyLogViewerPortlet.doView(DerbyLogViewerPortlet.java:60) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250) at javax.portlet.GenericPortlet.render(GenericPortlet.java:178) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvokerImpl.java:73) at org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:119) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPortlet(PortletContainerWrapperImpl.java:70) at org.apache.pluto.portalImpl.aggregation.PortletFragment.service(PortletFragment.java:168) at org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp:65) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112) at org.apache.jsp.WEB_002dINF.aggregation.RowFragment_jsp._jspService(org.apache.jsp.WEB_002dINF.aggregation.RowFragment_jsp:64) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at
Build Problem
I have been trying to build the latest source code with maven 1.0.2 and kept getting build failure. This is the build for the latest SNAPSHOT. I am not sure if anyone had similar problem. BUILD FAILED File.. /home/fanli/.maven/cache/maven-multiproject-plugin-1.3.1/plugin.jelly Element... maven:reactor Line.. 217 Column 9 Unable to obtain goal [test:test] -- /home/fanli/.maven/cache/maven-test-plugin- 1.6.2/plugin.jelly:181:54: fail There were test failures. Total time: 58 minutes 22 seconds Finished at: Thu Feb 16 09:49:19 PST 2006 Thanks Fan
[jira] Updated: (GERONIMO-1634) NoClassDefFoundError from Derby Log Viewer
[ http://issues.apache.org/jira/browse/GERONIMO-1634?page=all ] Joe Bohn updated GERONIMO-1634: --- Attachment: LogViewerDep.patch I fixed this problem. There appears to still be another problem with jetty only for the derby log viewer (a different exception). I'll open another JIRA for that. I'm not yet sure if the second problem is related to the dependency changes or not. NoClassDefFoundError from Derby Log Viewer -- Key: GERONIMO-1634 URL: http://issues.apache.org/jira/browse/GERONIMO-1634 Project: Geronimo Type: Bug Components: console Versions: 1.1 Environment: windows XP happens on tomcat and jetty Reporter: Joe Bohn Fix For: 1.1 Attachments: LogViewerDep.patch Changes that were introduced (by me :-( ) to eliminate unnecessary dependencies and reduce the size of the minimal assembly exposed places where dependencies were missing. This particular one is that the console configuration needs a dependency on geronimo.derby. This results in the following exception when attempting to view the derby logs: 13:51:55,441 ERROR [[DerbyLogViewer]] Servlet.service() for servlet DerbyLogViewer threw exception java.lang.NoClassDefFoundError at org.apache.geronimo.console.derbylogmanager.DerbyLogViewerPortlet.class$(DerbyLogViewerPortlet.java:60) at org.apache.geronimo.console.derbylogmanager.DerbyLogViewerPortlet.doView(DerbyLogViewerPortlet.java:60) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250) at javax.portlet.GenericPortlet.render(GenericPortlet.java:178) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvokerImpl.java:73) at org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:119) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPortlet(PortletContainerWrapperImpl.java:70) at org.apache.pluto.portalImpl.aggregation.PortletFragment.service(PortletFragment.java:168) at org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp:65) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112) at org.apache.jsp.WEB_002dINF.aggregation.RowFragment_jsp._jspService(org.apache.jsp.WEB_002dINF.aggregation.RowFragment_jsp:64) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) at
Re: Build Problem
That indicates there were some JUnit test failures. We have some tests that fail on some platforms with timing issues; its amazingly hard to write highly asynchronous concurrent message based unit test cases that always work on every platform. If you seach for [ERROR] you'll find the actual tests that failed. Then if you look in target/test-reports/TEST-$name.txt (in the module thats being built) you'll find the output of the test case. If you could post those it'd really help us fix it. James On 2/16/06, Li, Fan [EMAIL PROTECTED] wrote: I have been trying to build the latest source code with maven 1.0.2 and kept getting build failure. This is the build for the latest SNAPSHOT. I am not sure if anyone had similar problem. BUILD FAILED File.. /home/fanli/.maven/cache/maven-multiproject-plugin-1.3.1 /plugin.jelly Element... maven:reactor Line.. 217 Column 9 Unable to obtain goal [test:test] -- /home/fanli/.maven/cache/maven-test-plugin- 1.6.2/plugin.jelly:181:54: fail There were test failures. Total time: 58 minutes 22 seconds Finished at: Thu Feb 16 09:49:19 PST 2006 Thanks Fan -- James --- http://radio.weblogs.com/0112098/
Re: mutiple WebServiceBuilder gbeans
On Feb 16, 2006, at 7:50 AM, David Jencks wrote: sorry for the delay in replying On Feb 10, 2006, at 9:46 AM, Conrad O'Dea wrote: Hi David, On 10 Feb 2006, at 16:04, David Jencks wrote: in the current default configuration for Geronimo, there appears to be single WebServiceBuilder deployed which is the AxisBuilder. Is it possible to have a second builder of this type deployed? Is so what will happen when another Gbean (for example the Jetty or Tomcat deployer) invokes on it? Basically, I am looking for a way to deploy another WebServiceBuilder that can be used by the module deployers without having to update the plans for each, if possible. You won't be able to use it for ejb web services because the openejb web service implementation is hard coded to use axis. Is there any reason that the OpenEJB stuff must use Axis or could it be updated to be more flexible? I don't think there is any fundamental reason but right now it is coded that way and in the limited time I've been able to look at it I haven't seen how to disentangle it. David Blevins might have a better idea how to approach this. The webservices support in OpenEJB and Geronimo both use this interface that I came up with: http://svn.apache.org/repos/asf/geronimo/trunk/modules/webservices/ src/java/org/apache/geronimo/webservices/WebServiceContainer.java That can be wrapped in a servlet, wrapped directly by jetty, or wrapped in anything that can support an http-like request/response. These wrapping things I'm talking about are essentially front-ends and all our front-ends rely upon that interface cleanly and are not tied to any WebServiceContainer we have. The Axis implementation is here: http://svn.apache.org/repos/asf/geronimo/trunk/modules/axis/src/java/ org/apache/geronimo/axis/server/AxisWebServiceContainer.java An out-of-date XFire implementation is here: http://cvs.openejb.org/viewrep/openejb/trunk/openejb2/modules/core/ src/java/org/openejb/server/xfire/WSContainer.java?r=1895 I prototyped on XFire first and then eventually created an Axis implementation which is what we certify with. The runtime is very decoupled and can essentially support any webservice that implements the WebServiceContainer interface. It's pretty much deployment that ties us to Axis. If you can find what we need to do to peal our Axis implementation out, I'm happy to help. I'd like to see XFire as an option again, myself. -David
Geronimo Web site update
Hi Bruce, sorry for keep bothering, have you had the chance to run the last diff I uploaded? I have more updates on hold for the site that I do not want to push through until we figure out what I am doing wrong and/or why you are having issues with the updates I am attaching to the JIRA. Is there any other check/test I could run localy to save you some time while dealing with all these issues? Cheers! Hernan
Help test out the sevicemix 3.0 M1 release candidate
Hi Everybody, Servicemix has made some great progress in the recent weeks and I thought it might ready to start thinking about doing a M1 release soon. So in that spirit, I've built a release candidate for the M1 release. Like all first attempts at a release, I'm sure we have missed something. Please help me find the problems with it. I've posted the release candidate here: http://people.apache.org/~chirino/incubator-servicemix-3.0-M1/ and tagged the source used to build it here: https://svn.apache.org/repos/asf/incubator/servicemix/tags/ servicemix-3.0-M1 If no glaring problems are found, and everybody else feels we are really ready for a M1, we can call a vote to make these binaries our M1 release. Regards, Hiram
[jira] Created: (GERONIMODEVTOOLS-65) Support qualifer builds
Support qualifer builds --- Key: GERONIMODEVTOOLS-65 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-65 Project: Geronimo-Devtools Type: Task Components: eclipse-plugin Reporter: Sachin Patel Support qualifiers in plugins and features. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMODEVTOOLS-66) Move to M2
Move to M2 -- Key: GERONIMODEVTOOLS-66 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-66 Project: Geronimo-Devtools Type: Task Components: eclipse-plugin Reporter: Sachin Patel Migrate build to M2. Need to rid of geronimo-emf and see if model and edit code can be generated independently since their associated projects. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMODEVTOOLS-67) M2 plugin to generate WTP adopter API usage report
M2 plugin to generate WTP adopter API usage report -- Key: GERONIMODEVTOOLS-67 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-67 Project: Geronimo-Devtools Type: Task Components: eclipse-plugin Reporter: Sachin Patel -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Let's rewind!!! (Re: [VOTE] accept donation of a business process engine into the ServiceMix project)
A BPEL engine is integrated within JBI using a JBI component. In such a case, the BPEL engine should only communicate with the JBI bus (excluding direct http calls or whatever else). The JBI container is really a container which communicates with a component using a set of specified interfaces, but in no way there is a strong tie from the bpel engine to jbi: it is more like having the right entry points to be able to perform everything needed by the jbi spec: retrieving the wsdl, finding inputs and outputs. If I have to make a comparison, it would say it is similar to the database and its jdbc driver: the database does not need to be dependant on jdbc, but they offer a driver that wraps jdbc specific stuff to native calls.. Here the component wraps JBI calls to BPEL events. The main difference is that usually, the BPEL engine will be embedded in the JBI component ... Cheers, Guillaume Nodet [EMAIL PROTECTED] wrote: James, I'm afraid I'm not as familiar with JBI as I probably should be (which is to say not at all). Would leveraging JBI to do Ode's heavy lifting introduce a dependency on ServiceMix and/or JBI into Ode, or is it merely a Java-based interface to BPEL, along the lines of JDBC or JNDI? Thanks, Ian It's better to be hated for who you are than loved for who you are not Ian D. Stewart Appl Dev Analyst-Advisory, DCS Automation JPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Pager: (888) 260-0078 James Strachan [EMAIL PROTECTED]To: general@incubator.apache.org mail.comcc: dev@geronimo.apache.org, [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Let's rewind!!! (Re: [VOTE] accept donation of a business process engine 02/15/2006 03:27 into the ServiceMix project) AM Please respond to dev On 14 Feb 2006, at 21:38, Matthieu Riou wrote: Also, I don't at all agree with your comparison of a BPEL Engine to Geronimo. I would compare it to the transaction manager within Geronimo. It's a discrete component, and we're not going to take the best of 20 different projects to make a transaction manager, and I don't see why we'd do the same to make a BPEL Engine. I've been trying to stay out of the discussion so far because I'm obviously partial (as a contributor on Agila BPEL), however I've seen this opinion voiced many time on these threads and can't ignore it anymore. Aaron it's not against you at all :) I've worked enough on BPEL implementing it to say, really strongly, that BPEL is very far from being a discrete component. You can see it as something behind the scene when you're working on a JBI container, however when you're interested in having an orchestration layer, you really don't. I don't think Oracle, IBM and many other editors would be so successful in selling their product if it was so discrete. You really don't need a JBI container if you're only dealing with web services interfaces. Sure but it really helps. The JBI container does much of the heavy lifting, letting the BPEL engine focus on its core feature - correlation orchestration and not worrying about all the other stuff as well. Actually my view on this was that an ESB is just a communication bus around an orchestration layer. Quite the reverse opinion, isn't it? And I can't see any JBI implementation dealing with the BPEL grammar. Is the JBI implementation going to deal with compensation, correlation and partner links? I don't think so. Agreed. But similarly - should a BPEL engine deal with different integration components, different SOAP stacks, different WS-* policies, monitoring, management, using HTTP or JMS or Jabber or file systems, deployment, versioning, runtime management monitoring of each flow? The J2EE analogy is quite good; BPEL is a discrete service but can reuse the container environment of JBI to avoid the BPEL engine having to write a container, a deployment model and a suite of 'binding components' to
Re: Let's rewind!!! (Re: [VOTE] accept donation of a business process engine into the ServiceMix project)
On 16 Feb 2006, at 23:44, [EMAIL PROTECTED] wrote: James, I'm afraid I'm not as familiar with JBI as I probably should be (which is to say not at all). Would leveraging JBI to do Ode's heavy lifting introduce a dependency on ServiceMix and/or JBI into Ode, or is it merely a Java-based interface to BPEL, along the lines of JDBC or JNDI? You'd be adding a *optional* dependency to the JBI standard (JSR 208) (there's no reason why you couldn't support other techniques)... http://www.jcp.org/en/jsr/detail?id=208 think of it as a bit like the JMS API for working with BPEL engines, integration services or any WSDL defined MEP. The use of JBI is twofold: you can use JBI (as an optional module) inside Ode to perform all the message exchanges - avoiding the need of Ode to worry about different SOAP stacks, transports, transactions, QoS together with building your own mini-application server into the BPEL engine etc. Or you can use JBI to invoke and interact with a BPEL engine if you are some application or integration component that wishes to reuse BPEL. Its a little like integrating JMS or JDBC; once you've a JBI integration point, there is a large range of providers you can then use; in terms of JBI container (ServiceMix, Petals, OpenESB, commercial vendors like Sonic etc) as well as integration services like BPEL engines (Ode, maybe jBPM or Oracles' etc) and integration components. (e.g. these are the JBI components available in ServiceMix right now... http://incubator.apache.org/servicemix/Components http://incubator.apache.org/servicemix/Routing So Ode could have other integration points too though - its just that JBI should be the first and foremost connector, since its standards based and already provides integration to the widest range of different services and binding components. James Thanks, Ian It's better to be hated for who you are than loved for who you are not Ian D. Stewart Appl Dev Analyst-Advisory, DCS Automation JPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Pager: (888) 260-0078 James Strachan [EMAIL PROTECTED]To: general@incubator.apache.org mail.comcc: dev@geronimo.apache.org, [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Let's rewind!!! (Re: [VOTE] accept donation of a business process engine 02/15/2006 03:27 into the ServiceMix project) AM Please respond to dev On 14 Feb 2006, at 21:38, Matthieu Riou wrote: Also, I don't at all agree with your comparison of a BPEL Engine to Geronimo. I would compare it to the transaction manager within Geronimo. It's a discrete component, and we're not going to take the best of 20 different projects to make a transaction manager, and I don't see why we'd do the same to make a BPEL Engine. I've been trying to stay out of the discussion so far because I'm obviously partial (as a contributor on Agila BPEL), however I've seen this opinion voiced many time on these threads and can't ignore it anymore. Aaron it's not against you at all :) I've worked enough on BPEL implementing it to say, really strongly, that BPEL is very far from being a discrete component. You can see it as something behind the scene when you're working on a JBI container, however when you're interested in having an orchestration layer, you really don't. I don't think Oracle, IBM and many other editors would be so successful in selling their product if it was so discrete. You really don't need a JBI container if you're only dealing with web services interfaces. Sure but it really helps. The JBI container does much of the heavy lifting, letting the BPEL engine focus on its core feature - correlation orchestration and not worrying about all the other stuff as well. Actually my view on this was that an ESB is just a communication bus around an orchestration layer. Quite the reverse opinion, isn't it? And I can't see any JBI implementation dealing with the BPEL grammar. Is the JBI implementation going to deal with compensation, correlation and partner links? I don't think so. Agreed. But similarly - should a BPEL engine deal with different integration components, different SOAP stacks, different WS-* policies, monitoring, management, using HTTP or JMS or Jabber or file systems, deployment, versioning, runtime management monitoring of each flow? The J2EE analogy is quite good; BPEL is a discrete service but can reuse the container environment of JBI to avoid the BPEL engine having to write a container, a deployment model and a suite of 'binding components' to different SOAP stacks, WS-* policies and transports - together with all the runtime management. BPEL engines and orchestration services were one of the primary drivers of
