Re: Switch to Maven 2?? Delete our m1 build files??
On 7/10/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hi Folks, So to me it looks like our maven 2 build is now is now producing an equivalent binary distribution to our maven 1 build. Openwire is now getting generated correctly with m2 also. I think we are over the hump and anything left should just be small details. Do you think we should delete our m1 build files to avoid confusion and encourage folks to do the switch? +1 Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://incubator.apache.org/activemq/ Apache ServiceMix - http://incubator.apache.org/servicemix/ Castor - http://castor.org/
Re: Switch to Maven 2?? Delete our m1 build files??
+1 to switch On 7/11/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hi Folks, So to me it looks like our maven 2 build is now is now producing an equivalent binary distribution to our maven 1 build. Openwire is now getting generated correctly with m2 also. I think we are over the hump and anything left should just be small details. Do you think we should delete our m1 build files to avoid confusion and encourage folks to do the switch? -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Created: (AMQ-811) MBean improvements
MBean improvements -- Key: AMQ-811 URL: https://issues.apache.org/activemq/browse/AMQ-811 Project: ActiveMQ Type: Improvement Versions: 4.0.1 Reporter: james strachan Assigned to: james strachan Fix For: 4.1 We could do with some improvements in the MBean APIs... * allow Messages to be browsed on a BrokerViewMBean (e.g. adding a browseMessages() or browseMessages(selector) method * allow durable subscriptions to be destroyed via DurableSubscriptionViewMBean.destroy() For more background see http://www.nabble.com/ActiveMQ-JMX-Questions..-tf1917262.html#a5248649 http://www.nabble.com/Maintaining-connections-subscriptions-tf1921466.html#a5260973 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Switch to Maven 2?? Delete our m1 build files??
+1 - though lets keep the m1 builds for 4.0 branch. So 4.1 onwards is m2 but leave m1 for 4.0. On 7/11/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hi Folks, So to me it looks like our maven 2 build is now is now producing an equivalent binary distribution to our maven 1 build. Openwire is now getting generated correctly with m2 also. I think we are over the hump and anything left should just be small details. Do you think we should delete our m1 build files to avoid confusion and encourage folks to do the switch? -- Regards, Hiram Blog: http://hiramchirino.com -- James --- http://radio.weblogs.com/0112098/
[jira] Commented: (AMQ-744) add a vmstat agent to the maven activemq performance plugin so we can track the CPU, IO, RAM use on the machine we are running the test on
[ https://issues.apache.org/activemq/browse/AMQ-744?page=comments#action_36552 ] james strachan commented on AMQ-744: Looks great - thanks! add a vmstat agent to the maven activemq performance plugin so we can track the CPU, IO, RAM use on the machine we are running the test on Key: AMQ-744 URL: https://issues.apache.org/activemq/browse/AMQ-744 Project: ActiveMQ Type: Improvement Components: Performance Test Reporter: james strachan Assignee: Adrian Co Fix For: 4.1 When running a performance test it would be good to spawn off a process to run 'vmstat' which works on linux and solaris (the flags may differ etc) which outputs the amout of CPU use in system/user code and how much is idle together with RAM IO numbers. I'd be good to include in each snapshot whatever vmstat numbes we can find so we can see how the box was doing as the test was running. e.g. sample index=5 ... machine cpuSystem=50 cpuUser=25 cpuIdle=25 ram=44 io=1000/ /sample Note that we may wanna make a few different machine monitoring agents using different tools - so lets make it pluggable - let 'em write whatever XML they can - though we should be able to get linux and solaris done (linux only would be fine for now) To call vmstat we'll need to do a System.exec() then parse the results etc -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-811) MBean improvements
[ https://issues.apache.org/activemq/browse/AMQ-811?page=all ] james strachan resolved AMQ-811: Resolution: Fixed MBean improvements -- Key: AMQ-811 URL: https://issues.apache.org/activemq/browse/AMQ-811 Project: ActiveMQ Type: Improvement Versions: 4.0.1 Reporter: james strachan Assignee: james strachan Fix For: 4.1 We could do with some improvements in the MBean APIs... * allow Messages to be browsed on a BrokerViewMBean (e.g. adding a browseMessages() or browseMessages(selector) method * allow durable subscriptions to be destroyed via DurableSubscriptionViewMBean.destroy() For more background see http://www.nabble.com/ActiveMQ-JMX-Questions..-tf1917262.html#a5248649 http://www.nabble.com/Maintaining-connections-subscriptions-tf1921466.html#a5260973 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Switch to Maven 2?? Delete our m1 build files??
Ok. I'm going to go ahead and do this. So this is a warning for all you folks that had setup a CI build using the old maven 1 stuff. It's going to break. Please upgrade the new m2 stuff. On 7/11/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hi Folks, So to me it looks like our maven 2 build is now is now producing an equivalent binary distribution to our maven 1 build. Openwire is now getting generated correctly with m2 also. I think we are over the hump and anything left should just be small details. Do you think we should delete our m1 build files to avoid confusion and encourage folks to do the switch? -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com
Re: Regarding ClassLoader Changes in Geronimo 1.1
Hi , Thanks for the tip. I was wondering why the behaviour has changed though. Whatever I am using works on another app server like Websphere and also in 1.0 of Geronimo where tomcat's classloader is used. My question is shouldn't the Web Application Classloader have access to the resources outside of the WEB-INF directory inside the war? On glancing through the spec I didn't see anything abt it but most of the app servers seem to support this. ThanksManu On 7/10/06, Mario Ruebsam [EMAIL PROTECTED] wrote: Manu George wrote: Hi, I have an application that is packaged as an EAR. The WAR inside the EAR is having some images in the images directory directly inside the war. In Geronimo 1.0 , I was able to access them using Thread.currentThread().getContextClassLoader().getResource() method, but now I am unable to do so. On debugging I found that the classloader I got for 1.0 was WebappClassLoader from Tomcat which had access to the files, while for 1.1, I got JarFileClassLoader of geronimo which did not have access to those files. Can anyone throw further light on this problem. Thanks ManuHi,can you try to get the correct resource URL via the URL javax.servlet.ServletContext.getResource(String path)method? Once you have the base URL to the war you can easily loadyour resources from the war.Thanks,Mario
Re: 1.1 Press Release
Susan, I am -0 on companies being included in the press release. There are many companies associated with G, but I think that we should not make this a marketting exercise for them. But IF we are going to list companies then I would like Mort Bay listed http://www.mortbay.com as the company that supports Jetty and it's integration into G. regards Susan Wu wrote: From what I understand, the code release has been made available on the Geronimo web site and a general announcement has been made with regards to its availability. Geronimo folks: do you want this also issued as an official press release? If so, do you have any customers or partners we could include as part of the announcement? E.g. quotes or complementary announcements? On Sat, 8 Jul 2006, Sally Khudairi wrote: Hello Matt, Thank you for your note. I'm curious -- did this release go out? If so, where was it distributed and via which channels? I didn't see any feedback from the PRC on this, so I'm just double-checking to make sure I haven't missed any emails. Thanks in advance for this. Kind regards, Sally --- Matt Hogstrom [EMAIL PROTECTED] wrote: Here is the press release. I've included Jacek's comments. I am not sure of the City and State so I'll defer to the PRC to update those. Cheers Apache Software Foundation Announces Release of Apache Geronimo Version 1.1 Usability Improvements Simplify Configuration and Deployment of J2EE Applications (City, State) July 05, 2006 -- The Apache Software Foundation is pleased to announce the release of Apache Geronimo Version 1.1, an open source application server from the Apache community. The release continues the J2EE certification path led by the previous version of Geronimo, providing a fully compliant and usable J2EE container suitable for everything from development to enterprise deployments. Apache Geronimo v1.1 introduces several structural changes improving scalability, portability and overall organization, as well as including new features and functionality. Enhancements have been made to the administration console including memory utilization graphics and plugins to improve usability. Also, improvements have been made to the innovative configuration and administration/plug-in architecture. Whereas the previous version offered a full J2EE configuration, v1.1 includes a �Little G� configuration, a smaller footprint web-oriented version of Geronimo that can be scaled up to JMS or full J2EE using plug-ins as users� needs change. The addition of Little G provides an option for those who want to use Geronimo for lightweight applications without the additional installation overhead. One of the main goals of Apache Geronimo is flexibility. Geronimo is flexible enough to include only the capabilities that users want and need. Geronimo already offers a modular architecture that makes it easy to create custom distributions with custom feature sets. With v1.1, we (the Apache Geronimo Team) looked at users� needs and added even more features to benefit those needs, increase functionality, and extend usability. The flexible, easy-to-use, and easy-to-configure application server is built from best-of-breed open source components and is fully licensed under the business-friendly Apache Software License offering multiple benefits to organizations and their development teams. The software is available for download from the Apache Geronimo web site (http://geronimo.apache.org/). About the Apache Software Foundation The Apache Software Foundation provides organizational, legal and financial support for a broad range of open source software projects. The Foundation provides an established framework for intellectual property and financial contributions that simultaneously limits contributors' potential legal exposure. Through a collaborative and meritocratic development process, Apache projects deliver enterprise-grade, freely available software products that attract large communities of users. The pragmatic Apache License makes it easy for all users, commercial and individual, to deploy Apache products. For more information on The Apache Software Foundation, please visit http://www.apache.org/. Java and J2EE are trademarks or registered trademarks of Sun Microsystems,Inc. in the United States and other countries. All other trademarks or registered trademarks herein are property of their respective owners. mobile +1 617 921 8656 :: fax +1 617 321 4085 siphttp://www.dorsetcafe.com/ trade http://www.haloworldwide.com/ self http://www.khudairi.net/ skype sallykhudairi __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: 1.1 Press Release
Matt Hogstrom wrote: Susan Wu wrote: From what I understand, the code release has been made available on the Geronimo web site and a general announcement has been made with regards to its availability. Geronimo folks: do you want this also issued as an official press release? Yes please. +1 If so, do you have any customers or partners we could include as part of the announcement? E.g. quotes or complementary announcements? I'll defer to others but I think the Press Release should be heading out straight away. The clock is ticking :) I think the announcement is fine as it is without listing companies whose employees work on Geronimo. The focus of the announcement is on Geronimo and the Apache Foundation and IMHO that is as it should be. That said, if it is the custom of Apache to list the names of companies who have employees who contribute to Geronimo, then I can provide a name. regards Jan On Sat, 8 Jul 2006, Sally Khudairi wrote: Hello Matt, Thank you for your note. I'm curious -- did this release go out? If so, where was it distributed and via which channels? I didn't see any feedback from the PRC on this, so I'm just double-checking to make sure I haven't missed any emails. Thanks in advance for this. Kind regards, Sally --- Matt Hogstrom [EMAIL PROTECTED] wrote: Here is the press release. I've included Jacek's comments. I am not sure of the City and State so I'll defer to the PRC to update those. Cheers Apache Software Foundation Announces Release of Apache Geronimo Version 1.1 Usability Improvements Simplify Configuration and Deployment of J2EE Applications (City, State) July 05, 2006 -- The Apache Software Foundation is pleased to announce the release of Apache Geronimo Version 1.1, an open source application server from the Apache community. The release continues the J2EE certification path led by the previous version of Geronimo, providing a fully compliant and usable J2EE container suitable for everything from development to enterprise deployments. Apache Geronimo v1.1 introduces several structural changes improving scalability, portability and overall organization, as well as including new features and functionality. Enhancements have been made to the administration console including memory utilization graphics and plugins to improve usability. Also, improvements have been made to the innovative configuration and administration/plug-in architecture. Whereas the previous version offered a full J2EE configuration, v1.1 includes a �Little G� configuration, a smaller footprint web-oriented version of Geronimo that can be scaled up to JMS or full J2EE using plug-ins as users� needs change. The addition of Little G provides an option for those who want to use Geronimo for lightweight applications without the additional installation overhead. One of the main goals of Apache Geronimo is flexibility. Geronimo is flexible enough to include only the capabilities that users want and need. Geronimo already offers a modular architecture that makes it easy to create custom distributions with custom feature sets. With v1.1, we (the Apache Geronimo Team) looked at users� needs and added even more features to benefit those needs, increase functionality, and extend usability. The flexible, easy-to-use, and easy-to-configure application server is built from best-of-breed open source components and is fully licensed under the business-friendly Apache Software License offering multiple benefits to organizations and their development teams. The software is available for download from the Apache Geronimo web site (http://geronimo.apache.org/). About the Apache Software Foundation The Apache Software Foundation provides organizational, legal and financial support for a broad range of open source software projects. The Foundation provides an established framework for intellectual property and financial contributions that simultaneously limits contributors' potential legal exposure. Through a collaborative and meritocratic development process, Apache projects deliver enterprise-grade, freely available software products that attract large communities of users. The pragmatic Apache License makes it easy for all users, commercial and individual, to deploy Apache products. For more information on The Apache Software Foundation, please visit http://www.apache.org/. Java and J2EE are trademarks or registered trademarks of Sun Microsystems,Inc. in the United States and other countries. All other trademarks or registered trademarks herein are property of their respective owners. mobile +1 617 921 8656 :: fax +1 617 321 4085 siphttp://www.dorsetcafe.com/ trade http://www.haloworldwide.com/ self http://www.khudairi.net/ skype sallykhudairi __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Created: (XBEAN-23) xbean-spring does not work with spring 2.0-rc2
xbean-spring does not work with spring 2.0-rc2 -- Key: XBEAN-23 URL: http://issues.apache.org/jira/browse/XBEAN-23 Project: XBean Type: Bug Components: spring Versions: 2.4 Reporter: james strachan Assigned to: james strachan Fix For: 2.5 The following stack trace is created... Caused by: java.lang.IllegalArgumentException: ClassLoader must not be null at org.springframework.util.Assert.notNull(Assert.java:113) at org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.init(DefaultNamespaceHandlerResolver.java:82) at org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.init(DefaultNamespaceHandlerResolver.java:74) at org.apache.xbean.spring.context.v2.XBeanNamespaceHandlerResolver.init(XBeanNamespaceHandlerResolver.java:26) at org.apache.xbean.spring.context.v2.XBeanXmlBeanDefinitionReader.createDefaultNamespaceHandlerResolver(XBeanXmlBeanDefinitionReader.java:81) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.createReaderContext(XmlBeanDefinitionReader.java:496) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:476) at org.apache.xbean.spring.context.v2.XBeanXmlBeanDefinitionReader.registerBeanDefinitions(XBeanXmlBeanDefinitionReader.java:77) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:386) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:340) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:315) at org.apache.xbean.spring.context.ResourceXmlApplicationContext.loadBeanDefinitions(ResourceXmlApplicationContext.java:106) at org.apache.xbean.spring.context.ResourceXmlApplicationContext.loadBeanDefinitions(ResourceXmlApplicationContext.java:99) at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:89) -- 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] Resolved: (XBEAN-23) xbean-spring does not work with spring 2.0-rc2
[ http://issues.apache.org/jira/browse/XBEAN-23?page=all ] james strachan resolved XBEAN-23: - Resolution: Fixed patch applied in trunk xbean-spring does not work with spring 2.0-rc2 -- Key: XBEAN-23 URL: http://issues.apache.org/jira/browse/XBEAN-23 Project: XBean Type: Bug Components: spring Versions: 2.4 Reporter: james strachan Assignee: james strachan Fix For: 2.5 The following stack trace is created... Caused by: java.lang.IllegalArgumentException: ClassLoader must not be null at org.springframework.util.Assert.notNull(Assert.java:113) at org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.init(DefaultNamespaceHandlerResolver.java:82) at org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.init(DefaultNamespaceHandlerResolver.java:74) at org.apache.xbean.spring.context.v2.XBeanNamespaceHandlerResolver.init(XBeanNamespaceHandlerResolver.java:26) at org.apache.xbean.spring.context.v2.XBeanXmlBeanDefinitionReader.createDefaultNamespaceHandlerResolver(XBeanXmlBeanDefinitionReader.java:81) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.createReaderContext(XmlBeanDefinitionReader.java:496) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:476) at org.apache.xbean.spring.context.v2.XBeanXmlBeanDefinitionReader.registerBeanDefinitions(XBeanXmlBeanDefinitionReader.java:77) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:386) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:340) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:315) at org.apache.xbean.spring.context.ResourceXmlApplicationContext.loadBeanDefinitions(ResourceXmlApplicationContext.java:106) at org.apache.xbean.spring.context.ResourceXmlApplicationContext.loadBeanDefinitions(ResourceXmlApplicationContext.java:99) at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:89) -- 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] Resolved: (XBEAN-21) org\apache\xbean\spring\context\XmlWebApplicationContext.java does not work
[ http://issues.apache.org/jira/browse/XBEAN-21?page=all ] james strachan resolved XBEAN-21: - Resolution: Fixed Path applied for this bug fix - many thanks Guillaume org\apache\xbean\spring\context\XmlWebApplicationContext.java does not work --- Key: XBEAN-21 URL: http://issues.apache.org/jira/browse/XBEAN-21 Project: XBean Type: Bug Components: spring Versions: 2.4 Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 2.5 Attachments: XBEAN-21.patch -- 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
[VOTE] Release 2.5 of XBean
I've just applied 2 trivial bug fixes to the xbean-spring module of XBean. The first is a patch from Guillaume which is a one liner to create the xml parser using a helper method (used by all the other ApplicationContext implementations). http://issues.apache.org/jira/browse/XBEAN-21 The other is a trivial fix but has a major impact. Version 2.0-rc2 of spring barfs if you pass a null ClassLoader into the NamespaceHandler stuff - however the regression tests for 2.0-rc1 and 2.0-m5 work fine. Basically this means that all projects using xbean-spring (such as ActiveMQ, OpenEJB, XFire, ServiceMix, Jetty etc) will all break if the user upgrades from 2.0-m5 or 2.0-rc1 of spring to 2.0-rc2. I've just added a one liner to use the current threads context class loader if the class loader is null to avoid the exception which seems to work fine. (I added a regression test for 2.0-rc2 by just cut and pasting the regression test for 2.0-rc1 which reproduced the error so I could test the fix worked). Due to the serious nature of this bug (and we've already had a few user mails on ActiveMQ about this already and spring 2.0-rc2 has only been out a short time) I'd like us to get a release of xbean out ASAP to avoid users hittitng this issue. Here's my +1 -- James --- http://radio.weblogs.com/0112098/
Re: Geronimo, Genesis and OpenEJB2... oh my
That's cool, dude. Now can we please have some intro to Genesis. I saw a fleeting mention of it in another mail thread. Cheers Prasad On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote: ... will now all build from Continuum when adding their pom URL's as m2 projects :-) But, due to Continuum not always building them in the right order it might be necessary to Build All a few times to get everything all happy. This means that we will soon be able to deploy SNAPSHOT artifacts, and eliminate the need to build OpenEJB2 w/m2 to bootstrap the G build. :-) --jason
Re: [Vote] Geronimo Eclipse Plugin v1.1.0
As I mentioned earlier the test environment mode is not feature complete and it only works in the one scenario I mentioned.On Jul 10, 2006, at 11:28 PM, Lin Sun wrote:I started to have problems in deploying my second application which I had itrunning with v1.0's plugin. It is a simple ClassViewer application thathas a jsp and a servlet. The jsp calls the servlet when user clicks on thesubmit button to get the class description.Upon deployment of the application, I got the following CNP exception whenthe two checkboxes (Enable in-place deployment Run standalone modulesdirectly from workspace) are checked:Caused by: java.lang.ClassNotFoundException: samples.cviewer.ClassViewerServlet inclassloader samples/cviewer/1.1/war at java.lang.Throwable.init(Throwable.java:57) at java.lang.Throwable.init(Throwable.java:81) atjava.lang.ClassNotFoundException.init(ClassNotFoundException.java:80) atorg.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:249) at java.lang.ClassLoader.loadClass(ClassLoader.java:561) atorg.apache.geronimo.tomcat.GeronimoStandardContext.addChild(GeronimoStandardContext.java:234) ... 84 moreI have gotten this error before(https://bugs.eclipse.org/bugs/show_bug.cgi?id=123803) in v1.0 but I don'tthink this is the same prob as I had before this time. I noticed that in my project's .classpath file, I have:classpathentry path="build/classes" kind="output"/However, I don't have the servlet class in that directory. I tried toupdate it to the path where the servlet class is located (ImportedClasses/samples/cviewer) but still the same error. I'll look into more of this but I thought I'd let everyone know since it isvoting time of the plugin.P.S. Later on I discovered that the sample works fine when I don't have thetwo checkboxes checked. I can see the servlet and jsp in the goodstructure in the repo. Lin-Original Message-From: Sachin Patel [mailto:[EMAIL PROTECTED]] On Behalf Of Sachin PatelSent: Sunday, July 09, 2006 4:25 PMTo: dev@geronimo.apache.orgSubject: [Vote] Geronimo Eclipse Plugin v1.1.0The following distributions of the Geronimo Eclipse plugin are ready to be voted on for final release. Since binding votes are needed, each PMC member if possible, please cast your vote within 72 hours.http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse- plugin-1.1-deployable-RC4.ziphttp://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse- plugin-1.1-updatesite-RC4.zipHere is my +1.- sachin -sachin
Re: [Vote] Geronimo Eclipse Plugin v1.1.0
On Jul 10, 2006, at 11:29 PM, Kevan Miller wrote:Sachin,At a minimum, you need to add:OpenEJB, MX4J, and XStream to the root LICENSE fileWhich root license file I you referring to? Do I just append each license to this?MX4J, and XMLBeans to the root NOTICE fileAgain which root?Did you investigate Hessian licensing? Yeah its under Apache 1.0 I think, but could not find a copy of it on their site.I didn't find any licensing info (at first). So, took a look at the source. The first source file I looked at contained the following:/* * Copyright (c) 1998-2004 Caucho Technology -- all rights reserved * * This file is part of Resin(R) Open Source * * Each copy or derived work must preserve the copyright notice and this * notice unmodified. * * Resin Open Source is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * Resin Open Source is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE, or any warranty * of NON-INFRINGEMENT. See the GNU General Public License for more * details. * * You should have received a copy of the GNU General Public License * along with Resin Open Source; if not, write to the * Free SoftwareFoundation, Inc. * 59 Temple Place, Suite 330 * Boston, MA 02111-1307 USA * * @author Scott Ferguson */I now see the following statement on their wiki:"Caucho Technology has released this Hessian implementation under an open source license (the Apache license). Anyone may freely download, use, and redistribute the Hessian implementation."But that's the strongest source of licensing info, that I've found...--kevanOn Jul 10, 2006, at 10:42 PM, Sachin Patel wrote:Fixed. Re-vote.http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-deployable-RC5.ziphttp://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-updatesite-RC5.zip (still uploading available shortly)On Jul 10, 2006, at 8:21 PM, Kevan Miller wrote:Sachin,I'm afraid I don't see either a NOTICE or LICENSE files in the plugin zip file, itself, nor any of the embedded jar files. They all must contain both LICENSE and NOTICE files. Afraid this is a hard requirement. And you'll need to create new binaries... See http://www.apache.org/dev/release.html#what-must-every-release-contain for more information.We should be able to reuse some of the license information we generated for G 1.1. I'm happy to help with that. I'm not sure how we're putting the NOTICE and LICENSE info in each of the jar files. Shouldn't be too hard to figure out, but perhaps someone can chime in...--kevanOn Jul 9, 2006, at 4:24 PM, Sachin Patel wrote: The following distributions of the Geronimo Eclipse plugin are ready to be voted on for final release. Since binding votes are needed, each PMC member if possible, please cast your vote within 72 hours.http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-deployable-RC4.ziphttp://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-updatesite-RC4.zipHere is my +1.- sachin -sachin -sachin
Re: Geronimo Eclipse Plugin FAQ
i have not gotten to the user part of it yet will add soonOn Jul 10, 2006, at 11:09 PM, Lin Sun wrote:Hi Sachin,It is great that you put out the FAQ - we definitely need that!One question I'd like to get answered is: There are two checkboxes in theAG server configuration panel: Enable in-place deployment Run standalone modules directly from workspace.What's the difference between them? I understand the in-place deployment,same as the deploy.bat --inPlace option. I figure that if a user choosesin-Place deployment, the project would stay where they are and won't bedeployed to the repo thus the user will run it directly from the eclipseworkspace. Doesn't the second checkbox mean the same?Thanks, Lin-Original Message-From: Sachin Patel [mailto:[EMAIL PROTECTED]] On Behalf Of Sachin PatelSent: Sunday, July 09, 2006 8:37 PMTo: dev@geronimo.apache.orgSubject: Geronimo Eclipse Plugin FAQI've started a eclipse plugin FAQ athttp://cwiki.apache.org/confluence/display/GMOxDOC11/Geronimo+Eclipse +Plugin+FAQ -sachin
Re: [Vote] Geronimo Eclipse Plugin v1.1.0
As far as Hessian, I found the following note and appears the source files are incorrect...http://www.caucho.com/support/hessian-interest/0606/0002.htmlSo does this mean that I should add a copy of the Apache 1.1 license?On Jul 10, 2006, at 11:29 PM, Kevan Miller wrote:Sachin,At a minimum, you need to add:OpenEJB, MX4J, and XStream to the root LICENSE fileMX4J, and XMLBeans to the root NOTICE fileDid you investigate Hessian licensing? I didn't find any licensing info (at first). So, took a look at the source. The first source file I looked at contained the following:/* * Copyright (c) 1998-2004 Caucho Technology -- all rights reserved * * This file is part of Resin(R) Open Source * * Each copy or derived work must preserve the copyright notice and this * notice unmodified. * * Resin Open Source is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * Resin Open Source is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE, or any warranty * of NON-INFRINGEMENT. See the GNU General Public License for more * details. * * You should have received a copy of the GNU General Public License * along with Resin Open Source; if not, write to the * Free SoftwareFoundation, Inc. * 59 Temple Place, Suite 330 * Boston, MA 02111-1307 USA * * @author Scott Ferguson */I now see the following statement on their wiki:"Caucho Technology has released this Hessian implementation under an open source license (the Apache license). Anyone may freely download, use, and redistribute the Hessian implementation."But that's the strongest source of licensing info, that I've found...--kevanOn Jul 10, 2006, at 10:42 PM, Sachin Patel wrote:Fixed. Re-vote.http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-deployable-RC5.ziphttp://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-updatesite-RC5.zip (still uploading available shortly)On Jul 10, 2006, at 8:21 PM, Kevan Miller wrote:Sachin,I'm afraid I don't see either a NOTICE or LICENSE files in the plugin zip file, itself, nor any of the embedded jar files. They all must contain both LICENSE and NOTICE files. Afraid this is a hard requirement. And you'll need to create new binaries... See http://www.apache.org/dev/release.html#what-must-every-release-contain for more information.We should be able to reuse some of the license information we generated for G 1.1. I'm happy to help with that. I'm not sure how we're putting the NOTICE and LICENSE info in each of the jar files. Shouldn't be too hard to figure out, but perhaps someone can chime in...--kevanOn Jul 9, 2006, at 4:24 PM, Sachin Patel wrote: The following distributions of the Geronimo Eclipse plugin are ready to be voted on for final release. Since binding votes are needed, each PMC member if possible, please cast your vote within 72 hours.http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-deployable-RC4.ziphttp://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-updatesite-RC4.zipHere is my +1.- sachin -sachin -sachin
Re: [Vote] Geronimo Eclipse Plugin v1.1.0
On Jul 11, 2006, at 8:41 AM, Sachin Patel wrote:On Jul 10, 2006, at 11:29 PM, Kevan Miller wrote:Sachin,At a minimum, you need to add:OpenEJB, MX4J, and XStream to the root LICENSE fileWhich root license file I you referring to? Do I just append each license to this?By root, I meant the notice and license files in g-eclipse-plugin-1-1/META-INF/. I actually don't think that they should be in the META-INF dir. I think you should end up with the following when you unzip:geronimo-eclipse-plugin-1-1/LICENSEgeronimo-eclipse-plugin-1-1/NOTICE (both license and notice should either be .txt or have no suffix)geronimo-eclipse-plugin-1-1/plugins/...geronimo-eclipse-plugin-1-1/features/...The additional license and notice information should be appended to the ASL license and notice info. see geronimo/branches/modules/scripts/src/resources/LICENSE.txt and NOTICE.txt (you can just steal the appropriate sections from these files).Looks like some of the jar files are still missing LICENSE and NOTICE files. org.apache.geronimo.v11.deployment.model.edit_1.0.0.jar, for instance.--kevan MX4J, and XMLBeans to the root NOTICE fileAgain which root?Did you investigate Hessian licensing? Yeah its under Apache 1.0 I think, but could not find a copy of it on their site.I didn't find any licensing info (at first). So, took a look at the source. The first source file I looked at contained the following:/* * Copyright (c) 1998-2004 Caucho Technology -- all rights reserved * * This file is part of Resin(R) Open Source * * Each copy or derived work must preserve the copyright notice and this * notice unmodified. * * Resin Open Source is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * Resin Open Source is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE, or any warranty * of NON-INFRINGEMENT. See the GNU General Public License for more * details. * * You should have received a copy of the GNU General Public License * along with Resin Open Source; if not, write to the * Free SoftwareFoundation, Inc. * 59 Temple Place, Suite 330 * Boston, MA 02111-1307 USA * * @author Scott Ferguson */I now see the following statement on their wiki:"Caucho Technology has released this Hessian implementation under an open source license (the Apache license). Anyone may freely download, use, and redistribute the Hessian implementation."But that's the strongest source of licensing info, that I've found...--kevanOn Jul 10, 2006, at 10:42 PM, Sachin Patel wrote:Fixed. Re-vote.http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-deployable-RC5.ziphttp://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-updatesite-RC5.zip (still uploading available shortly)On Jul 10, 2006, at 8:21 PM, Kevan Miller wrote:Sachin,I'm afraid I don't see either a NOTICE or LICENSE files in the plugin zip file, itself, nor any of the embedded jar files. They all must contain both LICENSE and NOTICE files. Afraid this is a hard requirement. And you'll need to create new binaries... See http://www.apache.org/dev/release.html#what-must-every-release-contain for more information.We should be able to reuse some of the license information we generated for G 1.1. I'm happy to help with that. I'm not sure how we're putting the NOTICE and LICENSE info in each of the jar files. Shouldn't be too hard to figure out, but perhaps someone can chime in...--kevanOn Jul 9, 2006, at 4:24 PM, Sachin Patel wrote: The following distributions of the Geronimo Eclipse plugin are ready to be voted on for final release. Since binding votes are needed, each PMC member if possible, please cast your vote within 72 hours.http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-deployable-RC4.ziphttp://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-updatesite-RC4.zipHere is my +1.- sachin -sachin -sachin
Re: [Vote] Geronimo Eclipse Plugin v1.1.0
[EMAIL PROTECTED] ok ignore rc6On Jul 11, 2006, at 9:59 AM, Kevan Miller wrote:On Jul 11, 2006, at 8:41 AM, Sachin Patel wrote:On Jul 10, 2006, at 11:29 PM, Kevan Miller wrote:Sachin,At a minimum, you need to add:OpenEJB, MX4J, and XStream to the root LICENSE fileWhich root license file I you referring to? Do I just append each license to this?By root, I meant the notice and license files in g-eclipse-plugin-1-1/META-INF/. I actually don't think that they should be in the META-INF dir. I think you should end up with the following when you unzip:geronimo-eclipse-plugin-1-1/LICENSEgeronimo-eclipse-plugin-1-1/NOTICE (both license and notice should either be .txt or have no suffix)geronimo-eclipse-plugin-1-1/plugins/...geronimo-eclipse-plugin-1-1/features/...The additional license and notice information should be appended to the ASL license and notice info. see geronimo/branches/modules/scripts/src/resources/LICENSE.txt and NOTICE.txt (you can just steal the appropriate sections from these files).Looks like some of the jar files are still missing LICENSE and NOTICE files. org.apache.geronimo.v11.deployment.model.edit_1.0.0.jar, for instance.--kevan MX4J, and XMLBeans to the root NOTICE fileAgain which root?Did you investigate Hessian licensing? Yeah its under Apache 1.0 I think, but could not find a copy of it on their site.I didn't find any licensing info (at first). So, took a look at the source. The first source file I looked at contained the following:/* * Copyright (c) 1998-2004 Caucho Technology -- all rights reserved * * This file is part of Resin(R) Open Source * * Each copy or derived work must preserve the copyright notice and this * notice unmodified. * * Resin Open Source is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * Resin Open Source is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE, or any warranty * of NON-INFRINGEMENT. See the GNU General Public License for more * details. * * You should have received a copy of the GNU General Public License * along with Resin Open Source; if not, write to the * Free SoftwareFoundation, Inc. * 59 Temple Place, Suite 330 * Boston, MA 02111-1307 USA * * @author Scott Ferguson */I now see the following statement on their wiki:"Caucho Technology has released this Hessian implementation under an open source license (the Apache license). Anyone may freely download, use, and redistribute the Hessian implementation."But that's the strongest source of licensing info, that I've found...--kevanOn Jul 10, 2006, at 10:42 PM, Sachin Patel wrote:Fixed. Re-vote.http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-deployable-RC5.ziphttp://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-updatesite-RC5.zip (still uploading available shortly)On Jul 10, 2006, at 8:21 PM, Kevan Miller wrote:Sachin,I'm afraid I don't see either a NOTICE or LICENSE files in the plugin zip file, itself, nor any of the embedded jar files. They all must contain both LICENSE and NOTICE files. Afraid this is a hard requirement. And you'll need to create new binaries... See http://www.apache.org/dev/release.html#what-must-every-release-contain for more information.We should be able to reuse some of the license information we generated for G 1.1. I'm happy to help with that. I'm not sure how we're putting the NOTICE and LICENSE info in each of the jar files. Shouldn't be too hard to figure out, but perhaps someone can chime in...--kevanOn Jul 9, 2006, at 4:24 PM, Sachin Patel wrote: The following distributions of the Geronimo Eclipse plugin are ready to be voted on for final release. Since binding votes are needed, each PMC member if possible, please cast your vote within 72 hours.http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-deployable-RC4.ziphttp://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-updatesite-RC4.zipHere is my +1.- sachin -sachin -sachin -sachin
[jira] Resolved: (AMQ-608) Change logging level of some DemandForwardingBridge log messages.
[ https://issues.apache.org/activemq/browse/AMQ-608?page=all ] Hiram Chirino resolved AMQ-608: --- Resolution: Fixed Patch applied! Thanks Kevin! Change logging level of some DemandForwardingBridge log messages. - Key: AMQ-608 URL: https://issues.apache.org/activemq/browse/AMQ-608 Project: ActiveMQ Type: Improvement Components: Broker Versions: 4.0 Reporter: Kevin Yaussy Assignee: Hiram Chirino Fix For: 4.1, 4.0.2 Attachments: DemandForwardingBridge.java, DemandForwardingBridgeSupport.java, DemandForwardingBridgeSupport.patch, FailoverTransport.java, FailoverTransport.java, FailoverTransport.patch, InactivityMonitor.patch, InactivityMonitor.patch2 In DemandForwardingBridge, I'd like to be able to see subscription messages (and unsubscription messages), but not bridging messages. Both classes of log messages are log.trace. Seems like the bridging messages should remain trace, as you would want to look at that when you are doing pretty detailed debugging. However, I'd like to see subscribe/unsubscribe messages all the time. If those could be either info or debug, that would allow me to turn those on separately. I realize that I can see what is currently subscribed via the JMX console. However, seeing the subscribe/unsubscribe messages will allow diagnostics over time - who subscribed when type of questions. Mainly, I'm referring to messages logged as trace in: DemandForwardingBridge.serviceRemoteConsumerAdvisory DemandForwardingBridge.removeDemandSubscription -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-813) can get a shutdown hang when using embedded broker with VM transport along with the activemq-web module
can get a shutdown hang when using embedded broker with VM transport along with the activemq-web module --- Key: AMQ-813 URL: https://issues.apache.org/activemq/browse/AMQ-813 Project: ActiveMQ Type: Bug Reporter: james strachan Fix For: 4.1 See attached thread dump. I think we just need to use a timeout on the close operations (such as to close consumers, sessions, producers) Full thread dump Java HotSpot(TM) Client VM (1.5.0_04-b05 mixed mode, sharing): Shutdown prio=1 tid=0x08385960 nid=0x5e99 in Object.wait() [0xaed7d000..0xaed7e130] at java.lang.Object.wait(Native Method) - waiting on 0x88af01c8 (a edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar) at java.lang.Object.wait(Object.java:474) at edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar.await(CondVar.java:75) - locked 0x88af01c8 (a edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar) at edu.emory.mathcs.backport.java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:318) at org.apache.activemq.transport.FutureResponse.getResult(FutureResponse.java:41) at org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:72) at org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1130) at org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:1660) at org.apache.activemq.ActiveMQMessageConsumer.close(ActiveMQMessageConsumer.java:516) at org.apache.activemq.web.WebClient.closeConsumers(WebClient.java:135) - locked 0x893e6558 (a org.apache.activemq.web.WebClient) at org.apache.activemq.web.WebClient.close(WebClient.java:145) - locked 0x893e6558 (a org.apache.activemq.web.WebClient) at org.apache.activemq.web.WebClient.valueUnbound(WebClient.java:318) at org.mortbay.jetty.servlet.AbstractSessionManager$Session.unbindValue(AbstractSessionManager.java:899) at org.mortbay.jetty.servlet.AbstractSessionManager$Session.invalidate(AbstractSessionManager.java:755) - locked 0x893caa88 (a org.mortbay.jetty.servlet.HashSessionManager$Session) at org.mortbay.jetty.servlet.AbstractSessionManager.doStop(AbstractSessionManager.java:551) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:63) at org.mortbay.jetty.servlet.SessionHandler.doStop(SessionHandler.java:124) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:63) at org.mortbay.jetty.handler.HandlerWrapper.doStop(HandlerWrapper.java:131) at org.mortbay.jetty.handler.ContextHandler.doStop(ContextHandler.java:467) at org.mortbay.jetty.webapp.WebAppContext.doStop(WebAppContext.java:477) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:63) at org.mortbay.jetty.handler.HandlerCollection.doStop(HandlerCollection.java:173) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:63) at org.mortbay.jetty.handler.HandlerCollection.doStop(HandlerCollection.java:173) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:63) at org.mortbay.jetty.handler.HandlerWrapper.doStop(HandlerWrapper.java:131) at org.mortbay.jetty.Server.doStop(Server.java:242) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:63) at org.mortbay.jetty.Server$ShutdownHookThread.run(Server.java:450) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-813) can get a shutdown hang when using embedded broker with VM transport along with the activemq-web module
[ https://issues.apache.org/activemq/browse/AMQ-813?page=all ] Hiram Chirino resolved AMQ-813: --- Fix Version: 4.0.2 Resolution: Fixed Assign To: Hiram Chirino Fixed: http://svn.apache.org/viewvc/incubator/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/transport/vm/VMTransport.java?r1=415306r2=420714pathrev=420714 The VMTransport's oneway method was dropping the send request when the peer was disconnected like in the case where the broker is shutdown at the same time that the client is shutdown. can get a shutdown hang when using embedded broker with VM transport along with the activemq-web module --- Key: AMQ-813 URL: https://issues.apache.org/activemq/browse/AMQ-813 Project: ActiveMQ Type: Bug Reporter: james strachan Assignee: Hiram Chirino Fix For: 4.1, 4.0.2 See attached thread dump. I think we just need to use a timeout on the close operations (such as to close consumers, sessions, producers) Full thread dump Java HotSpot(TM) Client VM (1.5.0_04-b05 mixed mode, sharing): Shutdown prio=1 tid=0x08385960 nid=0x5e99 in Object.wait() [0xaed7d000..0xaed7e130] at java.lang.Object.wait(Native Method) - waiting on 0x88af01c8 (a edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar) at java.lang.Object.wait(Object.java:474) at edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar.await(CondVar.java:75) - locked 0x88af01c8 (a edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar) at edu.emory.mathcs.backport.java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:318) at org.apache.activemq.transport.FutureResponse.getResult(FutureResponse.java:41) at org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:72) at org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1130) at org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:1660) at org.apache.activemq.ActiveMQMessageConsumer.close(ActiveMQMessageConsumer.java:516) at org.apache.activemq.web.WebClient.closeConsumers(WebClient.java:135) - locked 0x893e6558 (a org.apache.activemq.web.WebClient) at org.apache.activemq.web.WebClient.close(WebClient.java:145) - locked 0x893e6558 (a org.apache.activemq.web.WebClient) at org.apache.activemq.web.WebClient.valueUnbound(WebClient.java:318) at org.mortbay.jetty.servlet.AbstractSessionManager$Session.unbindValue(AbstractSessionManager.java:899) at org.mortbay.jetty.servlet.AbstractSessionManager$Session.invalidate(AbstractSessionManager.java:755) - locked 0x893caa88 (a org.mortbay.jetty.servlet.HashSessionManager$Session) at org.mortbay.jetty.servlet.AbstractSessionManager.doStop(AbstractSessionManager.java:551) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:63) at org.mortbay.jetty.servlet.SessionHandler.doStop(SessionHandler.java:124) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:63) at org.mortbay.jetty.handler.HandlerWrapper.doStop(HandlerWrapper.java:131) at org.mortbay.jetty.handler.ContextHandler.doStop(ContextHandler.java:467) at org.mortbay.jetty.webapp.WebAppContext.doStop(WebAppContext.java:477) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:63) at org.mortbay.jetty.handler.HandlerCollection.doStop(HandlerCollection.java:173) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:63) at org.mortbay.jetty.handler.HandlerCollection.doStop(HandlerCollection.java:173) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:63) at org.mortbay.jetty.handler.HandlerWrapper.doStop(HandlerWrapper.java:131) at org.mortbay.jetty.Server.doStop(Server.java:242) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:63) at org.mortbay.jetty.Server$ShutdownHookThread.run(Server.java:450) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-732) Infinite recovery loop.
[
https://issues.apache.org/activemq/browse/AMQ-732?page=comments#action_36556 ]
Hiram Chirino commented on AMQ-732:
---
We need to build activeio beta-4 and ship with that.
Infinite recovery loop.
---
Key: AMQ-732
URL: https://issues.apache.org/activemq/browse/AMQ-732
Project: ActiveMQ
Type: Bug
Components: Broker
Versions: 4.0
Environment: Linux RHEL 3
Reporter: Maxim Fateev
Assignee: Hiram Chirino
Fix For: 4.1, 4.0.2
Attachments: activemq-data-1-journal.tar.gz, activemq-data-2-journal.tar.gz
The simplest way to reproduce the problem:
1. Remove storage directory.
2. Start broker using the following code:
public static void main(String[] args) throws Exception {
BrokerService broker = new BrokerService();
broker.setPersistent(true);
DefaultPersistenceAdapterFactory pFactory = new
DefaultPersistenceAdapterFactory();
pFactory.setJournalLogFiles(1);
pFactory.setJournalLogFileSize(2048);
broker.setPersistenceFactory(pFactory);
broker.setUseJmx(false);
broker.addConnector(tcp://localhost:61616);
broker.start();
Thread.sleep(1l);
}
3. Shutdown the broker.
4. Start broker.
It enters infinite loop
[ main] BrokerService INFO
ActiveMQ null JMS Message Broker (localhost) is starting
[ main] BrokerService INFO For
help or more information please see: http://incubator.apache.org/activemq/
[ main] JDBCPersistenceAdapter INFO
Database driver recognized: [apache_derby_embedded_jdbc_driver]
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE TABLE ACTIVEMQ_MSGS(ID INTEGER NOT NULL, CONTAINER
VARCHAR(250), MSGID_PROD VARCHAR(250), MSGID_SEQ INTEGER, EXPIRATION BIGINT,
MSG BLOB, PRIMARY KEY ( ID ) )
[ main] DefaultJDBCAdapter DEBUG Could
not create JDBC tables; The message table already existed. Failure was:
CREATE TABLE ACTIVEMQ_MSGS(ID INTEGER NOT NULL, CONTAINER VARCHAR(250),
MSGID_PROD VARCHAR(250), MSGID_SEQ INTEGER, EXPIRATION BIGINT, MSG BLOB,
PRIMARY KEY ( ID ) ) Message: Table/View 'ACTIVEMQ_MSGS' already exists in
Schema 'APP'. SQLState: X0Y32 Vendor code: 2
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_MIDX ON ACTIVEMQ_MSGS
(MSGID_PROD,MSGID_SEQ)
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_CIDX ON ACTIVEMQ_MSGS (CONTAINER)
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_EIDX ON ACTIVEMQ_MSGS (EXPIRATION)
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE TABLE ACTIVEMQ_ACKS(CONTAINER VARCHAR(250) NOT NULL,
CLIENT_ID VARCHAR(250) NOT NULL, SUB_NAME VARCHAR(250) NOT NULL, SELECTOR
VARCHAR(250), LAST_ACKED_ID INTEGER, PRIMARY KEY ( CONTAINER, CLIENT_ID,
SUB_NAME))
[ main] DefaultJDBCAdapter DEBUG Could
not create JDBC tables; The message table already existed. Failure was:
CREATE TABLE ACTIVEMQ_ACKS(CONTAINER VARCHAR(250) NOT NULL, CLIENT_ID
VARCHAR(250) NOT NULL, SUB_NAME VARCHAR(250) NOT NULL, SELECTOR VARCHAR(250),
LAST_ACKED_ID INTEGER, PRIMARY KEY ( CONTAINER, CLIENT_ID, SUB_NAME))
Message: Table/View 'ACTIVEMQ_ACKS' already exists in Schema 'APP'. SQLState:
X0Y32 Vendor code: 2
[ main] JDBCPersistenceAdapter DEBUG
Cleaning up old messages.
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: DELETE FROM ACTIVEMQ_MSGS WHERE ( EXPIRATION0 AND
EXPIRATION?) OR ID = ( SELECT min(ACTIVEMQ_ACKS.LAST_ACKED_ID) FROM
ACTIVEMQ_ACKS WHERE ACTIVEMQ_ACKS.CONTAINER=ACTIVEMQ_MSGS.CONTAINER)
[ main] DefaultJDBCAdapter DEBUG Deleted
0 old message(s).
[ main] JDBCPersistenceAdapter DEBUG Cleanup
done.
[ main] JournalPersistenceAdapter INFO Journal
Recovery Started from: Active Journal: using 1 x 0.001953125 Megs at:
/workplace/fateev/install/activemq-4.0-SNAPSHOT/activemq-core/activemq-data/journal
[ main] JournalPersistenceAdapter DEBUG TRACE
Entry: RECOVERED
[Journal Writer] LogFileManager DEBUG
getNextDataRecordLocation offset=53
[Journal Writer] LogFileManager DEBUG
getNextDataRecordLocation offset=97
[Journal Writer] LogFileManager DEBUG
getNextDataRecordLocation overflowing into next logFile=0
[
Re: Regarding ClassLoader Changes in Geronimo 1.1
So are you saying that in Geronimo 1.0 the WAR directory itself was on the class path (as opposed to the JARs in WEB-INF/lib and the dir WEB-INF/classes)? I don't think that's really portable behavior (the spec only covers lib and classes as far as I know), so you might not want to rely on it in any case. You can file a Jira if you like so we can see if other people run into the same thing. Thanks, Aaron On 7/10/06, Manu George [EMAIL PROTECTED] wrote: Hi, I have an application that is packaged as an EAR. The WAR inside the EAR is having some images in the images directory directly inside the war. In Geronimo 1.0, I was able to access them using Thread.currentThread().getContextClassLoader().getResource() method, but now I am unable to do so. On debugging I found that the classloader I got for 1.0 was WebappClassLoader from Tomcat which had access to the files, while for 1.1, I got JarFileClassLoader of geronimo which did not have access to those files. Can anyone throw further light on this problem. Thanks Manu
Re: Geronimo 1.1 JARs in Maven 2 Repo
On 7/10/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: I think that it's better to have different group ids for the M1 and M2 jars since their contents, maven wise, are quite different. IIUC, we really shouldn't be putting M1 jars into an M2 repo. So are you taking the position that we should not support Maven 2 builds with dependencies on Geronimo 1.1, or that we should support Maven 2 builds with dependencies on 1.1 but only if they use the Maven 1 Group ID for Geronimo and then change the Group ID when they update to Geronimo 1.2? My position is that if someone is using Maven 2 with dependencies on Geronimo, they should use the Maven 2 Group ID for Geronimo, regardless of which version of Geronimo they're depending on. Or, perhaps you're saying that we should keep the JARs in a Maven 1 repo but put them in there twice, in one place for the Maven 1 Group ID (for Maven 1 clients) and in a different place for the Maven 2 Group ID for Maven 2 clients (who need to point their build to a Maven 1 repo but from what you've said that will work)? Thanks, Aaron
Re: war manifest classpath in ear (GERONIMO-2125)
What if the WAR is in a subdir within the EAR like foo/bar/some.war? Then .. alone won't work to resolve paths relative to the EAR. I would think from a WAR-in-EAR, we could identify the Module ID of the EAR, and then use the repo to construct a path to the JAR-in-EAR with the EAR module ID and the JAR path. Is there a reason why that wouldn't work? Thanks, Aaron On 7/10/06, David Jencks [EMAIL PROTECTED] wrote: I've finally managed to reproduce the problem in GERONIMO-2125, in which you have an ear, with a war inside, with a manifest classpath, and the stuff on the mcp doesn't work. The problem is pretty much caused by our new configuration for the war, although I think a similar problem would occur for an exploded ejb jar in an ear. ( I suspect the latter doesn't work at all now, since in that case we should manually add the mcp entries to the cp, which we don't) so, we a uri out of the mcp, and try to resolve it against the war config base uri, such as web.war, and add it to the config classpath, so we get e.g. an entry of jar.jar. However, this is relative to the war config, which does not have this jar in it: it's actually in the containing ear config, typically up one directory. e.g. ear config is at /Users/david/geronimo/svn/geronimo/trunk/assemblies/j2ee-jetty-server/ target/geronimo-1.2-SNAPSHOT/repository/default/ear-1.0-SNAPSHOT/ 1152577205326/ear-1.0-SNAPSHOT-1152577205326.car war config inside it is at /Users/david/geronimo/svn/geronimo/trunk/assemblies/j2ee-jetty-server/ target/geronimo-1.2-SNAPSHOT/repository/default/ear-1.0-SNAPSHOT/ 1152577205326/ear-1.0-SNAPSHOT-1152577205326.car/web.war the mcp entry should be ../jar.jar or we need to copy another copy of the jar.jar into the war configuration. I'm in favor of relativizing the mcp entry to ../jar.jar but I'm a little worried about the consequences. Anyone see any problems with this? thanks david jencks
Bean lookup taking forever
I deployed a simple session bean in my geronimo 1.0 server, however, when i try to lookup the bean from a Java Application it takes forever, i mean, no error is returned, but the lookup never finishes. Any help will be greatly appreciated Rafael
Re: war manifest classpath in ear (GERONIMO-2125)
On Jul 11, 2006, at 8:03 AM, Aaron Mulder wrote: What if the WAR is in a subdir within the EAR like foo/bar/some.war? Then .. alone won't work to resolve paths relative to the EAR. Yes, whatever relative path we might generate certainly would have to take account of the position of the war inside the ear. I would think from a WAR-in-EAR, we could identify the Module ID of the EAR, and then use the repo to construct a path to the JAR-in-EAR with the EAR module ID and the JAR path. Is there a reason why that wouldn't work? IIUC you are suggesting that the war configuration/module keep track of two parts of its classpath: one inside itself, for WEB-INF/lib and WEB-INF/classes, and one inside the enclosing ear, for the manifest classpath. This certainly seems possible to me but I wonder what advantage it would have over only tracking stuff in one place. So, now I see even more possibilities: 1. copy the manifest cp entries from the ear into the war. This would keep the war self contained, but otherwise seems like a lot of extra work for nothing. 2. keep track of the stuff inside the war and inside the ear separately (your proposal IIUC) 3. keep track of the war classpath based on the war location inside the ear, so manifest classpath entries get a ../ prepended to them (if the war was in a subdirectory in the ear, manifest cp entries would most likely already have one or more ../ since entries are relative to the war location). 4. keep track of the entire war classpath based on the ear location, so the stuff in WEB-INF/[lib,classes] would have the war location inside the ear prepended. I'm tempted by (4).To me it says, here's the ear with a lot of stuff inside, and you can define classloaders that access an arbitrary subset of the stuff inside. I think this is the most compatible with the idea that's been floating around for a while of keeping the configuration separate from the j2ee artifact that is is based on: i.e. copy (possibly with unpacking) the j2ee artifact into the repo, and not into the car file: the car file just gets pointers into the j2ee artifact to define its classloader. Any further thoughts? thanks david jencks Thanks, Aaron On 7/10/06, David Jencks [EMAIL PROTECTED] wrote: I've finally managed to reproduce the problem in GERONIMO-2125, in which you have an ear, with a war inside, with a manifest classpath, and the stuff on the mcp doesn't work. The problem is pretty much caused by our new configuration for the war, although I think a similar problem would occur for an exploded ejb jar in an ear. ( I suspect the latter doesn't work at all now, since in that case we should manually add the mcp entries to the cp, which we don't) so, we a uri out of the mcp, and try to resolve it against the war config base uri, such as web.war, and add it to the config classpath, so we get e.g. an entry of jar.jar. However, this is relative to the war config, which does not have this jar in it: it's actually in the containing ear config, typically up one directory. e.g. ear config is at /Users/david/geronimo/svn/geronimo/trunk/assemblies/j2ee-jetty- server/ target/geronimo-1.2-SNAPSHOT/repository/default/ear-1.0-SNAPSHOT/ 1152577205326/ear-1.0-SNAPSHOT-1152577205326.car war config inside it is at /Users/david/geronimo/svn/geronimo/trunk/assemblies/j2ee-jetty- server/ target/geronimo-1.2-SNAPSHOT/repository/default/ear-1.0-SNAPSHOT/ 1152577205326/ear-1.0-SNAPSHOT-1152577205326.car/web.war the mcp entry should be ../jar.jar or we need to copy another copy of the jar.jar into the war configuration. I'm in favor of relativizing the mcp entry to ../jar.jar but I'm a little worried about the consequences. Anyone see any problems with this? thanks david jencks
PackageBuilderShellMojo (m2) and classloaders
Jason Dillon asked last night on IRC why the PackgeBuilderShellMojo for the m2 packaging plugin used reflection to create the PackageBuilder. We need to control the classloader for PackageBuilder pretty closely so it has the same classpath as j2ee- system. In maven 1, IIUC, plugins get instantiated using a child classloader of the project calling the plugin: this classloader typically has a more or less random selection of large numbers of geronimo jars in it, far more than j2ee-system, and in particular including all the classes for the dependencies of the module/ configuration you are trying to build. The only solution I could see for m1 was to construct a classloader myself and load PackageBuilder in my own classloader and access the instance by reflection. I believe the situation is better in m2 and that the plugin is instantiated using a classloader determined solely by the plugin's pom. If so, we should be safe in eliminating this extra reflection code and in fact using PackageBuilder directly without the shell. If not, we should keep using the inconvenient reflection code. thanks david jencks
Re: war manifest classpath in ear (GERONIMO-2125)
I'm not sure what you mean by keep track of the stuff inside the war and inside the ear separately -- I don't think I understand the issue. But the option 4 that you like (everything relative to EAR location) sounds fine to me too. Though, I guess I need to ask -- if you have a relative manifest Class-Path entry in a WAR in a subdirectory of an EAR, is it relative to the WAR location within the EAR or the EAR root? I guess I had been assuming it was relative to the EAR root, but now that I think about it, it would make more sense to be relative to the WAR location within the EAR, so .. would be fine. Anyway, I still like option 4. Thanks, Aaron On 7/11/06, David Jencks [EMAIL PROTECTED] wrote: On Jul 11, 2006, at 8:03 AM, Aaron Mulder wrote: What if the WAR is in a subdir within the EAR like foo/bar/some.war? Then .. alone won't work to resolve paths relative to the EAR. Yes, whatever relative path we might generate certainly would have to take account of the position of the war inside the ear. I would think from a WAR-in-EAR, we could identify the Module ID of the EAR, and then use the repo to construct a path to the JAR-in-EAR with the EAR module ID and the JAR path. Is there a reason why that wouldn't work? IIUC you are suggesting that the war configuration/module keep track of two parts of its classpath: one inside itself, for WEB-INF/lib and WEB-INF/classes, and one inside the enclosing ear, for the manifest classpath. This certainly seems possible to me but I wonder what advantage it would have over only tracking stuff in one place. So, now I see even more possibilities: 1. copy the manifest cp entries from the ear into the war. This would keep the war self contained, but otherwise seems like a lot of extra work for nothing. 2. keep track of the stuff inside the war and inside the ear separately (your proposal IIUC) 3. keep track of the war classpath based on the war location inside the ear, so manifest classpath entries get a ../ prepended to them (if the war was in a subdirectory in the ear, manifest cp entries would most likely already have one or more ../ since entries are relative to the war location). 4. keep track of the entire war classpath based on the ear location, so the stuff in WEB-INF/[lib,classes] would have the war location inside the ear prepended. I'm tempted by (4).To me it says, here's the ear with a lot of stuff inside, and you can define classloaders that access an arbitrary subset of the stuff inside. I think this is the most compatible with the idea that's been floating around for a while of keeping the configuration separate from the j2ee artifact that is is based on: i.e. copy (possibly with unpacking) the j2ee artifact into the repo, and not into the car file: the car file just gets pointers into the j2ee artifact to define its classloader. Any further thoughts? thanks david jencks Thanks, Aaron On 7/10/06, David Jencks [EMAIL PROTECTED] wrote: I've finally managed to reproduce the problem in GERONIMO-2125, in which you have an ear, with a war inside, with a manifest classpath, and the stuff on the mcp doesn't work. The problem is pretty much caused by our new configuration for the war, although I think a similar problem would occur for an exploded ejb jar in an ear. ( I suspect the latter doesn't work at all now, since in that case we should manually add the mcp entries to the cp, which we don't) so, we a uri out of the mcp, and try to resolve it against the war config base uri, such as web.war, and add it to the config classpath, so we get e.g. an entry of jar.jar. However, this is relative to the war config, which does not have this jar in it: it's actually in the containing ear config, typically up one directory. e.g. ear config is at /Users/david/geronimo/svn/geronimo/trunk/assemblies/j2ee-jetty- server/ target/geronimo-1.2-SNAPSHOT/repository/default/ear-1.0-SNAPSHOT/ 1152577205326/ear-1.0-SNAPSHOT-1152577205326.car war config inside it is at /Users/david/geronimo/svn/geronimo/trunk/assemblies/j2ee-jetty- server/ target/geronimo-1.2-SNAPSHOT/repository/default/ear-1.0-SNAPSHOT/ 1152577205326/ear-1.0-SNAPSHOT-1152577205326.car/web.war the mcp entry should be ../jar.jar or we need to copy another copy of the jar.jar into the war configuration. I'm in favor of relativizing the mcp entry to ../jar.jar but I'm a little worried about the consequences. Anyone see any problems with this? thanks david jencks
Re: [VOTE] Release 2.5 of XBean
+1 Jacek Laskowski wrote: On 7/11/06, James Strachan [EMAIL PROTECTED] wrote: Due to the serious nature of this bug (and we've already had a few user mails on ActiveMQ about this already and spring 2.0-rc2 has only been out a short time) I'd like us to get a release of xbean out ASAP to avoid users hittitng this issue. Here's my +1 +1 Jacek
[jira] Commented: (AMQ-816) new transport for load balancing client requests across many brokers
[ https://issues.apache.org/activemq/browse/AMQ-816?page=comments#action_36560 ] Hiram Chirino commented on AMQ-816: --- Sounds similar to the fanout transport we currently have. Except that in the fanout transport it's backwards. We broadcast the publish to multiple brokers and only consume from 1. new transport for load balancing client requests across many brokers Key: AMQ-816 URL: https://issues.apache.org/activemq/browse/AMQ-816 Project: ActiveMQ Type: Improvement Reporter: james strachan Fix For: 4.2 Rather than creating store and forward networks, it might be nice to have a kind of composite transport where... * consumers are created on each broker found/discovered. This allows messages to be sent to any broker and consumed by any consumer * producers could dynmically choose which broker to send a message to (or could just pick one broker per session/producer) this allows for a load balancing layer at the client side which avoids the need for store/forward networks (which results in more network traffic and often increases load on the brokers). So it basically pushes load back to the clients. The downside of this appoach is that the clients have more connections to brokers - but given the linear scalability of this, it sounds a great idea to me at least :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [xbean] Colossus server
On Jul 11, 2006, at 8:21 AM, toby cabot wrote: Dain, Apologies in advance if this is a naive question but is Colossus the future direction of Geronimo? No, not at all. What's the goal? I want to have a single colossus spring.xml so that I have a large working base to experiment with different modularity solutions. Basically, this is a setup for more experimentation. -dain
Re: war manifest classpath in ear (GERONIMO-2125)
On Jul 11, 2006, at 8:30 AM, David Jencks wrote: On Jul 11, 2006, at 8:03 AM, Aaron Mulder wrote: What if the WAR is in a subdir within the EAR like foo/bar/some.war? Then .. alone won't work to resolve paths relative to the EAR. Yes, whatever relative path we might generate certainly would have to take account of the position of the war inside the ear. IIRC, the manifest class path is relative to the archive itself. In this case it is relative to the some.war, so if you want something in the foo dir, the manifest class path entry would have to be ../../ jar.jar Also, I think all of this is out side of the spec. IIRC the spec only talks about manifest class path entries of jar files, and since a war is not a jar file it isn't covered by the spec. Regardless, I think it is a good idea to support this, but I want to clarify that I don't believe this is a certification issue. I would think from a WAR-in-EAR, we could identify the Module ID of the EAR, and then use the repo to construct a path to the JAR-in-EAR with the EAR module ID and the JAR path. Is there a reason why that wouldn't work? IIUC you are suggesting that the war configuration/module keep track of two parts of its classpath: one inside itself, for WEB-INF/ lib and WEB-INF/classes, and one inside the enclosing ear, for the manifest classpath. This certainly seems possible to me but I wonder what advantage it would have over only tracking stuff in one place. So, now I see even more possibilities: 1. copy the manifest cp entries from the ear into the war. This would keep the war self contained, but otherwise seems like a lot of extra work for nothing. 2. keep track of the stuff inside the war and inside the ear separately (your proposal IIUC) 3. keep track of the war classpath based on the war location inside the ear, so manifest classpath entries get a ../ prepended to them (if the war was in a subdirectory in the ear, manifest cp entries would most likely already have one or more ../ since entries are relative to the war location). 4. keep track of the entire war classpath based on the ear location, so the stuff in WEB-INF/[lib,classes] would have the war location inside the ear prepended. I'm tempted by (4).To me it says, here's the ear with a lot of stuff inside, and you can define classloaders that access an arbitrary subset of the stuff inside. I think this is the most compatible with the idea that's been floating around for a while of keeping the configuration separate from the j2ee artifact that is is based on: i.e. copy (possibly with unpacking) the j2ee artifact into the repo, and not into the car file: the car file just gets pointers into the j2ee artifact to define its classloader. Um I didn't really understand all the options, but I would like to suggest that the class path contain patterns (the code is already in place for this) and we resolve these patterns against the root dir of the war. For manifest class path entries, we would just need to prepend each entry with ../ to get outside the war dir and prepend them to the class path with the manifest entries. For example, the example aaron used above would result in the following: War base dir: foo/bar/web.war/ War class path: ../../../jar.jar lib/classes lib/*.jar lib/*.zip Final class path: foo/jar.jar foo/bar/web.war/lib/classes foo/bar/web.war/lib/lib.jar foo/bar/web.war/lib/lib.zip -dain
Re: [VOTE] Release 2.5 of XBean
+1 dain On Jul 11, 2006, at 3:42 AM, James Strachan wrote: I've just applied 2 trivial bug fixes to the xbean-spring module of XBean. The first is a patch from Guillaume which is a one liner to create the xml parser using a helper method (used by all the other ApplicationContext implementations). http://issues.apache.org/jira/browse/XBEAN-21 The other is a trivial fix but has a major impact. Version 2.0-rc2 of spring barfs if you pass a null ClassLoader into the NamespaceHandler stuff - however the regression tests for 2.0-rc1 and 2.0-m5 work fine. Basically this means that all projects using xbean-spring (such as ActiveMQ, OpenEJB, XFire, ServiceMix, Jetty etc) will all break if the user upgrades from 2.0-m5 or 2.0-rc1 of spring to 2.0-rc2. I've just added a one liner to use the current threads context class loader if the class loader is null to avoid the exception which seems to work fine. (I added a regression test for 2.0-rc2 by just cut and pasting the regression test for 2.0-rc1 which reproduced the error so I could test the fix worked). Due to the serious nature of this bug (and we've already had a few user mails on ActiveMQ about this already and spring 2.0-rc2 has only been out a short time) I'd like us to get a release of xbean out ASAP to avoid users hittitng this issue. Here's my +1 -- James --- http://radio.weblogs.com/0112098/
Re: Should we add large String value support in MapMessage in 4.0.2 ?? re: AMQ-788
+1 - sounds good to me On 11 Jul 2006, at 16:42, Hiram Chirino wrote: Hi Folks. In 4.1 we added a patch that add support of handling large string values ( 32k ) in map messages. See: http://issues.apache.org/activemq/browse/AMQ-788 I just wanted to see if you guys think we should backport that to 4.0.2also? The only down side is that a slight incompatibility in marshaling is introduced. It only affect messages that use string values 8k. With the patch once a string value is 8k, we now use a different marshaling strategy that allow for marshaling String values up to 2 gigs. So if you have = 4.0.1 clients talking to 4.0.2 clients sending map messages with String values 8k then the = 4.0.1 clients may not be able handle the messages from the 4.0.2 clients. I think it's safe enough to add since we did not support large messages anyways in 4.0.1. -- Regards, Hiram Blog: http://hiramchirino.com
Re: war manifest classpath in ear (GERONIMO-2125)
I'm not sure but I think the Class-Path entry in war files is covered by the spec because EAR, WAR and RAR are JAR files. J2EE 1.4 excluded EAR files from that. EAR manifest files should not contain a Class-Path entry. packaging description from sun: http://java.sun.com/j2ee/verified/packaging.html Also the class path entry is relative to the war file not the WEB-INF/classes or WEB-INF/lib in the war file. Thanks, Mario Dain Sundstrom wrote: On Jul 11, 2006, at 8:30 AM, David Jencks wrote: On Jul 11, 2006, at 8:03 AM, Aaron Mulder wrote: What if the WAR is in a subdir within the EAR like foo/bar/some.war? Then .. alone won't work to resolve paths relative to the EAR. Yes, whatever relative path we might generate certainly would have to take account of the position of the war inside the ear. IIRC, the manifest class path is relative to the archive itself. In this case it is relative to the some.war, so if you want something in the foo dir, the manifest class path entry would have to be ../../jar.jar Also, I think all of this is out side of the spec. IIRC the spec only talks about manifest class path entries of jar files, and since a war is not a jar file it isn't covered by the spec. Regardless, I think it is a good idea to support this, but I want to clarify that I don't believe this is a certification issue. I would think from a WAR-in-EAR, we could identify the Module ID of the EAR, and then use the repo to construct a path to the JAR-in-EAR with the EAR module ID and the JAR path. Is there a reason why that wouldn't work? IIUC you are suggesting that the war configuration/module keep track of two parts of its classpath: one inside itself, for WEB-INF/lib and WEB-INF/classes, and one inside the enclosing ear, for the manifest classpath. This certainly seems possible to me but I wonder what advantage it would have over only tracking stuff in one place. So, now I see even more possibilities: 1. copy the manifest cp entries from the ear into the war. This would keep the war self contained, but otherwise seems like a lot of extra work for nothing. 2. keep track of the stuff inside the war and inside the ear separately (your proposal IIUC) 3. keep track of the war classpath based on the war location inside the ear, so manifest classpath entries get a ../ prepended to them (if the war was in a subdirectory in the ear, manifest cp entries would most likely already have one or more ../ since entries are relative to the war location). 4. keep track of the entire war classpath based on the ear location, so the stuff in WEB-INF/[lib,classes] would have the war location inside the ear prepended. I'm tempted by (4).To me it says, here's the ear with a lot of stuff inside, and you can define classloaders that access an arbitrary subset of the stuff inside. I think this is the most compatible with the idea that's been floating around for a while of keeping the configuration separate from the j2ee artifact that is is based on: i.e. copy (possibly with unpacking) the j2ee artifact into the repo, and not into the car file: the car file just gets pointers into the j2ee artifact to define its classloader. Um I didn't really understand all the options, but I would like to suggest that the class path contain patterns (the code is already in place for this) and we resolve these patterns against the root dir of the war. For manifest class path entries, we would just need to prepend each entry with ../ to get outside the war dir and prepend them to the class path with the manifest entries. For example, the example aaron used above would result in the following: War base dir: foo/bar/web.war/ War class path: ../../../jar.jar lib/classes lib/*.jar lib/*.zip Final class path: foo/jar.jar foo/bar/web.war/lib/classes foo/bar/web.war/lib/lib.jar foo/bar/web.war/lib/lib.zip -dain
Re: [Vote] Geronimo Eclipse Plugin v1.1.0
This will be properly documented in the release notes but cannot change this in the code stream.On Jul 11, 2006, at 1:15 PM, Lin Sun wrote:I would prefer some statement on the Geronimo server configuration panel to state that this function is not feature complete and works only with static html pages. This was not clear to me and I am sure others will run into same issues as well. I don’t think I would want to enable this test environment for now. P.S I also found out the deploy list-modules output has been changed after I checked the two checkboxes: deploy.bat list-modulesFound 39 modules + default/eclipse-config-store/1.0/car on geronimo/j2ee-system/1.1/car?ServiceModule=geronimo/j2ee-system/1.1/car,j2eeType=ConfigurationStore,name=Local + geronimo/activemq/1.1/car on geronimo/j2ee-system/1.1/car?ServiceModule=geronimo/j2ee-system/1.1/car,j2eeType=ConfigurationStore,name=Local + geronimo/activemq-broker/1.1/car on geronimo/j2ee-system/1.1/car?ServiceModule=geronimo/j2ee-system/1.1/car,j2eeType=ConfigurationStore,name=Local… Thanks, Lin -Original Message-From: Sachin Patel [mailto:[EMAIL PROTECTED]] On Behalf Of Sachin PatelSent: Tuesday, July 11, 2006 8:32 AMTo: dev@geronimo.apache.orgSubject: Re: [Vote] Geronimo Eclipse Plugin v1.1.0 As I mentioned earlier the test environment mode is not feature complete and it only works in the one scenario I mentioned. On Jul 10, 2006, at 11:28 PM, Lin Sun wrote:I started to have problems in deploying my second application which I had itrunning with v1.0's plugin. It is a simple ClassViewer application thathas a jsp and a servlet. The jsp calls the servlet when user clicks on thesubmit button to get the class description. Upon deployment of the application, I got the following CNP exception whenthe two checkboxes (Enable in-place deployment Run standalone modulesdirectly from workspace) are checked: Caused by: java.lang.ClassNotFoundException: samples.cviewer.ClassViewerServlet inclassloader samples/cviewer/1.1/war at java.lang.Throwable.init(Throwable.java:57) at java.lang.Throwable.init(Throwable.java:81) atjava.lang.ClassNotFoundException.init(ClassNotFoundException.java:80) atorg.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:249) at java.lang.ClassLoader.loadClass(ClassLoader.java:561) atorg.apache.geronimo.tomcat.GeronimoStandardContext.addChild(GeronimoStandardContext.java:234) ... 84 more I have gotten this error before(https://bugs.eclipse.org/bugs/show_bug.cgi?id=123803) in v1.0 but I don'tthink this is the same prob as I had before this time. I noticed that in my project's .classpath file, I have: classpathentry path="build/classes" kind="output"/ However, I don't have the servlet class in that directory. I tried toupdate it to the path where the servlet class is located (ImportedClasses/samples/cviewer) but still the same error. I'll look into more of this but I thought I'd let everyone know since it isvoting time of the plugin. P.S. Later on I discovered that the sample works fine when I don't have thetwo checkboxes checked. I can see the servlet and jsp in the goodstructure in the repo. Lin -Original Message-From: Sachin Patel [mailto:[EMAIL PROTECTED]] On Behalf Of Sachin PatelSent: Sunday, July 09, 2006 4:25 PMTo: dev@geronimo.apache.orgSubject: [Vote] Geronimo Eclipse Plugin v1.1.0 The following distributions of the Geronimo Eclipse plugin are ready to be voted on for final release. Since binding votes are needed, each PMC member if possible, please cast your vote within 72 hours. http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse- plugin-1.1-deployable-RC4.ziphttp://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse- plugin-1.1-updatesite-RC4.zip Here is my +1. - sachin -sachin -sachin
RE: [Vote] Geronimo Eclipse Plugin v1.1.0
I just checked the g-eclipse-plugin-1.1-updatesite-RC5.zip file and only see Apache License there (not the full Apache 2.0 license) in all 3 features. It might be important to correct the license in these features as installing via update manager is the recommended method to install the Eclipse plugin. In Eclipse, user will have to accept the licenses in install panel before the Eclipse continues the installation. Lin -Original Message- From: Sachin Patel [mailto:[EMAIL PROTECTED] On Behalf Of Sachin Patel Sent: Tuesday, July 11, 2006 12:58 PM To: dev@geronimo.apache.org Subject: Re: [Vote] Geronimo Eclipse Plugin v1.1.0 Ok one last time hopefully... http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-deployable-RC7.zip On Jul 11, 2006, at 10:03 AM, Sachin Patel wrote: [EMAIL PROTECTED] ok ignore rc6 On Jul 11, 2006, at 9:59 AM, Kevan Miller wrote: On Jul 11, 2006, at 8:41 AM, Sachin Patel wrote: On Jul 10, 2006, at 11:29 PM, Kevan Miller wrote: Sachin, At a minimum, you need to add: OpenEJB, MX4J, and XStream to the root LICENSE file Which root license file I you referring to? Do I just append each license to this? By root, I meant the notice and license files in g-eclipse-plugin-1-1/META-INF/. I actually don't think that they should be in the META-INF dir. I think you should end up with the following when you unzip: geronimo-eclipse-plugin-1-1/LICENSE geronimo-eclipse-plugin-1-1/NOTICE (both license and notice should either be .txt or have no suffix) geronimo-eclipse-plugin-1-1/plugins/... geronimo-eclipse-plugin-1-1/features/... The additional license and notice information should be appended to the ASL license and notice info. see geronimo/branches/modules/scripts/src/resources/LICENSE.txt and NOTICE.txt (you can just steal the appropriate sections from these files). Looks like some of the jar files are still missing LICENSE and NOTICE files.org.apache.geronimo.v11.deployment.model.edit_1.0.0.jar, for instance. --kevan MX4J, and XMLBeans to the root NOTICE file Again which root? Did you investigate Hessian licensing? Yeah its under Apache 1.0 I think, but could not find a copy of it on their site. I didn't find any licensing info (at first). So, took a look at the source. The first source file I looked at contained the following: /* * Copyright (c) 1998-2004 Caucho Technology -- all rights reserved * * This file is part of Resin(R) Open Source * * Each copy or derived work must preserve the copyright notice and this * notice unmodified. * * Resin Open Source is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * Resin Open Source is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE, or any warranty * of NON-INFRINGEMENT. See the GNU General Public License for more * details. * * You should have received a copy of the GNU General Public License * along with Resin Open Source; if not, write to the * Free SoftwareFoundation, Inc. * 59 Temple Place, Suite 330 * Boston, MA 02111-1307 USA * * @author Scott Ferguson */ I now see the following statement on their wiki: Caucho Technology has released this Hessian implementation under an open source license (the Apache license). Anyone may freely download, use, and redistribute the Hessian implementation. But that's the strongest source of licensing info, that I've found... --kevan On Jul 10, 2006, at 10:42 PM, Sachin Patel wrote: Fixed. Re-vote. http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-deployable-RC5.zip http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-updatesite-RC5.zip (still uploading available shortly) On Jul 10, 2006, at 8:21 PM, Kevan Miller wrote: Sachin, I'm afraid I don't see either a NOTICE or LICENSE files in the plugin zip file, itself, nor any of the embedded jar files. They all must contain both LICENSE and NOTICE files. Afraid this is a hard requirement. And you'll need to create new binaries... See http://www.apache.org/dev/release.html#what-must-every-release-contain for more information. We should be able to reuse some of the license information we generated for G 1.1. I'm happy to help with that. I'm not sure how we're putting the NOTICE and LICENSE info
Re: war manifest classpath in ear (GERONIMO-2125)
You're right. Here are some snippits from the j2ee 1.4 spec: A JAR format file (such as a.jar file,.war file, or.rar file) can reference a .jar file by naming the referenced.jar file in aClass- Path header in the referencing JAR file’s Manifest file. The referenced.jar file is named using a URL relative to the URL of the referencing JAR file. The deployment tool must install the.jar files in a way that preserves the relative references between the files. Typically this is done by installing the.jar files into a directory hierarchy that matches the original application directory hierarchy. All referenced .jar files must appear in the logical class path of the referencing JAR files at runtime. Only JAR format files containing class files or resources to be loaded directly by a standardClassLoader should be the target of aClass-Path reference; such files are always named with a.jar extension. Top level JAR files that are processed by a deployment tool should not containClass-Path entries; such entries would, by definition, reference other files external to the deployment unit. A deployment tool is not required to process such external references. Given the above text the I would categorize this bug as a blocker for 1.1.1. -dain On Jul 11, 2006, at 10:20 AM, Mario Ruebsam wrote: I'm not sure but I think the Class-Path entry in war files is covered by the spec because EAR, WAR and RAR are JAR files. J2EE 1.4 excluded EAR files from that. EAR manifest files should not contain a Class-Path entry. packaging description from sun: http://java.sun.com/j2ee/verified/packaging.html Also the class path entry is relative to the war file not the WEB- INF/classes or WEB-INF/lib in the war file. Thanks, Mario Dain Sundstrom wrote: On Jul 11, 2006, at 8:30 AM, David Jencks wrote: On Jul 11, 2006, at 8:03 AM, Aaron Mulder wrote: What if the WAR is in a subdir within the EAR like foo/bar/ some.war? Then .. alone won't work to resolve paths relative to the EAR. Yes, whatever relative path we might generate certainly would have to take account of the position of the war inside the ear. IIRC, the manifest class path is relative to the archive itself. In this case it is relative to the some.war, so if you want something in the foo dir, the manifest class path entry would have to be ../../jar.jar Also, I think all of this is out side of the spec. IIRC the spec only talks about manifest class path entries of jar files, and since a war is not a jar file it isn't covered by the spec. Regardless, I think it is a good idea to support this, but I want to clarify that I don't believe this is a certification issue. I would think from a WAR-in-EAR, we could identify the Module ID of the EAR, and then use the repo to construct a path to the JAR-in- EAR with the EAR module ID and the JAR path. Is there a reason why that wouldn't work? IIUC you are suggesting that the war configuration/module keep track of two parts of its classpath: one inside itself, for WEB- INF/lib and WEB-INF/classes, and one inside the enclosing ear, for the manifest classpath. This certainly seems possible to me but I wonder what advantage it would have over only tracking stuff in one place. So, now I see even more possibilities: 1. copy the manifest cp entries from the ear into the war. This would keep the war self contained, but otherwise seems like a lot of extra work for nothing. 2. keep track of the stuff inside the war and inside the ear separately (your proposal IIUC) 3. keep track of the war classpath based on the war location inside the ear, so manifest classpath entries get a ../ prepended to them (if the war was in a subdirectory in the ear, manifest cp entries would most likely already have one or more ../ since entries are relative to the war location). 4. keep track of the entire war classpath based on the ear location, so the stuff in WEB-INF/[lib,classes] would have the war location inside the ear prepended. I'm tempted by (4).To me it says, here's the ear with a lot of stuff inside, and you can define classloaders that access an arbitrary subset of the stuff inside. I think this is the most compatible with the idea that's been floating around for a while of keeping the configuration separate from the j2ee artifact that is is based on: i.e. copy (possibly with unpacking) the j2ee artifact into the repo, and not into the car file: the car file just gets pointers into the j2ee artifact to define its classloader. Um I didn't really understand all the options, but I would like to suggest that the class path contain patterns (the code is already in place for this) and we resolve these patterns against the root dir of the war. For manifest class path entries, we would just need to prepend each entry with ../ to get outside the war dir and prepend them to the class path with the manifest entries.
Re: war manifest classpath in ear (GERONIMO-2125)
On 7/11/06, Dain Sundstrom [EMAIL PROTECTED] wrote: You're right. Here are some snippits from the j2ee 1.4 spec: ... Wow, I had thought that was all optional. Guess not! Given the above text the I would categorize this bug as a blocker for 1.1.1. I agree. Thanks, Aaron On Jul 11, 2006, at 10:20 AM, Mario Ruebsam wrote: I'm not sure but I think the Class-Path entry in war files is covered by the spec because EAR, WAR and RAR are JAR files. J2EE 1.4 excluded EAR files from that. EAR manifest files should not contain a Class-Path entry. packaging description from sun: http://java.sun.com/j2ee/verified/packaging.html Also the class path entry is relative to the war file not the WEB- INF/classes or WEB-INF/lib in the war file. Thanks, Mario Dain Sundstrom wrote: On Jul 11, 2006, at 8:30 AM, David Jencks wrote: On Jul 11, 2006, at 8:03 AM, Aaron Mulder wrote: What if the WAR is in a subdir within the EAR like foo/bar/ some.war? Then .. alone won't work to resolve paths relative to the EAR. Yes, whatever relative path we might generate certainly would have to take account of the position of the war inside the ear. IIRC, the manifest class path is relative to the archive itself. In this case it is relative to the some.war, so if you want something in the foo dir, the manifest class path entry would have to be ../../jar.jar Also, I think all of this is out side of the spec. IIRC the spec only talks about manifest class path entries of jar files, and since a war is not a jar file it isn't covered by the spec. Regardless, I think it is a good idea to support this, but I want to clarify that I don't believe this is a certification issue. I would think from a WAR-in-EAR, we could identify the Module ID of the EAR, and then use the repo to construct a path to the JAR-in- EAR with the EAR module ID and the JAR path. Is there a reason why that wouldn't work? IIUC you are suggesting that the war configuration/module keep track of two parts of its classpath: one inside itself, for WEB- INF/lib and WEB-INF/classes, and one inside the enclosing ear, for the manifest classpath. This certainly seems possible to me but I wonder what advantage it would have over only tracking stuff in one place. So, now I see even more possibilities: 1. copy the manifest cp entries from the ear into the war. This would keep the war self contained, but otherwise seems like a lot of extra work for nothing. 2. keep track of the stuff inside the war and inside the ear separately (your proposal IIUC) 3. keep track of the war classpath based on the war location inside the ear, so manifest classpath entries get a ../ prepended to them (if the war was in a subdirectory in the ear, manifest cp entries would most likely already have one or more ../ since entries are relative to the war location). 4. keep track of the entire war classpath based on the ear location, so the stuff in WEB-INF/[lib,classes] would have the war location inside the ear prepended. I'm tempted by (4).To me it says, here's the ear with a lot of stuff inside, and you can define classloaders that access an arbitrary subset of the stuff inside. I think this is the most compatible with the idea that's been floating around for a while of keeping the configuration separate from the j2ee artifact that is is based on: i.e. copy (possibly with unpacking) the j2ee artifact into the repo, and not into the car file: the car file just gets pointers into the j2ee artifact to define its classloader. Um I didn't really understand all the options, but I would like to suggest that the class path contain patterns (the code is already in place for this) and we resolve these patterns against the root dir of the war. For manifest class path entries, we would just need to prepend each entry with ../ to get outside the war dir and prepend them to the class path with the manifest entries. For example, the example aaron used above would result in the following: War base dir: foo/bar/web.war/ War class path: ../../../jar.jar lib/classes lib/*.jar lib/*.zip Final class path: foo/jar.jar foo/bar/web.war/lib/classes foo/bar/web.war/lib/lib.jar foo/bar/web.war/lib/lib.zip -dain
[jira] Commented: (GERONIMO-2167) deployer.jar not cleaning up properly during redeploy and undeploy
[
http://issues.apache.org/jira/browse/GERONIMO-2167?page=comments#action_12420391
]
Kevan Miller commented on GERONIMO-2167:
OK. It does look like a Windows file locking problem. Furthermore, it's only
happening on Tomcat, not Jetty (at least in this usage scenario).
The file that's not being cleaned up is
repository/littleoldme/dwrdemo/1.1/dwrdemo-1.1.war/WEB-INF/classes/db.sql
deployer.jar not cleaning up properly during redeploy and undeploy
--
Key: GERONIMO-2167
URL: http://issues.apache.org/jira/browse/GERONIMO-2167
Project: Geronimo
Type: Bug
Security: public(Regular issues)
Components: deployment
Versions: 1.1
Environment: Win32/XP SP1
Sun JDK 1.5_06
Reporter: Leonard Wu
Assignee: Kevan Miller
Fix For: 1.1.1
Attachments: dwr-demo.war
deployment using deploy.jar doesn't appear to clean up correctly.
first deploy always works. subsequent re-deploy and un-deploy are problematic.
following illustrates the full sequence of events as i had encountered:
--
D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar
deployer.ja
r --user system --password manager deploy D:/work/SERVER/dwr-demo.war
Deployed littleoldme/dwrdemo/1.1/war @ http://vaio:8080/dwr-demo
D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar
deployer.ja
r --user system --password manager redeploy D:/work/SERVER/dwr-demo.war
No ModuleID or TargetModuleID provided. Attempting to guess based
on the content of the archive.
Attempting to use ModuleID 'littleoldme/dwrdemo/1.1/war'
Stopped littleoldme/dwrdemo/1.1/war
Unloaded littleoldme/dwrdemo/1.1/war
Uninstalled littleoldme/dwrdemo/1.1/war
Deployed littleoldme/dwrdemo/1.1/war
Started littleoldme/dwrdemo/1.1/war
Redeployed littleoldme/dwrdemo/1.1/war
D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar
deployer.ja
r --user system --password manager redeploy D:/work/SERVER/dwr-demo.war
No ModuleID or TargetModuleID provided. Attempting to guess based
on the content of the archive.
Attempting to use ModuleID 'littleoldme/dwrdemo/1.1/war'
Stopped littleoldme/dwrdemo/1.1/war
Unloaded littleoldme/dwrdemo/1.1/war
Uninstalled littleoldme/dwrdemo/1.1/war
Error: Operation failed:
org.apache.geronimo.kernel.config.ConfigurationAlreadyExistsException:
Configuration already exists: littleoldme/dwrdemo/1.1/war
Configuration already exists: littleoldme/dwrdemo/1.1/war
D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar
deployer.ja
r --user system --password manager undeploy littleoldme/dwrdemo/1.1/war
Error: littleoldme/dwrdemo/1.1/war does not appear to be a the name
of a module available on the selected server. Perhaps it has already
been stopped or undeployed? If you're trying to specify a
TargetModuleID, use the syntax TargetName|ModuleName instead. If
you're not sure what's running, try the list-modules command.
--
While in this broken state, i'm able to recover by manually removing the
${geronimo}/repository/littleoldme directory and removing the one line in
${geronimo}/var/config/config.xml that says
module load=false name=littleoldme/dwrdemo/1.1/war/
However, this only gets me to a fresh beginning, and then the whole sequence
starts again as I repeat (re/un)deploying.
--
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
openejb-jar.xml
I would like to know which is the correct usage of openejb-jar.xml, since my deployment fails because of inconsistent parentIds and configIds that i dont know how to fix or even if they have to be in the file. Any help, as alwayas will be very appreciated Thanks in advance Rafael
Re: PackageBuilderShellMojo (m2) and classloaders
Thanks for following up on this. Would have been nice if there were comments in the codebase to this effect. Was there any reason why the setters were all invoked through reflection as well? --jason On Jul 11, 2006, at 8:43 AM, David Jencks wrote: Jason Dillon asked last night on IRC why the PackgeBuilderShellMojo for the m2 packaging plugin used reflection to create the PackageBuilder. We need to control the classloader for PackageBuilder pretty closely so it has the same classpath as j2ee- system. In maven 1, IIUC, plugins get instantiated using a child classloader of the project calling the plugin: this classloader typically has a more or less random selection of large numbers of geronimo jars in it, far more than j2ee-system, and in particular including all the classes for the dependencies of the module/ configuration you are trying to build. The only solution I could see for m1 was to construct a classloader myself and load PackageBuilder in my own classloader and access the instance by reflection. I believe the situation is better in m2 and that the plugin is instantiated using a classloader determined solely by the plugin's pom. If so, we should be safe in eliminating this extra reflection code and in fact using PackageBuilder directly without the shell. If not, we should keep using the inconvenient reflection code. thanks david jencks
Re: Geronimo 1.1 JARs in Maven 2 Repo
I'd recommend that projects using m2 wait for G 1.2, which will hopefully be sooner rather than later. I don't think it is a good idea for m1 projects to publish to m2 repositories (unless the Maven team comes up with a supported plugin to do so). If a project is using m2 and can't wait for G 1.2, then it should setup a legacy repo and use the m1 artifacts. --jason On Jul 11, 2006, at 7:59 AM, Aaron Mulder wrote: On 7/10/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: I think that it's better to have different group ids for the M1 and M2 jars since their contents, maven wise, are quite different. IIUC, we really shouldn't be putting M1 jars into an M2 repo. So are you taking the position that we should not support Maven 2 builds with dependencies on Geronimo 1.1, or that we should support Maven 2 builds with dependencies on 1.1 but only if they use the Maven 1 Group ID for Geronimo and then change the Group ID when they update to Geronimo 1.2? My position is that if someone is using Maven 2 with dependencies on Geronimo, they should use the Maven 2 Group ID for Geronimo, regardless of which version of Geronimo they're depending on. Or, perhaps you're saying that we should keep the JARs in a Maven 1 repo but put them in there twice, in one place for the Maven 1 Group ID (for Maven 1 clients) and in a different place for the Maven 2 Group ID for Maven 2 clients (who need to point their build to a Maven 1 repo but from what you've said that will work)? Thanks, Aaron
[jira] Updated: (AMQ-361) duplicate delivery, already consumed messages are reconsumed after server restart
[ https://issues.apache.org/activemq/browse/AMQ-361?page=all ] Hiram Chirino updated AMQ-361: -- Fix Version: 4.1 (was: 4.0.1) Version: 4.0 (was: 3.1) Could you please provide a test case that shows this in action? duplicate delivery, already consumed messages are reconsumed after server restart - Key: AMQ-361 URL: https://issues.apache.org/activemq/browse/AMQ-361 Project: ActiveMQ Type: Bug Components: Broker, Message Store, JCA Container Versions: 4.0 Environment: windows xp, jdk 1.5, embedded activemq 3.1 broker, jboss 4.02, persistent messages with derby db. Reporter: Gokturk Ozer Fix For: 4.1 Attachments: 1.log I am running an embedded activemq broker inside jboss server, I send 1000 messages with ~10K size each to a queue, these messages are consumed by MDBs. After all the messages are consumed, I check the queue via hermes, it also shows no message in the queue. Everything works perfect up to this point. I observe the problem after I stop the jboss server. I connect to derby database via networkserver, I still see some messages in activemq_msgs table. I shutdown derby networkserver and start jboss again, I see from the log that some of the messages which were consumed previously, are being consumed again. If I start the server without deploying the MDB and check the queue via hermes, I see some but not all the messages which were consumed previously still in the queue, before restart hermes was showing no messages. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Geronimo 1.1 JARs in Maven 2 Repo
On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote: I'd recommend that projects using m2 wait for G 1.2, which will hopefully be sooner rather than later. Too late. For example, the Quartz plugin (already available on the plugin repo) uses G 1.1 and Maven 2. I've been copying JARs around by hand, which is annoying, and why I want to solve this. There are more people getting involved in developing plugins, and it's hard to recommend Maven 1 and hard to recommend file copying (and *extra* hard to recommend waiting for Geronimo 1.2, given the current velocity). If a project is using m2 and can't wait for G 1.2, then it should setup a legacy repo and use the m1 artifacts. OK, that's fine, but should it use the groupId geronimo or org.apache.geronimo.modules when referring to, e.g., geronimo-kernel? Thanks, Aaron On Jul 11, 2006, at 7:59 AM, Aaron Mulder wrote: On 7/10/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: I think that it's better to have different group ids for the M1 and M2 jars since their contents, maven wise, are quite different. IIUC, we really shouldn't be putting M1 jars into an M2 repo. So are you taking the position that we should not support Maven 2 builds with dependencies on Geronimo 1.1, or that we should support Maven 2 builds with dependencies on 1.1 but only if they use the Maven 1 Group ID for Geronimo and then change the Group ID when they update to Geronimo 1.2? My position is that if someone is using Maven 2 with dependencies on Geronimo, they should use the Maven 2 Group ID for Geronimo, regardless of which version of Geronimo they're depending on. Or, perhaps you're saying that we should keep the JARs in a Maven 1 repo but put them in there twice, in one place for the Maven 1 Group ID (for Maven 1 clients) and in a different place for the Maven 2 Group ID for Maven 2 clients (who need to point their build to a Maven 1 repo but from what you've said that will work)? Thanks, Aaron
[jira] Assigned: (AMQ-480) add consume ability to openwire-c
[ https://issues.apache.org/activemq/browse/AMQ-480?page=all ] Hiram Chirino reassigned AMQ-480: - Assign To: (was: Hiram Chirino) Will revisit this later as time allows. add consume ability to openwire-c - Key: AMQ-480 URL: https://issues.apache.org/activemq/browse/AMQ-480 Project: ActiveMQ Type: Improvement Reporter: james strachan Fix For: 4.3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [M2 build] : Error building application uddi-db on XP
There u go..
Cheers
Prasad
On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote:
Can you send the output of the build plz.
--jason
On Jul 11, 2006, at 7:15 AM, Prasad Kashyap wrote:
Nope. No such luck. I deleted the entire applications dir. I also
deleted the o.a.g.applications group from the local repo. I then did
an 'svn update' from top level geronimo dir. I rebuilt the bootstrap
stage and then the assembly stage. Same problem.
Cheers
Prasad
On 7/10/06, Jason Dillon [EMAIL PROTECTED] wrote:
The uddi-db module should be buildable now since #420661
Give it a whirl and let me know if you run into anything else.
--jason
On Jul 10, 2006, at 4:28 PM, Jason Dillon wrote:
It appears that the uddi-db module should *NOT* have any webapp
stuff, but only the derby database files.
So, unless someone can shed some light onto why the db module has
webapp files in it, I'm going to remove them.
--jason
On Jul 10, 2006, at 4:15 PM, Jason Dillon wrote:
Why are the uddi-* webapp files duplicated in the -server and -db
modules?
snip
uddi-db/src
uddi-db/src/sql
uddi-db/src/sql/juddi.sql
uddi-db/src/webapp
uddi-db/src/webapp/happyjuddi.jsp
uddi-db/src/webapp/WEB-INF
uddi-db/src/webapp/WEB-INF/juddi.properties
uddi-db/src/webapp/WEB-INF/web.xml
uddi-server/src
uddi-server/src/webapp
uddi-server/src/webapp/happyjuddi.jsp
uddi-server/src/webapp/WEB-INF
uddi-server/src/webapp/WEB-INF/juddi.properties
uddi-server/src/webapp/WEB-INF/web.xml
/snip
--jason
On Jul 10, 2006, at 5:12 AM, Prasad Kashyap wrote:
Seeing this error on Windows XP only. Unable to recreate it on
Linux.
I am trying to build the trunk using m2. I began with a clean
repo and
did a fresh checkout.
I executed build.bat and it ran the bootstrap stage. Then I
executed
build.bat -Dstage=assembly -Dmaven.test.skip=true.
It failed while trying to build applications/uddi-db with the
following error
---
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[delete] Deleting directory
C:\Apache\geronimo\trunk\applications\uddi-db\target\resources
\META-INF\geronimo-uddi-db\var\derby
[mkdir] Created dir:
C:\Apache\geronimo\trunk\applications\uddi-db\target\resources
\META-INF\geronimo-uddi-db\var\derby
[sql] Executing file:
C:\Apache\geronimo\trunk\applications\uddi-db\src\sql\juddi.sql
[sql] 87 of 87 SQL statements executed successfully
[INFO] Executed tasks
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [jspc:compile {execution: jspc}]
[INFO] Built File: \happyjuddi.jsp
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[delete] Deleting directory
C:\Apache\geronimo\trunk\applications\uddi-db\taget\resources
\META-INF\geronimo-uddi-db\var\derby
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error executing ant tasks
Embedded error: Unable to delete file
C:\Apache\geronimo\trunk\applications\uddi-db\target\resources
\META-INF\geronimo-uddi-db\var\derby\UddiDatabase\db.lck
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 minute 36 seconds
[INFO] Finished at: Mon Jul 10 07:47:20 EDT 2006
[INFO] Final Memory: 28M/51M
-
It is trying to execute the antrun plugin in the
applications/uddi-db/pom.xml a second time when the error occurs.
Cheers
Prasad
mvn.log
Description: Binary data
Re: Geronimo 1.1 JARs in Maven 2 Repo
On Jul 11, 2006, at 12:29 PM, Aaron Mulder wrote: On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote: I'd recommend that projects using m2 wait for G 1.2, which will hopefully be sooner rather than later. Too late. For example, the Quartz plugin (already available on the plugin repo) uses G 1.1 and Maven 2. I've been copying JARs around by hand, which is annoying, and why I want to solve this. There are more people getting involved in developing plugins, and it's hard to recommend Maven 1 and hard to recommend file copying (and *extra* hard to recommend waiting for Geronimo 1.2, given the current velocity). If a project is using m2 and can't wait for G 1.2, then it should setup a legacy repo and use the m1 artifacts. OK, that's fine, but should it use the groupId geronimo or org.apache.geronimo.modules when referring to, e.g., geronimo-kernel? I think it should use geronimo I think otherwise we will get into trouble later on when transitive dependencies become available. If we clearly distinguish real m2 jars from m1 built jars accessed through m2 I think we will have fewer upgrade problems. david jencks Thanks, Aaron On Jul 11, 2006, at 7:59 AM, Aaron Mulder wrote: On 7/10/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: I think that it's better to have different group ids for the M1 and M2 jars since their contents, maven wise, are quite different. IIUC, we really shouldn't be putting M1 jars into an M2 repo. So are you taking the position that we should not support Maven 2 builds with dependencies on Geronimo 1.1, or that we should support Maven 2 builds with dependencies on 1.1 but only if they use the Maven 1 Group ID for Geronimo and then change the Group ID when they update to Geronimo 1.2? My position is that if someone is using Maven 2 with dependencies on Geronimo, they should use the Maven 2 Group ID for Geronimo, regardless of which version of Geronimo they're depending on. Or, perhaps you're saying that we should keep the JARs in a Maven 1 repo but put them in there twice, in one place for the Maven 1 Group ID (for Maven 1 clients) and in a different place for the Maven 2 Group ID for Maven 2 clients (who need to point their build to a Maven 1 repo but from what you've said that will work)? Thanks, Aaron
Re: Geronimo 1.1 JARs in Maven 2 Repo
On 7/11/06, David Jencks [EMAIL PROTECTED] wrote: I think it should use geronimo I think otherwise we will get into trouble later on when transitive dependencies become available. If we clearly distinguish real m2 jars from m1 built jars accessed through m2 I think we will have fewer upgrade problems. I'm OK with this if that's what most people prefer, but I hope everyone on the thread will chip in with their preferred group ID. However, I don't see what the problem is that you're referring to. Let's say you have a project using M1-built Geronimo 1.1 JARs, and you later change your project to use the M1-built Geronimo 1.1.1 JARs and then still later the M2-built Geronimo 1.2 JARs. On that last step, your build will bring down POMs and some transitive dependencies in addition to the JARs explicitly listed. What's the problem and where does it happen? Thanks, Aaron On Jul 11, 2006, at 7:59 AM, Aaron Mulder wrote: On 7/10/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: I think that it's better to have different group ids for the M1 and M2 jars since their contents, maven wise, are quite different. IIUC, we really shouldn't be putting M1 jars into an M2 repo. So are you taking the position that we should not support Maven 2 builds with dependencies on Geronimo 1.1, or that we should support Maven 2 builds with dependencies on 1.1 but only if they use the Maven 1 Group ID for Geronimo and then change the Group ID when they update to Geronimo 1.2? My position is that if someone is using Maven 2 with dependencies on Geronimo, they should use the Maven 2 Group ID for Geronimo, regardless of which version of Geronimo they're depending on. Or, perhaps you're saying that we should keep the JARs in a Maven 1 repo but put them in there twice, in one place for the Maven 1 Group ID (for Maven 1 clients) and in a different place for the Maven 2 Group ID for Maven 2 clients (who need to point their build to a Maven 1 repo but from what you've said that will work)? Thanks, Aaron
Re: Geronimo, Genesis and OpenEJB2... oh my
On Jul 11, 2006, at 4:48 AM, Prasad Kashyap wrote:
That's cool, dude. Now can we please have some intro to Genesis. I
saw a fleeting mention of it in another mail thread.
Sure, its about time... now that its working.
Genesis is a simple project that contains modules that help in the
creation of other projects. It is nothing fancy, just a collection
of modules to provide shared/common configuration and a place to put
G-related plugins.
Currently there are 2 trees: config and plugins
The config tree contains modules which provide the shared/common
configuration, and plugins provide support modules (like plugin-
support) and custom plugins (currently there are none, but I may have
to make a sql plugin to fix the uddi-db problems on windows, etc, and
that would go here).
NOTE: Genesis must be bootstrapped until Maven fixes the issue with
extension plugins built in the same build cycle.
* * *
So what do we have so far:
config/checkstyle-config
This module contains the Checkstyle configuration, taken from etc/
geronimo_checks.xml. It is installed as a build extension, so that
its contents are available to be loaded as resources. This allows
the Checkstyle plugin to be configure with just this (no need to
use ../../ which won't work when building with Continuum, or to
duplicate the config in each module):
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-checkstyle-plugin/artifactId
version2.1/version
configuration
!-- Pulled as resource from checkstyle-config plugin --
configLocationorg/apache/geronimo/checkstyle.xml/
configLocation
/configuration
/plugin
While it is possible to use a URL for this configuration, to keep the
build in sync with the SVN repo I do not recommend using remote
resources whenever possible.
config/clover-config
This provides the clover.license so that Clover can be used. It is
also installed as a build extension, and picked up in the same way
that checkstyle.xml is.
The license that is here is what Cenqua gave me for development on
Apache Geronimo.
config/logging-config
This provides the common log4j.properties used by all modules when
running tests. This is a normal dependency, included in the test
scope.
The key thing that this provides is that all tests will create a $
{basedir}/target/test.log file that has the full logging detail for
surefire tests.
IMO tests by default should produce no output so that it is easy for
folks to see what is passing and what is failing on the build
console. For failure details, the log file + surefire reports can be
used.
We can also add a few properties to control the default level that
goes to console for easy development, but I have yet to implement that.
There is no need to add per-module log4j.properties configuration
files anymore.
config/project-config
This module contains the common m2 build configuration that most
every G-related project needs to produce builds, generate sites, run
tests, etc.
This is the _parent_ of each projects _root_ pom.
Have a look yourself, but it basically sets up the default mailing
lists, issue tracking, etc.
Here you will find where the other config modules are included into
the build.
Also, this is where plugin versions are controlled, so that we don't
run into problems in the future when plugin vendors release new
versions that are incompatible with the build configuration that is
checked in to SVN. This is key to support building projects that are
pulled from older branches.
plugins/plugin-support
This is a jar module, that contains common code that our plugins
use. Right now that is simply MojoSupport, which handles setting up
logging and provides exception handling at the root so that
extensions do not need to worry about that.
As we add more plugins expect more commonly used code to move here.
* * *
The idea is to keep all of the common bits in one place, so that we
can easily reuse that configuration across projects.
I've setup the svkmerge/m2migration branch to use this project's
modules to simplify the required build configuration.
Right now, since its just coming together we are using genesis 1.0.0-
SNAPSHOT versions, but once the configuration is solid, then we will
make a release of Genesis and then update projects to just use the
1.0.0 version. After that, we only need to change the versions when
the common configuration is changed.
The changes should be infrequent, but will happen from time to time.
In general the time required to maintain projects in this fashion is
much less than the alternative of not sharing. This means that it
will be much easier to keep all projects in sync with the latest
build configuration.
* * *
I hope that helps explain what Genesis is... and more so what the
direction that I'm setting is for maintainable project
Re: PackageBuilderShellMojo (m2) and classloaders
Was there any reason why the setters were all invoked through reflection as well? well, in the m1 plugin the class of the PackageBuilder instance is in a different classloader than the PackageBuilderShell, so I don't see how there is any other way to call the setters. Am I missing something? If we said PackageBuilder pb = (PackageBuilder) packageBuilderInstance we'd get a class cast exception. I think what you've done for m2 should work: if we start getting bizarre class cast exceptions when trying to build configs we'll have to revisit this question. Note that the m2 plugin had already switched to using the same classloader for PBSM and PB, so the reflective setter calls were pointless. Okay, I added a comment to the changes I made (which removed the reflection) to note that if we run into crazy errors that we should re-implement the classloader isolation. --jason
Re: [M2 build] : Error building application uddi-db on XP
From your local workspace path, it looks like you are building from
trunk, which I have not touched.
Also this line is telling:
[INFO] [antrun:run {execution: default}]
I changed the id of the antrun execution to setup-db, so it appears
you are not using the code-line that I fixed ;-)
Please use this SVN URL:
https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/
m2migration/
--jason
On Jul 11, 2006, at 12:31 PM, Prasad Kashyap wrote:
There u go..
Cheers
Prasad
On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote:
Can you send the output of the build plz.
--jason
On Jul 11, 2006, at 7:15 AM, Prasad Kashyap wrote:
Nope. No such luck. I deleted the entire applications dir. I also
deleted the o.a.g.applications group from the local repo. I then
did
an 'svn update' from top level geronimo dir. I rebuilt the
bootstrap
stage and then the assembly stage. Same problem.
Cheers
Prasad
On 7/10/06, Jason Dillon [EMAIL PROTECTED] wrote:
The uddi-db module should be buildable now since #420661
Give it a whirl and let me know if you run into anything else.
--jason
On Jul 10, 2006, at 4:28 PM, Jason Dillon wrote:
It appears that the uddi-db module should *NOT* have any webapp
stuff, but only the derby database files.
So, unless someone can shed some light onto why the db module
has
webapp files in it, I'm going to remove them.
--jason
On Jul 10, 2006, at 4:15 PM, Jason Dillon wrote:
Why are the uddi-* webapp files duplicated in the -server
and -db
modules?
snip
uddi-db/src
uddi-db/src/sql
uddi-db/src/sql/juddi.sql
uddi-db/src/webapp
uddi-db/src/webapp/happyjuddi.jsp
uddi-db/src/webapp/WEB-INF
uddi-db/src/webapp/WEB-INF/juddi.properties
uddi-db/src/webapp/WEB-INF/web.xml
uddi-server/src
uddi-server/src/webapp
uddi-server/src/webapp/happyjuddi.jsp
uddi-server/src/webapp/WEB-INF
uddi-server/src/webapp/WEB-INF/juddi.properties
uddi-server/src/webapp/WEB-INF/web.xml
/snip
--jason
On Jul 10, 2006, at 5:12 AM, Prasad Kashyap wrote:
Seeing this error on Windows XP only. Unable to recreate it on
Linux.
I am trying to build the trunk using m2. I began with a clean
repo and
did a fresh checkout.
I executed build.bat and it ran the bootstrap stage. Then I
executed
build.bat -Dstage=assembly -Dmaven.test.skip=true.
It failed while trying to build applications/uddi-db with the
following error
---
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[delete] Deleting directory
C:\Apache\geronimo\trunk\applications\uddi-db\target\resources
\META-INF\geronimo-uddi-db\var\derby
[mkdir] Created dir:
C:\Apache\geronimo\trunk\applications\uddi-db\target\resources
\META-INF\geronimo-uddi-db\var\derby
[sql] Executing file:
C:\Apache\geronimo\trunk\applications\uddi-db\src\sql
\juddi.sql
[sql] 87 of 87 SQL statements executed successfully
[INFO] Executed tasks
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [jspc:compile {execution: jspc}]
[INFO] Built File: \happyjuddi.jsp
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[delete] Deleting directory
C:\Apache\geronimo\trunk\applications\uddi-db\taget\resources
\META-INF\geronimo-uddi-db\var\derby
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error executing ant tasks
Embedded error: Unable to delete file
C:\Apache\geronimo\trunk\applications\uddi-db\target\resources
\META-INF\geronimo-uddi-db\var\derby\UddiDatabase\db.lck
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 minute 36 seconds
[INFO] Finished at: Mon Jul 10 07:47:20 EDT 2006
[INFO] Final Memory: 28M/51M
-
It is trying to execute the antrun plugin in the
applications/uddi-db/pom.xml a second time when the error
occurs.
Cheers
Prasad
mvn.log
Re: Geronimo 1.1 JARs in Maven 2 Repo
I agree it should use geronimo, since that is the groupId used for the bulk of the m1 build. IMO it would be very confusing to deploy these artifacts anywhere, or expect people to install them by hand with a different groupId. --jason On Jul 11, 2006, at 12:39 PM, David Jencks wrote: On Jul 11, 2006, at 12:29 PM, Aaron Mulder wrote: On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote: I'd recommend that projects using m2 wait for G 1.2, which will hopefully be sooner rather than later. Too late. For example, the Quartz plugin (already available on the plugin repo) uses G 1.1 and Maven 2. I've been copying JARs around by hand, which is annoying, and why I want to solve this. There are more people getting involved in developing plugins, and it's hard to recommend Maven 1 and hard to recommend file copying (and *extra* hard to recommend waiting for Geronimo 1.2, given the current velocity). If a project is using m2 and can't wait for G 1.2, then it should setup a legacy repo and use the m1 artifacts. OK, that's fine, but should it use the groupId geronimo or org.apache.geronimo.modules when referring to, e.g., geronimo-kernel? I think it should use geronimo I think otherwise we will get into trouble later on when transitive dependencies become available. If we clearly distinguish real m2 jars from m1 built jars accessed through m2 I think we will have fewer upgrade problems. david jencks Thanks, Aaron On Jul 11, 2006, at 7:59 AM, Aaron Mulder wrote: On 7/10/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: I think that it's better to have different group ids for the M1 and M2 jars since their contents, maven wise, are quite different. IIUC, we really shouldn't be putting M1 jars into an M2 repo. So are you taking the position that we should not support Maven 2 builds with dependencies on Geronimo 1.1, or that we should support Maven 2 builds with dependencies on 1.1 but only if they use the Maven 1 Group ID for Geronimo and then change the Group ID when they update to Geronimo 1.2? My position is that if someone is using Maven 2 with dependencies on Geronimo, they should use the Maven 2 Group ID for Geronimo, regardless of which version of Geronimo they're depending on. Or, perhaps you're saying that we should keep the JARs in a Maven 1 repo but put them in there twice, in one place for the Maven 1 Group ID (for Maven 1 clients) and in a different place for the Maven 2 Group ID for Maven 2 clients (who need to point their build to a Maven 1 repo but from what you've said that will work)? Thanks, Aaron
Re: Geronimo 1.1 JARs in Maven 2 Repo
On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote: I agree it should use geronimo, since that is the groupId used for the bulk of the m1 build. OK. IMO it would be very confusing to deploy these artifacts anywhere, or expect people to install them by hand with a different groupId. Copy bad, check. Never want to see them deployed anywhere, I'm confused -- they are deployed to http://www.ibiblio.org/maven/geronimo/jars/ already. Thanks, Aaron On Jul 11, 2006, at 12:39 PM, David Jencks wrote: On Jul 11, 2006, at 12:29 PM, Aaron Mulder wrote: On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote: I'd recommend that projects using m2 wait for G 1.2, which will hopefully be sooner rather than later. Too late. For example, the Quartz plugin (already available on the plugin repo) uses G 1.1 and Maven 2. I've been copying JARs around by hand, which is annoying, and why I want to solve this. There are more people getting involved in developing plugins, and it's hard to recommend Maven 1 and hard to recommend file copying (and *extra* hard to recommend waiting for Geronimo 1.2, given the current velocity). If a project is using m2 and can't wait for G 1.2, then it should setup a legacy repo and use the m1 artifacts. OK, that's fine, but should it use the groupId geronimo or org.apache.geronimo.modules when referring to, e.g., geronimo-kernel? I think it should use geronimo I think otherwise we will get into trouble later on when transitive dependencies become available. If we clearly distinguish real m2 jars from m1 built jars accessed through m2 I think we will have fewer upgrade problems. david jencks Thanks, Aaron On Jul 11, 2006, at 7:59 AM, Aaron Mulder wrote: On 7/10/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: I think that it's better to have different group ids for the M1 and M2 jars since their contents, maven wise, are quite different. IIUC, we really shouldn't be putting M1 jars into an M2 repo. So are you taking the position that we should not support Maven 2 builds with dependencies on Geronimo 1.1, or that we should support Maven 2 builds with dependencies on 1.1 but only if they use the Maven 1 Group ID for Geronimo and then change the Group ID when they update to Geronimo 1.2? My position is that if someone is using Maven 2 with dependencies on Geronimo, they should use the Maven 2 Group ID for Geronimo, regardless of which version of Geronimo they're depending on. Or, perhaps you're saying that we should keep the JARs in a Maven 1 repo but put them in there twice, in one place for the Maven 1 Group ID (for Maven 1 clients) and in a different place for the Maven 2 Group ID for Maven 2 clients (who need to point their build to a Maven 1 repo but from what you've said that will work)? Thanks, Aaron
Re: Geronimo 1.1 JARs in Maven 2 Repo
IMO it would be very confusing to deploy these artifacts anywhere, or expect people to install them by hand with a different groupId. Copy bad, check. Never want to see them deployed anywhere, I'm confused -- they are deployed to http://www.ibiblio.org/maven/geronimo/jars/ already. These appear to be the artifacts built with m1, which I'd expect to find here. I meant that I would not expect to see artifacts built w/ m2 here (under http://www.ibiblio.org/maven anywhere) or see the m1 artifacts moved to http://www.ibiblio.org/maven/org.apache.geronimo.modules/jars/ The only time I would expect to see stuff under http:// www.ibiblio.org/maven/org.apache.geronimo.modules/jars/ or http:// www.ibiblio.org/maven/org.apache.geronimo/jars/ would be if our m2 build published to that repository... and since we won't have m2 build until 1.2 I'm a tad confused myself why this path exists in central for 1.0 jars. --jason
GBeans/JARs in an EAR
Let's say you want to deploy certain GBeans when an EAR is deployed. The problem seems to be getting them onto the classpath for the EAR. The options seem to be somewhat forced: - put them in a JAR in a RAR in the EAR - put them in an EJB JAR in the EAR - put them in a JAR in the EAR and add a reference to that JAR to the manifest Class-Path of an EJB JAR in the EAR - put them in a JAR in the repository and add a dependency to geronimo-application.xml - put them in a service module JAR or in a different application module using one of these options and add that module as a dependency in geronimo-application.xml Is that right? It seems like it might be valuable to be able to include a JAR of GBeans in the EAR and somehow reference it from the geronimo-application.xml so it could be added to the EAR classpath without being in a J2EE module in the EAR, and still benefit from the hot deployment features and stuff that don't work as well for JARs in the repository. That would also provide an option other than the manifest Class-Path for having multiple J2EE modules in an EAR refer to the same JAR in the EAR. What do you think? Thanks, Aaron
Re: Geronimo 1.1 JARs in Maven 2 Repo
OK. On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote: These appear to be the artifacts built with m1, which I'd expect to find here. I meant that I would not expect to see artifacts built w/ m2 here (under http://www.ibiblio.org/maven anywhere) or see the m1 artifacts moved to http://www.ibiblio.org/maven/org.apache.geronimo.modules/jars/ The only time I would expect to see stuff under http:// www.ibiblio.org/maven/org.apache.geronimo.modules/jars/ or http:// www.ibiblio.org/maven/org.apache.geronimo/jars/ would be if our m2 build published to that repository... and since we won't have m2 build until 1.2 I'm a tad confused myself why this path exists in central for 1.0 jars. --jason
Re: [Vote] Geronimo Eclipse Plugin v1.1.0
On Jul 11, 2006, at 4:09 PM, Sachin Patel wrote:FYI the current vote is on.. (breaking the all time software record on the number of release candidate drivers in one day)http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-deployable-RC10.zipSachin, All the license/notices look good. I created/started a server; created, deployed and tested a jsp. Looks good to me. Nice work!Here's my non-binding +1.--kevan
[jira] Updated: (GERONIMO-2125) Classpath entries in the web app archive META-INF/MANIFEST.MF are not added to the wep app class path
[ http://issues.apache.org/jira/browse/GERONIMO-2125?page=all ] David Jencks updated GERONIMO-2125: --- Attachment: ear-1.0-SNAPSHOT.ear manifestcp-itest-v3.jar Here's my sample application that demonstrated the problem and convinced me I fixed it. Classpath entries in the web app archive META-INF/MANIFEST.MF are not added to the wep app class path - Key: GERONIMO-2125 URL: http://issues.apache.org/jira/browse/GERONIMO-2125 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Environment: 1.1 release Reporter: Mario Ruebsam Assignee: David Jencks Priority: Blocker Fix For: 1.2, 1.1.1 Attachments: ear-1.0-SNAPSHOT.ear, ear-1.0-SNAPSHOT.ear, ear-1.0-SNAPSHOT.ear, ear-1.0-SNAPSHOT.ear, manifestcp-itest-v2.jar, manifestcp-itest-v3.jar, manifestcp-itest.jar A working EAR for Geronimo 1.0 with this structure: app.ear/ app.jar cpa.jar found.jar webclient.war The util JARs are referenced from the webclient.war/META-INF/MANIFEST.MF Class-Path: app.jar cpa.jar found.jar Deployment of this EAR in G 1.1-rc1 result in ClassNotFoundExceptions because of the missing classes in the JARs which are not found. Putting the JARs into the webclient.war/WEB-INF/lib worked. -- 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] Resolved: (GERONIMO-2125) Classpath entries in the web app archive META-INF/MANIFEST.MF are not added to the wep app class path
[ http://issues.apache.org/jira/browse/GERONIMO-2125?page=all ] David Jencks resolved GERONIMO-2125: Resolution: Fixed AFAICT this is fixed in 1.1.1 (rev 420979) and 1.2 (rev 420984). Please verify. Classpath entries in the web app archive META-INF/MANIFEST.MF are not added to the wep app class path - Key: GERONIMO-2125 URL: http://issues.apache.org/jira/browse/GERONIMO-2125 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Environment: 1.1 release Reporter: Mario Ruebsam Assignee: David Jencks Priority: Blocker Fix For: 1.2, 1.1.1 Attachments: ear-1.0-SNAPSHOT.ear, ear-1.0-SNAPSHOT.ear, ear-1.0-SNAPSHOT.ear, ear-1.0-SNAPSHOT.ear, manifestcp-itest-v2.jar, manifestcp-itest-v3.jar, manifestcp-itest.jar A working EAR for Geronimo 1.0 with this structure: app.ear/ app.jar cpa.jar found.jar webclient.war The util JARs are referenced from the webclient.war/META-INF/MANIFEST.MF Class-Path: app.jar cpa.jar found.jar Deployment of this EAR in G 1.1-rc1 result in ClassNotFoundExceptions because of the missing classes in the JARs which are not found. Putting the JARs into the webclient.war/WEB-INF/lib worked. -- 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: [M2 build] : Error building application uddi-db on XP
Shucks.. I gotta get used to this m2migration branch.
Thanx Jason. BTW, since this is a bug fix, this can go into trunk too,
rt ? No RTC needed.
Are you going to put it there ? Or will it be Jacek who has to do the
code synch now ? :-)
Cheers
Prasad.
On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote:
From your local workspace path, it looks like you are building from
trunk, which I have not touched.
Also this line is telling:
[INFO] [antrun:run {execution: default}]
I changed the id of the antrun execution to setup-db, so it appears
you are not using the code-line that I fixed ;-)
Please use this SVN URL:
https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/
m2migration/
--jason
On Jul 11, 2006, at 12:31 PM, Prasad Kashyap wrote:
There u go..
Cheers
Prasad
On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote:
Can you send the output of the build plz.
--jason
On Jul 11, 2006, at 7:15 AM, Prasad Kashyap wrote:
Nope. No such luck. I deleted the entire applications dir. I also
deleted the o.a.g.applications group from the local repo. I then
did
an 'svn update' from top level geronimo dir. I rebuilt the
bootstrap
stage and then the assembly stage. Same problem.
Cheers
Prasad
On 7/10/06, Jason Dillon [EMAIL PROTECTED] wrote:
The uddi-db module should be buildable now since #420661
Give it a whirl and let me know if you run into anything else.
--jason
On Jul 10, 2006, at 4:28 PM, Jason Dillon wrote:
It appears that the uddi-db module should *NOT* have any webapp
stuff, but only the derby database files.
So, unless someone can shed some light onto why the db module
has
webapp files in it, I'm going to remove them.
--jason
On Jul 10, 2006, at 4:15 PM, Jason Dillon wrote:
Why are the uddi-* webapp files duplicated in the -server
and -db
modules?
snip
uddi-db/src
uddi-db/src/sql
uddi-db/src/sql/juddi.sql
uddi-db/src/webapp
uddi-db/src/webapp/happyjuddi.jsp
uddi-db/src/webapp/WEB-INF
uddi-db/src/webapp/WEB-INF/juddi.properties
uddi-db/src/webapp/WEB-INF/web.xml
uddi-server/src
uddi-server/src/webapp
uddi-server/src/webapp/happyjuddi.jsp
uddi-server/src/webapp/WEB-INF
uddi-server/src/webapp/WEB-INF/juddi.properties
uddi-server/src/webapp/WEB-INF/web.xml
/snip
--jason
On Jul 10, 2006, at 5:12 AM, Prasad Kashyap wrote:
Seeing this error on Windows XP only. Unable to recreate it on
Linux.
I am trying to build the trunk using m2. I began with a clean
repo and
did a fresh checkout.
I executed build.bat and it ran the bootstrap stage. Then I
executed
build.bat -Dstage=assembly -Dmaven.test.skip=true.
It failed while trying to build applications/uddi-db with the
following error
---
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[delete] Deleting directory
C:\Apache\geronimo\trunk\applications\uddi-db\target\resources
\META-INF\geronimo-uddi-db\var\derby
[mkdir] Created dir:
C:\Apache\geronimo\trunk\applications\uddi-db\target\resources
\META-INF\geronimo-uddi-db\var\derby
[sql] Executing file:
C:\Apache\geronimo\trunk\applications\uddi-db\src\sql
\juddi.sql
[sql] 87 of 87 SQL statements executed successfully
[INFO] Executed tasks
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [jspc:compile {execution: jspc}]
[INFO] Built File: \happyjuddi.jsp
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[delete] Deleting directory
C:\Apache\geronimo\trunk\applications\uddi-db\taget\resources
\META-INF\geronimo-uddi-db\var\derby
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error executing ant tasks
Embedded error: Unable to delete file
C:\Apache\geronimo\trunk\applications\uddi-db\target\resources
\META-INF\geronimo-uddi-db\var\derby\UddiDatabase\db.lck
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 minute 36 seconds
[INFO] Finished at: Mon Jul 10 07:47:20 EDT 2006
[INFO] Final Memory: 28M/51M
-
It is trying to execute the antrun plugin in the
applications/uddi-db/pom.xml a second time when the error
occurs.
Cheers
Prasad
mvn.log
Re: [M2 build] : Error building application uddi-db on XP
I can do it... was going to, but only when the current m2migration
code is merged over. I don't really want to merge bit by bit... way
to much work.
--jason
On Jul 11, 2006, at 1:40 PM, Prasad Kashyap wrote:
Shucks.. I gotta get used to this m2migration branch.
Thanx Jason. BTW, since this is a bug fix, this can go into trunk too,
rt ? No RTC needed.
Are you going to put it there ? Or will it be Jacek who has to do the
code synch now ? :-)
Cheers
Prasad.
On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote:
From your local workspace path, it looks like you are building from
trunk, which I have not touched.
Also this line is telling:
[INFO] [antrun:run {execution: default}]
I changed the id of the antrun execution to setup-db, so it appears
you are not using the code-line that I fixed ;-)
Please use this SVN URL:
https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/
m2migration/
--jason
On Jul 11, 2006, at 12:31 PM, Prasad Kashyap wrote:
There u go..
Cheers
Prasad
On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote:
Can you send the output of the build plz.
--jason
On Jul 11, 2006, at 7:15 AM, Prasad Kashyap wrote:
Nope. No such luck. I deleted the entire applications dir. I
also
deleted the o.a.g.applications group from the local repo. I then
did
an 'svn update' from top level geronimo dir. I rebuilt the
bootstrap
stage and then the assembly stage. Same problem.
Cheers
Prasad
On 7/10/06, Jason Dillon [EMAIL PROTECTED] wrote:
The uddi-db module should be buildable now since #420661
Give it a whirl and let me know if you run into anything else.
--jason
On Jul 10, 2006, at 4:28 PM, Jason Dillon wrote:
It appears that the uddi-db module should *NOT* have any
webapp
stuff, but only the derby database files.
So, unless someone can shed some light onto why the db module
has
webapp files in it, I'm going to remove them.
--jason
On Jul 10, 2006, at 4:15 PM, Jason Dillon wrote:
Why are the uddi-* webapp files duplicated in the -server
and -db
modules?
snip
uddi-db/src
uddi-db/src/sql
uddi-db/src/sql/juddi.sql
uddi-db/src/webapp
uddi-db/src/webapp/happyjuddi.jsp
uddi-db/src/webapp/WEB-INF
uddi-db/src/webapp/WEB-INF/juddi.properties
uddi-db/src/webapp/WEB-INF/web.xml
uddi-server/src
uddi-server/src/webapp
uddi-server/src/webapp/happyjuddi.jsp
uddi-server/src/webapp/WEB-INF
uddi-server/src/webapp/WEB-INF/juddi.properties
uddi-server/src/webapp/WEB-INF/web.xml
/snip
--jason
On Jul 10, 2006, at 5:12 AM, Prasad Kashyap wrote:
Seeing this error on Windows XP only. Unable to recreate
it on
Linux.
I am trying to build the trunk using m2. I began with a
clean
repo and
did a fresh checkout.
I executed build.bat and it ran the bootstrap stage. Then I
executed
build.bat -Dstage=assembly -Dmaven.test.skip=true.
It failed while trying to build applications/uddi-db
with the
following error
---
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[delete] Deleting directory
C:\Apache\geronimo\trunk\applications\uddi-db\target
\resources
\META-INF\geronimo-uddi-db\var\derby
[mkdir] Created dir:
C:\Apache\geronimo\trunk\applications\uddi-db\target
\resources
\META-INF\geronimo-uddi-db\var\derby
[sql] Executing file:
C:\Apache\geronimo\trunk\applications\uddi-db\src\sql
\juddi.sql
[sql] 87 of 87 SQL statements executed successfully
[INFO] Executed tasks
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [jspc:compile {execution: jspc}]
[INFO] Built File: \happyjuddi.jsp
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[delete] Deleting directory
C:\Apache\geronimo\trunk\applications\uddi-db\taget
\resources
\META-INF\geronimo-uddi-db\var\derby
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error executing ant tasks
Embedded error: Unable to delete file
C:\Apache\geronimo\trunk\applications\uddi-db\target
\resources
\META-INF\geronimo-uddi-db\var\derby\UddiDatabase\db.lck
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 minute 36 seconds
[INFO] Finished at: Mon Jul 10 07:47:20 EDT 2006
[INFO] Final Memory: 28M/51M
-
It is trying to execute the antrun plugin in the
applications/uddi-db/pom.xml
Re: [M2 build] : Error building application uddi-db on XP
Ah.. makes sense. Will work with the m2migration branch then
Cheers
Prasad
On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote:
I can do it... was going to, but only when the current m2migration
code is merged over. I don't really want to merge bit by bit... way
to much work.
--jason
On Jul 11, 2006, at 1:40 PM, Prasad Kashyap wrote:
Shucks.. I gotta get used to this m2migration branch.
Thanx Jason. BTW, since this is a bug fix, this can go into trunk too,
rt ? No RTC needed.
Are you going to put it there ? Or will it be Jacek who has to do the
code synch now ? :-)
Cheers
Prasad.
On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote:
From your local workspace path, it looks like you are building from
trunk, which I have not touched.
Also this line is telling:
[INFO] [antrun:run {execution: default}]
I changed the id of the antrun execution to setup-db, so it appears
you are not using the code-line that I fixed ;-)
Please use this SVN URL:
https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/
m2migration/
--jason
On Jul 11, 2006, at 12:31 PM, Prasad Kashyap wrote:
There u go..
Cheers
Prasad
On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote:
Can you send the output of the build plz.
--jason
On Jul 11, 2006, at 7:15 AM, Prasad Kashyap wrote:
Nope. No such luck. I deleted the entire applications dir. I
also
deleted the o.a.g.applications group from the local repo. I then
did
an 'svn update' from top level geronimo dir. I rebuilt the
bootstrap
stage and then the assembly stage. Same problem.
Cheers
Prasad
On 7/10/06, Jason Dillon [EMAIL PROTECTED] wrote:
The uddi-db module should be buildable now since #420661
Give it a whirl and let me know if you run into anything else.
--jason
On Jul 10, 2006, at 4:28 PM, Jason Dillon wrote:
It appears that the uddi-db module should *NOT* have any
webapp
stuff, but only the derby database files.
So, unless someone can shed some light onto why the db module
has
webapp files in it, I'm going to remove them.
--jason
On Jul 10, 2006, at 4:15 PM, Jason Dillon wrote:
Why are the uddi-* webapp files duplicated in the -server
and -db
modules?
snip
uddi-db/src
uddi-db/src/sql
uddi-db/src/sql/juddi.sql
uddi-db/src/webapp
uddi-db/src/webapp/happyjuddi.jsp
uddi-db/src/webapp/WEB-INF
uddi-db/src/webapp/WEB-INF/juddi.properties
uddi-db/src/webapp/WEB-INF/web.xml
uddi-server/src
uddi-server/src/webapp
uddi-server/src/webapp/happyjuddi.jsp
uddi-server/src/webapp/WEB-INF
uddi-server/src/webapp/WEB-INF/juddi.properties
uddi-server/src/webapp/WEB-INF/web.xml
/snip
--jason
On Jul 10, 2006, at 5:12 AM, Prasad Kashyap wrote:
Seeing this error on Windows XP only. Unable to recreate
it on
Linux.
I am trying to build the trunk using m2. I began with a
clean
repo and
did a fresh checkout.
I executed build.bat and it ran the bootstrap stage. Then I
executed
build.bat -Dstage=assembly -Dmaven.test.skip=true.
It failed while trying to build applications/uddi-db
with the
following error
---
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[delete] Deleting directory
C:\Apache\geronimo\trunk\applications\uddi-db\target
\resources
\META-INF\geronimo-uddi-db\var\derby
[mkdir] Created dir:
C:\Apache\geronimo\trunk\applications\uddi-db\target
\resources
\META-INF\geronimo-uddi-db\var\derby
[sql] Executing file:
C:\Apache\geronimo\trunk\applications\uddi-db\src\sql
\juddi.sql
[sql] 87 of 87 SQL statements executed successfully
[INFO] Executed tasks
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [jspc:compile {execution: jspc}]
[INFO] Built File: \happyjuddi.jsp
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[delete] Deleting directory
C:\Apache\geronimo\trunk\applications\uddi-db\taget
\resources
\META-INF\geronimo-uddi-db\var\derby
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error executing ant tasks
Embedded error: Unable to delete file
C:\Apache\geronimo\trunk\applications\uddi-db\target
\resources
\META-INF\geronimo-uddi-db\var\derby\UddiDatabase\db.lck
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
Session/clustering API and the web tier
All, Here are my comments on the Session API that were promised after apachecon dublin. This is also CC'd to the wadi list and some of the points are relevant to them as well. My own reason for focusing on the Session API when I think about clustering, is that I like the idea of pluggable clustering implementations. Clustering is not one size fits all and solutions can go from non-replicated nodes configured in a flat file to auto discovered, self healing, redundant hierarchies. I think the previous discussions we had on this were making good progress, but I think we ran out of steam before the API was improved etc. So I think it worthwhile to re-read the original threads. But I will repeat my main unresolved concerns here: While I appreciate the keep-it-simple-stupid approach adopted by the proposed session API, I remain concerned that it may over simplify and may also mix concerns. However, I do think that the API is pitched at about the right level - namely that it is below the specific concerns of things such as HTTP. As the implementor of the web container, I would prefer to not delegate HttpSession management or request proxying to a pluggable session implementation (I doubt that a cluster impl wants to deal with non-blocking proxying of requests etc.) I see that the webcontainer needs to interact with the cluster implementation in 4 areas: 1) Policy - When a container receives a request, it needs to make a policy decision along the lines of: 1) The request can be handled locally. 2) The request can be handled locally, but only after some other actions (eg session is moved to local) 3) request cannot be handled locally, but can be redirected to another node 4) request cannot be handled locally, but can be proxied to another node. This kind of corresponds to the Locator and SessionLocation APIs. However these APIs give the power to enact a policy decision, but give no support to make a policy decision. To implement a policy, you might want to use: the size of the cluster, the total number of sessions, the number of session on the local node, the number of sessions collocated with a remote session, how many requests for the session have recently arrived on what nodes, etc. etc. The API does not give me this information and I think it would be difficult to provide all that might be used. Potentially we could get by with a mechanism to store/access cluster wide meta-data attributes? However, it is very unlikely that one policy will fit all, so each consumer of this Location API will have to implement a pluggable policy frame work of some sorts. But as the session API is already a pluggable framework, why don't we just delegate the policy decision to the API. The web container should make the policy decision, but should call the session API to make the decision. Something like: SessionLocation executeAt = locator.getSessionExecutionLocation(clientId); if (executeAt.isLocal()) // handle request else // proxy or redirect to executeAt location. (Note the need for something like this has been discussed before and generally agreed. I have seen the proposed RemoteSessionStrategy, but I am not sure how you obtain a handle to one - nor do I think the policy should decide between redirect and proxy - which is HTTP business). I final concern about location and policy is that the API does not support non-homogeneous clusters. For a given client ID, the EJBSession beans may be on one node and the HttpSession beans on another.So perhaps the type of the session needs to be passed to the policy and the policy may decide to only move part of the session around. 2) State. The proposed Session interface is where we put the state for the session. The first question about this is why does it not implement the Map interface? The primatives are much the same: addState(String key, Object value); getState(String key); removeState(String key); but without any support for size, iteration, bulk operations etc. These operations will be needed to implement getAttributeNames at least. Also note that there is not a 1 to 1 mapping between this session object and a HttpSession, as for a given client ID there may be a HttpSession for each webapp context visited, plus EJB sessions etc. To handle this, the name space of the session must be structured, so when the user calls setAttribute(foo,value); the actual call is something like addState(web:+contextPath+foo,value); Which kind of sux on a number of levels. First of all contextPath is not sufficiently uniq and virtual hosts and ports must be brought into play. There is also going to be a cost in creating lots of strings just to lookup values. I don't see why this scoping could not be done by the session instance itself and that the web container is passed an instance that is pre-scoped to the specific context (even if it just added names
Re: [RTC] Vote restart on 2 javamail patches
Rick, I have reviewed your patches and they appear fine to me. You get my +1. Jeff Rick McGuire wrote: These two patches have been sitting in [RTC] state for 2 weeks now with no activity. The only votes received so far have been non-binding ones. These changes are holding up other work, including trying to convince the James developers to convert to using the Geronimo javamail version. First issue, removing the javamail-transport module and replacing it with a dependency on the javamail-provider jar. http://issues.apache.org/jira/browse/GERONIMO-2147 NOTE: The above patch is another example of an area where svn diff and patch don't work well together. Applying this patch will prompt for a Reverse action on the patch. It doesn't matter how you reply, because after the patch applies, delete the javamail-transport module subdirectory, and this should build ok. Second issue, creating a new javamail 1.4 spec jar. http://issues.apache.org/jira/browse/GERONIMO-2148 Rick
Re: Geronimo 1.1 JARs in Maven 2 Repo
The Geronimo Eclipse Plug-in build uses Maven 2 and depends on the v4 POMs to load the Geronimo dependencies correctly If you try to build the Plug-in using legacy Maven 1 repos, it will always fail. Alan D. Cabrera wrote: Aaron Mulder wrote: Since we don't necessarily plan on converting Geronimo 1.1.x to Maven 2, can we post the 1.1 JARs in a Maven 2 repo somewhere, with a structure corresponding to the new 1.2/Maven 2 group IDs (o.a.g.*) but no POMs? That would help with building plugins using Maven 2 against the 1.1 JARs (such as kernel, system, etc.). At least if you put in an explicit dependency in your plugin POM it should be able to pull the JARs for you. (And of course they're only needed at compile time since they'll be pulled in via parent module dependencies at runtime.) If no one has any better idea, maybe I'll post them on my people.apache.org for now. But if we can agree to post them to the Maven 2 repo at iBiblio that would be great. Maven 1 repos can be used from Maven 2. Why would we need to post maven 1 jars into a maven 2 repository? Regards, Alan smime.p7s Description: S/MIME Cryptographic Signature
Re: [M2 build] : Error building application uddi-db on XP
done.
--jason
On Jul 11, 2006, at 8:57 PM, Prasad Kashyap wrote:
I began using the m2migration branch. The configs build stalled while
building the jsp-examples-* configs on Windoze due to the now familiar
long path problem.
C:\Apache\geronimo\sandbox\m2migration\configs\jsp-examples-jetty
\target\repository\org\apache\geronimo\configs\jsp-examples-jetty
\1.2-SNAPSHOT\jsp-examples-jetty-1.2-SNAPSHOT.car\WEB-INF\classes
\org\apache\jsp\jsp2\tagfiles
unable to be deleted.
There are 2 example artifacts, jsp-examples and servlets-examples that
come from a separate geronimo-samples groupId. They should be built by
jar'ring their classes into web-inf/lib too. The maven-war-plugin in
their build should use the archiveClassestrue/archiveClasses
config option.
Meanwhile, we should comment out the build of the configs for those
examples. They are not in our assemblies anyways.
So here's the patch. Please apply it to the m2migration branch
Cheers
Prasad
On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote:
Thanks, it will make it easier for us all to keep in sync and to
rapidly accept patches if we use this code-line.
And then... RTC with a functional build and be done with it.
--jason
On Jul 11, 2006, at 2:01 PM, Prasad Kashyap wrote:
Ah.. makes sense. Will work with the m2migration branch then
Cheers
Prasad
On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote:
I can do it... was going to, but only when the current m2migration
code is merged over. I don't really want to merge bit by
bit... way
to much work.
--jason
On Jul 11, 2006, at 1:40 PM, Prasad Kashyap wrote:
Shucks.. I gotta get used to this m2migration branch.
Thanx Jason. BTW, since this is a bug fix, this can go into
trunk too,
rt ? No RTC needed.
Are you going to put it there ? Or will it be Jacek who has to
do the
code synch now ? :-)
Cheers
Prasad.
On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote:
From your local workspace path, it looks like you are building
from
trunk, which I have not touched.
Also this line is telling:
[INFO] [antrun:run {execution: default}]
I changed the id of the antrun execution to setup-db, so it
appears
you are not using the code-line that I fixed ;-)
Please use this SVN URL:
https://svn.apache.org/repos/asf/geronimo/sandbox/
svkmerge/
m2migration/
--jason
On Jul 11, 2006, at 12:31 PM, Prasad Kashyap wrote:
There u go..
Cheers
Prasad
On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote:
Can you send the output of the build plz.
--jason
On Jul 11, 2006, at 7:15 AM, Prasad Kashyap wrote:
Nope. No such luck. I deleted the entire applications
dir. I
also
deleted the o.a.g.applications group from the local repo.
I then
did
an 'svn update' from top level geronimo dir. I rebuilt the
bootstrap
stage and then the assembly stage. Same problem.
Cheers
Prasad
On 7/10/06, Jason Dillon [EMAIL PROTECTED] wrote:
The uddi-db module should be buildable now since #420661
Give it a whirl and let me know if you run into anything
else.
--jason
On Jul 10, 2006, at 4:28 PM, Jason Dillon wrote:
It appears that the uddi-db module should *NOT* have
any
webapp
stuff, but only the derby database files.
So, unless someone can shed some light onto why the db
module
has
webapp files in it, I'm going to remove them.
--jason
On Jul 10, 2006, at 4:15 PM, Jason Dillon wrote:
Why are the uddi-* webapp files duplicated in the -
server
and -db
modules?
snip
uddi-db/src
uddi-db/src/sql
uddi-db/src/sql/juddi.sql
uddi-db/src/webapp
uddi-db/src/webapp/happyjuddi.jsp
uddi-db/src/webapp/WEB-INF
uddi-db/src/webapp/WEB-INF/juddi.properties
uddi-db/src/webapp/WEB-INF/web.xml
uddi-server/src
uddi-server/src/webapp
uddi-server/src/webapp/happyjuddi.jsp
uddi-server/src/webapp/WEB-INF
uddi-server/src/webapp/WEB-INF/juddi.properties
uddi-server/src/webapp/WEB-INF/web.xml
/snip
--jason
On Jul 10, 2006, at 5:12 AM, Prasad Kashyap wrote:
Seeing this error on Windows XP only. Unable to
recreate
it on
Linux.
I am trying to build the trunk using m2. I began
with a
clean
repo and
did a fresh checkout.
I executed build.bat and it ran the bootstrap stage.
Then I
executed
build.bat -Dstage=assembly -Dmaven.test.skip=true.
It failed while trying to build applications/uddi-db
with the
following error
---
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[delete] Deleting directory
C:\Apache\geronimo\trunk\applications\uddi-db\target
\resources
\META-INF\geronimo-uddi-db\var\derby
[mkdir] Created dir:
Re: [M2 build] : Error building application uddi-db on XP
Earlier, my jetty assembly build always used the 2.2-SNAPSHOT of the
maven-assembly-plugin that I had freshly built. Now in the m2migration
branch, it always downloads and uses the 2.1 v of the
maven-assembly-plugin. It's 1 am EST and I am too tired to go looking
for what's changed in the pluginRepositories to cause this. If u know
offhand, please send me a mail. I'll have the jetty assembly patch
ready the first thing in the morning.
It's not letting me build in the offline mode either.
--
GroupId: org.apache.maven.plugins
ArtifactId: maven-assembly-plugin
Version: 2.1
Reason: System is offline.
org.apache.maven.plugins:maven-assembly-plugin:pom:2.1
NOTE: Maven is executing in offline mode. Any artifacts not already in
your loca repository will be inaccessible.
---
Cheers
Prasad
On 7/12/06, Jason Dillon [EMAIL PROTECTED] wrote:
done.
--jason
On Jul 11, 2006, at 8:57 PM, Prasad Kashyap wrote:
I began using the m2migration branch. The configs build stalled while
building the jsp-examples-* configs on Windoze due to the now familiar
long path problem.
C:\Apache\geronimo\sandbox\m2migration\configs\jsp-examples-jetty
\target\repository\org\apache\geronimo\configs\jsp-examples-jetty
\1.2-SNAPSHOT\jsp-examples-jetty-1.2-SNAPSHOT.car\WEB-INF\classes
\org\apache\jsp\jsp2\tagfiles
unable to be deleted.
There are 2 example artifacts, jsp-examples and servlets-examples that
come from a separate geronimo-samples groupId. They should be built by
jar'ring their classes into web-inf/lib too. The maven-war-plugin in
their build should use the archiveClassestrue/archiveClasses
config option.
Meanwhile, we should comment out the build of the configs for those
examples. They are not in our assemblies anyways.
So here's the patch. Please apply it to the m2migration branch
Cheers
Prasad
On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote:
Thanks, it will make it easier for us all to keep in sync and to
rapidly accept patches if we use this code-line.
And then... RTC with a functional build and be done with it.
--jason
On Jul 11, 2006, at 2:01 PM, Prasad Kashyap wrote:
Ah.. makes sense. Will work with the m2migration branch then
Cheers
Prasad
On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote:
I can do it... was going to, but only when the current m2migration
code is merged over. I don't really want to merge bit by
bit... way
to much work.
--jason
On Jul 11, 2006, at 1:40 PM, Prasad Kashyap wrote:
Shucks.. I gotta get used to this m2migration branch.
Thanx Jason. BTW, since this is a bug fix, this can go into
trunk too,
rt ? No RTC needed.
Are you going to put it there ? Or will it be Jacek who has to
do the
code synch now ? :-)
Cheers
Prasad.
On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote:
From your local workspace path, it looks like you are building
from
trunk, which I have not touched.
Also this line is telling:
[INFO] [antrun:run {execution: default}]
I changed the id of the antrun execution to setup-db, so it
appears
you are not using the code-line that I fixed ;-)
Please use this SVN URL:
https://svn.apache.org/repos/asf/geronimo/sandbox/
svkmerge/
m2migration/
--jason
On Jul 11, 2006, at 12:31 PM, Prasad Kashyap wrote:
There u go..
Cheers
Prasad
On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote:
Can you send the output of the build plz.
--jason
On Jul 11, 2006, at 7:15 AM, Prasad Kashyap wrote:
Nope. No such luck. I deleted the entire applications
dir. I
also
deleted the o.a.g.applications group from the local repo.
I then
did
an 'svn update' from top level geronimo dir. I rebuilt the
bootstrap
stage and then the assembly stage. Same problem.
Cheers
Prasad
On 7/10/06, Jason Dillon [EMAIL PROTECTED] wrote:
The uddi-db module should be buildable now since #420661
Give it a whirl and let me know if you run into anything
else.
--jason
On Jul 10, 2006, at 4:28 PM, Jason Dillon wrote:
It appears that the uddi-db module should *NOT* have
any
webapp
stuff, but only the derby database files.
So, unless someone can shed some light onto why the db
module
has
webapp files in it, I'm going to remove them.
--jason
On Jul 10, 2006, at 4:15 PM, Jason Dillon wrote:
Why are the uddi-* webapp files duplicated in the -
server
and -db
modules?
snip
uddi-db/src
uddi-db/src/sql
uddi-db/src/sql/juddi.sql
uddi-db/src/webapp
uddi-db/src/webapp/happyjuddi.jsp
uddi-db/src/webapp/WEB-INF
uddi-db/src/webapp/WEB-INF/juddi.properties
uddi-db/src/webapp/WEB-INF/web.xml
uddi-server/src
uddi-server/src/webapp
Re: [M2 build] : Error building application uddi-db on XP
maven-assembly-plugin v2.1 is the default that is specified in
genesis/config/project-config/pom.xml
If you want to use something else, then you need to explicitly define
the plugin's version in the pom you use it from.
--jason
On Jul 11, 2006, at 9:56 PM, Prasad Kashyap wrote:
Earlier, my jetty assembly build always used the 2.2-SNAPSHOT of the
maven-assembly-plugin that I had freshly built. Now in the m2migration
branch, it always downloads and uses the 2.1 v of the
maven-assembly-plugin. It's 1 am EST and I am too tired to go looking
for what's changed in the pluginRepositories to cause this. If u know
offhand, please send me a mail. I'll have the jetty assembly patch
ready the first thing in the morning.
It's not letting me build in the offline mode either.
--
GroupId: org.apache.maven.plugins
ArtifactId: maven-assembly-plugin
Version: 2.1
Reason: System is offline.
org.apache.maven.plugins:maven-assembly-plugin:pom:2.1
NOTE: Maven is executing in offline mode. Any artifacts not already in
your loca repository will be inaccessible.
---
Cheers
Prasad
On 7/12/06, Jason Dillon [EMAIL PROTECTED] wrote:
done.
--jason
On Jul 11, 2006, at 8:57 PM, Prasad Kashyap wrote:
I began using the m2migration branch. The configs build stalled
while
building the jsp-examples-* configs on Windoze due to the now
familiar
long path problem.
C:\Apache\geronimo\sandbox\m2migration\configs\jsp-examples-jetty
\target\repository\org\apache\geronimo\configs\jsp-examples-jetty
\1.2-SNAPSHOT\jsp-examples-jetty-1.2-SNAPSHOT.car\WEB-INF\classes
\org\apache\jsp\jsp2\tagfiles
unable to be deleted.
There are 2 example artifacts, jsp-examples and servlets-
examples that
come from a separate geronimo-samples groupId. They should be
built by
jar'ring their classes into web-inf/lib too. The maven-war-
plugin in
their build should use the archiveClassestrue/archiveClasses
config option.
Meanwhile, we should comment out the build of the configs for those
examples. They are not in our assemblies anyways.
So here's the patch. Please apply it to the m2migration branch
Cheers
Prasad
On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote:
Thanks, it will make it easier for us all to keep in sync and to
rapidly accept patches if we use this code-line.
And then... RTC with a functional build and be done with it.
--jason
On Jul 11, 2006, at 2:01 PM, Prasad Kashyap wrote:
Ah.. makes sense. Will work with the m2migration branch then
Cheers
Prasad
On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote:
I can do it... was going to, but only when the current
m2migration
code is merged over. I don't really want to merge bit by
bit... way
to much work.
--jason
On Jul 11, 2006, at 1:40 PM, Prasad Kashyap wrote:
Shucks.. I gotta get used to this m2migration branch.
Thanx Jason. BTW, since this is a bug fix, this can go into
trunk too,
rt ? No RTC needed.
Are you going to put it there ? Or will it be Jacek who
has to
do the
code synch now ? :-)
Cheers
Prasad.
On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote:
From your local workspace path, it looks like you are
building
from
trunk, which I have not touched.
Also this line is telling:
[INFO] [antrun:run {execution: default}]
I changed the id of the antrun execution to setup-db, so it
appears
you are not using the code-line that I fixed ;-)
Please use this SVN URL:
https://svn.apache.org/repos/asf/geronimo/sandbox/
svkmerge/
m2migration/
--jason
On Jul 11, 2006, at 12:31 PM, Prasad Kashyap wrote:
There u go..
Cheers
Prasad
On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote:
Can you send the output of the build plz.
--jason
On Jul 11, 2006, at 7:15 AM, Prasad Kashyap wrote:
Nope. No such luck. I deleted the entire applications
dir. I
also
deleted the o.a.g.applications group from the local
repo.
I then
did
an 'svn update' from top level geronimo dir. I
rebuilt the
bootstrap
stage and then the assembly stage. Same problem.
Cheers
Prasad
On 7/10/06, Jason Dillon [EMAIL PROTECTED] wrote:
The uddi-db module should be buildable now since
#420661
Give it a whirl and let me know if you run into
anything
else.
--jason
On Jul 10, 2006, at 4:28 PM, Jason Dillon wrote:
It appears that the uddi-db module should *NOT* have
any
webapp
stuff, but only the derby database files.
So, unless someone can shed some light onto why
the db
module
has
webapp files in it, I'm going to remove them.
--jason
On Jul 10, 2006, at 4:15 PM, Jason Dillon wrote:
Why are the uddi-* webapp files duplicated in the -
server
and -db
modules?
snip
[jira] Assigned: (SM-474) Add validation code in for jbi descriptor to enforce the inclusion of bootstrap classname and classpath elements
[ https://issues.apache.org/activemq/browse/SM-474?page=all ] Grant McDonald reassigned SM-474: - Assign To: Grant McDonald Add validation code in for jbi descriptor to enforce the inclusion of bootstrap classname and classpath elements Key: SM-474 URL: https://issues.apache.org/activemq/browse/SM-474 Project: ServiceMix Type: Improvement Components: servicemix-core Versions: incubation Environment: Ubuntu Linux 5.10, Windows XP SP2 Reporter: Grant McDonald Assignee: Grant McDonald Original Estimate: 30 minutes Remaining: 30 minutes Installers whose jbi.xml doesn't contain a bootstrap classpath and class name are invalid as described by the jbi spec and also cause an NPE to be thrown when the component is installed. Add in a validation on the jbi.xml to this effect (hint: JbiElementProcessor or for an easier implementation - DescriptorFactory) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
