error when start broker
Hi, My database is sybaseASE12.5,and I use the activemq4.1.0. The following is the series of messages when I start broker: - ActiveMQ 4.1.0-incubator JMS Message Broker (xuke) is starting - For help or more information please see: http://incubator.apache.org/activemq/ - Database driver recognized: [jconnect__tm__for_jdbc__tm_] - Attempting to acquire the exclusive lock to become the Master broker - Failed to acquire lock: com.sybase.jdbc3.jdbc.SybSQLException: FOR UPDATE can not be used in a SELECT which is not part of the declaration of a cursor or which is not a stored procedure. com.sybase.jdbc3.jdbc.SybSQLException: FOR UPDATE can not be used in a SELECT which is not part of the declaration of a cursor or which is not a stored procedure. at com.sybase.jdbc3.tds.Tds.a(Unknown Source) at com.sybase.jdbc3.tds.Tds.nextResult(Unknown Source) at com.sybase.jdbc3.jdbc.ResultGetter.nextResult(Unknown Source) at com.sybase.jdbc3.jdbc.SybStatement.nextResult(Unknown Source) at com.sybase.jdbc3.jdbc.SybStatement.nextResult(Unknown Source) at com.sybase.jdbc3.jdbc.SybStatement.executeLoop(Unknown Source) at com.sybase.jdbc3.jdbc.SybStatement.execute(Unknown Source) at com.sybase.jdbc3.jdbc.SybPreparedStatement.execute(Unknown Source) at org.apache.commons.dbcp.DelegatingPreparedStatement.execute(DelegatingPreparedStatement.java:117) at org.apache.commons.dbcp.DelegatingPreparedStatement.execute(DelegatingPreparedStatement.java:117) at org.apache.activemq.store.jdbc.DefaultDatabaseLocker.start(DefaultDatabaseLocker.java:59) How can I handle this? -- View this message in context: http://www.nabble.com/error-when-start-broker-tf2844348.html#a7942260 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
[jira] Commented: (GERONIMO-1642) Deployment plan namespace validation
[ http://issues.apache.org/jira/browse/GERONIMO-1642?page=comments#action_12459220 ] David Jencks commented on GERONIMO-1642: I'm really not sure this is still a problem. For instance JettyModuleBuilder AFAICT throws an exception explaining the xml problem if it finds a geronimo-web or geronimo-jetty.xml file that it can't interpret. When looking for examples that fail keep in mind that XmlBeansUtil.parse does a lot of namespace substitution and many builders have code to upgrade documents valid for earlier versions of geronimo plan schemas to the latest versions. So, wrong namespace should mean namespace we have never used rather than not the current namespace Deployment plan namespace validation Key: GERONIMO-1642 URL: http://issues.apache.org/jira/browse/GERONIMO-1642 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment, OpenEJB, web Affects Versions: 1.1 Reporter: Aaron Mulder Assigned To: Rakesh Midha Priority: Critical Fix For: 1.1.x When you deploy with a geronimo deployment plan packaged in the archive, but it has the wrong namespace, the file is ignored. If anything, you get a message saying the plan is required, or that the archive is not a WAR/JAR/etc. We should have special detection for geronimo-application.xml, geronimo-ra.xml, geronimo-web.xml, and openejb-jar.xml that notices if the file is present but has the wrong namespace, and prints a suggestive WARN or ERROR message to the console. Probably for the application.xml, web.xml, ra.xml, and ejb-jar.xml too. People have asked for help on the mailing list several times recently when they had this (bad namespace) problem. -- 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] Updated: (GERONIMO-1642) Deployment plan namespace validation
[ http://issues.apache.org/jira/browse/GERONIMO-1642?page=all ] Rakesh Midha updated GERONIMO-1642: --- Attachment: namespace1642.patch I tried this and found following results - for geronimo-web.xml -- It gives Error: Unable to distribute myphonebook-web.war: Cannot handle web plan with namespace http://geronimo.apache.org/xml/ns/j2ee/web-1.21 -- expecting http://geronimo.apache.org/xml/ns/j2ee/web-1.2 or http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.2 I think it was fixed in revision 406804 for geronimo-ra.xml - It gives error: The document is not a [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/connector-1.2: document element namespace mismatch expected http://geronimo.apache.org/xml/ns/j2ee/connector-1.2; got http://geronimo.apache.org/xml/ns/j2ee/connector-1.1a; Again it is fixed geronimo-application.xml, openejb-jar.xml and application-client -- It is a problem mentioned in JIRA --- --- The attached patch tries to fix it in generic way using SchemaConversionUtils.java It tries to check for wrong element or namespace and instead of returning null, it throws XmlException with message Cannot find desiredElement application with namespace{http://geronimo.apache.org/xml/ns/j2ee/application-1.2} in the plan provided. So after applying patch, geronimo-application.xml, openejb-jar.xml and application-client gives required error msg -- Cannot find desiredElement application with namespace{http://geronimo.apache.org/xml/ns/j2ee/application-1.2} in the plan provided. I hope this is what is desired. Thanks Deployment plan namespace validation Key: GERONIMO-1642 URL: http://issues.apache.org/jira/browse/GERONIMO-1642 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment, OpenEJB, web Affects Versions: 1.1 Reporter: Aaron Mulder Assigned To: Rakesh Midha Priority: Critical Fix For: 1.1.x Attachments: namespace1642.patch When you deploy with a geronimo deployment plan packaged in the archive, but it has the wrong namespace, the file is ignored. If anything, you get a message saying the plan is required, or that the archive is not a WAR/JAR/etc. We should have special detection for geronimo-application.xml, geronimo-ra.xml, geronimo-web.xml, and openejb-jar.xml that notices if the file is present but has the wrong namespace, and prints a suggestive WARN or ERROR message to the console. Probably for the application.xml, web.xml, ra.xml, and ejb-jar.xml too. People have asked for help on the mailing list several times recently when they had this (bad namespace) problem. -- 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] Updated: (GERONIMO-1642) Deployment plan namespace validation
[ http://issues.apache.org/jira/browse/GERONIMO-1642?page=all ] Rakesh Midha updated GERONIMO-1642: --- Patch Info: [Patch Available] Fix Version/s: 2.0 (was: 1.1.x) Assignee: (was: Rakesh Midha) Hello David You are right, in number of cases it is already fixed, but there are still few cases where it is a problem. Though I didnt like the way it is fixed in geronimo-web.xml, via revision 406804. In a way it hardcodes the namespace which I didnt like. Anyways for failing cases, geronimo-application.xml, openejb-jar.xml and application-client I attached to patch, which actually doesn't check for any particular version of schema but just validates the root element, and if root element or namespace is wrong it throws Cannot find desiredElement application with namespace{http://geronimo.apache.org/xml/ns/j2ee/application-1.2} in the plan provided. What do you say? Can you please review it and commit it. It is just short changes and will not take your lot of time. (small amount of changes, but one of those cases where it take lot of time to find the place where fix should go :-) ) Mark patch available and unassigning. Thanks Rakesh Deployment plan namespace validation Key: GERONIMO-1642 URL: http://issues.apache.org/jira/browse/GERONIMO-1642 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: web, deployment, OpenEJB Affects Versions: 1.1 Reporter: Aaron Mulder Priority: Critical Fix For: 2.0 Attachments: namespace1642.patch When you deploy with a geronimo deployment plan packaged in the archive, but it has the wrong namespace, the file is ignored. If anything, you get a message saying the plan is required, or that the archive is not a WAR/JAR/etc. We should have special detection for geronimo-application.xml, geronimo-ra.xml, geronimo-web.xml, and openejb-jar.xml that notices if the file is present but has the wrong namespace, and prints a suggestive WARN or ERROR message to the console. Probably for the application.xml, web.xml, ra.xml, and ejb-jar.xml too. People have asked for help on the mailing list several times recently when they had this (bad namespace) problem. -- 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] 2.0-M1 Release
All, I have prepared 2.0-M1 for release. Of course all the hard work was done by the lot of y'all :) I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied with the results. All modes of operation functioned well (SLSB, Direct, EJB and JPA). I toned all the logs down to error to not overwhelm the users with lots of diagnostic output (they can always turn it up later if they want.) The uploads are taking forever so you'll see some piece parts trickle in. For the review I expect you'll want to focus on http:// people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies for your review and testing. I've included both Tomcat and Jetty as well as the minimal and j5ee assemblies. The source code is also there. Note that if you are planning on building you'll need to obtain the openejb-2.2-incubating jars to your local repo. The easiest way to do this is to modify the root pom and add a repository for David's home directory at http://people.apache.org/~dblevins/stage/. For SNAPSHOTs of certain plugins I have resolved these files to the most recent SNAPSHOT date / timestamp. I'm pulling a copy of these and will be putting them into our SVN for folks who may want to build in the future. I'm not too concerned about repeatability as this Milestone will be superseded at the end of January with the next version. The other MAven artifacts will be trickling onto people across my horribly slow home pipe and dropped into http://people.apache.org/ ~hogstrom/stage over the next few hours. Please review and cast your vote early. The faster we determine this build is good or if there is an issue the better. Thanks in advance for all your help in this effort. This vote will conclude at 0400 ET on Dec 21 (unless all you PMC members vote quicker :) If a respin is is necessary this vote will be suspended and a new one will start. Matt Hogstrom [EMAIL PROTECTED]
High, Rob is out of the office.
I will be out of the office starting 12/18/2006 and will not return until 01/02/2007. I'm on vacation.
Re: svn commit: r488131 - /geronimo/server/branches/2.0-M1/assemblies/geronimo-boilerplate-minimal/src/main/resources/RELEASE-NOTES-2.0-M1.txt
Are we not including J2EE Management 1.1 in this list because of JSR77.3.5.0.1 - deploymentDescriptor? Thanks Anita --- [EMAIL PROTECTED] wrote: Author: hogstrom Date: Sun Dec 17 21:53:00 2006 New Revision: 488131 URL: http://svn.apache.org/viewvc?view=revrev=488131 Log: Added RELEASE notes to assembly Added: geronimo/server/branches/2.0-M1/assemblies/geronimo-boilerplate-minimal/src/main/resources/RELEASE-NOTES-2.0-M1.txt (with props) Added: geronimo/server/branches/2.0-M1/assemblies/geronimo-boilerplate-minimal/src/main/resources/RELEASE-NOTES-2.0-M1.txt URL: http://svn.apache.org/viewvc/geronimo/server/branches/2.0-M1/assemblies/geronimo-boilerplate-minimal/src/main/resources/RELEASE-NOTES-2.0-M1.txt?view=autorev=488131 == --- geronimo/server/branches/2.0-M1/assemblies/geronimo-boilerplate-minimal/src/main/resources/RELEASE-NOTES-2.0-M1.txt (added) +++ geronimo/server/branches/2.0-M1/assemblies/geronimo-boilerplate-minimal/src/main/resources/RELEASE-NOTES-2.0-M1.txt Sun Dec 17 21:53:00 2006 @@ -0,0 +1,265 @@ +Release Notes -- Apache Geronimo -- Version 2.0 - Milestone 1 + +Geronimo URLs +- +Home Page: http://geronimo.apache.org/ +Downloads: http://geronimo.apache.org/downloads.html +Documentation: http://geronimo.apache.org/documentation.html +Mailing Lists: http://geronimo.apache.org/mailing.html +Source Code: http://geronimo.apache.org/svn.html +Bug Tracking: http://issues.apache.org/jira/browse/GERONIMO +Wiki: http://cwiki.apache.org/geronimo + + +IMPORTANT +- +This is a Milestone release, that means that is not the final version of +Apache Geronimo v2.0 Take a look at Known Issues and Limitations section for +further details. + +System Requirements +--- +You need a platform that supports the Sun JDK 5.0+ (J2SE 1.5.0+). + +Most testing has been done on Linux, Mac OS X, and Windows. + + +Significant Changes in the 2.0 Release +-- +Apache Geronimo v2.0 includes the following features: + +- Full Sun JDK 5.0+ (J2SE 1.5.0+) +- Servlet 2.5 (Tomcat) +- JSP 2.1 (Tomcat) +- JSP Debug 1.0 (Tomcat) +- Servlet 2.5 (Jetty) +- JSP 2.1 (Jetty - via Jasper) +- JSP Debug 1.0 (Jetty) +- JSF 1.2 +- JSTL 1.2 +- Common Annotations 1.0 +- JAF 1.1 +- JavaMail 1.4 +- EJB 3.0 (JPA only) +- JTA 1.1 +- JMS 1.1 +- JACC 1.1 + +Installing Starting Geronimo +-- +To install, simply unpack the .zip (Windows) or tar.gz (Unix) file containing +Geronimo. + +If you wish to modify the default ports that Geronimo will use, edit the file +geronimo_home/var/config/config.xml + +Geronimo comes with batch and script files to control server start and stop +functions. To see usage examples simply type geronimo.bat or geronimo.sh +command as appropriate for your platform. It is necessary to set JAVA_HOME to +the copy of your Sun 5 JDK/JRE prior to executing the command. + +Here is an example to set JAVA_HOME: + +export JAVA_HOME=JDK/JRE_home + +To see the available command options type: + +geronimo_home/bin/geronimo.sh +or +geronimo_home/bin/geronimo.bat + +The command will display help text instructing you as to how to start and stop +the Geronimo server. + +If you prefer to start the server without a script file you can simply type: + +java -jar geronimo_home/bin/server.jar + +Once the server has started, you can access the Geronimo Administration Console +at http://localhost:8080/console/ . The default user name is system and the +default password is manager. + + +Administration Console Security Configuration +- +The default administration user/password for the Geronimo Administration Console +and deployment tool is system/manager. You can change these defaults directly +from the Geronimo Administration Console by accessing Security - Console Realm +and change the user name and password from the Console Realm Users portlet. + +As an alternative, you can make the same changes by editing the +geronimo_home/var/security/users.properties and +geronimo_home/var/security/groups.properties files. + + +Deploying Applications +-- +Geronimo comes with deploy scripts and batch files to deploy J2EE modules or +applications. You can use the scripts or simply invoke the executable jar by +running the following command (note that you need to start Geronimo first): + +geronimo_home/bin/java -jar deployer.jar deploy my-web-app.war [deploy plan] + +You will need to use the username system and password manager unless you +customized those during the install process. The deployment plan argument is +optional -- you can pack a deployment plan into the application module, provide +it on the command line, or in some
[jira] Created: (SM-781) Re: Bug in ScritpComponent when using script attribute
Re: Bug in ScritpComponent when using script attribute Key: SM-781 URL: https://issues.apache.org/activemq/browse/SM-781 Project: ServiceMix Issue Type: Bug Components: servicemix-components Affects Versions: 3.0 Reporter: Andrea Zoppello When the script component is configured using the script attribute instead of scriptText attribute the components doesn't work. For example: sm:activationSpec componentName=myGenericGroovymioGroovy service=foo:myGenericGroovymioGroovy destinationService=*foo:myScreenOutputmioGroovy* sm:component bean class=org.apache.servicemix.components.groovy.GroovyComponent property name=script value=c:/tmp/sm/groovy/testsmx.groovy / /bean /sm:component /sm:activationSpec fails with message: If no 'compiledScript' is specified you must specify the 'scriptText' The problems seems to be in the start() method of org.apache.servicemix.components.script.ScriptComponent class. in the following lines: if (compiledScript == null) { checkScriptTextAvailable(); } if (compiledScript == null) { if (engine instanceof Compilable) { Compilable compilable = (Compilable) engine; compileScript(compilable); } } I've replaced this code with the code below and it works correctly: . if ((compiledScript == null) (script != null)) { if (engine instanceof Compilable) { Compilable compilable = (Compilable) engine; compileScript(compilable); } } if (compiledScript == null) { checkScriptTextAvailable(); } . -- 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] Updated: (SM-781) Re: Bug in ScritpComponent when using script attribute
[ https://issues.apache.org/activemq/browse/SM-781?page=all ] Andrea Zoppello updated SM-781: --- Attachment: ScriptComponent.java.diff The file attached is the patch proposed to resolve the problem described Re: Bug in ScritpComponent when using script attribute Key: SM-781 URL: https://issues.apache.org/activemq/browse/SM-781 Project: ServiceMix Issue Type: Bug Components: servicemix-components Affects Versions: 3.0 Reporter: Andrea Zoppello Attachments: ScriptComponent.java.diff When the script component is configured using the script attribute instead of scriptText attribute the components doesn't work. For example: sm:activationSpec componentName=myGenericGroovymioGroovy service=foo:myGenericGroovymioGroovy destinationService=*foo:myScreenOutputmioGroovy* sm:component bean class=org.apache.servicemix.components.groovy.GroovyComponent property name=script value=c:/tmp/sm/groovy/testsmx.groovy / /bean /sm:component /sm:activationSpec fails with message: If no 'compiledScript' is specified you must specify the 'scriptText' The problems seems to be in the start() method of org.apache.servicemix.components.script.ScriptComponent class. in the following lines: if (compiledScript == null) { checkScriptTextAvailable(); } if (compiledScript == null) { if (engine instanceof Compilable) { Compilable compilable = (Compilable) engine; compileScript(compilable); } } I've replaced this code with the code below and it works correctly: . if ((compiledScript == null) (script != null)) { if (engine instanceof Compilable) { Compilable compilable = (Compilable) engine; compileScript(compilable); } } if (compiledScript == null) { checkScriptTextAvailable(); } . -- 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] Closed: (GERONIMO-2669) fix o.a.g.j.ClusteredSessionManager to match changes in Jetty AbstractSessionManager
[ http://issues.apache.org/jira/browse/GERONIMO-2669?page=all ] Gianny Damour closed GERONIMO-2669. --- Fix Version/s: 2.0-M2 (was: 2.0) Resolution: Fixed Thanks for having fixed the build and opened this JIRA David. I have reviewed and done some integration testings. Load-balancing and session replications are working with Jetty6. fix o.a.g.j.ClusteredSessionManager to match changes in Jetty AbstractSessionManager Key: GERONIMO-2669 URL: http://issues.apache.org/jira/browse/GERONIMO-2669 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Jetty Affects Versions: 2.0 Reporter: David Jencks Assigned To: Gianny Damour Fix For: 2.0-M2 Recent changes in jetty's AbstractSessionManager break the geronimo-jetty6 module build. I'm committing something that compiles and lets the console run (unclustered) but this needs some attention from someone who knows what is going on. -- 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: [VOTE] 2.0-M1 Release
Looks good. +1. On Dec 18, 2006, at 3:57 AM, Matt Hogstrom wrote: All, I have prepared 2.0-M1 for release. Of course all the hard work was done by the lot of y'all :) I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied with the results. All modes of operation functioned well (SLSB, Direct, EJB and JPA). I toned all the logs down to error to not overwhelm the users with lots of diagnostic output (they can always turn it up later if they want.) The uploads are taking forever so you'll see some piece parts trickle in. For the review I expect you'll want to focus on http:// people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies for your review and testing. I've included both Tomcat and Jetty as well as the minimal and j5ee assemblies. The source code is also there. Note that if you are planning on building you'll need to obtain the openejb-2.2-incubating jars to your local repo. The easiest way to do this is to modify the root pom and add a repository for David's home directory at http://people.apache.org/~dblevins/stage/. For SNAPSHOTs of certain plugins I have resolved these files to the most recent SNAPSHOT date / timestamp. I'm pulling a copy of these and will be putting them into our SVN for folks who may want to build in the future. I'm not too concerned about repeatability as this Milestone will be superseded at the end of January with the next version. The other MAven artifacts will be trickling onto people across my horribly slow home pipe and dropped into http://people.apache.org/ ~hogstrom/stage over the next few hours. Please review and cast your vote early. The faster we determine this build is good or if there is an issue the better. Thanks in advance for all your help in this effort. This vote will conclude at 0400 ET on Dec 21 (unless all you PMC members vote quicker :) If a respin is is necessary this vote will be suspended and a new one will start. Matt Hogstrom [EMAIL PROTECTED] -sachin
Re: [VOTE] 2.0-M1 Release
On Dec 18, 2006, at 3:57 AM, Matt Hogstrom wrote: Please review and cast your vote early. The faster we determine this build is good or if there is an issue the better. Thanks in advance for all your help in this effort. This vote will conclude at 0400 ET on Dec 21 (unless all you PMC members vote quicker :) If a respin is is necessary this vote will be suspended and a new one will start. There's a source file missing a license header. Not sure if it was added after my last scan of the code or if I just missed it. Anyway, it needs to be fixed. All servers start. I'm getting some [info] log messages sent to STDOUT, but I don't think that should hold up an M1 release. I've scanned the jetty java ee5 binary -- looks good. Working on tomcat and some more sanity checks. Other that the license header, things look good... --kevan
Re: [VOTE] 2.0-M1 Release
+1 Matt Hogstrom wrote: All, I have prepared 2.0-M1 for release. Of course all the hard work was done by the lot of y'all :) I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied with the results. All modes of operation functioned well (SLSB, Direct, EJB and JPA). I toned all the logs down to error to not overwhelm the users with lots of diagnostic output (they can always turn it up later if they want.) The uploads are taking forever so you'll see some piece parts trickle in. For the review I expect you'll want to focus on http://people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies for your review and testing. I've included both Tomcat and Jetty as well as the minimal and j5ee assemblies. The source code is also there. Note that if you are planning on building you'll need to obtain the openejb-2.2-incubating jars to your local repo. The easiest way to do this is to modify the root pom and add a repository for David's home directory at http://people.apache.org/~dblevins/stage/. For SNAPSHOTs of certain plugins I have resolved these files to the most recent SNAPSHOT date / timestamp. I'm pulling a copy of these and will be putting them into our SVN for folks who may want to build in the future. I'm not too concerned about repeatability as this Milestone will be superseded at the end of January with the next version. The other MAven artifacts will be trickling onto people across my horribly slow home pipe and dropped into http://people.apache.org/~hogstrom/stage over the next few hours. Please review and cast your vote early. The faster we determine this build is good or if there is an issue the better. Thanks in advance for all your help in this effort. This vote will conclude at 0400 ET on Dec 21 (unless all you PMC members vote quicker :) If a respin is is necessary this vote will be suspended and a new one will start. Matt Hogstrom [EMAIL PROTECTED]
Re: [VOTE] 2.0-M1 Release
I tried tomcat6-jee5: -- The log file is empty. -- Is it necessary to change all the log levels from WARN to ERROR (rev 488143)? Thanks Anita --- Matt Hogstrom [EMAIL PROTECTED] wrote: All, I have prepared 2.0-M1 for release. Of course all the hard work was done by the lot of y'all :) I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied with the results. All modes of operation functioned well (SLSB, Direct, EJB and JPA). I toned all the logs down to error to not overwhelm the users with lots of diagnostic output (they can always turn it up later if they want.) The uploads are taking forever so you'll see some piece parts trickle in. For the review I expect you'll want to focus on http:// people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies for your review and testing. I've included both Tomcat and Jetty as well as the minimal and j5ee assemblies. The source code is also there. Note that if you are planning on building you'll need to obtain the openejb-2.2-incubating jars to your local repo. The easiest way to do this is to modify the root pom and add a repository for David's home directory at http://people.apache.org/~dblevins/stage/. For SNAPSHOTs of certain plugins I have resolved these files to the most recent SNAPSHOT date / timestamp. I'm pulling a copy of these and will be putting them into our SVN for folks who may want to build in the future. I'm not too concerned about repeatability as this Milestone will be superseded at the end of January with the next version. The other MAven artifacts will be trickling onto people across my horribly slow home pipe and dropped into http://people.apache.org/ ~hogstrom/stage over the next few hours. Please review and cast your vote early. The faster we determine this build is good or if there is an issue the better. Thanks in advance for all your help in this effort. This vote will conclude at 0400 ET on Dec 21 (unless all you PMC members vote quicker :) If a respin is is necessary this vote will be suspended and a new one will start. Matt Hogstrom [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [VOTE] 2.0-M1 Release
Which log is empty? anita kulshreshtha wrote: I tried tomcat6-jee5: -- The log file is empty. -- Is it necessary to change all the log levels from WARN to ERROR (rev 488143)? Thanks Anita --- Matt Hogstrom [EMAIL PROTECTED] wrote: All, I have prepared 2.0-M1 for release. Of course all the hard work was done by the lot of y'all :) I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied with the results. All modes of operation functioned well (SLSB, Direct, EJB and JPA). I toned all the logs down to error to not overwhelm the users with lots of diagnostic output (they can always turn it up later if they want.) The uploads are taking forever so you'll see some piece parts trickle in. For the review I expect you'll want to focus on http:// people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies for your review and testing. I've included both Tomcat and Jetty as well as the minimal and j5ee assemblies. The source code is also there. Note that if you are planning on building you'll need to obtain the openejb-2.2-incubating jars to your local repo. The easiest way to do this is to modify the root pom and add a repository for David's home directory at http://people.apache.org/~dblevins/stage/. For SNAPSHOTs of certain plugins I have resolved these files to the most recent SNAPSHOT date / timestamp. I'm pulling a copy of these and will be putting them into our SVN for folks who may want to build in the future. I'm not too concerned about repeatability as this Milestone will be superseded at the end of January with the next version. The other MAven artifacts will be trickling onto people across my horribly slow home pipe and dropped into http://people.apache.org/ ~hogstrom/stage over the next few hours. Please review and cast your vote early. The faster we determine this build is good or if there is an issue the better. Thanks in advance for all your help in this effort. This vote will conclude at 0400 ET on Dec 21 (unless all you PMC members vote quicker :) If a respin is is necessary this vote will be suspended and a new one will start. Matt Hogstrom [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [VOTE] 2.0-M1 Release
Hi All, I have two basic comments/questions. 1- I see a bunch of INFO messages in both Tomcat and Jetty at startup, not a show stopper for this release. 2- Deployment on Jetty is not behaving exactly as I expected. Not sure if I messed up the dep plans given the new specs, however this same WAR works just fine with Tomcat. In Jetty I deploy a WAR and when I access the app it will list the content of the WAR, if I click on the JSP it will work fine. Something like not following the web.xml welcome-file maybe? The context-root is correct. Am I missing anything obvious? Cheers! Hernan Matt Hogstrom wrote: All, I have prepared 2.0-M1 for release. Of course all the hard work was done by the lot of y'all :) I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied with the results. All modes of operation functioned well (SLSB, Direct, EJB and JPA). I toned all the logs down to error to not overwhelm the users with lots of diagnostic output (they can always turn it up later if they want.) The uploads are taking forever so you'll see some piece parts trickle in. For the review I expect you'll want to focus on http://people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies for your review and testing. I've included both Tomcat and Jetty as well as the minimal and j5ee assemblies. The source code is also there. Note that if you are planning on building you'll need to obtain the openejb-2.2-incubating jars to your local repo. The easiest way to do this is to modify the root pom and add a repository for David's home directory at http://people.apache.org/~dblevins/stage/. For SNAPSHOTs of certain plugins I have resolved these files to the most recent SNAPSHOT date / timestamp. I'm pulling a copy of these and will be putting them into our SVN for folks who may want to build in the future. I'm not too concerned about repeatability as this Milestone will be superseded at the end of January with the next version. The other MAven artifacts will be trickling onto people across my horribly slow home pipe and dropped into http://people.apache.org/~hogstrom/stage over the next few hours. Please review and cast your vote early. The faster we determine this build is good or if there is an issue the better. Thanks in advance for all your help in this effort. This vote will conclude at 0400 ET on Dec 21 (unless all you PMC members vote quicker :) If a respin is is necessary this vote will be suspended and a new one will start. Matt Hogstrom [EMAIL PROTECTED]
Re: [VOTE] 2.0-M1 Release
+1 I tried all 4 assemblies and deployed a simple web application to each. All went as expected. As already mentioned, there are some info messages (more with tomcat than jetty). Joe Matt Hogstrom wrote: All, I have prepared 2.0-M1 for release. Of course all the hard work was done by the lot of y'all :) I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied with the results. All modes of operation functioned well (SLSB, Direct, EJB and JPA). I toned all the logs down to error to not overwhelm the users with lots of diagnostic output (they can always turn it up later if they want.) The uploads are taking forever so you'll see some piece parts trickle in. For the review I expect you'll want to focus on http:// people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies for your review and testing. I've included both Tomcat and Jetty as well as the minimal and j5ee assemblies. The source code is also there. Note that if you are planning on building you'll need to obtain the openejb-2.2-incubating jars to your local repo. The easiest way to do this is to modify the root pom and add a repository for David's home directory at http://people.apache.org/~dblevins/stage/. For SNAPSHOTs of certain plugins I have resolved these files to the most recent SNAPSHOT date / timestamp. I'm pulling a copy of these and will be putting them into our SVN for folks who may want to build in the future. I'm not too concerned about repeatability as this Milestone will be superseded at the end of January with the next version. The other MAven artifacts will be trickling onto people across my horribly slow home pipe and dropped into http://people.apache.org/ ~hogstrom/stage over the next few hours. Please review and cast your vote early. The faster we determine this build is good or if there is an issue the better. Thanks in advance for all your help in this effort. This vote will conclude at 0400 ET on Dec 21 (unless all you PMC members vote quicker :) If a respin is is necessary this vote will be suspended and a new one will start. Matt Hogstrom [EMAIL PROTECTED]
Re: [VOTE] 2.0-M1 Release
geronimo.log is empty on both Jetty and Tomcat Cheers! Hernan Jeff Genender wrote: Which log is empty? anita kulshreshtha wrote: I tried tomcat6-jee5: -- The log file is empty. -- Is it necessary to change all the log levels from WARN to ERROR (rev 488143)? Thanks Anita --- Matt Hogstrom [EMAIL PROTECTED] wrote: All, I have prepared 2.0-M1 for release. Of course all the hard work was done by the lot of y'all :) I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied with the results. All modes of operation functioned well (SLSB, Direct, EJB and JPA). I toned all the logs down to error to not overwhelm the users with lots of diagnostic output (they can always turn it up later if they want.) The uploads are taking forever so you'll see some piece parts trickle in. For the review I expect you'll want to focus on http:// people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies for your review and testing. I've included both Tomcat and Jetty as well as the minimal and j5ee assemblies. The source code is also there. Note that if you are planning on building you'll need to obtain the openejb-2.2-incubating jars to your local repo. The easiest way to do this is to modify the root pom and add a repository for David's home directory at http://people.apache.org/~dblevins/stage/. For SNAPSHOTs of certain plugins I have resolved these files to the most recent SNAPSHOT date / timestamp. I'm pulling a copy of these and will be putting them into our SVN for folks who may want to build in the future. I'm not too concerned about repeatability as this Milestone will be superseded at the end of January with the next version. The other MAven artifacts will be trickling onto people across my horribly slow home pipe and dropped into http://people.apache.org/ ~hogstrom/stage over the next few hours. Please review and cast your vote early. The faster we determine this build is good or if there is an issue the better. Thanks in advance for all your help in this effort. This vote will conclude at 0400 ET on Dec 21 (unless all you PMC members vote quicker :) If a respin is is necessary this vote will be suspended and a new one will start. Matt Hogstrom [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [VOTE] 2.0-M1 Release
If you want more extensive debugging you can crank the log level up. for M2 I want to look at the log in a bit more detail as a user I would expect some server started messages and the like and I think we need to tweak the server to get that level of usability. The log does work which is one reason I lowered the log levels :) On Dec 18, 2006, at 10:21 AM, anita kulshreshtha wrote: I tried tomcat6-jee5: -- The log file is empty. -- Is it necessary to change all the log levels from WARN to ERROR (rev 488143)? Thanks Anita --- Matt Hogstrom [EMAIL PROTECTED] wrote: All, I have prepared 2.0-M1 for release. Of course all the hard work was done by the lot of y'all :) I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied with the results. All modes of operation functioned well (SLSB, Direct, EJB and JPA). I toned all the logs down to error to not overwhelm the users with lots of diagnostic output (they can always turn it up later if they want.) The uploads are taking forever so you'll see some piece parts trickle in. For the review I expect you'll want to focus on http:// people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies for your review and testing. I've included both Tomcat and Jetty as well as the minimal and j5ee assemblies. The source code is also there. Note that if you are planning on building you'll need to obtain the openejb-2.2-incubating jars to your local repo. The easiest way to do this is to modify the root pom and add a repository for David's home directory at http://people.apache.org/~dblevins/stage/. For SNAPSHOTs of certain plugins I have resolved these files to the most recent SNAPSHOT date / timestamp. I'm pulling a copy of these and will be putting them into our SVN for folks who may want to build in the future. I'm not too concerned about repeatability as this Milestone will be superseded at the end of January with the next version. The other MAven artifacts will be trickling onto people across my horribly slow home pipe and dropped into http://people.apache.org/ ~hogstrom/stage over the next few hours. Please review and cast your vote early. The faster we determine this build is good or if there is an issue the better. Thanks in advance for all your help in this effort. This vote will conclude at 0400 ET on Dec 21 (unless all you PMC members vote quicker :) If a respin is is necessary this vote will be suspended and a new one will start. Matt Hogstrom [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com Matt Hogstrom [EMAIL PROTECTED]
[DISCUSS] 2.0-M1 Release
All, I opened this thread for general comments and questions about the release. Let's have the discussions here and leave the vote thread for +/- voting only so it will be easier to process Thanks. Matt Hogstrom [EMAIL PROTECTED]
Re: svn commit: r488106 - /geronimo/server/trunk/modules/geronimo-naming/src/main/java/org/apache/geronimo/gjndi/binding/GBeanBinding.java
It would be nice if this was included in 2.0-M1. It will allow clean shutdown of the server without changing all the log levels from WARN to ERROR. Thanks Anita --- [EMAIL PROTECTED] wrote: Author: dims Date: Sun Dec 17 19:18:42 2006 New Revision: 488106 URL: http://svn.apache.org/viewvc?view=revrev=488106 Log: prevent NPE if the hashmap is empty Modified: geronimo/server/trunk/modules/geronimo-naming/src/main/java/org/apache/geronimo/gjndi/binding/GBeanBinding.java Modified: geronimo/server/trunk/modules/geronimo-naming/src/main/java/org/apache/geronimo/gjndi/binding/GBeanBinding.java URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/geronimo-naming/src/main/java/org/apache/geronimo/gjndi/binding/GBeanBinding.java?view=diffrev=488106r1=488105r2=488106 == --- geronimo/server/trunk/modules/geronimo-naming/src/main/java/org/apache/geronimo/gjndi/binding/GBeanBinding.java (original) +++ geronimo/server/trunk/modules/geronimo-naming/src/main/java/org/apache/geronimo/gjndi/binding/GBeanBinding.java Sun Dec 17 19:18:42 2006 @@ -156,12 +156,13 @@ * @param abstractName the abstract name of the gbean to unbind */ protected synchronized void removeBinding(AbstractName abstractName) { -if (first(bindings).getKey().equals(abstractName)) { +Map.Entry entry = first(bindings); +if (entry != null entry.getKey().equals(abstractName)) { Object oldValue = bindings.remove(abstractName); -Map.Entry newEntry = first(bindings); -if (newEntry != null) { -Object newAbstractName = newEntry.getValue(); -Object newValue = newEntry.getValue(); +entry = first(bindings); +if (entry != null) { +Object newAbstractName = entry.getValue(); +Object newValue = entry.getValue(); try { context.rebind(name, newValue); } catch (NamingException e) { __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [DISCUSS] 2.0-M1 Release
On Dec 18, 2006, at 9:49 AM, Kevan Miller wrote: There's a source file missing a license header. Not sure if it was added after my last scan of the code or if I just missed it. Anyway, it needs to be fixed. All servers start. I'm getting some [info] log messages sent to STDOUT, but I don't think that should hold up an M1 release. I've scanned the jetty java ee5 binary -- looks good. Working on tomcat and some more sanity checks. Other that the license header, things look good... --kevan Kevan, If you'll add it to tags I'll re-spin that module. This doesn't affect the server binaries so updating and spinning that module should be fine. I'd say thanks for finding this but I now officially hate your keen eye :) On the positive note...we are doing way better than we ever have previously in terms of legal clearance so thanks to you and all the others making this easier. I think Jason's legal plugin plus the RAT tool, plus all the paranoid eyes are helping :)
Re: [VOTE] 2.0-M1 Release
+1 Best wishes, Paul On 12/18/06, Matt Hogstrom [EMAIL PROTECTED] wrote: All, I have prepared 2.0-M1 for release. Of course all the hard work was done by the lot of y'all :) I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied with the results. All modes of operation functioned well (SLSB, Direct, EJB and JPA). I toned all the logs down to error to not overwhelm the users with lots of diagnostic output (they can always turn it up later if they want.) The uploads are taking forever so you'll see some piece parts trickle in. For the review I expect you'll want to focus on http:// people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies for your review and testing. I've included both Tomcat and Jetty as well as the minimal and j5ee assemblies. The source code is also there. Note that if you are planning on building you'll need to obtain the openejb-2.2-incubating jars to your local repo. The easiest way to do this is to modify the root pom and add a repository for David's home directory at http://people.apache.org/~dblevins/stage/. For SNAPSHOTs of certain plugins I have resolved these files to the most recent SNAPSHOT date / timestamp. I'm pulling a copy of these and will be putting them into our SVN for folks who may want to build in the future. I'm not too concerned about repeatability as this Milestone will be superseded at the end of January with the next version. The other MAven artifacts will be trickling onto people across my horribly slow home pipe and dropped into http://people.apache.org/ ~hogstrom/stage over the next few hours. Please review and cast your vote early. The faster we determine this build is good or if there is an issue the better. Thanks in advance for all your help in this effort. This vote will conclude at 0400 ET on Dec 21 (unless all you PMC members vote quicker :) If a respin is is necessary this vote will be suspended and a new one will start. Matt Hogstrom [EMAIL PROTECTED]
[jira] Created: (XBEAN-66) Schemas generated by xbean are sometimes invalid (xs:any conflict)
Schemas generated by xbean are sometimes invalid (xs:any conflict) -- Key: XBEAN-66 URL: http://issues.apache.org/jira/browse/XBEAN-66 Project: XBean Issue Type: Bug Components: maven-plugin, spring Affects Versions: 2.7 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 2.8 -- 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] Closed: (XBEAN-66) Schemas generated by xbean are sometimes invalid (xs:any conflict)
[ http://issues.apache.org/jira/browse/XBEAN-66?page=all ] Guillaume Nodet closed XBEAN-66. Resolution: Fixed Fixed as part of XBEAN-65 Schemas generated by xbean are sometimes invalid (xs:any conflict) -- Key: XBEAN-66 URL: http://issues.apache.org/jira/browse/XBEAN-66 Project: XBean Issue Type: Bug Components: maven-plugin, spring Affects Versions: 2.7 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 2.8 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (XBEAN-67) When an xbean tag is mispelled, a CNFE is thrown instead of a more explicit exception
When an xbean tag is mispelled, a CNFE is thrown instead of a more explicit exception - Key: XBEAN-67 URL: http://issues.apache.org/jira/browse/XBEAN-67 Project: XBean Issue Type: Bug Components: spring Affects Versions: 2.7 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 2.8 -- 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] Closed: (XBEAN-67) When an xbean tag is mispelled, a CNFE is thrown instead of a more explicit exception
[ http://issues.apache.org/jira/browse/XBEAN-67?page=all ] Guillaume Nodet closed XBEAN-67. Resolution: Fixed Author: gnodet Date: Mon Dec 18 07:57:04 2006 New Revision: 488309 URL: http://svn.apache.org/viewvc?view=revrev=488309 Log: XBEAN-67: When an xbean tag is mispelled, a CNFE is thrown instead of a more explicit exception Modified: geronimo/xbean/trunk/xbean-spring-common/src/main/java/org/apache/xbean/spring/context/impl/MappingMetaData.java When an xbean tag is mispelled, a CNFE is thrown instead of a more explicit exception - Key: XBEAN-67 URL: http://issues.apache.org/jira/browse/XBEAN-67 Project: XBean Issue Type: Bug Components: spring Affects Versions: 2.7 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 2.8 -- 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
Patches in RTC (Geronimo - 2006-12-18)
Geronimo - Monday, December 18, 2006 5 Patches in RTC [GERONIMO-2638] Improve ModuleBuilder and ConfigurationBuilder interfaces to replace use of JarFile - Assignee: Sachin Patel - Reporter: Sachin Patel - Created: Thu Dec 07 23:41:31 GMT 2006 - Updated: Mon Dec 11 16:21:45 GMT 2006 - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMO-2638 [GERONIMO-2485] PersistenceUnitGBean needs a NamespaceDrivenDeployer - Assignee: David Jencks - Reporter: David Jencks - Created: Wed Oct 11 21:23:29 GMT 2006 - Updated: Thu Dec 07 20:28:27 GMT 2006 - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMO-2485 [GERONIMO-1277] Change group-id to org.apache.geronimo - Assignee: Jason Dillon - Reporter: Dain Sundstrom - Created: Sat Dec 03 10:55:12 GMT 2005 - Updated: Tue Nov 07 23:57:44 GMT 2006 - Votes: 3 1 David Jencks 2 Donald Woods 3 Vamsavardhana Reddy - http://issues.apache.org/jira/browse/GERONIMO-1277 [GERONIMO-2015] Let's replace JKS to PKCS12 key store type - Assignee: Unassigned - Reporter: Nikolay Chugunov - Created: Fri May 12 21:54:17 GMT 2006 - Updated: Wed Dec 06 06:57:11 GMT 2006 - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMO-2015 [GERONIMODEVTOOLS-112] Loading deployment plan editor on empty file should auto-create plan - Assignee: Sachin Patel - Reporter: Sachin Patel - Created: Wed Oct 11 21:45:57 GMT 2006 - Updated: Wed Dec 06 14:11:15 GMT 2006 - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-112 NOTE: This email is generated and does not constitute and offical vote or vote result. All official voting is done on the dev list. If you do not see your issue here, click the Begin RTC Review link under the Available Workflow Actions of the JIRA page. If you do not see your vote here, click the Vote link under the Operations section of the JIRA page. *** ALL COMMUNITY MEMBERS ARE ENCOURAGED TO VOTE *** Template: http://svn.apache.org/repos/asf/geronimo/gbuild/jirareports/patchesInRtc.vm
[jira] Created: (XBEAN-68) Upgrade to QDox 1.6.1 for better java 5 support
Upgrade to QDox 1.6.1 for better java 5 support Key: XBEAN-68 URL: http://issues.apache.org/jira/browse/XBEAN-68 Project: XBean Issue Type: Improvement Components: maven-plugin, spring Affects Versions: 2.7 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 2.8 -- 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] Closed: (XBEAN-68) Upgrade to QDox 1.6.1 for better java 5 support
[ http://issues.apache.org/jira/browse/XBEAN-68?page=all ] Guillaume Nodet closed XBEAN-68. Resolution: Fixed Author: gnodet Date: Mon Dec 18 08:01:55 2006 New Revision: 488310 URL: http://svn.apache.org/viewvc?view=revrev=488310 Log: Remove exclusions which cause spring to not be included in the build :( Modified: geronimo/xbean/trunk/xbean-spring-v2/pom.xml Upgrade to QDox 1.6.1 for better java 5 support --- Key: XBEAN-68 URL: http://issues.apache.org/jira/browse/XBEAN-68 Project: XBean Issue Type: Improvement Components: maven-plugin, spring Affects Versions: 2.7 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 2.8 -- 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] Commented: (XBEAN-68) Upgrade to QDox 1.6.1 for better java 5 support
[ http://issues.apache.org/jira/browse/XBEAN-68?page=comments#action_12459397 ] Guillaume Nodet commented on XBEAN-68: -- Oops, wrong revision. The following is the correct one: Author: gnodet Date: Mon Dec 18 08:13:55 2006 New Revision: 488321 URL: http://svn.apache.org/viewvc?view=revrev=488321 Log: XBEAN-68: Upgrade to QDox 1.6.1 Modified: geronimo/xbean/trunk/pom.xml Upgrade to QDox 1.6.1 for better java 5 support --- Key: XBEAN-68 URL: http://issues.apache.org/jira/browse/XBEAN-68 Project: XBean Issue Type: Improvement Components: maven-plugin, spring Affects Versions: 2.7 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 2.8 -- 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: [VOTE] 2.0-M1 Release
The geronimo.log is empty. It does not contain system information. Thanks Anita --- Jeff Genender [EMAIL PROTECTED] wrote: Which log is empty? anita kulshreshtha wrote: I tried tomcat6-jee5: -- The log file is empty. -- Is it necessary to change all the log levels from WARN to ERROR (rev 488143)? Thanks Anita --- Matt Hogstrom [EMAIL PROTECTED] wrote: All, I have prepared 2.0-M1 for release. Of course all the hard work was done by the lot of y'all :) I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied with the results. All modes of operation functioned well (SLSB, Direct, EJB and JPA). I toned all the logs down to error to not overwhelm the users with lots of diagnostic output (they can always turn it up later if they want.) The uploads are taking forever so you'll see some piece parts trickle in. For the review I expect you'll want to focus on http:// people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies for your review and testing. I've included both Tomcat and Jetty as well as the minimal and j5ee assemblies. The source code is also there. Note that if you are planning on building you'll need to obtain the openejb-2.2-incubating jars to your local repo. The easiest way to do this is to modify the root pom and add a repository for David's home directory at http://people.apache.org/~dblevins/stage/. For SNAPSHOTs of certain plugins I have resolved these files to the most recent SNAPSHOT date / timestamp. I'm pulling a copy of these and will be putting them into our SVN for folks who may want to build in the future. I'm not too concerned about repeatability as this Milestone will be superseded at the end of January with the next version. The other MAven artifacts will be trickling onto people across my horribly slow home pipe and dropped into http://people.apache.org/ ~hogstrom/stage over the next few hours. Please review and cast your vote early. The faster we determine this build is good or if there is an issue the better. Thanks in advance for all your help in this effort. This vote will conclude at 0400 ET on Dec 21 (unless all you PMC members vote quicker :) If a respin is is necessary this vote will be suspended and a new one will start. Matt Hogstrom [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Created: (AMQ-1101) Problem when compiling vs2005-activemq project with unsafe method call
Problem when compiling vs2005-activemq project with unsafe method call -- Key: AMQ-1101 URL: https://issues.apache.org/activemq/browse/AMQ-1101 Project: ActiveMQ Issue Type: Bug Components: NMS (C# client) Affects Versions: 4.0 Environment: Windows XP, SP2 Reporter: Pascal ST-LAURENT In vs2005-activemq project, src/main/csharp/ActiveMQ/Commands/ActiveMQTextMessage.cs file, Text property. Must use Marchal.SizeOf() method instead of sizeof(). In this case, we don't need to specified to build the project with unsafe directive and uses only managed code. -- 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
[VOTE] Release XBean 2.8
I'm starting a vote to release XBean 2.8. There has not been much changes since 2.7, but a few bugs fixed, and the addition of the xbean-finder module. Anyway, the bugs are important enough to deserver a new release (the generated schemas can not be validated). [ ] +1 Start xbean 2.8 release process [ ] +/- 0 [ ] -1 Don't release xbean 2.8 now Here's my +1. -- Cheers, Guillaume Nodet
Re: [VOTE] Release XBean 2.8
+1 On 12/18/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I'm starting a vote to release XBean 2.8. There has not been much changes since 2.7, but a few bugs fixed, and the addition of the xbean-finder module. Anyway, the bugs are important enough to deserver a new release (the generated schemas can not be validated). [ ] +1 Start xbean 2.8 release process [ ] +/- 0 [ ] -1 Don't release xbean 2.8 now Here's my +1. -- Cheers, Guillaume Nodet -- James --- http://radio.weblogs.com/0112098/
Re: [DISCUSS] 2.0-M1 Release
anita, If I turn logging up to INFO in var/log/server-log4j.properties I get information in the log. On Dec 18, 2006, at 10:37 AM, Matt Hogstrom wrote: All, I opened this thread for general comments and questions about the release. Let's have the discussions here and leave the vote thread for +/- voting only so it will be easier to process Thanks. Matt Hogstrom [EMAIL PROTECTED] Matt Hogstrom [EMAIL PROTECTED]
[jira] Created: (GERONIMO-2671) Streaming API for XML and JAXB integration
Streaming API for XML and JAXB integration -- Key: GERONIMO-2671 URL: http://issues.apache.org/jira/browse/GERONIMO-2671 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Affects Versions: 2.0 Reporter: Jarek Gawor Attachments: stax-jaxb.patch The attached patch integrates the Streaming API for XML and JAXB with Geronimo. Any web application (JSP, servlet) or EJB will be able to use the StAX or JAXB API. The patch also includes basic tests to verify that the streaming and JAXB API can be used within the web or ejb container. The woodstox xml processor is used as the implementation behind the streaming API. The Sun's JAXB RI is used for JAXB support. Since this is my first attempt at such integration, please let me know if there is a better way of doing things, if i missed something, etc. This patch supersedes the patch in https://issues.apache.org/jira/browse/GERONIMO-2667. -- 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] Updated: (GERONIMO-2671) Streaming API for XML and JAXB integration
[ http://issues.apache.org/jira/browse/GERONIMO-2671?page=all ] Jarek Gawor updated GERONIMO-2671: -- Attachment: stax-jaxb.patch Streaming API for XML and JAXB integration -- Key: GERONIMO-2671 URL: http://issues.apache.org/jira/browse/GERONIMO-2671 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Affects Versions: 2.0 Reporter: Jarek Gawor Attachments: stax-jaxb.patch The attached patch integrates the Streaming API for XML and JAXB with Geronimo. Any web application (JSP, servlet) or EJB will be able to use the StAX or JAXB API. The patch also includes basic tests to verify that the streaming and JAXB API can be used within the web or ejb container. The woodstox xml processor is used as the implementation behind the streaming API. The Sun's JAXB RI is used for JAXB support. Since this is my first attempt at such integration, please let me know if there is a better way of doing things, if i missed something, etc. This patch supersedes the patch in https://issues.apache.org/jira/browse/GERONIMO-2667. -- 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] Closed: (GERONIMO-2667) Streaming API for XML integration
[ http://issues.apache.org/jira/browse/GERONIMO-2667?page=all ] Jarek Gawor closed GERONIMO-2667. - Resolution: Duplicate https://issues.apache.org/jira/browse/GERONIMO-2671 contains updated patch with JAXB support. Streaming API for XML integration - Key: GERONIMO-2667 URL: http://issues.apache.org/jira/browse/GERONIMO-2667 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: general Affects Versions: 2.0 Reporter: Jarek Gawor Attachments: stax.patch The attached patch integrates the Streaming API for XML with Geronimo. Any web application (JSP, servlet) or EJB will be able to use the streaming API. The patch also includes basic tests to verify that the streaming API can be used within the web or ejb container. The woodstox xml processor is used as the implementation behind the API. Since this is my first attempt at such integration, please let me know if there is a better way of doing things, if i missed something, etc. -- 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: [VOTE] Release XBean 2.8
+1 On 12/18/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I'm starting a vote to release XBean 2.8. There has not been much changes since 2.7, but a few bugs fixed, and the addition of the xbean-finder module. Anyway, the bugs are important enough to deserver a new release (the generated schemas can not be validated). [ ] +1 Start xbean 2.8 release process [ ] +/- 0 [ ] -1 Don't release xbean 2.8 now Here's my +1. -- Cheers, Guillaume Nodet -- Regards, Hiram Blog: http://hiramchirino.com
Re: [VOTE] 2.0-M1 Release
Found no show-stopping issues for a milestone. +1 Cheers Prasad On 12/18/06, Matt Hogstrom [EMAIL PROTECTED] wrote: All, I have prepared 2.0-M1 for release. Of course all the hard work was done by the lot of y'all :) I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied with the results. All modes of operation functioned well (SLSB, Direct, EJB and JPA). I toned all the logs down to error to not overwhelm the users with lots of diagnostic output (they can always turn it up later if they want.) The uploads are taking forever so you'll see some piece parts trickle in. For the review I expect you'll want to focus on http:// people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies for your review and testing. I've included both Tomcat and Jetty as well as the minimal and j5ee assemblies. The source code is also there. Note that if you are planning on building you'll need to obtain the openejb-2.2-incubating jars to your local repo. The easiest way to do this is to modify the root pom and add a repository for David's home directory at http://people.apache.org/~dblevins/stage/. For SNAPSHOTs of certain plugins I have resolved these files to the most recent SNAPSHOT date / timestamp. I'm pulling a copy of these and will be putting them into our SVN for folks who may want to build in the future. I'm not too concerned about repeatability as this Milestone will be superseded at the end of January with the next version. The other MAven artifacts will be trickling onto people across my horribly slow home pipe and dropped into http://people.apache.org/ ~hogstrom/stage over the next few hours. Please review and cast your vote early. The faster we determine this build is good or if there is an issue the better. Thanks in advance for all your help in this effort. This vote will conclude at 0400 ET on Dec 21 (unless all you PMC members vote quicker :) If a respin is is necessary this vote will be suspended and a new one will start. Matt Hogstrom [EMAIL PROTECTED]
Re: [DISCUSS] 2.0-M1 Release
On Dec 18, 2006, at 10:46 AM, Matt Hogstrom wrote: On Dec 18, 2006, at 9:49 AM, Kevan Miller wrote: There's a source file missing a license header. Not sure if it was added after my last scan of the code or if I just missed it. Anyway, it needs to be fixed. All servers start. I'm getting some [info] log messages sent to STDOUT, but I don't think that should hold up an M1 release. I've scanned the jetty java ee5 binary -- looks good. Working on tomcat and some more sanity checks. Other that the license header, things look good... --kevan Kevan, If you'll add it to tags I'll re-spin that module. This doesn't affect the server binaries so updating and spinning that module should be fine. I'd say thanks for finding this but I now officially hate your keen eye :) On the positive note...we are doing way better than we ever have previously in terms of legal clearance so thanks to you and all the others making this easier. I think Jason's legal plugin plus the RAT tool, plus all the paranoid eyes are helping :) Ok. Fixed with 488326. --kevan
Re: [DISCUSS] 2.0-M1 Release
Matt, I had to change the following lines in server-log4j.properties to get system information logged: log4j.rootLogger=INFO, CONSOLE, FILE log4j.appender.FILE.Threshold=INFO In addition I see the following stack trace during shutdown. A fix for this is already available in rev 488106: http://www.nabble.com/Re%3A-svn-commit%3A-r488106geronimo-server-trunk-modules-geronimo-naming-src-main-java-org-apache-geronimo-gjndi-binding-GBeanBinding.java-p7930963.html Is it a good idea to supress all warning messages like this even for a M1 release ? Thanks Anita 12:39:24,552 WARN [BasicLifecycleMonitor] Exception occured while notifying listener java.lang.NullPointerException at org.apache.geronimo.gjndi.binding.GBeanBinding.removeBinding(GBeanBinding.java:159) at org.apache.geronimo.gjndi.binding.GBeanBinding$GBeanLifecycleListener.stopped(GBeanBinding.java:108) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireStoppedEvent(BasicLifecycleMonitor.java:197) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$500(BasicLifecycleMonitor.java:41) at ... --- Matt Hogstrom [EMAIL PROTECTED] wrote: anita, If I turn logging up to INFO in var/log/server-log4j.properties I get information in the log. On Dec 18, 2006, at 10:37 AM, Matt Hogstrom wrote: All, I opened this thread for general comments and questions about the release. Let's have the discussions here and leave the vote thread for +/- voting only so it will be easier to process Thanks. Matt Hogstrom [EMAIL PROTECTED] Matt Hogstrom [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [DISCUSS] 2.0-M1 Release
I think its a preference. At this point I think M1 is what it is and we'll update the Wiki with known issues. On Dec 18, 2006, at 12:49 PM, anita kulshreshtha wrote: Matt, I had to change the following lines in server-log4j.properties to get system information logged: log4j.rootLogger=INFO, CONSOLE, FILE log4j.appender.FILE.Threshold=INFO In addition I see the following stack trace during shutdown. A fix for this is already available in rev 488106: http://www.nabble.com/Re%3A-svn-commit%3A-r488106geronimo- server-trunk-modules-geronimo-naming-src-main-java-org-apache- geronimo-gjndi-binding-GBeanBinding.java-p7930963.html Is it a good idea to supress all warning messages like this even for a M1 release ? Thanks Anita 12:39:24,552 WARN [BasicLifecycleMonitor] Exception occured while notifying listener java.lang.NullPointerException at org.apache.geronimo.gjndi.binding.GBeanBinding.removeBinding (GBeanBinding.java:159) at org.apache.geronimo.gjndi.binding.GBeanBinding $GBeanLifecycleListener.stopped(GBeanBinding.java:108) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireStoppedEven t(BasicLifecycleMonitor.java:197) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$500 (BasicLifecycleMonitor.java:41) at ... --- Matt Hogstrom [EMAIL PROTECTED] wrote: anita, If I turn logging up to INFO in var/log/server-log4j.properties I get information in the log. On Dec 18, 2006, at 10:37 AM, Matt Hogstrom wrote: All, I opened this thread for general comments and questions about the release. Let's have the discussions here and leave the vote thread for +/- voting only so it will be easier to process Thanks. Matt Hogstrom [EMAIL PROTECTED] Matt Hogstrom [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com Matt Hogstrom [EMAIL PROTECTED]
Re: [DISCUSS] 2.0-M1 Release
Thanks for finding this Kevan. I reposted the source, there are no modules. Updated source is in: http://people.apache.org/~hogstrom/2.0-M1/ Thanks for finding this. On Dec 18, 2006, at 12:36 PM, Kevan Miller wrote: On Dec 18, 2006, at 10:46 AM, Matt Hogstrom wrote: On Dec 18, 2006, at 9:49 AM, Kevan Miller wrote: There's a source file missing a license header. Not sure if it was added after my last scan of the code or if I just missed it. Anyway, it needs to be fixed. All servers start. I'm getting some [info] log messages sent to STDOUT, but I don't think that should hold up an M1 release. I've scanned the jetty java ee5 binary -- looks good. Working on tomcat and some more sanity checks. Other that the license header, things look good... --kevan Kevan, If you'll add it to tags I'll re-spin that module. This doesn't affect the server binaries so updating and spinning that module should be fine. I'd say thanks for finding this but I now officially hate your keen eye :) On the positive note...we are doing way better than we ever have previously in terms of legal clearance so thanks to you and all the others making this easier. I think Jason's legal plugin plus the RAT tool, plus all the paranoid eyes are helping :) Ok. Fixed with 488326. --kevan Matt Hogstrom [EMAIL PROTECTED]
Re: [VOTE] Release XBean 2.8
On Dec 18, 2006, at 11:25 AM, Guillaume Nodet wrote: I'm starting a vote to release XBean 2.8. There has not been much changes since 2.7, but a few bugs fixed, and the addition of the xbean-finder module. Anyway, the bugs are important enough to deserver a new release (the generated schemas can not be validated). [ ] +1 Start xbean 2.8 release process [ ] +/- 0 [ ] -1 Don't release xbean 2.8 now Here's my +1. Not sure what you mean by release process. But here are the issues which look like they would block a release: 1. NOTICE files do not conform to current ASF standards 2. The following files either do not contain a valid license header (not all files will require one, but many of these need one) or have an out-of-date license header (all need to be updated). ==resource (./xbean-classloader/src/test-data/resourceFinderTest/jar1/ resource) ==resource (./xbean-classloader/src/test-data/resourceFinderTest/jar2/ resource) ==package-info.java (./xbean-finder/src/test/java/org/acme/foo/ package-info.java) ==java.io.InputStream (./xbean-finder/src/test/resources/META-INF/ java.io.InputStream) ==java.io.OutputStream (./xbean-finder/src/test/resources/META-INF/ java.io.OutputStream) ==java.io.Serializable (./xbean-finder/src/test/resources/META-INF/ java.io.Serializable) ==one (./xbean-finder/src/test/resources/META-INF/externalizables/one) ==three (./xbean-finder/src/test/resources/META-INF/externalizables/ three) ==two (./xbean-finder/src/test/resources/META-INF/externalizables/two) ==bar (./xbean-finder/src/test/resources/META-INF/ java.net.URLStreamHandler/bar) ==baz (./xbean-finder/src/test/resources/META-INF/ java.net.URLStreamHandler/baz) ==foo (./xbean-finder/src/test/resources/META-INF/ java.net.URLStreamHandler/foo) ==kernel (./xbean-finder/src/test/resources/META-INF/ javax.naming.spi.ObjectFactory/kernel) ==ldap (./xbean-finder/src/test/resources/META-INF/ javax.naming.spi.ObjectFactory/ldap) ==ishtar.properties (./xbean-finder/src/test/resources/META-INF/ movies/ishtar.properties) ==kingkong.properties (./xbean-finder/src/test/resources/META-INF/ movies/kingkong.properties) ==serentity.properties (./xbean-finder/src/test/resources/META-INF/ movies/serentity.properties) ==one (./xbean-finder/src/test/resources/META-INF/serializables/one) ==three (./xbean-finder/src/test/resources/META-INF/serializables/three) ==two (./xbean-finder/src/test/resources/META-INF/serializables/two) ==familyguy.properties (./xbean-finder/src/test/resources/META-INF/ tvshows/familyguy.properties) ==simpsons.properties (./xbean-finder/src/test/resources/META-INF/ tvshows/simpsons.properties) ==package.html (./xbean-kernel/src/main/java/org/apache/xbean/kernel/ package.html) ==package.html (./xbean-kernel/src/main/java/org/apache/xbean/kernel/ standard/package.html) ==pom.xml (./xbean-naming/pom.xml) ==xbean-naming/src/main/java/org/apache/xbean/naming/context/ AbstractContext.java ==xbean-naming/src/main/java/org/apache/xbean/naming/context/ AbstractFederatedContext.java ==xbean-naming/src/main/java/org/apache/xbean/naming/context/ ContextAccess.java ==xbean-naming/src/main/java/org/apache/xbean/naming/context/ ContextAccessControlList.java ==xbean-naming/src/main/java/org/apache/xbean/naming/context/ ContextFederation.java ==xbean-naming/src/main/java/org/apache/xbean/naming/context/ ContextFlyweight.java ==xbean-naming/src/main/java/org/apache/xbean/naming/context/ ContextUtil.java ==xbean-naming/src/main/java/org/apache/xbean/naming/context/ ImmutableContext.java ==xbean-naming/src/main/java/org/apache/xbean/naming/context/ NestedContextFactory.java ==xbean-naming/src/main/java/org/apache/xbean/naming/context/ VirtualSubcontext.java ==xbean-naming/src/main/java/org/apache/xbean/naming/context/ WritableContext.java ==xbean-naming/src/main/java/org/apache/xbean/naming/global/ GlobalContextManager.java ==xbean-naming/src/main/java/org/apache/xbean/naming/java/ javaURLContextFactory.java ==xbean-naming/src/main/java/org/apache/xbean/naming/reference/ CachingReference.java ==xbean-naming/src/main/java/org/apache/xbean/naming/reference/ SimpleReference.java ==xbean-naming/src/test/java/org/apache/xbean/naming/context/ AbstractContextTest.java ==xbean-naming/src/test/java/org/apache/xbean/naming/context/ ContextAccessControlListTest.java ==xbean-naming/src/test/java/org/apache/xbean/naming/context/ FederationTest.java ==xbean-naming/src/test/java/org/apache/xbean/naming/context/ ImmutableContextTest.java ==xbean-naming/src/test/java/org/apache/xbean/naming/context/ UnmodifiableContextTest.java ==xbean-naming/src/test/java/org/apache/xbean/naming/context/ WritableContextTest.java ==xbean-naming/src/test/java/org/apache/xbean/naming/global/ GlobalContextManagerTest.java ==spring-beans.xsd (./xbean-spring-common/src/main/resources/org/ apache/xbean/spring/spring-beans.xsd) ==pom.xml (./xbean-spring-itests/2.0/pom.xml) ==pom.xml (./xbean-spring-itests/2.0-rc3/pom.xml)
Re: [VOTE] 2.0-M1 Release
With the addition of a license header to geronimo/server/tags/2.0-M1/ testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/ resources/META-INF/ejb-jar.xml, I'm +1. --kevan
Re: [VOTE] Release XBean 2.8
On 12/18/06, Kevan Miller [EMAIL PROTECTED] wrote: On Dec 18, 2006, at 11:25 AM, Guillaume Nodet wrote: I'm starting a vote to release XBean 2.8. There has not been much changes since 2.7, but a few bugs fixed, and the addition of the xbean-finder module. Anyway, the bugs are important enough to deserver a new release (the generated schemas can not be validated). [ ] +1 Start xbean 2.8 release process [ ] +/- 0 [ ] -1 Don't release xbean 2.8 now Here's my +1. Not sure what you mean by release process. Running mvn release:prepare release:perform ;) But here are the issues which look like they would block a release: 1. NOTICE files do not conform to current ASF standards What do you mean exactly ? They have the same content that the ones I've always seen. Could you point me to a better template for these ? 2. The following files either do not contain a valid license header (not all files will require one, but many of these need one) or have an out-of-date license header (all need to be updated). Thanks. I'll fix these asap. You run rat for that, right ? ==resource (./xbean-classloader/src/test-data/resourceFinderTest/jar1/ resource) ==resource (./xbean-classloader/src/test-data/resourceFinderTest/jar2/ resource) ==package-info.java (./xbean-finder/src/test/java/org/acme/foo/ package-info.java) ==java.io.InputStream (./xbean-finder/src/test/resources/META-INF/ java.io.InputStream) ==java.io.OutputStream (./xbean-finder/src/test/resources/META-INF/ java.io.OutputStream) ==java.io.Serializable (./xbean-finder/src/test/resources/META-INF/ java.io.Serializable) ==one (./xbean-finder/src/test/resources/META-INF/externalizables/one) ==three (./xbean-finder/src/test/resources/META-INF/externalizables/ three) ==two (./xbean-finder/src/test/resources/META-INF/externalizables/two) ==bar (./xbean-finder/src/test/resources/META-INF/ java.net.URLStreamHandler/bar) ==baz (./xbean-finder/src/test/resources/META-INF/ java.net.URLStreamHandler/baz) ==foo (./xbean-finder/src/test/resources/META-INF/ java.net.URLStreamHandler/foo) ==kernel (./xbean-finder/src/test/resources/META-INF/ javax.naming.spi.ObjectFactory/kernel) ==ldap (./xbean-finder/src/test/resources/META-INF/ javax.naming.spi.ObjectFactory/ldap) ==ishtar.properties (./xbean-finder/src/test/resources/META-INF/ movies/ishtar.properties) ==kingkong.properties (./xbean-finder/src/test/resources/META-INF/ movies/kingkong.properties) ==serentity.properties (./xbean-finder/src/test/resources/META-INF/ movies/serentity.properties) ==one (./xbean-finder/src/test/resources/META-INF/serializables/one) ==three (./xbean-finder/src/test/resources/META-INF/serializables/three) ==two (./xbean-finder/src/test/resources/META-INF/serializables/two) ==familyguy.properties (./xbean-finder/src/test/resources/META-INF/ tvshows/familyguy.properties) ==simpsons.properties (./xbean-finder/src/test/resources/META-INF/ tvshows/simpsons.properties) ==package.html (./xbean-kernel/src/main/java/org/apache/xbean/kernel/ package.html) ==package.html (./xbean-kernel/src/main/java/org/apache/xbean/kernel/ standard/package.html) ==pom.xml (./xbean-naming/pom.xml) ==xbean-naming/src/main/java/org/apache/xbean/naming/context/ AbstractContext.java ==xbean-naming/src/main/java/org/apache/xbean/naming/context/ AbstractFederatedContext.java ==xbean-naming/src/main/java/org/apache/xbean/naming/context/ ContextAccess.java ==xbean-naming/src/main/java/org/apache/xbean/naming/context/ ContextAccessControlList.java ==xbean-naming/src/main/java/org/apache/xbean/naming/context/ ContextFederation.java ==xbean-naming/src/main/java/org/apache/xbean/naming/context/ ContextFlyweight.java ==xbean-naming/src/main/java/org/apache/xbean/naming/context/ ContextUtil.java ==xbean-naming/src/main/java/org/apache/xbean/naming/context/ ImmutableContext.java ==xbean-naming/src/main/java/org/apache/xbean/naming/context/ NestedContextFactory.java ==xbean-naming/src/main/java/org/apache/xbean/naming/context/ VirtualSubcontext.java ==xbean-naming/src/main/java/org/apache/xbean/naming/context/ WritableContext.java ==xbean-naming/src/main/java/org/apache/xbean/naming/global/ GlobalContextManager.java ==xbean-naming/src/main/java/org/apache/xbean/naming/java/ javaURLContextFactory.java ==xbean-naming/src/main/java/org/apache/xbean/naming/reference/ CachingReference.java ==xbean-naming/src/main/java/org/apache/xbean/naming/reference/ SimpleReference.java ==xbean-naming/src/test/java/org/apache/xbean/naming/context/ AbstractContextTest.java ==xbean-naming/src/test/java/org/apache/xbean/naming/context/ ContextAccessControlListTest.java ==xbean-naming/src/test/java/org/apache/xbean/naming/context/ FederationTest.java ==xbean-naming/src/test/java/org/apache/xbean/naming/context/ ImmutableContextTest.java ==xbean-naming/src/test/java/org/apache/xbean/naming/context/ UnmodifiableContextTest.java ==xbean-naming/src/test/java/org/apache/xbean/naming/context/ WritableContextTest.java
Performance Issue
I am facing a really bad performance of ActiveMq on linux box. When running on windows 1000 transactions are taking 2 seconds and when running on Linux same are taking 40 sec. Please if anybody can tell me solution to performance issue. Here is the code i am using to send and receive the message. Thanks in advance public class Requestor{ private Session session; private Destination replyQueue; private MessageProducer requestProducer; private MessageConsumer replyConsumer; Logger logger = null; /** * Constructor */ protected Requestor() { super(); logger = LoggerWrapper.getLogger(this.getClass().getName()); } /** * This method will return the object of Requestor * @param connection, Connection * @param requestQueueName , String * @return Requestor object * @throws JMSException * @throws NamingException */ public static Requestor newRequestor(Connection connection, String requestQueueName)throws JMSException, NamingException { Requestor requestor = new Requestor(); requestor.initialize(connection, requestQueueName); return requestor; } /** * This method will initialize the Producer and Consumer on request and reply queue * @param connection, Connection * @param requestQueueName , String * @throws NamingException * @throws JMSException */ protected void initialize(Connection connection, String requestQueueName)throws NamingException, JMSException { session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE); Destination requestQueue = session.createQueue(requestQueueName); replyQueue = session.createTemporaryQueue(); requestProducer = session.createProducer(requestQueue); requestProducer.setDeliveryMode(DeliveryMode.NON_PERSISTENT); replyConsumer = session.createConsumer(replyQueue); replyConsumer.receive(10); } /** * This method is used to send the message to queue * @param message * @throws JMSException */ public String send(String message) throws JMSException { TextMessage requestMessage = (TextMessage) session.createTextMessage(); requestMessage.setText(message); requestMessage.setJMSReplyTo(replyQueue); requestProducer.send(requestMessage); return receiveSync(); } /** * This method is used to receive the message from the queue * @return String * @throws JMSException */ private String receiveSync() throws JMSException { TextMessage replyMessage = null; Message msg = replyConsumer.receive(); if (msg instanceof TextMessage){ replyMessage = (TextMessage) msg; } logger.debug(receive Sync:+ new Date().getTime()); return replyMessage.getText(); } } public class Replier implements MessageListener { private Session session; Logger logger = null; Engine engineRef = null; Transformer transformerRef = null; MessageConsumer requestConsumer = null; Destination replyDestination = null; private static Map destinationMap = new HashMap(); /** * Constructor * */ protected Replier(){ super(); logger = LoggerWrapper.getLogger(this.getClass().getName()); } /** * This will return the instance of replier * @param connection, Connection * @param requestQueueName * @return * @throws Exception */ public static Replier newReplier(Connection connection,String requestQueueName ,Engine engine,Transformer transformer)throws Exception { Replier replier = new Replier(); replier.initialize(connection, requestQueueName,engine,transformer); return replier; } /** * This method will initilize the consumer on request queue * @param connection * @param requestQueueName * @throws Exception */ protected void initialize(Connection connection, String requestQueueName, Engine engine,Transformer transformer)throws Exception { session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE); // Create the destination (Topic or Queue) //Destination requestQueue =
Re: [VOTE] Release XBean 2.8
On Dec 18, 2006, at 1:31 PM, Guillaume Nodet wrote: On 12/18/06, Kevan Miller [EMAIL PROTECTED] wrote: On Dec 18, 2006, at 11:25 AM, Guillaume Nodet wrote: I'm starting a vote to release XBean 2.8. There has not been much changes since 2.7, but a few bugs fixed, and the addition of the xbean-finder module. Anyway, the bugs are important enough to deserver a new release (the generated schemas can not be validated). [ ] +1 Start xbean 2.8 release process [ ] +/- 0 [ ] -1 Don't release xbean 2.8 now Here's my +1. Not sure what you mean by release process. Running mvn release:prepare release:perform ;) But here are the issues which look like they would block a release: 1. NOTICE files do not conform to current ASF standards What do you mean exactly ? They have the same content that the ones I've always seen. Could you point me to a better template for these ? Hi Guillaume, Yes, they've changed slightly... Source files no longer contain a copyright statement. Copyright is now in the notice file. Here's a pointer to the current standards -- http://www.apache.org/legal/src- headers.html Notice files take the following form: Apache [PRODUCT_NAME] Copyright [] The Apache Software Foundation This product includes software developed at The Apache Software Foundation (http://www.apache.org/). I don't see any external projects being included in xbean binaries. So, it would seem that's the only content that the NOTICE files would require. I took a peak at the generated jar files. Looks like license/notice files are missing from at least the following jar file: xbean-naming Genesis will automatically check for these during a build. Dain (I think) had a one line command to scan for missing notice/license files, but I can't remember how it went... 2. The following files either do not contain a valid license header (not all files will require one, but many of these need one) or have an out-of-date license header (all need to be updated). Thanks. I'll fix these asap. You run rat for that, right ? Yes, but rat doesn't identify old-style license headers. For these, I've found the following grep command to be useful: grep -RL --include=*.java Licensed to the Apache Software Foundation (ASF) * --kevan
Re: Release schedule
Is 4.1 released? If not, what is rlelease plans? -Sileshi Hiram Chirino wrote: On 10/4/06, yaussy [EMAIL PROTECTED] wrote: Sorry about that. I'd forgotten about the wireformat stuff. Looks like you can set AMQ 4.1 minimum wire format to 1 and then it will connect to AMQ 4.0.2 (still breaks with AMQ 4.0.1, but 4.0.1 and 4.0.2 work together). This gives me the rollout path we need. Since 4.0.2 has not been officially released, which 4.0.2 versin are you using? RC4 ? I think 4.0.2 RC 4 should be able to connecto the 4.1 without any config changes. A small bug in 4.0 was fixed in 4.0.2 that fixes auto wirefomat versin negociation. Two things though: 1) I could not get multiple connection properties on the TCP connectors, such as tcp://perfgc1a::5112?minmumWireFormatVersion=1connectionTimeout=5000. The XML parser complained. How should this look?? in XML you need replace all the '' with 'amp;' 2) Even with minmumWireFormatVersion=1, will two AMQ 4.1 brokers connect using their newer v2 format? Hum they should. Sees odd that the default is not 1... it should be 1. I'll double check. Thanks for testing this stuff out! yaussy wrote: I put a post in the user forum for this, but thought I'd add something to this thread. I'm concerned about backward compatibility. I've got a test environment with all brokers at 4.0.1, except one I'm upgrading to 4.1. This would be how our production environment would be upgraded - a machine or so at a time. However, the 4.0.1 brokers will not connect to the 4.1 broker, giving the following exception: Exception in thread ActiveMQ Transport: tcp:///170.137.15.160:34695 java.lang.IllegalArgumentException: Invalid version: 2, could not l oad org.apache.activemq.openwire.v2.MarshallerFactory at org.apache.activemq.openwire.OpenWireFormat.setVersion(OpenWireFormat.java:329) at org.apache.activemq.openwire.OpenWireFormat.renegociatWireFormat(OpenWireFormat.java:569) at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:100) at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:122) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:87) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:143) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.ClassNotFoundException: org.apache.activemq.openwire.v2.MarshallerFactory at org.apache.activemq.util.ClassLoading.loadClass(ClassLoading.java:104) at org.apache.activemq.openwire.OpenWireFormat.setVersion(OpenWireFormat.java:327) ... 6 more There must be an upgrade path for 4.1. If that means I have to go to 4.0.2 (which I did not try yet), that is OK. But, I can't possibly tell my management that I have to upgrade the AMQ version on all 50 or so machines we have in production. Hiram Chirino wrote: I'm starting to work on the first release candidate for 4.1.. please let me know if I should hold off! On 10/3/06, Vadim Pesochinsky [EMAIL PROTECTED] wrote: Hi James, It looks like this is changed now with 4.0.3. Any idea when 4.1 is going to be out? Thanks. -- View this message in context: http://www.nabble.com/Release-schedule-tf2124265.html#a6630219 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- Regards, Hiram Blog: http://hiramchirino.com -- View this message in context: http://www.nabble.com/Release-schedule-tf2124265.html#a6647640 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- Regards, Hiram Blog: http://hiramchirino.com -- View this message in context: http://www.nabble.com/Release-schedule-tf2124265.html#a7935126 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: Release schedule
4.1 has been released. -Brian On Dec 18, 2006, at 11:40 AM, sileshi wrote: Is 4.1 released? If not, what is rlelease plans? -Sileshi Hiram Chirino wrote: On 10/4/06, yaussy [EMAIL PROTECTED] wrote: Sorry about that. I'd forgotten about the wireformat stuff. Looks like you can set AMQ 4.1 minimum wire format to 1 and then it will connect to AMQ 4.0.2 (still breaks with AMQ 4.0.1, but 4.0.1 and 4.0.2 work together). This gives me the rollout path we need. Since 4.0.2 has not been officially released, which 4.0.2 versin are you using? RC4 ? I think 4.0.2 RC 4 should be able to connecto the 4.1 without any config changes. A small bug in 4.0 was fixed in 4.0.2 that fixes auto wirefomat versin negociation. Two things though: 1) I could not get multiple connection properties on the TCP connectors, such as tcp://perfgc1a::5112? minmumWireFormatVersion=1connectionTimeout=5000. The XML parser complained. How should this look?? in XML you need replace all the '' with 'amp;' 2) Even with minmumWireFormatVersion=1, will two AMQ 4.1 brokers connect using their newer v2 format? Hum they should. Sees odd that the default is not 1... it should be 1. I'll double check. Thanks for testing this stuff out! yaussy wrote: I put a post in the user forum for this, but thought I'd add something to this thread. I'm concerned about backward compatibility. I've got a test environment with all brokers at 4.0.1, except one I'm upgrading to 4.1. This would be how our production environment would be upgraded - a machine or so at a time. However, the 4.0.1 brokers will not connect to the 4.1 broker, giving the following exception: Exception in thread ActiveMQ Transport: tcp:/// 170.137.15.160:34695 java.lang.IllegalArgumentException: Invalid version: 2, could not l oad org.apache.activemq.openwire.v2.MarshallerFactory at org.apache.activemq.openwire.OpenWireFormat.setVersion (OpenWireFormat.java:329) at org.apache.activemq.openwire.OpenWireFormat.renegociatWireFormat (OpenWireFormat.java:569) at org.apache.activemq.transport.WireFormatNegotiator.onCommand (WireFormatNegotiator.java:100) at org.apache.activemq.transport.InactivityMonitor.onCommand (InactivityMonitor.java:122) at org.apache.activemq.transport.TransportSupport.doConsume (TransportSupport.java:87) at org.apache.activemq.transport.tcp.TcpTransport.run (TcpTransport.java:143) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.ClassNotFoundException: org.apache.activemq.openwire.v2.MarshallerFactory at org.apache.activemq.util.ClassLoading.loadClass (ClassLoading.java:104) at org.apache.activemq.openwire.OpenWireFormat.setVersion (OpenWireFormat.java:327) ... 6 more There must be an upgrade path for 4.1. If that means I have to go to 4.0.2 (which I did not try yet), that is OK. But, I can't possibly tell my management that I have to upgrade the AMQ version on all 50 or so machines we have in production. Hiram Chirino wrote: I'm starting to work on the first release candidate for 4.1.. please let me know if I should hold off! On 10/3/06, Vadim Pesochinsky [EMAIL PROTECTED] wrote: Hi James, It looks like this is changed now with 4.0.3. Any idea when 4.1 is going to be out? Thanks. -- View this message in context: http://www.nabble.com/Release-schedule-tf2124265.html#a6630219 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- Regards, Hiram Blog: http://hiramchirino.com -- View this message in context: http://www.nabble.com/Release-schedule-tf2124265.html#a6647640 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- Regards, Hiram Blog: http://hiramchirino.com -- View this message in context: http://www.nabble.com/Release- schedule-tf2124265.html#a7935126 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
[jira] Created: (SM-782) Re-deploy with In-Only Mep
Re-deploy with In-Only Mep -- Key: SM-782 URL: https://issues.apache.org/activemq/browse/SM-782 Project: ServiceMix Issue Type: Bug Components: servicemix-jms Affects Versions: 3.1 Environment: Linux x86/ Java (1.5.0_09) Reporter: Grégoire A. First deploy JMS-endpoint with target InOnly Service like Mail. Run several call. redeploy the same JMS-endpoint without modification. And recall the service, u should have this exception. It could be a safe thread pb, this error is launched in 75% of the cases. I think the context of the message cannot be refind. ERROR - JmsComponent - Error processing exchange InOnly[ id: ID:jjp-34393-1166462101789-6:229 status: Done role: consumer service: {urn:fr.gouv.hello}mailSender endpoint: mailSender in: ?xml version=1.0 encoding=UTF-8?ns1:HashString xmlns:ns1=http://tempuri.org/HashService/HashClass; xmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/; xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; xmlns:ZSI=http://www.zolera.com/schemas/ZSI/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;ns1:StrMessage Change dans BPEL 4 JMS Service /ns1:Strns1:HashTypeMD5/ns1:HashType/ns1:HashString ] java.lang.NullPointerException at org.apache.servicemix.jms.multiplexing.MultiplexingConsumerProcessor.process(MultiplexingConsumerProcessor.java:105) at org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:490) at org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:464) at org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46) at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610) at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174) at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176) at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:595) ERROR - JmsComponent - Error setting exchange status to ERROR javax.jbi.messaging.MessagingException: illegal call to send / sendSync at org.apache.servicemix.jbi.messaging.MessageExchangeImpl.handleSend(MessageExchangeImpl.java:571) at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.doSend(DeliveryChannelImpl.java:350) at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.send(DeliveryChannelImpl.java:397) at org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:58) at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610) at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174) at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176) at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:595) and this is my configuration jms:endpoint service=hello:jmsReceiver endpoint=HELLOJmsReceiver targetService=hello:mailSender role=consumer destinationStyle=queue jmsProviderDestinationName=jms/queue/hello connectionFactory=#jmsFactory defaultMep=http://www.w3.org/2004/08/wsdl/in-only; / FYI: when you block SMX with in a debugger, it seems to work fine. -- 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: [VOTE] Release XBean 2.8
I've fixed the missing / bad ASF headers and use the new maven plugin to generate LICENSE/NOTICE file. On 12/18/06, Kevan Miller [EMAIL PROTECTED] wrote: On Dec 18, 2006, at 1:31 PM, Guillaume Nodet wrote: On 12/18/06, Kevan Miller [EMAIL PROTECTED] wrote: On Dec 18, 2006, at 11:25 AM, Guillaume Nodet wrote: I'm starting a vote to release XBean 2.8. There has not been much changes since 2.7, but a few bugs fixed, and the addition of the xbean-finder module. Anyway, the bugs are important enough to deserver a new release (the generated schemas can not be validated). [ ] +1 Start xbean 2.8 release process [ ] +/- 0 [ ] -1 Don't release xbean 2.8 now Here's my +1. Not sure what you mean by release process. Running mvn release:prepare release:perform ;) But here are the issues which look like they would block a release: 1. NOTICE files do not conform to current ASF standards What do you mean exactly ? They have the same content that the ones I've always seen. Could you point me to a better template for these ? Hi Guillaume, Yes, they've changed slightly... Source files no longer contain a copyright statement. Copyright is now in the notice file. Here's a pointer to the current standards -- http://www.apache.org/legal/src- headers.html Notice files take the following form: Apache [PRODUCT_NAME] Copyright [] The Apache Software Foundation This product includes software developed at The Apache Software Foundation (http://www.apache.org/). I don't see any external projects being included in xbean binaries. So, it would seem that's the only content that the NOTICE files would require. I took a peak at the generated jar files. Looks like license/notice files are missing from at least the following jar file: xbean-naming Genesis will automatically check for these during a build. Dain (I think) had a one line command to scan for missing notice/license files, but I can't remember how it went... 2. The following files either do not contain a valid license header (not all files will require one, but many of these need one) or have an out-of-date license header (all need to be updated). Thanks. I'll fix these asap. You run rat for that, right ? Yes, but rat doesn't identify old-style license headers. For these, I've found the following grep command to be useful: grep -RL --include=*.java Licensed to the Apache Software Foundation (ASF) * --kevan -- Cheers, Guillaume Nodet
Re: svn commit: r488326 - /geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml
Ugh... this is why I don't like all that moving of branches to tags... A tag or label should never be modified... its a point in time, not indented (or expected) to be changed. I believe that we would be doing ourselves a major favor by following some SCM best practices... moving branches to tags is not one of them... neither is changing code in a tag. --jason On Dec 18, 2006, at 8:35 AM, [EMAIL PROTECTED] wrote: Author: kevan Date: Mon Dec 18 08:35:24 2006 New Revision: 488326 URL: http://svn.apache.org/viewvc?view=revrev=488326 Log: add missing license header Modified: geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/ manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml Modified: geronimo/server/tags/2.0-M1/testsuite/deployment- testsuite/manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb- jar.xml URL: http://svn.apache.org/viewvc/geronimo/server/tags/2.0-M1/ testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/ resources/META-INF/ejb-jar.xml? view=diffrev=488326r1=488325r2=488326 == --- geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/ manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml (original) +++ geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/ manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml Mon Dec 18 08:35:24 2006 @@ -1,4 +1,20 @@ ?xml version=1.0 encoding=UTF-8? +!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the License); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an AS IS BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +-- ejb-jar version=2.1 xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
Re: [VOTE] 2.0-M1 Release
+1 I don't think we should spend too much time on this release. Lets just note the issues we run into and try to fix them for M2, possibly implementing more build support to help us avoid more legal-related issues, which seem to be the bulk of problems we run into. --jason On Dec 18, 2006, at 12:57 AM, Matt Hogstrom wrote: All, I have prepared 2.0-M1 for release. Of course all the hard work was done by the lot of y'all :) I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied with the results. All modes of operation functioned well (SLSB, Direct, EJB and JPA). I toned all the logs down to error to not overwhelm the users with lots of diagnostic output (they can always turn it up later if they want.) The uploads are taking forever so you'll see some piece parts trickle in. For the review I expect you'll want to focus on http:// people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies for your review and testing. I've included both Tomcat and Jetty as well as the minimal and j5ee assemblies. The source code is also there. Note that if you are planning on building you'll need to obtain the openejb-2.2-incubating jars to your local repo. The easiest way to do this is to modify the root pom and add a repository for David's home directory at http://people.apache.org/~dblevins/stage/. For SNAPSHOTs of certain plugins I have resolved these files to the most recent SNAPSHOT date / timestamp. I'm pulling a copy of these and will be putting them into our SVN for folks who may want to build in the future. I'm not too concerned about repeatability as this Milestone will be superseded at the end of January with the next version. The other MAven artifacts will be trickling onto people across my horribly slow home pipe and dropped into http://people.apache.org/ ~hogstrom/stage over the next few hours. Please review and cast your vote early. The faster we determine this build is good or if there is an issue the better. Thanks in advance for all your help in this effort. This vote will conclude at 0400 ET on Dec 21 (unless all you PMC members vote quicker :) If a respin is is necessary this vote will be suspended and a new one will start. Matt Hogstrom [EMAIL PROTECTED]
Re: [DISCUSS] 2.0-M1 Release
Rerouting to this thread from [VOTE] 2.0-M1 Release Hi All, I have two basic comments/questions. 1- I see a bunch of INFO messages in both Tomcat and Jetty at startup, not a show stopper for this release. 2- Deployment on Jetty is not behaving exactly as I expected. Not sure if I messed up the deployment plans given the new specs, however this same WAR works just fine with Tomcat. In Jetty I deploy a WAR and when I access the application it will list the content of the WAR, if I click on the JSP it will work fine. Something like not following the web.xml welcome-file maybe? The context-root however is correct. Just in case you may ask, here are the deployment plans: geronimo-web.xml == ?xml version=1.0 encoding=UTF-8? web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-1.2; environment moduleId groupIdsample.applications/groupId artifactIdHelloWorldApp/artifactId version2.0/version typewar/type /moduleId /environment context-root/hello/context-root /web-app == web.xml == ?xml version=1.0 encoding=UTF-8? web-app version=2.4 xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; welcome-file-list welcome-fileHelloWorld.jsp/welcome-file /welcome-file-list /web-app == Am I missing anything obvious? Cheers! Hernan Matt Hogstrom wrote: All, I opened this thread for general comments and questions about the release. Let's have the discussions here and leave the vote thread for +/- voting only so it will be easier to process Thanks. Matt Hogstrom [EMAIL PROTECTED]
[jira] Closed: (GERONIMO-2648) Integrate JSF 1.2 into 2.0-M1
[ http://issues.apache.org/jira/browse/GERONIMO-2648?page=all ] Tim McConnell closed GERONIMO-2648. --- Resolution: Fixed Integrated into 2.0-M1 build Integrate JSF 1.2 into 2.0-M1 - Key: GERONIMO-2648 URL: http://issues.apache.org/jira/browse/GERONIMO-2648 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.0-M1 Reporter: Tim McConnell Assigned To: Tim McConnell Fix For: 2.0-M1 Attachments: GERONIMO-2648.patch, modules.zip -- 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: [VOTE] Release XBean 2.8
On Dec 18, 2006, at 3:44 PM, Guillaume Nodet wrote: I've fixed the missing / bad ASF headers and use the new maven plugin to generate LICENSE/NOTICE file. Looks like the following still needs some attention: xbean-spring-v1/pom.xml These all have old style license headers. Sorry, I didn't spot them last scan. xbean-spring-v2/src/site/site.xml xbean-spring-v2a/src/site/site.xml xbean-spring-v2b/src/site/site.xml xbean-spring-v2c/src/site/site.xml I'm done, after that... ;-) --kevan
Re: svn commit: r488326 - /geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml
On Dec 18, 2006, at 3:45 PM, Jason Dillon wrote: Ugh... this is why I don't like all that moving of branches to tags... A tag or label should never be modified... its a point in time, not indented (or expected) to be changed. I believe that we would be doing ourselves a major favor by following some SCM best practices... moving branches to tags is not one of them... neither is changing code in a tag. I'm sympathetic to your concern. However, we don't (to my knowledge) have a documented release process for our projects. So, we're currently leaving these practices in the hands of our release managers. In this case, I did what the release manager asked me to do... So, what do you feel would be the appropriate techniques for building a release? --kevan
openejb-2.2 tag is not buildable
I'm trying to build the OpenEJB 2.2 release so that I can continue working on Geronimo CTS/TCK automation... but the openejb-2.2 release tag is not buildable in a clean environment: snip + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] OpenEJB [INFO] OpenEJB :: Modules [INFO] OpenEJB :: Core [INFO] OpenEJB :: Axis [INFO] OpenEJB :: PK Generation :: Builder [INFO] OpenEJB :: CORBA [INFO] OpenEJB :: Builder [INFO] OpenEJB :: CORBA Builder [INFO] OpenEJB :: CORBA :: Yoko [INFO] OpenEJB :: iTests [INFO] OpenEJB :: iTests :: Core [INFO] snapshot org.apache.geronimo.genesis.plugins:tools-maven- plugin:1.1-SNAPSHOT: checking for updates from codehaus-snapshots [INFO] snapshot org.apache.geronimo.genesis.plugins:tools-maven- plugin:1.1-SNAPSHOT: checking for updates from apache-snapshots Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/ apache/geronimo/genesis/plugins/tools-maven-plugin/1.1-SNAPSHOT/tools- maven-plugin-1.1-20061214.032036-20.pom 1K downloaded [INFO] snapshot org.apache.geronimo.genesis.plugins:plugins:1.1- SNAPSHOT: checking for updates from codehaus-snapshots [INFO] snapshot org.apache.geronimo.genesis.plugins:plugins:1.1- SNAPSHOT: checking for updates from apache-snapshots Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/ apache/geronimo/genesis/plugins/plugins/1.1-SNAPSHOT/ plugins-1.1-20061214.032036-13.pom 9K downloaded [INFO] snapshot org.apache.geronimo.genesis:genesis:1.1-SNAPSHOT: checking for updates from codehaus-snapshots [INFO] snapshot org.apache.geronimo.genesis:genesis:1.1-SNAPSHOT: checking for updates from apache-snapshots Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/ apache/geronimo/genesis/genesis/1.1-SNAPSHOT/ genesis-1.1-20061214.032036-13.pom 10K downloaded Downloading: http://repository.codehaus.org/org/apache/apache/3/ apache-3.pom [WARNING] Unable to get resource from repository codehaus (http:// repository.codehaus.org) Downloading: http://repo1.maven.org/maven2/org/apache/apache/3/ apache-3.pom 3K downloaded Downloading: http://snapshots.repository.codehaus.org/org/apache/ geronimo/genesis/plugins/tools-maven-plugin/1.1-SNAPSHOT/tools-maven- plugin-1.1-SNAPSHOT.jar [WARNING] Unable to get resource from repository codehaus-snapshots (http://snapshots.repository.codehaus.org) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file - DgroupId=org.apache.geronimo.genesis.plugins -DartifactId=tools-maven- plugin \ -Dversion=1.1-SNAPSHOT -Dpackaging=maven-plugin -Dfile=/path/ to/file org.apache.geronimo.genesis.plugins:tools-maven-plugin:maven- plugin:1.1-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus (http://repository.codehaus.org), codehaus-snapshots (http://snapshots.repository.codehaus.org) org.apache.geronimo.genesis.plugins:tools-maven-plugin:maven- plugin:1.1-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus (http://repository.codehaus.org), codehaus-snapshots (http://snapshots.repository.codehaus.org) [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file - DgroupId=org.apache.geronimo.genesis.plugins -DartifactId=tools-maven- plugin \ -Dversion=1.1-SNAPSHOT -Dpackaging=maven-plugin -Dfile=/path/ to/file org.apache.geronimo.genesis.plugins:tools-maven-plugin:maven- plugin:1.1-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus (http://repository.codehaus.org), codehaus-snapshots (http://snapshots.repository.codehaus.org) org.apache.geronimo.genesis.plugins:tools-maven-plugin:maven- plugin:1.1-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus (http://repository.codehaus.org), codehaus-snapshots (http://snapshots.repository.codehaus.org) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.findExtensions (DefaultLifecycleExecutor.java:179) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLifecycleExecutor.java:138) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at
[jira] Created: (AMQ-1102) Infinite loop from broker's network connector when using multiple durable subscribers (topics) with msg selector.
Infinite loop from broker's network connector when using multiple durable subscribers (topics) with msg selector. - Key: AMQ-1102 URL: https://issues.apache.org/activemq/browse/AMQ-1102 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.1.0 Environment: Linux Reporter: Samson The following is the series of messages resulting from the broker (infinite loop): INFO DemandForwardingBridge - Network connection between vm://localhost#0 and tcp://localhost/127.0.0.1:61601 shutdown due to a local error: javax.jms.JMSException: Durable consumer is in use for client: NC_SWITCH1BROKER_inboundlocalhost and subscriptionName: localhost_TEST.FOO INFO TransportConnector - Connector vm://localhost Stopped INFO NetworkConnector - Establishing network connection between from vm://localhost?network=true to tcp://switch:61601 INFO TransportConnector - Connector vm://localhost Started INFO DemandForwardingBridge - Network connection between vm://localhost#2 and tcp://localhost/127.0.0.1:61601(SWITCH1BROKER) has been established. INFO DemandForwardingBridge - Network connection between vm://localhost#2 and tcp://localhost/127.0.0.1:61601 shutdown due to a local error: javax.jms.JMSException: Durable consumer is in use for client: NC_SWITCH1BROKER_inboundlocalhost and subscriptionName: localhost_TEST.FOO INFO TransportConnector - Connector vm://localhost Stopped ... EXACT STEPS TO REPRODUCE: 1 -Start standalone broker -using default conf/activemq.xml file 2 -Start EmbeddedBroker (with network connector specified): BrokerService broker = new BrokerService(); broker.setUseJmx(true); broker.setBrokerName(SWITCH1BROKER); TransportConnector connector = broker.addConnector(new URI(tcp://localhost:+61601)); connector.setDiscoveryUri(new URI(multicast://default)); broker.addNetworkConnector(new URI(multicast://default)); broker.start(); At this point, I'll get the following output (which looks normal): INFO NetworkConnector - Establishing network connection between from vm://localhost?network=true to tcp://switch:61601 INFO TransportConnector - Connector vm://localhost Started INFO DemandForwardingBridge - Network connection between vm://localhost#0 and tcp://localhost/127.0.0.1:61601(SWITCH1BROKER) has been established. 3. -Edit line 105 of ConsumerTool to specify any message selector consumer = session.createDurableSubscriber((Topic) destination, consumerName, BLAH = '1', false); 4. -Start ConsumerTool with clientID consumer1 -connect to tcp://localhost:61601 -using topics, durable subscription, w/ message selector 5. -Start ConsumerTool with clientID consumer2 -connect to tcp://localhost:61601 -using topics, durable subscription, w/ message selector -- 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
sm 3.0 build fails under java 6
however, binary seems to execute fine. -- (x86 linux - FC5, sun jdk 1.6.0, apache-servicemix-3.0-incubating-src.tar.gz) mvn -Dmaven.test.skip=true -Dprofile=step2 install ... [INFO] [compiler:compile] Compiling 114 source files to /home/tbiernat/work/servicemix/apache-servicemix-3.0-incubating/src/servicemix-components/target/classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /home/tbiernat/work/servicemix/apache-servicemix-3.0-incubating/src/servicemix-components/src/main/java/org/apache/servicemix/components/script/ScriptComponent.java:[210,36] cannot find symbol symbol : method createNamespace() location: interface javax.script.ScriptEngine /home/tbiernat/work/servicemix/apache-servicemix-3.0-incubating/src/servicemix-components/src/main/java/org/apache/servicemix/components/script/ScriptComponent.java:[261,26] cannot find symbol symbol : method eval(javax.script.Namespace) location: class javax.script.CompiledScript /home/tbiernat/work/servicemix/apache-servicemix-3.0-incubating/src/servicemix-components/src/main/java/org/apache/servicemix/components/script/ScriptComponent.java:[269,14] cannot find symbol symbol : method eval(java.lang.String,javax.script.Namespace) location: interface javax.script.ScriptEngine -- View this message in context: http://www.nabble.com/sm-3.0-build-fails-under-java-6-tf2842650s12049.html#a7937393 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
[jira] Closed: (SM-521) Tuning parameters configuration
[ https://issues.apache.org/activemq/browse/SM-521?page=all ] Guillaume Nodet closed SM-521. -- Resolution: Duplicate Thread pools can be configured with the ExecutorFactory on the jbi container. Throttling should be configurable on a per endpoint basis. Tuning parameters configuration --- Key: SM-521 URL: https://issues.apache.org/activemq/browse/SM-521 Project: ServiceMix Issue Type: Improvement Components: servicemix-core Reporter: Guillaume Nodet Fix For: 3.1 We need to provide a way to configure tuning parameters for servicemix: * thread pools (core + flows + seda queues + components ) * queues (delivery channels + seda queues) * component throttling This may need a way to configure dummy activationSpecs (with no components, only the component name) so that we can configure these parameters when using JBI std installation -- 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] Updated: (SM-745) Allow usage of other JMS providers than ActiveMQ
[ https://issues.apache.org/activemq/browse/SM-745?page=all ] Guillaume Nodet updated SM-745: --- Fix Version/s: (was: 3.1) Allow usage of other JMS providers than ActiveMQ Key: SM-745 URL: https://issues.apache.org/activemq/browse/SM-745 Project: ServiceMix Issue Type: Improvement Affects Versions: 3.0.1 Reporter: Christian Schneider Attachments: jmsflow.patch, jmsflow.patch, jmsflow2.patch, jmsflow3.patch JMSFlow and JCA flow are too tightly bound to ActiveMQ. Instead of ActiveMQ specific classes jms Interfaces should be used where possible. I have attached a patch that replaces ActiveMQConnection and ActiveMQConnectionFactory by the jms equivalents. There is one possible issue with my patch. The getConnectionFactory now returns a ConnectionFactory instead of a ActiveMQConnectionFactory. I don´t know if any other part of the sources depends on the specific class. My patch is of course only the first step. The next could be having a specific subclass JMSFlowActiveMQ that does all stuff that is ActiveMQ specific. I will deliver a second patch for this. -- 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: sm 3.0 build fails under java 6
It seems we use an older version of jsr223. It has just gone final a few days ago, and there are lots of changes from the version we currently use. Could you please raise a JIRA for that ? On 12/18/06, timbo [EMAIL PROTECTED] wrote: however, binary seems to execute fine. -- (x86 linux - FC5, sun jdk 1.6.0, apache-servicemix-3.0-incubating-src.tar.gz) mvn -Dmaven.test.skip=true -Dprofile=step2 install ... [INFO] [compiler:compile] Compiling 114 source files to /home/tbiernat/work/servicemix/apache-servicemix-3.0-incubating/src/servicemix-components/target/classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /home/tbiernat/work/servicemix/apache-servicemix-3.0-incubating/src/servicemix-components/src/main/java/org/apache/servicemix/components/script/ScriptComponent.java:[210,36] cannot find symbol symbol : method createNamespace() location: interface javax.script.ScriptEngine /home/tbiernat/work/servicemix/apache-servicemix-3.0-incubating/src/servicemix-components/src/main/java/org/apache/servicemix/components/script/ScriptComponent.java:[261,26] cannot find symbol symbol : method eval(javax.script.Namespace) location: class javax.script.CompiledScript /home/tbiernat/work/servicemix/apache-servicemix-3.0-incubating/src/servicemix-components/src/main/java/org/apache/servicemix/components/script/ScriptComponent.java:[269,14] cannot find symbol symbol : method eval(java.lang.String,javax.script.Namespace) location: interface javax.script.ScriptEngine -- View this message in context: http://www.nabble.com/sm-3.0-build-fails-under-java-6-tf2842650s12049.html#a7937393 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet
Re: [VOTE] Release XBean 2.8
Done :) On 12/18/06, Kevan Miller [EMAIL PROTECTED] wrote: On Dec 18, 2006, at 3:44 PM, Guillaume Nodet wrote: I've fixed the missing / bad ASF headers and use the new maven plugin to generate LICENSE/NOTICE file. Looks like the following still needs some attention: xbean-spring-v1/pom.xml These all have old style license headers. Sorry, I didn't spot them last scan. xbean-spring-v2/src/site/site.xml xbean-spring-v2a/src/site/site.xml xbean-spring-v2b/src/site/site.xml xbean-spring-v2c/src/site/site.xml I'm done, after that... ;-) --kevan -- Cheers, Guillaume Nodet
[jira] Commented: (SM-782) Re-deploy with In-Only Mep
[ https://issues.apache.org/activemq/browse/SM-782?page=comments#action_37723 ] Guillaume Nodet commented on SM-782: I think the problem comes from the fact that the endpoint is re-deployed. In such a case, another instance of the endpoint will be created, so that the pendingMessages map will be lost. For InOnly meps, it should be easy, as you said, to bypass this in case of DONE status. For ERROR status, well, not sure yet. For other meps, a better may be to extract the needed informations and put them as properties (they must be serializable) on the exchange, so that the jms component does not need to keep any state (hence, another component should be able to handle the answer if needed). Re-deploy with In-Only Mep -- Key: SM-782 URL: https://issues.apache.org/activemq/browse/SM-782 Project: ServiceMix Issue Type: Bug Components: servicemix-jms Affects Versions: 3.1 Environment: Linux x86/ Java (1.5.0_09) Reporter: Grégoire A. First deploy JMS-endpoint with target InOnly Service like Mail. Run several call. redeploy the same JMS-endpoint without modification. And recall the service, u should have this exception. It could be a safe thread pb, this error is launched in 75% of the cases. I think the context of the message cannot be refind. ERROR - JmsComponent - Error processing exchange InOnly[ id: ID:jjp-34393-1166462101789-6:229 status: Done role: consumer service: {urn:fr.gouv.hello}mailSender endpoint: mailSender in: ?xml version=1.0 encoding=UTF-8?ns1:HashString xmlns:ns1=http://tempuri.org/HashService/HashClass; xmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/; xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; xmlns:ZSI=http://www.zolera.com/schemas/ZSI/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;ns1:StrMessage Change dans BPEL 4 JMS Service /ns1:Strns1:HashTypeMD5/ns1:HashType/ns1:HashString ] java.lang.NullPointerException at org.apache.servicemix.jms.multiplexing.MultiplexingConsumerProcessor.process(MultiplexingConsumerProcessor.java:105) at org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:490) at org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:464) at org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46) at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610) at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174) at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176) at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:595) ERROR - JmsComponent - Error setting exchange status to ERROR javax.jbi.messaging.MessagingException: illegal call to send / sendSync at org.apache.servicemix.jbi.messaging.MessageExchangeImpl.handleSend(MessageExchangeImpl.java:571) at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.doSend(DeliveryChannelImpl.java:350) at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.send(DeliveryChannelImpl.java:397) at org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:58) at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610) at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174) at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176) at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:595) and this is my configuration jms:endpoint service=hello:jmsReceiver endpoint=HELLOJmsReceiver targetService=hello:mailSender role=consumer destinationStyle=queue jmsProviderDestinationName=jms/queue/hello connectionFactory=#jmsFactory defaultMep=http://www.w3.org/2004/08/wsdl/in-only; / FYI: when you block SMX with in a debugger, it seems to work fine. -- This message is
Release Guidlines (was: Re: svn commit: r488326 - /geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml)
On Dec 18, 2006, at 3:45 PM, Jason Dillon wrote: Ugh... this is why I don't like all that moving of branches to tags... I agree A tag or label should never be modified... its a point in time, not indented (or expected) to be changed. I believe that we would be doing ourselves a major favor by following some SCM best practices... moving branches to tags is not one of them... neither is changing code in a tag. Dain ran into a similar problem where while releasing he had an issue that a utility as part of the release process caused him to make a change to source because of a variable name. For the milestone I'm not concerned but I am concerned that we get the release process documented and agreed to. We're not going to fix these two release processes. I am writing up on the CWiki my thoughts for release that I'd like to get ironed out BEFORE we get to the next release. Not that we've done anything wrong but I feel this process is too fluid as we've changed it almost every release. This includes changes to voting, releasing, and build tools. We've worked through them each time and no process will be perfect but we should be refining something each time and not creating something new. Here are my list of items to start with: Define release in terms of Milestone, Beta, Full Version - includes definition of user expectations - quality of the release - logging level consistency - Release Notes content - Packing list for delivered content - Naming conventions for delivered modules (ala manually created source) Process of branching and tagging (we already have a plethora of discussion...I think this needs to get on a Wiki) - includes tags and modifications Including non-released artifacts and how they are handeled and where they go Voting time lines and expectations - Things like VOTE and DISCUSS threads - when do they get restarted (or do they)...how to handle issues like changes to the tree that were no previously caught - Is there a limit where the 72 hour timeline is satisfied previously? Ok, these are a few of my favorite things. Actually, this is a lot of process but to Jason's concern (which I agree with) we need to lock this down. Matt Hogstrom [EMAIL PROTECTED]
[jira] Updated: (SM-749) JSR181 component does not generate WSDL types for JAXB2-annotated classes
[ https://issues.apache.org/activemq/browse/SM-749?page=all ] Guillaume Nodet updated SM-749: --- Fix Version/s: (was: incubation) JSR181 component does not generate WSDL types for JAXB2-annotated classes - Key: SM-749 URL: https://issues.apache.org/activemq/browse/SM-749 Project: ServiceMix Issue Type: Bug Components: servicemix-jsr181 Affects Versions: 3.0.1 Environment: JSE 6 RC, Win XP Reporter: Los Morales Attachments: jira_sm749 reproduce.zip JSR181 component fails to unmarshal data from an XML document into JAXB2-annotated objects because the WSDL for types does not get properly generated. Similar to an already existing issue: (https://brutus.apache.org/activemq/browse/SM-739), the bug(s) seem to occur only when the POJOs have JAXB2 annotations. Removing these annotations seem to produce the proper WSDL (with all the respective types) when the JSR181 component is deployed (using JConsole), although the unmarshaling still does not work due to the missing annotations. The complete thread regarding this issue can be found here: http://www.nabble.com/connecting-to-jsr-181-jaxb2-tf2523299s12049.html -- 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: (SM-704) FTPPoller Improvements
[ https://issues.apache.org/activemq/browse/SM-704?page=all ] Guillaume Nodet resolved SM-704. Resolution: Fixed Assignee: Guillaume Nodet FTPPoller Improvements -- Key: SM-704 URL: https://issues.apache.org/activemq/browse/SM-704 Project: ServiceMix Issue Type: Improvement Components: servicemix-ftp Affects Versions: 3.0 Environment: Windows XP SP2; JSE 6 Beta 2 Reporter: Los Morales Assigned To: Guillaume Nodet Priority: Minor Fix For: 3.1 In the org.apache.servicemix.components.net.FTPPoller class, there are two things that can be improved upon. 1) Give the option to NOT delete the files from the FTP server by adding a deleteFile attribute w/ corresponding accessors. In order to make this work, you will also need to keep track of the files already retrieved by using the java.util.concurrent.CopyOnWriteArraySet to keep track of each FTPFile's raw listing. 2) In the processFile() method, move the client.completePendingCommand() line AFTER the call to in.close(). Sometimes my program would hang indefinitely when the call to completePendingCommand() was done prior to closing the input stream. This situation is discussed here as well: http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200412.mbox/[EMAIL PROTECTED] -los -- 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: (SM-783) build fails under java 6
build fails under java 6 - Key: SM-783 URL: https://issues.apache.org/activemq/browse/SM-783 Project: ServiceMix Issue Type: Bug Components: servicemix-components Affects Versions: 3.0 Environment: x86 linux - FC5, sun jdk 1.6.0, apache-servicemix-3.0-incubating-src.tar.gz Reporter: tim biernat Priority: Minor mvn -Dmaven.test.skip=true -Dprofile=step2 install ... [INFO] [compiler:compile] Compiling 114 source files to /home/tbiernat/work/servicemix/apache-servicemix-3.0-incubating/src/servicemix-components/target/classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /home/tbiernat/work/servicemix/apache-servicemix-3.0-incubating/src/servicemix-components/src/main/java/org/apache/servicemix/components/script/ScriptComponent.java:[210,36] cannot find symbol symbol : method createNamespace() location: interface javax.script.ScriptEngine /home/tbiernat/work/servicemix/apache-servicemix-3.0-incubating/src/servicemix-components/src/main/java/org/apache/servicemix/components/script/ScriptComponent.java:[261,26] cannot find symbol symbol : method eval(javax.script.Namespace) location: class javax.script.CompiledScript /home/tbiernat/work/servicemix/apache-servicemix-3.0-incubating/src/servicemix-components/src/main/java/org/apache/servicemix/components/script/ScriptComponent.java:[269,14] cannot find symbol symbol : method eval(java.lang.String,javax.script.Namespace) location: interface javax.script.ScriptEngine -- 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: svn commit: r488326 - /geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml
On Dec 18, 2006, at 1:49 PM, Kevan Miller wrote: A tag or label should never be modified... its a point in time, not indented (or expected) to be changed. I'm sympathetic to your concern. However, we don't (to my knowledge) have a documented release process for our projects. So, we're currently leaving these practices in the hands of our release managers. I understand why you did this... and I think that SVN is probably more to blame for this by how its implemented tagging. Most source control systems simply don't allow your to make code changes to a label/tag, most will allow retag from another branch, but not modification of the label directly. But svn implements tags as branches which forces the policy of what is a tag and what is a branch on to the users... which has a rather nasty side-effect of never really knowing if a tagged code line is a label or a branch. In this case, it would have been better if there was still a 2.0-M1 branch, and you made this change to the branch, and then re-tagged the changed file. I really don't think that moving branches to tags, or tags to branches is a good idea at all... even though svn will let you do that. Keep the branch around so that you can use it to make changes you need to, and then always copy to tag... and never change code on a tag, assume its read-only. In this case, I did what the release manager asked me to do... Well, I might have asked if they were smoking crack... and to give me some. :-P I would not recommend doing it again though. I believe that following some best practices for scm (as well as build) will really improve on Geronimo's ability to deliver in the long term. Little short-cuts like this will add up over time and slow down the machine considerably. So, what do you feel would be the appropriate techniques for building a release? This doesn't really related directly to the issue of changing code in a tag... though it is somewhat related. And this question is a bit of a loaded gun... but here are some of my thoughts, incomplete as they maybe at the moment: I believe that the process of releasing should be automated, and more so delegated to a well known environment. Automation of releases helps to ensure that releases are repeatable and reduce the chances of user error, which in generally will improve the quality and trustworthiness of releases. Releases should be performed in a well known environment so that local environmental changes do not adversely affect the contents or quality of a release. I believe that once a release is made (and I mean voted out and official), that no changes should ever be made to that release. If *anything* needs to be *fixed*, then cut a new release, *never, never, never* change the release. Release tags should really be buildable at anytime... be it one day, 2 weeks, 3 years. I know that as time passes the chances of this holding true begin to diminish, but it is something that we should aim for. With the proper tools and environment it should be possible to ensure that each release builds durability is in the years, if not decades rather than months. Related to ASF-style releasing, which I still think is a bit odd, but the whole make a release, then vote on the release, maybe re- cutting the same release, might be better of using a branch for code changes (for the recutting), and then a label per cycle, and once a label is finally blessed it can be renamed to the official release tag. It is just confusing to move branches to tags, and then back to branches, and then tags again as we move through this process. I think we also should include some sort of release/build iteration for times when we bounce back and forth... for example, 1.2-beta-1 (is the first), 1.2-beta-2 (is the second). This is commonly used by RPM packagers, where each package has its iteration, and often the iteration that is final is not -1, but more like -3 or -4. This is quite natural if you think of tags as permanent and non-changing... which I suggest is the best way to consider them for releases... though don't get me wrong, when using a promotion model, or for things like tagging last successful nightly builds, etc, then mutable tags are useful, but definitely not for releases. * * * I'm sure that I can come up with more... but I think the most important part is the automation... release made by me, or by you or by anyone else on the team, should be for the most part identical. I believe that the other bits, like svn tag policy, build iteration inclusion, etc, all fit together as pieces of the automation puzzle... and in many cases come naturally once you start to think about the problem as a set of repeatable steps to take that which can be applied to any project for releases, ci, nightly builds, etc. To make all of those work using more or less the same
Re: Release Guidlines (was: Re: svn commit: r488326 - /geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml)
On Dec 18, 2006, at 2:59 PM, Matt Hogstrom wrote: Dain ran into a similar problem where while releasing he had an issue that a utility as part of the release process caused him to make a change to source because of a variable name. Was this before or after the release tag was made? Can you elaborate on this? Or maybe Dain can, so that I can understand better. I know of several issues with the release plugin, I actually think that its only useful as part of an automated release solution, still need some additional build help and sanity checks to ensure that when its time to make a release, that everything is going to be happy. For the milestone I'm not concerned but I am concerned that we get the release process documented and agreed to. We're not going to fix these two release processes. I agree, though I hope we can fix some of these issues before M2 goes out. My point about the ci to tags however could have been avoided, by keeping the branch (not moving it to tags) and then copying to label, as is the recommended method to label things in svn. It was also more general that relating to releases... generally assume that a tag is read-only. Don't mv a branch to a tag, copy it. I am writing up on the CWiki my thoughts for release that I'd like to get ironed out BEFORE we get to the next release. Not that we've done anything wrong but I feel this process is too fluid as we've changed it almost every release. This includes changes to voting, releasing, and build tools. We've worked through them each time and no process will be perfect but we should be refining something each time and not creating something new. Well, I think a ci to a tag *was* wrong :-P But other than that I basically agree. Here are my list of items to start with: Define release in terms of Milestone, Beta, Full Version - includes definition of user expectations - quality of the release Yikes... not sure what either of these might actually be... can you give an example of what these might look like for 2.0-M1? - logging level consistency Um... you know that this one will differer based on which user consumes it right? Open-source-savvy user might expect INFO, where Joe-consumer-embedder, might expect its ERROR (and both may flag it as broke if its not what they expected). Not sure who the default release configuration should be tailored to... and god no... I'm not suggesting we make a release for each of them :-P - Release Notes content Yes, this is important... and IMO should be driven off of JIRA for that version as well as including detail about specific changes. I think that the AMQ folks do this well... as well as that Atlassian folks. I recommend we copy them. - Packing list for delivered content Eh, I don't care too much about this really. Though if it can be automated, then maybe it okay, else I see this as a non-important document which will quickly become out of date, and out of date documented is more harmful than it is useful. Though a general README.txt which explains the basic top-level directories should be good, and easy to maintain. - Naming conventions for delivered modules (ala manually created source) Process of branching and tagging (we already have a plethora of discussion...I think this needs to get on a Wiki) - includes tags and modifications Yes, it should... though the svn book covers most of this, I don't recommend we drift to far from it. Including non-released artifacts and how they are handeled and where they go Its been almost 6 months and I am still staying the same thing... we need our own repo, backed our svn, which can contain these bits... as the time to wait for other projects to release is crazy (especially if they too are ASF projects bound by the same style of release hell). Having our own svn backed repo allows us to always have the right versions of artifacts, labeled with our source, which helps increase the changes that codelines are buildable far into the future. And even if our repo is only subset, and the rest are pulled from central for starting out, we are in a better position. Even better to have *everything* in our svn repo, but that might be more work to implement than any of us have time right now. Voting time lines and expectations - Things like VOTE and DISCUSS threads - when do they get restarted (or do they)...how to handle issues like changes to the tree that were no previously caught - Is there a limit where the 72 hour timeline is satisfied previously? NOTE, if our release process was automated, then the time/effort to build a release would be minimal. We could easily spin off a version-VOTING-n build, and then once it passes, simply rebuild the exact same thing as a final. This is one significant advantage to building off of source control (either be it sources, or binaries checked in). But
Re: [VOTE] 2.0-M1 Release
+1 -David On Dec 18, 2006, at 12:57 AM, Matt Hogstrom wrote: All, I have prepared 2.0-M1 for release. Of course all the hard work was done by the lot of y'all :) I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied with the results. All modes of operation functioned well (SLSB, Direct, EJB and JPA). I toned all the logs down to error to not overwhelm the users with lots of diagnostic output (they can always turn it up later if they want.) The uploads are taking forever so you'll see some piece parts trickle in. For the review I expect you'll want to focus on http:// people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies for your review and testing. I've included both Tomcat and Jetty as well as the minimal and j5ee assemblies. The source code is also there. Note that if you are planning on building you'll need to obtain the openejb-2.2-incubating jars to your local repo. The easiest way to do this is to modify the root pom and add a repository for David's home directory at http://people.apache.org/~dblevins/stage/. For SNAPSHOTs of certain plugins I have resolved these files to the most recent SNAPSHOT date / timestamp. I'm pulling a copy of these and will be putting them into our SVN for folks who may want to build in the future. I'm not too concerned about repeatability as this Milestone will be superseded at the end of January with the next version. The other MAven artifacts will be trickling onto people across my horribly slow home pipe and dropped into http://people.apache.org/ ~hogstrom/stage over the next few hours. Please review and cast your vote early. The faster we determine this build is good or if there is an issue the better. Thanks in advance for all your help in this effort. This vote will conclude at 0400 ET on Dec 21 (unless all you PMC members vote quicker :) If a respin is is necessary this vote will be suspended and a new one will start. Matt Hogstrom [EMAIL PROTECTED]
Re: Release Guidlines (was: Re: svn commit: r488326 - /geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml)
On Dec 18, 2006, at 2:59 PM, Matt Hogstrom wrote: Process of branching and tagging (we already have a plethora of discussion...I think this needs to get on a Wiki) - includes tags and modifications Discussion, proposal, resolution and final vote. http://cwiki.apache.org/GMOxPMGT/release-branching-process.html Granted that was June, just about time to do it all over again :) In regards to the commit to the tag, I don't have a problem with it as it was completely ineffectual in any technical sense. We could of course thump the rule book and make Matt redo 8+ hours of work and have days worth of revoting followed up by a couple weeks worth of cumulative man hours on policy discussions... or we could just say close enough and focus on 2.0-M2. -David
Re: openejb-2.2 tag is not buildable
On Dec 18, 2006, at 1:51 PM, Jason Dillon wrote: I'm trying to build the OpenEJB 2.2 release so that I can continue working on Geronimo CTS/TCK automation... but the openejb-2.2 release tag is not buildable in a clean environment: [...] I am not sure that this is a priority for many folks, but I hope that someday it will become more important in your eyes. As you know you don't need to build openejb-2.2 to do your CTS/TCK testing. You can build 1.2-beta or 2.0-m1 as Dain or Matt did when they built those releases by adding this repo to your list temporarily: http://people.apache.org/~dblevins/stage/ But you're right, tags should be buildable. As openejb depends on geronimo and geronimo depends on openejb -- it's hard. As you and David J. have mentioned, it would be possible to: 1. release geronimo modules 2. release openejb 3. release geromimo applications, configs, and assemblies. But since we don't do that and I don't think anyone is willing to propose it, someone has to release with an imperfect tag and OpenEJB is always the one to fall on that sword. It has nothing to do with it not being important, that's just the compromise we make until either 1. OpenEJB stops depending on Geronimo snapshots, 2. Geronimo stops depending on OpenEJB snapshots, or 3. Geronimo releases modules and other in serial with a wait period in the middle for the OpenEJB release. You already know that too and I'm just reiterating what we've all gone over before. My perspective is we need a bit of 1, 2 and 3. In the meantime comments like I hope that someday it will become more important in your eyes don't sit well with me. So, the here and now: It's poor form to update tags, but it's also poor form to release stuff with snapshots, so I went with (hopefully) the lesser of the two evils and updated the tag. geronimo.*: 1.2-SNAPSHOT - 1.2-beta tools-maven-plugin: 1.1-SNAPSHOT - 1.1 Fair warning, the tag will still not build due to the missing geronimo dependencies. Geronimo 1.2-beta is waiting on OpenEJB 2.2 to be released. As you also know, you can add this repo to your list temporarily to build: http://people.apache.org/~dain/stage/ Hope this helps, -David
Re: Release Guidlines (was: Re: svn commit: r488326 - /geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml)
For the M1 release I would have said close enough and made the final release from trunk. But changing the tag is harmful by itself by setting precedence... something which should not be followed, yet unless people understand why, they will just continue along those bad practices. And technically speaking, making a change to a branch or hacking up a tag should have the exact same effect on any work that anyone might need to redo for a release. And really we could thump the rule book on the ci to tags too... which is pointless for this release. The important thing is that people understand that its not appropriate to alter a tag in that manner. This is a pure policy argument, as technically from the release perspective is identical using svn, in both cases, the release must be re-cut, re-approved, blah, blah, blah. And in general for release tags, it is best to treat them as read only. --jason On Dec 18, 2006, at 5:53 PM, David Blevins wrote: On Dec 18, 2006, at 2:59 PM, Matt Hogstrom wrote: Process of branching and tagging (we already have a plethora of discussion...I think this needs to get on a Wiki) - includes tags and modifications Discussion, proposal, resolution and final vote. http://cwiki.apache.org/GMOxPMGT/release-branching-process.html Granted that was June, just about time to do it all over again :) In regards to the commit to the tag, I don't have a problem with it as it was completely ineffectual in any technical sense. We could of course thump the rule book and make Matt redo 8+ hours of work and have days worth of revoting followed up by a couple weeks worth of cumulative man hours on policy discussions... or we could just say close enough and focus on 2.0-M2. -David
Re: openejb-2.2 tag is not buildable
On Dec 18, 2006, at 5:15 PM, David Blevins wrote: On Dec 18, 2006, at 1:51 PM, Jason Dillon wrote: I'm trying to build the OpenEJB 2.2 release so that I can continue working on Geronimo CTS/TCK automation... but the openejb-2.2 release tag is not buildable in a clean environment: [...] I am not sure that this is a priority for many folks, but I hope that someday it will become more important in your eyes. As you know you don't need to build openejb-2.2 to do your CTS/TCK testing. You can build 1.2-beta or 2.0-m1 as Dain or Matt did when they built those releases by adding this repo to your list temporarily: http://people.apache.org/~dblevins/stage/ This requires a change to the source code, which I can not automate... and kinda defeats the purpose of the automated builds. IMO relying on users to change the source in order to build a codeline is a serious flaw. But you're right, tags should be buildable. As openejb depends on geronimo and geronimo depends on openejb -- it's hard. As you and David J. have mentioned, it would be possible to: 1. release geronimo modules 2. release openejb 3. release geromimo applications, configs, and assemblies. But since we don't do that and I don't think anyone is willing to propose it, someone has to release with an imperfect tag and OpenEJB is always the one to fall on that sword. It has nothing to do with it not being important, that's just the compromise we make until either 1. OpenEJB stops depending on Geronimo snapshots, 2. Geronimo stops depending on OpenEJB snapshots, or 3. Geronimo releases modules and other in serial with a wait period in the middle for the OpenEJB release. Okay, I understand that... though the deps on Genesis and xmlbeans-m- p are completely different. You already know that too and I'm just reiterating what we've all gone over before. My perspective is we need a bit of 1, 2 and 3. Ya, would be better in this case to have G split up into components and assemblies, and release them separately... that is how I had to model it for automated builds. In the meantime comments like I hope that someday it will become more important in your eyes don't sit well with me. Sorry... though I think that we could have all done a better job at this if we had more longer term perspective... though I realize that given the circumstances that some corners needed to be cut to actually move forward. So, the here and now: It's poor form to update tags, but it's also poor form to release stuff with snapshots, so I went with (hopefully) the lesser of the two evils and updated the tag. geronimo.*: 1.2-SNAPSHOT - 1.2-beta tools-maven-plugin: 1.1-SNAPSHOT - 1.1 Fair warning, the tag will still not build due to the missing geronimo dependencies. Geronimo 1.2-beta is waiting on OpenEJB 2.2 to be released. As you also know, you can add this repo to your list temporarily to build: http://people.apache.org/~dain/stage/ Hope this helps, Thanks... though I hope we can avoid this in the future if possible... needing modify source to add these repos really does not help me when working from automated builds. It should have been possible to change each branch to use the right dependencies, then build them in order and produce a functional system... and a repeatable build. Inclusion of snapshots and split of specs to many branches has simply made it more difficult to make a reproducible build. --jason
Padraig O'Dowd is out of the office.
I will be out of the office starting 16/12/2006 and will not return until 02/01/2007. I will respond to your message when I return.
Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
--- Davanum Srinivas [EMAIL PROTECTED] wrote: Anita, Anyone who builds geronimo from scratch is likely to into into problem. We can't really tell people they can't use the jars they build themselves on their boxes and have to use the published SNAPSHOT jars. We do not tell people that they have to use the published jars. It is clear from this error that maven is still downloading jars from a remote repo instead of using the ones that were built locally. The only way to make sure that the local jars/cars are used is to do an offile build. Thanks Anita So i think we need to fix it. Just imagine that you are trying to fix a bug in Geronimo kernel for shipping to your customer, but the code does not have a serial version uid and the compiled jar is hence unusable...not a pretty picture. I don't think we have to worry about compatibility especially as right now if 2 jars built from same svn revision by 2 different people on different JDK's/JDK versions on different boxes, you can't mix the jars. So there is no compatibility right now :( Anyway my specific problem was because of lack of the UID in GBeanOperation and i checked in a patch for it (487759). thanks, dims On 12/16/06, anita kulshreshtha [EMAIL PROTECTED] wrote: Dims, Joe, and Prasad I wish I had seen this coming.. The compatibility of GBeanInfo was broken for 4 days (Dec 10th - Dec 14), while we discussed whether we should maintain this compatibility. In a perfect world it would not have mattered.. But sometimes Maven does not use locally built SNAPSHOTs in online build mode (some of the reasons for this are known). Once the SNAPSHOTs published during this time, are overwritten, this problem should go way. At least that is my thinking... Please correct me if I am on wrong track. Thanks Anita --- Joe Bohn [EMAIL PROTECTED] wrote: Prasad, I'm hitting this particular problem in trunk (but I have hit similar problems in 2.0-M1). I actually was trying to recreate the problem today in both trunk and 2.0-M1 ... after 4 builds on 2.0-M1 I didn't hit the problem but I hit it with the first attempt on trunk. As I mentioned, the second build attempt corrected the problem. Joe Prasad Kashyap wrote: I was able to build G successfully on a RedHat machine. I started with a completely clean repo (rm -rf .m2/repository). I did an 'svn up' of my 2.0-M1 directory. I had done a fresh checkout of these files last night. The entire tree built successfully with a -Dmaven.test.skip=true. I verified that both jetty and tomcat binaries run fine. I used the console to successfully deploy jsp-examples app on both binaries. Cheers Prasad On 12/15/06, Joe Bohn [EMAIL PROTECTED] wrote: This might be the sporadic problem after all. I just rebuilt again without any changes (still rev 487523) and the problem doesn't exist with the new images. Here's what I did this time: - mvn clean - from my local repo remove o/a/g/modules, configs, assemblies, and applications rather than removing the entire local repo. - mvn -Dstage=bootstrap - still failed in the geronimo-jetty6 SecurityTest (yes, I know I should have skipped the tests but I wanted to see if the failure/restart was in any way related to the failures) - mvn -Dstage=bootstrap -Dmaven.test.skip=true -Dmaven.itest.skip=true - mvn -Dstage=assemble -Dmaven.test.skip=true -Dmaven.itest.skip=true Joe Joe Bohn wrote: This is happening in trunk rev 487523. I'm not sure it is the same problem I reported earlier .. in fact I think it may be different and possibly related to the serialized UID change made earlier today. I was keeping careful track of what I did in case I hit the problem that I'm mentioned in other threads with the GBeanInfo object Here's what I did: - mvn clean - completely remove my local repository. - mvn -Dstage=bootstrap - this failed in modules/geronimo-jetty6 test case for SecurityTest ... expecting a 500 returned instead of a 404 that was returned. - mvn -Dstage=bootstrap -Dmaven.test.skip=true -Dmaven.itest.skip=true - mvn -Dstage=assemble -Dmaven.test.skip=true -Dmaven.itest.skip=true I then extracted the zip images created and began hitting this error attempting to start any of the generated assemblies and received the following attempting to start each of the server images. I'm building again just in case this is like the earlier problem that seems to disappear on a rebuild for no known reason. Booting Geronimo Kernel (in Java 1.5.0_06)... 13:29:19,163 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED
Re: Release Guidlines (was: Re: svn commit: r488326 - /geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml)
On Dec 18, 2006, at 10:37 PM, Jason Dillon wrote: For the M1 release I would have said close enough and made the final release from trunk. But changing the tag is harmful by itself by setting precedence... something which should not be followed, yet unless people understand why, they will just continue along those bad practices. And technically speaking, making a change to a branch or hacking up a tag should have the exact same effect on any work that anyone might need to redo for a release. And really we could thump the rule book on the ci to tags too... which is pointless for this release. The important thing is that people understand that its not appropriate to alter a tag in that manner. This is a pure policy argument, as technically from the release perspective is identical using svn, in both cases, the release must be re-cut, re- approved, blah, blah, blah. And in general for release tags, it is best to treat them as read only. We're all on the same page...I weighed the change versus lost sleep and my marriage. The commit won :) --jason On Dec 18, 2006, at 5:53 PM, David Blevins wrote: On Dec 18, 2006, at 2:59 PM, Matt Hogstrom wrote: Process of branching and tagging (we already have a plethora of discussion...I think this needs to get on a Wiki) - includes tags and modifications Discussion, proposal, resolution and final vote. http://cwiki.apache.org/GMOxPMGT/release-branching-process.html Thanks David...this is what I was referring to and I don't think we need to go through it again. I forgot it made it to the Wiki. Granted that was June, just about time to do it all over again :) In regards to the commit to the tag, I don't have a problem with it as it was completely ineffectual in any technical sense. We could of course thump the rule book and make Matt redo 8+ hours of work and have days worth of revoting followed up by a couple weeks worth of cumulative man hours on policy discussions... or we could just say close enough and focus on 2.0-M2. -David Matt Hogstrom [EMAIL PROTECTED]
Re: [VOTE] Release XBean 2.8
A note, please do not add headers to the following: ==package-info.java (./xbean-finder/src/test/java/org/acme/foo/ package-info.java) ==java.io.InputStream (./xbean-finder/src/test/resources/META-INF/ java.io.InputStream) ==java.io.OutputStream (./xbean-finder/src/test/resources/META-INF/ java.io.OutputStream) ==java.io.Serializable (./xbean-finder/src/test/resources/META-INF/ java.io.Serializable) ==one (./xbean-finder/src/test/resources/META-INF/externalizables/one) ==three (./xbean-finder/src/test/resources/META-INF/externalizables/ three) ==two (./xbean-finder/src/test/resources/META-INF/externalizables/two) ==bar (./xbean-finder/src/test/resources/META-INF/ java.net.URLStreamHandler/bar) ==baz (./xbean-finder/src/test/resources/META-INF/ java.net.URLStreamHandler/baz) ==foo (./xbean-finder/src/test/resources/META-INF/ java.net.URLStreamHandler/foo) ==kernel (./xbean-finder/src/test/resources/META-INF/ javax.naming.spi.ObjectFactory/kernel) ==ldap (./xbean-finder/src/test/resources/META-INF/ javax.naming.spi.ObjectFactory/ldap) ==ishtar.properties (./xbean-finder/src/test/resources/META-INF/ movies/ishtar.properties) ==kingkong.properties (./xbean-finder/src/test/resources/META-INF/ movies/kingkong.properties) ==serentity.properties (./xbean-finder/src/test/resources/META-INF/ movies/serentity.properties) ==one (./xbean-finder/src/test/resources/META-INF/serializables/one) ==three (./xbean-finder/src/test/resources/META-INF/serializables/ three) ==two (./xbean-finder/src/test/resources/META-INF/serializables/two) ==familyguy.properties (./xbean-finder/src/test/resources/META-INF/ tvshows/familyguy.properties) ==simpsons.properties (./xbean-finder/src/test/resources/META-INF/ tvshows/simpsons.properties) -David
[jira] Created: (GERONIMO-2672) Improving the Deployment schema documentation -geronimo-application.xsd
Improving the Deployment schema documentation -geronimo-application.xsd --- Key: GERONIMO-2672 URL: http://issues.apache.org/jira/browse/GERONIMO-2672 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: documentation Affects Versions: 1.x Environment: linux/windows Reporter: Kanchana Welagedara Assigned To: Kanchana Welagedara Priority: Minor Fix For: 1.2 Improving documentation of the geronimo-application.xsd -- 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: [VOTE] 2.0-M1 Release
+1 Jacek On 12/18/06, Matt Hogstrom [EMAIL PROTECTED] wrote: All, I have prepared 2.0-M1 for release. Of course all the hard work was done by the lot of y'all :) I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied with the results. All modes of operation functioned well (SLSB, Direct, EJB and JPA). I toned all the logs down to error to not overwhelm the users with lots of diagnostic output (they can always turn it up later if they want.) The uploads are taking forever so you'll see some piece parts trickle in. For the review I expect you'll want to focus on http:// people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies for your review and testing. I've included both Tomcat and Jetty as well as the minimal and j5ee assemblies. The source code is also there. Note that if you are planning on building you'll need to obtain the openejb-2.2-incubating jars to your local repo. The easiest way to do this is to modify the root pom and add a repository for David's home directory at http://people.apache.org/~dblevins/stage/. For SNAPSHOTs of certain plugins I have resolved these files to the most recent SNAPSHOT date / timestamp. I'm pulling a copy of these and will be putting them into our SVN for folks who may want to build in the future. I'm not too concerned about repeatability as this Milestone will be superseded at the end of January with the next version. The other MAven artifacts will be trickling onto people across my horribly slow home pipe and dropped into http://people.apache.org/ ~hogstrom/stage over the next few hours. Please review and cast your vote early. The faster we determine this build is good or if there is an issue the better. Thanks in advance for all your help in this effort. This vote will conclude at 0400 ET on Dec 21 (unless all you PMC members vote quicker :) If a respin is is necessary this vote will be suspended and a new one will start. Matt Hogstrom [EMAIL PROTECTED] -- Jacek Laskowski http://www.jaceklaskowski.pl