[jira] Commented: (GERONIMO-4475) Improve JMS portlet for AMQ 5.3 Borker configuration
[ https://issues.apache.org/jira/browse/GERONIMO-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670271#action_12670271 ] Ying Tang commented on GERONIMO-4475: - Thanks Ivan. The document has been posted on this page: http://cwiki.apache.org/confluence/display/GMOxDOC22/Configuring+the+JMS+server Any comments? > Improve JMS portlet for AMQ 5.3 Borker configuration > > > Key: GERONIMO-4475 > URL: https://issues.apache.org/jira/browse/GERONIMO-4475 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Ivan >Assignee: Donald Woods > Fix For: 2.2 > > Attachments: G4475-activemq-broker.patch, > G4475-activemq-portlet-update-02.patch, G4475-geronimo-activemq.patch, > G4475-geronimo-management.patch > > > Currently in the administrator console, the users could not add another embed > broker. Also, they could not edit the broker through administrator console. > I list the features that I could see : > 1. While creating the broker, let the use upload a configuration file. > 2. While editing the broker, show a text area, so that the user could edit > the spring XML file in it. Shall we give the user a more friendly interface, > so that they do not need the edit the XML file directly. I am not sure how it > should look like. > 3. Update the connector port let, so that while creating a new connector, > the user could specify the broker that it belongs to. > Please help to give some comments ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [GSHELL] Timeframe ?
Done. I still have a problem with the dependency on maven-project-2.1.0-r72 which I can't found anymore. I will try to upgrade to 3.0-alpha-1 and see what it gives. On Wed, Feb 4, 2009 at 04:47, Jason Dillon wrote: > Yes, go ahead. > > --jason > > > On Feb 4, 2009, at 3:04 AM, Guillaume Nodet wrote: > >> We are planning a release of ServiceMix Kernel before this month. >> Do you want me to roll back to genesis 1.6 ? >> >> On Mon, Jan 12, 2009 at 06:14, Jason Dillon wrote: >>> >>> Well, I think its mostly Genesis 2.0 that is causing the lag on GShell's >>> release. I'm going to see about fixing that this week, otherwise rolling >>> back to the Genesis 1.6 stuff for the alpha-2. >>> >>> --jason >>> >>> >>> On Jan 7, 2009, at 5:52 PM, Guillaume Nodet wrote: >>> We are planning a release of ServiceMix Kernel in the near future. What are the missing bits to release GShell soon ? On Fri, Oct 17, 2008 at 08:25, Jason Dillon wrote: > > The GShell APIs are getting closer and closer to stability. The major > changes have all been committed, and I don't have any plans to make any > other significant changes to the core APIs. What I am doing now is > trying > to slim down the core dependencies and speed up the boot time... and > sorting > out some of the many HACK/TODO comments which I've littered the > codebase > with. > > As for an alpha-2 release, I imagine that will be on the horizon soon. > I > don't plan on having all of the little things fixed before that, though > I > hope to sort out a few of the more significant ones before releasing. > If > I > had to guess I'd say that the codebase should be in a position to be > released in 2-4 weeks at present change velocity. > > --jason > > > On Oct 16, 2008, at 2:23 PM, Guillaume Nodet wrote: > >> In ServiceMix, we are considering upgrading to the latest trunk of >> GShell and I've already done the bigger part of the upgrade locally on >> my HD. Btw, I've committed a few small changes for that yesterday. >> However, I'm worried about the stability of gshell. We currently use >> an old and unreleased version of gshell, but I'd like to avoid such >> issue and having to rewrite this integration once more. >> Jason, what's your feeling about gshell's stability (in terms of APIs) >> and a possible ETA for a new release (be it alpha-2 or whatever) ? >> >> -- >> Cheers, >> Guillaume Nodet >> >> Blog: http://gnodet.blogspot.com/ >> >> Open Source SOA >> http://fusesource.com > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com >>> >>> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> >> Blog: http://gnodet.blogspot.com/ >> >> Open Source SOA >> http://fusesource.com > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[BUILD] branches/2.0: Failed for Revision: 740629
Geronimo Revision: 740629 built with tests included See the full build-0200.log file at http://people.apache.org/builds/geronimo/server/binaries/2.0/20090204/build-0200.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/2.0/20090204 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 34 minutes 24 seconds [INFO] Finished at: Wed Feb 04 02:38:14 EST 2009 [INFO] Final Memory: 219M/854M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/2.0/20090204/logs-0200-tomcat/test.log [WARNING] Deployer operation failed: java.lang.NullPointerException: key is null [WARNING] org.apache.geronimo.common.DeploymentException: java.lang.NullPointerException: key is null [WARNING] at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:400) [WARNING] at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:135) [WARNING] at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() [WARNING] at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) [WARNING] at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) [WARNING] at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) [WARNING] at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:865) [WARNING] at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) [WARNING] at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) [WARNING] at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke() [WARNING] at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) [WARNING] at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) [WARNING] at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) [WARNING] at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:865) [WARNING] at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) [WARNING] at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:168) [WARNING] at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213) [WARNING] at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220) [WARNING] at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815) [WARNING] at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784) [WARNING] at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1410) [WARNING] at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:81) [WARNING] at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1247) [WARNING] at java.security.AccessController.doPrivileged(Native Method) [WARNING] at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1350) [WARNING] at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:784) [WARNING] at sun.reflect.GeneratedMethodAccessor43.invoke(Unknown Source) [WARNING] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [WARNING] at java.lang.reflect.Method.invoke(Method.java:585) [WARNING] at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) [WARNING] at sun.rmi.transport.Transport$1.run(Transport.java:153) [WARNING] at java.security.AccessController.doPrivileged(Native Method) [WARNING] at sun.rmi.transport.Transport.serviceCall(Transport.java:149) [WARNING] at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466) [WARNING] at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) [WARNING] at java.lang.Thread.run(Thread.java:595) [WARNING] Caused by: java.lang.NullPointerException: key is null [WARNING] at org.apache.openejb.jee.KeyedCollection.add(KeyedCollection.java:92) [WARNING] at org.apache.geronimo.openejb.deployment.EjbRefBuilder.addRefs(EjbRefBuilder.java:293) [WARNING] at org.apache.geronimo.openejb.deployment.EjbRefBuilder.buildNaming(EjbRefBuilder.java:119) [WARNING] at org.apache.geronimo.openejb.deployment.EjbRefBuilder$$FastClassByCGLIB$$dbba8597.invoke() [WARNING] at net.sf.cglib.reflect.F
[jira] Updated: (GERONIMO-4525) No effective exit code for all Windows commands
[ https://issues.apache.org/jira/browse/GERONIMO-4525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4525: --- Attachment: Geronimo-4525_Jack.patch Enforcing process exit code with "cmd /c exit /b n", because "exit /b n" does not do that. Tested and works well. > No effective exit code for all Windows commands > --- > > Key: GERONIMO-4525 > URL: https://issues.apache.org/jira/browse/GERONIMO-4525 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: commands >Affects Versions: 2.1.3 > Environment: MS Windows >Reporter: Jack Cai > Fix For: 2.1.4, 2.2 > > Attachments: Geronimo-4525_Jack.patch > > > There are multiple problems in the current Windows batch commands (including > geronimo.bat, startup.bat, etc.) > - It's not recommended to define an environment variable with the name > ERRORLEVEL. See [1]. > - Set a value to ERRORLEVEL has no effect to the exit code of the batch > command (so the documented exit code "0" and "1" are not actually there). > - The value of the ERRORLEVEL variable will also get unset when the > "@endlocal" command is called. > [1] http://blogs.msdn.com/oldnewthing/archive/2008/09/26/8965755.aspx -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4527) Geronimo 2.0.x branch does not build after updating OpenEJB to released version (3.0)
[ https://issues.apache.org/jira/browse/GERONIMO-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-4527: Description: Because of a number of changes that have occurred in dependencies of Geronimo it will no longer build. In particular, after changing the dependency on OpenEJB from 3.0-beta-1 to 3.0, the build stopped working. Due to changes in the group/artifact names of the artifacts for XBeans - OpenEJB 3.0 no longer builds. There is now a new snapshot version of OpenEJB (3.0.1-SNAPSHOT). These changes include the new snapshot version of OpenEJB rather than the unbuildable 3.0 version. was:Because of a number of changes that have occurred in dependencies of Geronimo it will no longer build. Summary: Geronimo 2.0.x branch does not build after updating OpenEJB to released version (3.0) (was: Geronimo 2.0.x branch does not build with tests) Sorry for any confusion. This issue sprung up as a result of removing the dependency to the beta version of OpenEJB locally. > Geronimo 2.0.x branch does not build after updating OpenEJB to released > version (3.0) > - > > Key: GERONIMO-4527 > URL: https://issues.apache.org/jira/browse/GERONIMO-4527 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: core, kernel, OpenEJB >Affects Versions: 2.0.3 >Reporter: Jay D. McHugh >Assignee: Jay D. McHugh > Fix For: 2.0.3 > > Attachments: geronimo-4527.diff > > > Because of a number of changes that have occurred in dependencies of Geronimo > it will no longer build. > In particular, after changing the dependency on OpenEJB from 3.0-beta-1 to > 3.0, the build stopped working. > Due to changes in the group/artifact names of the artifacts for XBeans - > OpenEJB 3.0 no longer builds. There is now a new snapshot version of OpenEJB > (3.0.1-SNAPSHOT). These changes include the new snapshot version of OpenEJB > rather than the unbuildable 3.0 version. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4525) No effective exit code for all Windows commands
[ https://issues.apache.org/jira/browse/GERONIMO-4525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4525: --- Attachment: (was: Geronimo-4525.patch) > No effective exit code for all Windows commands > --- > > Key: GERONIMO-4525 > URL: https://issues.apache.org/jira/browse/GERONIMO-4525 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: commands >Affects Versions: 2.1.3 > Environment: MS Windows >Reporter: Jack Cai > Fix For: 2.1.4, 2.2 > > > There are multiple problems in the current Windows batch commands (including > geronimo.bat, startup.bat, etc.) > - It's not recommended to define an environment variable with the name > ERRORLEVEL. See [1]. > - Set a value to ERRORLEVEL has no effect to the exit code of the batch > command (so the documented exit code "0" and "1" are not actually there). > - The value of the ERRORLEVEL variable will also get unset when the > "@endlocal" command is called. > [1] http://blogs.msdn.com/oldnewthing/archive/2008/09/26/8965755.aspx -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4527) Geronimo 2.0.x branch does not build with tests
[ https://issues.apache.org/jira/browse/GERONIMO-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670248#action_12670248 ] Jarek Gawor commented on GERONIMO-4527: --- I understand. It was just confusing as the name of the bug implies the branch does not build as it. But it only does not build if you locally updated to openejb 3.0. > Geronimo 2.0.x branch does not build with tests > --- > > Key: GERONIMO-4527 > URL: https://issues.apache.org/jira/browse/GERONIMO-4527 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: core, kernel, OpenEJB >Affects Versions: 2.0.3 >Reporter: Jay D. McHugh >Assignee: Jay D. McHugh > Fix For: 2.0.3 > > Attachments: geronimo-4527.diff > > > Because of a number of changes that have occurred in dependencies of Geronimo > it will no longer build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4527) Geronimo 2.0.x branch does not build with tests
[ https://issues.apache.org/jira/browse/GERONIMO-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670246#action_12670246 ] Jay D. McHugh commented on GERONIMO-4527: - I have been trying to get 2.0 ready for release - including removing dependencies on beta versions. When I moved it to point it at OpenEJB 3.0 (rather than 3.0-beta-1), the build stopped working. If you switch away from the beta version, does the build still work for you? > Geronimo 2.0.x branch does not build with tests > --- > > Key: GERONIMO-4527 > URL: https://issues.apache.org/jira/browse/GERONIMO-4527 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: core, kernel, OpenEJB >Affects Versions: 2.0.3 >Reporter: Jay D. McHugh >Assignee: Jay D. McHugh > Fix For: 2.0.3 > > Attachments: geronimo-4527.diff > > > Because of a number of changes that have occurred in dependencies of Geronimo > it will no longer build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4527) Geronimo 2.0.x branch does not build with tests
[ https://issues.apache.org/jira/browse/GERONIMO-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670244#action_12670244 ] Jarek Gawor commented on GERONIMO-4527: --- You mean it doesn't build if you update to OpenEJB 3.0.1-SNAPSHOT? The branches/2.0 builds fine without any changes... > Geronimo 2.0.x branch does not build with tests > --- > > Key: GERONIMO-4527 > URL: https://issues.apache.org/jira/browse/GERONIMO-4527 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: core, kernel, OpenEJB >Affects Versions: 2.0.3 >Reporter: Jay D. McHugh >Assignee: Jay D. McHugh > Fix For: 2.0.3 > > Attachments: geronimo-4527.diff > > > Because of a number of changes that have occurred in dependencies of Geronimo > it will no longer build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4527) Geronimo 2.0.x branch does not build with tests
[ https://issues.apache.org/jira/browse/GERONIMO-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh resolved GERONIMO-4527. - Resolution: Fixed Fix Version/s: 2.0.3 Changes committed to branches/2.0 Sending modules/geronimo-client/src/main/java/org/apache/geronimo/client/AppClientContainer.java Sending modules/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java Sending modules/geronimo-openejb-builder/src/main/java/org/apache/geronimo/openejb/deployment/EjbRefBuilder.java Sendingpom.xml Transmitting file data Committed revision 740608. > Geronimo 2.0.x branch does not build with tests > --- > > Key: GERONIMO-4527 > URL: https://issues.apache.org/jira/browse/GERONIMO-4527 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: core, kernel, OpenEJB >Affects Versions: 2.0.3 >Reporter: Jay D. McHugh >Assignee: Jay D. McHugh > Fix For: 2.0.3 > > Attachments: geronimo-4527.diff > > > Because of a number of changes that have occurred in dependencies of Geronimo > it will no longer build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4527) Geronimo 2.0.x branch does not build with tests
[ https://issues.apache.org/jira/browse/GERONIMO-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-4527: Attachment: geronimo-4527.diff Put all of the changes here so that there would be an easily reviewable set of changes if anyone cared to see what was changed to fix the build. > Geronimo 2.0.x branch does not build with tests > --- > > Key: GERONIMO-4527 > URL: https://issues.apache.org/jira/browse/GERONIMO-4527 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: core, kernel, OpenEJB >Affects Versions: 2.0.3 >Reporter: Jay D. McHugh >Assignee: Jay D. McHugh > Attachments: geronimo-4527.diff > > > Because of a number of changes that have occurred in dependencies of Geronimo > it will no longer build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4527) Geronimo 2.0.x branch does not build with tests
Geronimo 2.0.x branch does not build with tests --- Key: GERONIMO-4527 URL: https://issues.apache.org/jira/browse/GERONIMO-4527 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: core, kernel, OpenEJB Affects Versions: 2.0.3 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Because of a number of changes that have occurred in dependencies of Geronimo it will no longer build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [GSHELL] Timeframe ?
Yes, go ahead. --jason On Feb 4, 2009, at 3:04 AM, Guillaume Nodet wrote: We are planning a release of ServiceMix Kernel before this month. Do you want me to roll back to genesis 1.6 ? On Mon, Jan 12, 2009 at 06:14, Jason Dillon wrote: Well, I think its mostly Genesis 2.0 that is causing the lag on GShell's release. I'm going to see about fixing that this week, otherwise rolling back to the Genesis 1.6 stuff for the alpha-2. --jason On Jan 7, 2009, at 5:52 PM, Guillaume Nodet wrote: We are planning a release of ServiceMix Kernel in the near future. What are the missing bits to release GShell soon ? On Fri, Oct 17, 2008 at 08:25, Jason Dillon wrote: The GShell APIs are getting closer and closer to stability. The major changes have all been committed, and I don't have any plans to make any other significant changes to the core APIs. What I am doing now is trying to slim down the core dependencies and speed up the boot time... and sorting out some of the many HACK/TODO comments which I've littered the codebase with. As for an alpha-2 release, I imagine that will be on the horizon soon. I don't plan on having all of the little things fixed before that, though I hope to sort out a few of the more significant ones before releasing. If I had to guess I'd say that the codebase should be in a position to be released in 2-4 weeks at present change velocity. --jason On Oct 16, 2008, at 2:23 PM, Guillaume Nodet wrote: In ServiceMix, we are considering upgrading to the latest trunk of GShell and I've already done the bigger part of the upgrade locally on my HD. Btw, I've committed a few small changes for that yesterday. However, I'm worried about the stability of gshell. We currently use an old and unreleased version of gshell, but I'd like to avoid such issue and having to rewrite this integration once more. Jason, what's your feeling about gshell's stability (in terms of APIs) and a possible ETA for a new release (be it alpha-2 or whatever) ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[BUILD] trunk: Failed for Revision: 740553
Geronimo Revision: 740553 built with tests included
See the full build-2100.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090203/build-2100.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090203
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 38 minutes 2 seconds
[INFO] Finished at: Tue Feb 03 21:43:40 EST 2009
[INFO] Final Memory: 630M/976M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090203/logs-2100-tomcat/test.log
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:43.490
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 36 test builds
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deploy RUNNING
[INFO] commands-testsuite/deploy SUCCESS (0:01:00.108)
[INFO] commands-testsuite/gshell RUNNING
[INFO] commands-testsuite/gshell SUCCESS (0:00:28.742)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:34.194)
[INFO] commands-testsuite/shutdownRUNNING
[INFO] commands-testsuite/shutdownSUCCESS (0:00:16.376)
[INFO] concurrent-testsuite/concurrent-basic RUNNING
[INFO] concurrent-testsuite/concurrent-basic SUCCESS (0:06:11.806)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced SUCCESS (0:01:20.058)
[INFO] console-testsuite/basicRUNNING
[INFO] console-testsuite/basicSUCCESS (0:01:43.620)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:45.503)
[INFO] corba-testsuite/corba-marshal RUNNING
[INFO] corba-testsuite/corba-marshal SUCCESS (0:00:50.177)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:40.445)
[INFO] deployment-testsuite/deployment-tests RUNNING
[INFO] deployment-testsuite/deployment-tests SUCCESS (0:00:30.194)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:29.650)
[INFO] deployment-testsuite/manifestcp-tests RUNNING
[INFO] deployment-testsuite/manifestcp-tests SUCCESS (0:00:31.581)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:48.331)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:52.158)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:01:04.005)
[INFO] enterprise-testsuite/sec-clientRUNNING
[INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:27.296)
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:48.252)
[INFO] security-testsuite/test-security RUNNING
[INFO] security-testsuite/test-security FAILURE (0:00:37.922) Java
returned: 1
[INFO] web-testsuite/test-2.1-jspsRUNNING
[INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:29.598)
[INFO] web-testsuite/test-2.5-servletsRUNNING
[INFO] web-testsuite/test-2.5
Re: Time for Geronimo 2.1.4 release?
Thanks Jarek! The JIRA list in the status page looks like pretty old (dated as "20081119 @ 10:15 EST"). I can make it updated if this helps... BTW, would someone please help to review and commit the fix for GERONIMO-4525? One user wants to call the shell commands and check the exit code accordingly. I hope this fix can go into the coming 2.1.4 release. - Jack 2009/2/4 Jarek Gawor > Hi, > > I think it's time for Geronimo 2.1.4 release. We've had a lot of > important fixes since 2.1.3 and we should get them out to our users. > And if we agree, I would also like to volunteer to be a release > manager for this release. > > Looking at the current status for 2.1.4 there are still a few things > that we need to do before we can go ahead with the release. I updated > the > http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+2.1.4+Release+Status > page with some of these items. If there are any open bugs that _need_ > to be fixed for 2.1.4 or if I missed anything in that list please just > update that wiki page. > > Thanks, > Jarek >
[jira] Closed: (GERONIMO-4337) Upgrade to activeMQ 5.x
[ https://issues.apache.org/jira/browse/GERONIMO-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-4337. -- Resolution: Fixed I think this is stable enough so we can use individual jira entries for any remaining problems. > Upgrade to activeMQ 5.x > --- > > Key: GERONIMO-4337 > URL: https://issues.apache.org/jira/browse/GERONIMO-4337 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: ActiveMQ >Affects Versions: 2.2 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 2.2 > > Attachments: geronimo-plugins.xml, plugins.svn.diff.zip, svn.diff > > > Upgrade activemq support to 5.x. A few steps along the way: > - create an activemq5 work area under plugins > - move the specification of amq version from the root pom dependency > management to the activemq and activemq5 plugins. > - keep only the broker gbean > - use an activemq configuration file in var/activemq, referenced by the > broker gbean > - update dependencies to latest activemq > - figure out how much of the current jms portlet functionality can be > reasonably kept. From discussions with Hiram I think that trying to > reconfigure the broker while its running is a very bad idea and we should > just drop the parts of the console that try to do this. > - investigate how to run the amq console in geronimo, preferably as portlets > inside the g. admin console. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3964) Concentrate spec security setup for webapps into one class. Consider not using excluded permissions
[ https://issues.apache.org/jira/browse/GERONIMO-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3964. -- Resolution: Fixed Trunk has been without excluded permissions for some time and no problems have surfaced. > Concentrate spec security setup for webapps into one class. Consider not > using excluded permissions > --- > > Key: GERONIMO-3964 > URL: https://issues.apache.org/jira/browse/GERONIMO-3964 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: security >Affects Versions: 2.2 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 2.2 > > > The security building code is a bit spread out between the jetty/tomcat web > module builders, the parent AbstractWebModuleBuilder, and some classes in > geronimo-security. > (1) reorganize this so its easier to understand with all the code in a single > package in the abstract web module builder module. Also, only use one call > to do all the building. > (2) Theoretically, excluded permissions are a bit weird why not simple > not hand out those permissions in the first place? After the reorganization > I'm planning to investigate how plausible this is. No excluded permissions > fit better into a standard rbac framework and are much easier to think about > IMO. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4239) car-maven-plugin dependencies configuration should enhance maven dependencies
[ https://issues.apache.org/jira/browse/GERONIMO-4239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-4239. -- Resolution: Fixed I think this is as done as it will get. > car-maven-plugin dependencies configuration should enhance maven dependencies > - > > Key: GERONIMO-4239 > URL: https://issues.apache.org/jira/browse/GERONIMO-4239 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: car-maven-plugin >Affects Versions: 2.2 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 2.2 > > > When useMavenDependencies is true, we should take any info in the c-m-p > plugin configuration dependencies section and use it to enhance the maven > dependencies with and information. This should let us > _always_ have useMavenDependencies on and result in much shorter plugin > configurations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4526) ejbTimout method not subject to permission checks
[ https://issues.apache.org/jira/browse/GERONIMO-4526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670180#action_12670180 ] David Jencks commented on GERONIMO-4526: branches/2.1 fixed in rev 740521 > ejbTimout method not subject to permission checks > - > > Key: GERONIMO-4526 > URL: https://issues.apache.org/jira/browse/GERONIMO-4526 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: OpenEJB >Affects Versions: 2.1.4, 2.2 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 2.1.4, 2.2 > > > Right now if you have security enabled ejbTimeout calls don't work, they get > an unauth exception. > Need to fix it so the permissions that aren't from an interface get into the > unchecked permissions. If someone adds the ejbTimeout method to an > interface, that will get a different permission so the new unchecked > permission shouldn't allow unwanted access. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Time for Geronimo 2.1.4 release?
Those classes that Geronimo is looking for are OpenEJB classes. Jay Jay D. McHugh wrote: > The problem is with the version of ASM that is brought in when using a > higher version of XBeans. > > OpenEJB is using a method that has been removed: > org.objectweb.asm.ClassReader.accept > > And Geronimo (already - not counting XBeans 3.5) is using classes that > have been removed: > LinkResolver > UniqueDefaultLinkResolver > > Jay > > Joe Bohn wrote: >> Thanks for the info Jay and for doing some more digging. >> >> I don't really have a strong desire to push everything to xBean 3.5. I >> was just trying to eliminate the use of multiple xBean versions as this >> could potentially cause problems (and confusion) for our users. >> >> It looks like we originally moved up to xBean 3.5 (actually >> 3.5-SNAPSHOT) to resolve a jca context issue (Geronimo-4375). However, >> it looks like it was soon discovered that there were issues with the >> OpenEJB, ASM and xBean versions in G. As a result ... we ended up >> reverting back to an older ASM and xBean 3.3 for finder and reflect >> while keeping the newer xbean-naming 3.5 so that the original issue was >> still resolved. That seems to be working and is perhaps the best >> approach. I was just concerned about using the various xBean versions >> in our Geronimo 2.1.4 server. Perhaps using the various xBean versions >> is still the best thing to do here. I didn't realize that there were >> core issues in OpenEJB attempting to use anything greater than 3.4.1. >> >> Thanks, >> Joe >> >> >> Jay D. McHugh wrote: >>> Hey everyone, >>> >>> If we want to get OpenEJB 3.0.1 to move up to XBeans 3.5, then I think >>> that we'll need to chip in to resolve the problems that pop up when you >>> use a version greater than 3.4.1. >>> >>> That was the highest version (available at the time) that could be used >>> in the OpenEJB 3.0 branch without causing errors. >>> >>> I'll try switching to XBeans 3.5 (after the build I am in the middle of >>> finishes) and let you all know if it goes through cleanly. >>> >>> My feeling is that it won't though. >>> >>> Also, I have been trying to get a 'final' Geronimo 2.0.x release put >>> together and will need OpenEJB 3.0.1 for that (3.0 no longer builds >>> because the artifacts for XBeans changed groupIds). >>> >>> Jay >>> >>> Joe Bohn wrote: I was relaying the information second-hand ... so it's very possible I got it wrong. It looks like there is a dependency xBean in OpenEJB ... but it's 3.4.1 rather than 3.3 (as we have in the branches/2.1). So, perhaps if we can convince OpenEJB 3.0.x to xBean 3.5 we can then make the references consistent in our 2.1 branch. Thanks, Joe Donald Woods wrote: > I don't see any dependencies on Xbean in OpenJPA 1.0.x or 1.2.x. > Maybe you're thinking about OpenEJB? > > > -Donald > > > Joe Bohn wrote: >> I agree we should get a 2.1.4 release out ... and you certainly have >> my vote for release manager! >> >> The only thing I would add to the list is to get our xBean references >> to a consistent versions. I noticed this as I was updating >> branches/2.1 and trunk to pull in the newly released xBean 3.5. In >> branches/2.1 we have a mix of 3.3 dependencies (finder and reflect) >> and 3.5 dependencies (naming). I've been told that this was due to >> OpenJPA dependencies on 3.3. Now that we are pulling in a new >> OpenJPA release we will hopefully be able to update everything to use >> xBean 3.5. >> >> Joe >> >> >> Jarek Gawor wrote: >>> Hi, >>> >>> I think it's time for Geronimo 2.1.4 release. We've had a lot of >>> important fixes since 2.1.3 and we should get them out to our users. >>> And if we agree, I would also like to volunteer to be a release >>> manager for this release. >>> >>> Looking at the current status for 2.1.4 there are still a few things >>> that we need to do before we can go ahead with the release. I updated >>> the >>> http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+2.1.4+Release+Status >>> >>> >>> page with some of these items. If there are any open bugs that _need_ >>> to be fixed for 2.1.4 or if I missed anything in that list please >>> just >>> update that wiki page. >>> >>> Thanks, >>> Jarek >>>
Re: Time for Geronimo 2.1.4 release?
The problem is with the version of ASM that is brought in when using a higher version of XBeans. OpenEJB is using a method that has been removed: org.objectweb.asm.ClassReader.accept And Geronimo (already - not counting XBeans 3.5) is using classes that have been removed: LinkResolver UniqueDefaultLinkResolver Jay Joe Bohn wrote: > Thanks for the info Jay and for doing some more digging. > > I don't really have a strong desire to push everything to xBean 3.5. I > was just trying to eliminate the use of multiple xBean versions as this > could potentially cause problems (and confusion) for our users. > > It looks like we originally moved up to xBean 3.5 (actually > 3.5-SNAPSHOT) to resolve a jca context issue (Geronimo-4375). However, > it looks like it was soon discovered that there were issues with the > OpenEJB, ASM and xBean versions in G. As a result ... we ended up > reverting back to an older ASM and xBean 3.3 for finder and reflect > while keeping the newer xbean-naming 3.5 so that the original issue was > still resolved. That seems to be working and is perhaps the best > approach. I was just concerned about using the various xBean versions > in our Geronimo 2.1.4 server. Perhaps using the various xBean versions > is still the best thing to do here. I didn't realize that there were > core issues in OpenEJB attempting to use anything greater than 3.4.1. > > Thanks, > Joe > > > Jay D. McHugh wrote: >> Hey everyone, >> >> If we want to get OpenEJB 3.0.1 to move up to XBeans 3.5, then I think >> that we'll need to chip in to resolve the problems that pop up when you >> use a version greater than 3.4.1. >> >> That was the highest version (available at the time) that could be used >> in the OpenEJB 3.0 branch without causing errors. >> >> I'll try switching to XBeans 3.5 (after the build I am in the middle of >> finishes) and let you all know if it goes through cleanly. >> >> My feeling is that it won't though. >> >> Also, I have been trying to get a 'final' Geronimo 2.0.x release put >> together and will need OpenEJB 3.0.1 for that (3.0 no longer builds >> because the artifacts for XBeans changed groupIds). >> >> Jay >> >> Joe Bohn wrote: >>> I was relaying the information second-hand ... so it's very possible I >>> got it wrong. >>> >>> It looks like there is a dependency xBean in OpenEJB ... but it's 3.4.1 >>> rather than 3.3 (as we have in the branches/2.1). So, perhaps if we can >>> convince OpenEJB 3.0.x to xBean 3.5 we can then make the references >>> consistent in our 2.1 branch. >>> >>> Thanks, >>> Joe >>> >>> >>> Donald Woods wrote: I don't see any dependencies on Xbean in OpenJPA 1.0.x or 1.2.x. Maybe you're thinking about OpenEJB? -Donald Joe Bohn wrote: > I agree we should get a 2.1.4 release out ... and you certainly have > my vote for release manager! > > The only thing I would add to the list is to get our xBean references > to a consistent versions. I noticed this as I was updating > branches/2.1 and trunk to pull in the newly released xBean 3.5. In > branches/2.1 we have a mix of 3.3 dependencies (finder and reflect) > and 3.5 dependencies (naming). I've been told that this was due to > OpenJPA dependencies on 3.3. Now that we are pulling in a new > OpenJPA release we will hopefully be able to update everything to use > xBean 3.5. > > Joe > > > Jarek Gawor wrote: >> Hi, >> >> I think it's time for Geronimo 2.1.4 release. We've had a lot of >> important fixes since 2.1.3 and we should get them out to our users. >> And if we agree, I would also like to volunteer to be a release >> manager for this release. >> >> Looking at the current status for 2.1.4 there are still a few things >> that we need to do before we can go ahead with the release. I updated >> the >> http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+2.1.4+Release+Status >> >> >> page with some of these items. If there are any open bugs that _need_ >> to be fixed for 2.1.4 or if I missed anything in that list please >> just >> update that wiki page. >> >> Thanks, >> Jarek >> > >> >
Re: Time for Geronimo 2.1.4 release?
Thanks for the info Jay and for doing some more digging. I don't really have a strong desire to push everything to xBean 3.5. I was just trying to eliminate the use of multiple xBean versions as this could potentially cause problems (and confusion) for our users. It looks like we originally moved up to xBean 3.5 (actually 3.5-SNAPSHOT) to resolve a jca context issue (Geronimo-4375). However, it looks like it was soon discovered that there were issues with the OpenEJB, ASM and xBean versions in G. As a result ... we ended up reverting back to an older ASM and xBean 3.3 for finder and reflect while keeping the newer xbean-naming 3.5 so that the original issue was still resolved. That seems to be working and is perhaps the best approach. I was just concerned about using the various xBean versions in our Geronimo 2.1.4 server. Perhaps using the various xBean versions is still the best thing to do here. I didn't realize that there were core issues in OpenEJB attempting to use anything greater than 3.4.1. Thanks, Joe Jay D. McHugh wrote: Hey everyone, If we want to get OpenEJB 3.0.1 to move up to XBeans 3.5, then I think that we'll need to chip in to resolve the problems that pop up when you use a version greater than 3.4.1. That was the highest version (available at the time) that could be used in the OpenEJB 3.0 branch without causing errors. I'll try switching to XBeans 3.5 (after the build I am in the middle of finishes) and let you all know if it goes through cleanly. My feeling is that it won't though. Also, I have been trying to get a 'final' Geronimo 2.0.x release put together and will need OpenEJB 3.0.1 for that (3.0 no longer builds because the artifacts for XBeans changed groupIds). Jay Joe Bohn wrote: I was relaying the information second-hand ... so it's very possible I got it wrong. It looks like there is a dependency xBean in OpenEJB ... but it's 3.4.1 rather than 3.3 (as we have in the branches/2.1). So, perhaps if we can convince OpenEJB 3.0.x to xBean 3.5 we can then make the references consistent in our 2.1 branch. Thanks, Joe Donald Woods wrote: I don't see any dependencies on Xbean in OpenJPA 1.0.x or 1.2.x. Maybe you're thinking about OpenEJB? -Donald Joe Bohn wrote: I agree we should get a 2.1.4 release out ... and you certainly have my vote for release manager! The only thing I would add to the list is to get our xBean references to a consistent versions. I noticed this as I was updating branches/2.1 and trunk to pull in the newly released xBean 3.5. In branches/2.1 we have a mix of 3.3 dependencies (finder and reflect) and 3.5 dependencies (naming). I've been told that this was due to OpenJPA dependencies on 3.3. Now that we are pulling in a new OpenJPA release we will hopefully be able to update everything to use xBean 3.5. Joe Jarek Gawor wrote: Hi, I think it's time for Geronimo 2.1.4 release. We've had a lot of important fixes since 2.1.3 and we should get them out to our users. And if we agree, I would also like to volunteer to be a release manager for this release. Looking at the current status for 2.1.4 there are still a few things that we need to do before we can go ahead with the release. I updated the http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+2.1.4+Release+Status page with some of these items. If there are any open bugs that _need_ to be fixed for 2.1.4 or if I missed anything in that list please just update that wiki page. Thanks, Jarek
Re: Time for Geronimo 2.1.4 release?
Hey everyone, If we want to get OpenEJB 3.0.1 to move up to XBeans 3.5, then I think that we'll need to chip in to resolve the problems that pop up when you use a version greater than 3.4.1. That was the highest version (available at the time) that could be used in the OpenEJB 3.0 branch without causing errors. I'll try switching to XBeans 3.5 (after the build I am in the middle of finishes) and let you all know if it goes through cleanly. My feeling is that it won't though. Also, I have been trying to get a 'final' Geronimo 2.0.x release put together and will need OpenEJB 3.0.1 for that (3.0 no longer builds because the artifacts for XBeans changed groupIds). Jay Joe Bohn wrote: > I was relaying the information second-hand ... so it's very possible I > got it wrong. > > It looks like there is a dependency xBean in OpenEJB ... but it's 3.4.1 > rather than 3.3 (as we have in the branches/2.1). So, perhaps if we can > convince OpenEJB 3.0.x to xBean 3.5 we can then make the references > consistent in our 2.1 branch. > > Thanks, > Joe > > > Donald Woods wrote: >> I don't see any dependencies on Xbean in OpenJPA 1.0.x or 1.2.x. >> Maybe you're thinking about OpenEJB? >> >> >> -Donald >> >> >> Joe Bohn wrote: >>> I agree we should get a 2.1.4 release out ... and you certainly have >>> my vote for release manager! >>> >>> The only thing I would add to the list is to get our xBean references >>> to a consistent versions. I noticed this as I was updating >>> branches/2.1 and trunk to pull in the newly released xBean 3.5. In >>> branches/2.1 we have a mix of 3.3 dependencies (finder and reflect) >>> and 3.5 dependencies (naming). I've been told that this was due to >>> OpenJPA dependencies on 3.3. Now that we are pulling in a new >>> OpenJPA release we will hopefully be able to update everything to use >>> xBean 3.5. >>> >>> Joe >>> >>> >>> Jarek Gawor wrote: Hi, I think it's time for Geronimo 2.1.4 release. We've had a lot of important fixes since 2.1.3 and we should get them out to our users. And if we agree, I would also like to volunteer to be a release manager for this release. Looking at the current status for 2.1.4 there are still a few things that we need to do before we can go ahead with the release. I updated the http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+2.1.4+Release+Status page with some of these items. If there are any open bugs that _need_ to be fixed for 2.1.4 or if I missed anything in that list please just update that wiki page. Thanks, Jarek >>> >>> >> >
Re: Time for Geronimo 2.1.4 release?
I was relaying the information second-hand ... so it's very possible I got it wrong. It looks like there is a dependency xBean in OpenEJB ... but it's 3.4.1 rather than 3.3 (as we have in the branches/2.1). So, perhaps if we can convince OpenEJB 3.0.x to xBean 3.5 we can then make the references consistent in our 2.1 branch. Thanks, Joe Donald Woods wrote: I don't see any dependencies on Xbean in OpenJPA 1.0.x or 1.2.x. Maybe you're thinking about OpenEJB? -Donald Joe Bohn wrote: I agree we should get a 2.1.4 release out ... and you certainly have my vote for release manager! The only thing I would add to the list is to get our xBean references to a consistent versions. I noticed this as I was updating branches/2.1 and trunk to pull in the newly released xBean 3.5. In branches/2.1 we have a mix of 3.3 dependencies (finder and reflect) and 3.5 dependencies (naming). I've been told that this was due to OpenJPA dependencies on 3.3. Now that we are pulling in a new OpenJPA release we will hopefully be able to update everything to use xBean 3.5. Joe Jarek Gawor wrote: Hi, I think it's time for Geronimo 2.1.4 release. We've had a lot of important fixes since 2.1.3 and we should get them out to our users. And if we agree, I would also like to volunteer to be a release manager for this release. Looking at the current status for 2.1.4 there are still a few things that we need to do before we can go ahead with the release. I updated the http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+2.1.4+Release+Status page with some of these items. If there are any open bugs that _need_ to be fixed for 2.1.4 or if I missed anything in that list please just update that wiki page. Thanks, Jarek
Re: Time for Geronimo 2.1.4 release?
I don't see any dependencies on Xbean in OpenJPA 1.0.x or 1.2.x. Maybe you're thinking about OpenEJB? -Donald Joe Bohn wrote: I agree we should get a 2.1.4 release out ... and you certainly have my vote for release manager! The only thing I would add to the list is to get our xBean references to a consistent versions. I noticed this as I was updating branches/2.1 and trunk to pull in the newly released xBean 3.5. In branches/2.1 we have a mix of 3.3 dependencies (finder and reflect) and 3.5 dependencies (naming). I've been told that this was due to OpenJPA dependencies on 3.3. Now that we are pulling in a new OpenJPA release we will hopefully be able to update everything to use xBean 3.5. Joe Jarek Gawor wrote: Hi, I think it's time for Geronimo 2.1.4 release. We've had a lot of important fixes since 2.1.3 and we should get them out to our users. And if we agree, I would also like to volunteer to be a release manager for this release. Looking at the current status for 2.1.4 there are still a few things that we need to do before we can go ahead with the release. I updated the http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+2.1.4+Release+Status page with some of these items. If there are any open bugs that _need_ to be fixed for 2.1.4 or if I missed anything in that list please just update that wiki page. Thanks, Jarek
Re: Time for Geronimo 2.1.4 release?
Agree and thanks for volunteering. -Donald Jarek Gawor wrote: Hi, I think it's time for Geronimo 2.1.4 release. We've had a lot of important fixes since 2.1.3 and we should get them out to our users. And if we agree, I would also like to volunteer to be a release manager for this release. Looking at the current status for 2.1.4 there are still a few things that we need to do before we can go ahead with the release. I updated the http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+2.1.4+Release+Status page with some of these items. If there are any open bugs that _need_ to be fixed for 2.1.4 or if I missed anything in that list please just update that wiki page. Thanks, Jarek
Re: Time for Geronimo 2.1.4 release?
+1 Thanks for volunteering to be the release manager! Lin On Tue, Feb 3, 2009 at 2:43 PM, Jarek Gawor wrote: > Hi, > > I think it's time for Geronimo 2.1.4 release. We've had a lot of > important fixes since 2.1.3 and we should get them out to our users. > And if we agree, I would also like to volunteer to be a release > manager for this release. > > Looking at the current status for 2.1.4 there are still a few things > that we need to do before we can go ahead with the release. I updated > the > http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+2.1.4+Release+Status > page with some of these items. If there are any open bugs that _need_ > to be fixed for 2.1.4 or if I missed anything in that list please just > update that wiki page. > > Thanks, > Jarek >
Re: [GSHELL] Timeframe ?
We are planning a release of ServiceMix Kernel before this month. Do you want me to roll back to genesis 1.6 ? On Mon, Jan 12, 2009 at 06:14, Jason Dillon wrote: > Well, I think its mostly Genesis 2.0 that is causing the lag on GShell's > release. I'm going to see about fixing that this week, otherwise rolling > back to the Genesis 1.6 stuff for the alpha-2. > > --jason > > > On Jan 7, 2009, at 5:52 PM, Guillaume Nodet wrote: > >> We are planning a release of ServiceMix Kernel in the near future. >> What are the missing bits to release GShell soon ? >> >> On Fri, Oct 17, 2008 at 08:25, Jason Dillon >> wrote: >>> >>> The GShell APIs are getting closer and closer to stability. The major >>> changes have all been committed, and I don't have any plans to make any >>> other significant changes to the core APIs. What I am doing now is >>> trying >>> to slim down the core dependencies and speed up the boot time... and >>> sorting >>> out some of the many HACK/TODO comments which I've littered the codebase >>> with. >>> >>> As for an alpha-2 release, I imagine that will be on the horizon soon. I >>> don't plan on having all of the little things fixed before that, though I >>> hope to sort out a few of the more significant ones before releasing. If >>> I >>> had to guess I'd say that the codebase should be in a position to be >>> released in 2-4 weeks at present change velocity. >>> >>> --jason >>> >>> >>> On Oct 16, 2008, at 2:23 PM, Guillaume Nodet wrote: >>> In ServiceMix, we are considering upgrading to the latest trunk of GShell and I've already done the bigger part of the upgrade locally on my HD. Btw, I've committed a few small changes for that yesterday. However, I'm worried about the stability of gshell. We currently use an old and unreleased version of gshell, but I'd like to avoid such issue and having to rewrite this integration once more. Jason, what's your feeling about gshell's stability (in terms of APIs) and a possible ETA for a new release (be it alpha-2 or whatever) ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com >>> >>> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> >> Blog: http://gnodet.blogspot.com/ >> >> Open Source SOA >> http://fusesource.com > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Plans for a OpenJPA 1.2.1 release?
Actually, looks like we may still have 2 TCK tests that are failing with OpenJPA 1.2.0/1.2.1-SNAPSHOT, that pass if we rollback to the 1.0.3 release, so let's put creating that branch on hold until we can further debug the failures we are seeing. Thanks, Donald Michael Dick wrote: Hi Donald, I'm looking into this at the moment. I need to do some JIRA issue cleanup (I suspect) but I'll try to get the branch created later tonight. -mike On Tue, Feb 3, 2009 at 12:37 PM, Donald Woods wrote: Have we started planning a OpenJPA 1.2.1 release? The upcoming Geronimo 2.1.4 release would like to include an updated OpenJPA release due to the issue mentioned below. Thanks, Donald Original Message On Jan 27, 2009, at 11:39 AM, Donald Woods wrote: Do we need to upgrade to OpenJPA 1.2.1-SNAPSHOT and approach the OpenJPA team for a release, based on the resolution in - https://issues.apache.org/jira/browse/OPENJPA-872 Yes. I'm in the process of sending them a note... Looks like we could consider using to work-around the problem, if necessary. --kevan
Re: Time for Geronimo 2.1.4 release?
I agree we should get a 2.1.4 release out ... and you certainly have my vote for release manager! The only thing I would add to the list is to get our xBean references to a consistent versions. I noticed this as I was updating branches/2.1 and trunk to pull in the newly released xBean 3.5. In branches/2.1 we have a mix of 3.3 dependencies (finder and reflect) and 3.5 dependencies (naming). I've been told that this was due to OpenJPA dependencies on 3.3. Now that we are pulling in a new OpenJPA release we will hopefully be able to update everything to use xBean 3.5. Joe Jarek Gawor wrote: Hi, I think it's time for Geronimo 2.1.4 release. We've had a lot of important fixes since 2.1.3 and we should get them out to our users. And if we agree, I would also like to volunteer to be a release manager for this release. Looking at the current status for 2.1.4 there are still a few things that we need to do before we can go ahead with the release. I updated the http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+2.1.4+Release+Status page with some of these items. If there are any open bugs that _need_ to be fixed for 2.1.4 or if I missed anything in that list please just update that wiki page. Thanks, Jarek
[jira] Resolved: (GSHELL-156) Disable system bell using the jline.nobell system property
[ https://issues.apache.org/jira/browse/GSHELL-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved GSHELL-156. Resolution: Fixed Fix Version/s: 1.0-alpha-2 Sending gshell-console/src/main/java/org/apache/geronimo/gshell/console/JLineConsole.java Transmitting file data . Committed revision 740396. > Disable system bell using the jline.nobell system property > -- > > Key: GSHELL-156 > URL: https://issues.apache.org/jira/browse/GSHELL-156 > Project: GShell > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Commands - Shell >Affects Versions: 1.0-alpha-2 > Environment: Windows >Reporter: Chris Custine >Assignee: Guillaume Nodet >Priority: Minor > Fix For: 1.0-alpha-2 > > Attachments: nobell.patch > > > On WIndows, attempting to backspace at the beginning of a line causes the > system bell to sound, thereby knocking many a user off their chair. I would > recommend disabling this for the sake of Windows users. *nix systems and Mac > OSX shells seem to disregard the system bell commands by default so disabling > the system bell in the ConsoleReader by default shouldn't affect them > adversely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GSHELL-156) Disable system bell using the jline.nobell system property
[ https://issues.apache.org/jira/browse/GSHELL-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned GSHELL-156: -- Assignee: Guillaume Nodet (was: Jason Dillon) > Disable system bell using the jline.nobell system property > -- > > Key: GSHELL-156 > URL: https://issues.apache.org/jira/browse/GSHELL-156 > Project: GShell > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Commands - Shell >Affects Versions: 1.0-alpha-2 > Environment: Windows >Reporter: Chris Custine >Assignee: Guillaume Nodet >Priority: Minor > Fix For: 1.0-alpha-2 > > Attachments: nobell.patch > > > On WIndows, attempting to backspace at the beginning of a line causes the > system bell to sound, thereby knocking many a user off their chair. I would > recommend disabling this for the sake of Windows users. *nix systems and Mac > OSX shells seem to disregard the system bell commands by default so disabling > the system bell in the ConsoleReader by default shouldn't affect them > adversely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-156) Disable system bell using the jline.nobell system property
[ https://issues.apache.org/jira/browse/GSHELL-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated GSHELL-156: --- Summary: Disable system bell using the jline.nobell system property (was: Disable system bell by default) > Disable system bell using the jline.nobell system property > -- > > Key: GSHELL-156 > URL: https://issues.apache.org/jira/browse/GSHELL-156 > Project: GShell > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Commands - Shell >Affects Versions: 1.0-alpha-2 > Environment: Windows >Reporter: Chris Custine >Assignee: Jason Dillon >Priority: Minor > Attachments: nobell.patch > > > On WIndows, attempting to backspace at the beginning of a line causes the > system bell to sound, thereby knocking many a user off their chair. I would > recommend disabling this for the sake of Windows users. *nix systems and Mac > OSX shells seem to disregard the system bell commands by default so disabling > the system bell in the ConsoleReader by default shouldn't affect them > adversely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Time for Geronimo 2.1.4 release?
Hi, I think it's time for Geronimo 2.1.4 release. We've had a lot of important fixes since 2.1.3 and we should get them out to our users. And if we agree, I would also like to volunteer to be a release manager for this release. Looking at the current status for 2.1.4 there are still a few things that we need to do before we can go ahead with the release. I updated the http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+2.1.4+Release+Status page with some of these items. If there are any open bugs that _need_ to be fixed for 2.1.4 or if I missed anything in that list please just update that wiki page. Thanks, Jarek
Re: [DISCUSS] Security Vulnerability Policy created
Sounds good. -Donald Joe Bohn wrote: Donald Woods wrote: Sounds good. I was assuming the SNAPSHOT build in #10 would be handled by Jarek's automated builds and we would just say "mmdd or later SNAPSHOT build" and include the URL to our published snapshot builds. Thanks Donald - I agree with using the automated build snapshots for the announce. So, is everybody OK with announcing vulnerabilities basically at the same time we create the JIRA and check the code in (the modified steps I listed below)? We would not be able to reference a SNAPSHOT in the announcement until one of our regularly scheduled builds runs ... which would imply that the basic information on the vulnerability would be "public" in the JIRA and code for perhaps a few hours before the official announce. Official release(s) that contained the fix would be as soon as reasonably possible after the announcement - probably several days or so for a new maintenance release on a major release that is already out there. Any new major release(s) under development would continue on the original schedule. Joe -Donald Joe Bohn wrote: I think the key question is when we will announce the vulnerability (current #11). My preference would be that we create a JIRA for the issue so that it can be included in the release notes (#9 - either with or without the CVE referenced). But that (along with the code check-in) creates a chicken and egg scenario which exposes some information about the vulnerability prior to the announce (currently step #11). I'm wondering if we should just go ahead and announce as soon as the code is checked-in and we have a SNAPSHOT available for download. In the announcement we could reference any appropriate workarounds and the availability of the fix in the latest SNAPSHOTS so that users can take appropriate action. Updated steps might look something like this (picking up at step #8): 8. Reach an agreement for the fix, announcement and release schedule with the submitter. 9. Create a JIRA and commit the fix in all actively maintained releases. 10. Announce the vulnerability (users, dev, secur...@a.o, bugtraq at securityfocus.com, full-disclosure at lists.grok.org.uk and project security pages) sighting workarounds and latest SNAPSHOT published. 11. Update the JIRA and svn log to include the CVE number. 12. Roll a release for each actively maintained branch (unreleased trunk can wait.) It's not optimal (would be much better to have a release in hand) but perhaps it is an appropriate compromise given that we can't prevent some information from going public when code is checked-in. Joe Kevan Miller wrote: On Jan 19, 2009, at 12:32 PM, Donald Woods wrote: Joe Bohn wrote: Is the omission of any discussion of a JIRA intentional? In other words, is it expected that a JIRA will *not* be created to document or track the code change and that CVE will be the only documentation of the issue (and then only after a server image has already been released by changing the commit log)? Good point. I believe we should create the JIRA as part of step #9. OK. That sounds good. I'm assuming the RELEASE_NOTES will also contain information regarding the vulnerability (including CVE, etc). If we are not creating a JIRA, then this brings up a documentation issue. Not announcing the issue until after a server release also causes some doc issues. - We typically use JIRAs to identify all changes within a release. - We include the list of JIRAs fixed and outstanding within the RELEASE_NOTES for each server release. - The RELEASE_NOTES are included in the server images so that anyone downloading a server image can easily understand what issues are resolved or still outstanding with that release. - So typically JIRAs must be resolved before we create a release candidate. The entire release (including the release notes) is then validated during the vote for the release candidate. Security fixes are important, so it seems that they should be mentioned in the release notes. I also understand the sensitive nature of these issues and the possibility of exploitation. However, it seems that the code check-in itself already has the potential to make the exposure public for those watching carefully. One possible solution would be to announce the vulnerability once we have a work-around available and/or a fix available in a SNAPSHOT image. Agree that we need to be as open as possible. As part of step #9, I'd like to see us add a reference to the fix (but not the complete details) on our Security pages for each release. Step #12 would also be updated, to go back and add the CVE number and more details to the Security pages as each branch is released. OK. Is it necessary to hide the CVE until 12? If so, I guess the RELEASE_NOTES shouldn't include the CVE... --kevan
[jira] Created: (GERONIMO-4526) ejbTimout method not subject to permission checks
ejbTimout method not subject to permission checks - Key: GERONIMO-4526 URL: https://issues.apache.org/jira/browse/GERONIMO-4526 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: OpenEJB Affects Versions: 2.1.4, 2.2 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1.4, 2.2 Right now if you have security enabled ejbTimeout calls don't work, they get an unauth exception. Need to fix it so the permissions that aren't from an interface get into the unchecked permissions. If someone adds the ejbTimeout method to an interface, that will get a different permission so the new unchecked permission shouldn't allow unwanted access. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Security Vulnerability Policy created
On Feb 3, 2009, at 11:20 AM, Joe Bohn wrote: Donald Woods wrote: Sounds good. I was assuming the SNAPSHOT build in #10 would be handled by Jarek's automated builds and we would just say "mmdd or later SNAPSHOT build" and include the URL to our published snapshot builds. Thanks Donald - I agree with using the automated build snapshots for the announce. So, is everybody OK with announcing vulnerabilities basically at the same time we create the JIRA and check the code in (the modified steps I listed below)? We would not be able to reference a SNAPSHOT in the announcement until one of our regularly scheduled builds runs ... which would imply that the basic information on the vulnerability would be "public" in the JIRA and code for perhaps a few hours before the official announce. Official release(s) that contained the fix would be as soon as reasonably possible after the announcement - probably several days or so for a new maintenance release on a major release that is already out there. Any new major release(s) under development would continue on the original schedule. I'm fine with this. thanks david jencks Joe -Donald Joe Bohn wrote: I think the key question is when we will announce the vulnerability (current #11). My preference would be that we create a JIRA for the issue so that it can be included in the release notes (#9 - either with or without the CVE referenced). But that (along with the code check-in) creates a chicken and egg scenario which exposes some information about the vulnerability prior to the announce (currently step #11). I'm wondering if we should just go ahead and announce as soon as the code is checked- in and we have a SNAPSHOT available for download. In the announcement we could reference any appropriate workarounds and the availability of the fix in the latest SNAPSHOTS so that users can take appropriate action. Updated steps might look something like this (picking up at step #8): 8. Reach an agreement for the fix, announcement and release schedule with the submitter. 9. Create a JIRA and commit the fix in all actively maintained releases. 10. Announce the vulnerability (users, dev, secur...@a.o, bugtraq at securityfocus.com, full-disclosure at lists.grok.org.uk and project security pages) sighting workarounds and latest SNAPSHOT published. 11. Update the JIRA and svn log to include the CVE number. 12. Roll a release for each actively maintained branch (unreleased trunk can wait.) It's not optimal (would be much better to have a release in hand) but perhaps it is an appropriate compromise given that we can't prevent some information from going public when code is checked-in. Joe Kevan Miller wrote: On Jan 19, 2009, at 12:32 PM, Donald Woods wrote: Joe Bohn wrote: Is the omission of any discussion of a JIRA intentional? In other words, is it expected that a JIRA will *not* be created to document or track the code change and that CVE will be the only documentation of the issue (and then only after a server image has already been released by changing the commit log)? Good point. I believe we should create the JIRA as part of step #9. OK. That sounds good. I'm assuming the RELEASE_NOTES will also contain information regarding the vulnerability (including CVE, etc). If we are not creating a JIRA, then this brings up a documentation issue. Not announcing the issue until after a server release also causes some doc issues. - We typically use JIRAs to identify all changes within a release. - We include the list of JIRAs fixed and outstanding within the RELEASE_NOTES for each server release. - The RELEASE_NOTES are included in the server images so that anyone downloading a server image can easily understand what issues are resolved or still outstanding with that release. - So typically JIRAs must be resolved before we create a release candidate. The entire release (including the release notes) is then validated during the vote for the release candidate. Security fixes are important, so it seems that they should be mentioned in the release notes. I also understand the sensitive nature of these issues and the possibility of exploitation. However, it seems that the code check-in itself already has the potential to make the exposure public for those watching carefully. One possible solution would be to announce the vulnerability once we have a work-around available and/or a fix available in a SNAPSHOT image. Agree that we need to be as open as possible. As part of step #9, I'd like to see us add a reference to the fix (but not the complete details) on our Security pages for each release. Step #12 would also be updated, to go back and add the CVE number and more details to the Security pages as each branch is released. OK. Is it necessary to hide the CVE until 12? If so, I guess the RELEASE_NOTES shouldn't in
Re: [DISCUSS] Security Vulnerability Policy created
Donald Woods wrote: Sounds good. I was assuming the SNAPSHOT build in #10 would be handled by Jarek's automated builds and we would just say "mmdd or later SNAPSHOT build" and include the URL to our published snapshot builds. Thanks Donald - I agree with using the automated build snapshots for the announce. So, is everybody OK with announcing vulnerabilities basically at the same time we create the JIRA and check the code in (the modified steps I listed below)? We would not be able to reference a SNAPSHOT in the announcement until one of our regularly scheduled builds runs ... which would imply that the basic information on the vulnerability would be "public" in the JIRA and code for perhaps a few hours before the official announce. Official release(s) that contained the fix would be as soon as reasonably possible after the announcement - probably several days or so for a new maintenance release on a major release that is already out there. Any new major release(s) under development would continue on the original schedule. Joe -Donald Joe Bohn wrote: I think the key question is when we will announce the vulnerability (current #11). My preference would be that we create a JIRA for the issue so that it can be included in the release notes (#9 - either with or without the CVE referenced). But that (along with the code check-in) creates a chicken and egg scenario which exposes some information about the vulnerability prior to the announce (currently step #11). I'm wondering if we should just go ahead and announce as soon as the code is checked-in and we have a SNAPSHOT available for download. In the announcement we could reference any appropriate workarounds and the availability of the fix in the latest SNAPSHOTS so that users can take appropriate action. Updated steps might look something like this (picking up at step #8): 8. Reach an agreement for the fix, announcement and release schedule with the submitter. 9. Create a JIRA and commit the fix in all actively maintained releases. 10. Announce the vulnerability (users, dev, secur...@a.o, bugtraq at securityfocus.com, full-disclosure at lists.grok.org.uk and project security pages) sighting workarounds and latest SNAPSHOT published. 11. Update the JIRA and svn log to include the CVE number. 12. Roll a release for each actively maintained branch (unreleased trunk can wait.) It's not optimal (would be much better to have a release in hand) but perhaps it is an appropriate compromise given that we can't prevent some information from going public when code is checked-in. Joe Kevan Miller wrote: On Jan 19, 2009, at 12:32 PM, Donald Woods wrote: Joe Bohn wrote: Is the omission of any discussion of a JIRA intentional? In other words, is it expected that a JIRA will *not* be created to document or track the code change and that CVE will be the only documentation of the issue (and then only after a server image has already been released by changing the commit log)? Good point. I believe we should create the JIRA as part of step #9. OK. That sounds good. I'm assuming the RELEASE_NOTES will also contain information regarding the vulnerability (including CVE, etc). If we are not creating a JIRA, then this brings up a documentation issue. Not announcing the issue until after a server release also causes some doc issues. - We typically use JIRAs to identify all changes within a release. - We include the list of JIRAs fixed and outstanding within the RELEASE_NOTES for each server release. - The RELEASE_NOTES are included in the server images so that anyone downloading a server image can easily understand what issues are resolved or still outstanding with that release. - So typically JIRAs must be resolved before we create a release candidate. The entire release (including the release notes) is then validated during the vote for the release candidate. Security fixes are important, so it seems that they should be mentioned in the release notes. I also understand the sensitive nature of these issues and the possibility of exploitation. However, it seems that the code check-in itself already has the potential to make the exposure public for those watching carefully. One possible solution would be to announce the vulnerability once we have a work-around available and/or a fix available in a SNAPSHOT image. Agree that we need to be as open as possible. As part of step #9, I'd like to see us add a reference to the fix (but not the complete details) on our Security pages for each release. Step #12 would also be updated, to go back and add the CVE number and more details to the Security pages as each branch is released. OK. Is it necessary to hide the CVE until 12? If so, I guess the RELEASE_NOTES shouldn't include the CVE... --kevan
[Fwd: Re: Plans for a OpenJPA 1.2.1 release?]
Original Message Subject: Re: Plans for a OpenJPA 1.2.1 release? Date: Tue, 3 Feb 2009 13:02:53 -0600 From: Michael Dick Reply-To: d...@openjpa.apache.org To: d...@openjpa.apache.org References: <49888ed5.3060...@apache.org> Hi Donald, I'm looking into this at the moment. I need to do some JIRA issue cleanup (I suspect) but I'll try to get the branch created later tonight. -mike On Tue, Feb 3, 2009 at 12:37 PM, Donald Woods wrote: Have we started planning a OpenJPA 1.2.1 release? The upcoming Geronimo 2.1.4 release would like to include an updated OpenJPA release due to the issue mentioned below. Thanks, Donald Original Message On Jan 27, 2009, at 11:39 AM, Donald Woods wrote: Do we need to upgrade to OpenJPA 1.2.1-SNAPSHOT and approach the OpenJPA team for a release, based on the resolution in - https://issues.apache.org/jira/browse/OPENJPA-872 Yes. I'm in the process of sending them a note... Looks like we could consider using to work-around the problem, if necessary. --kevan
Re: [DISCUSS] Security Vulnerability Policy created
Agree. Looks like we're ready to update the wiki and then request one last round of reviews to a broader group of people. -Donald Kevan Miller wrote: I've moved this back to the d...@. This is the danger of cross-posting. The reply-to for your original message (at least the one that I received) was u...@. This DISCUSS belongs on dev@ On Jan 19, 2009, at 5:10 PM, Donald Woods wrote: Sounds good to me. Should step #8 include a post to the private@ list, so other PMC members will have some history behind the fixes being checked into svn in step #9? I like it. 8 is probably a good place to coordinate with the PMC. --kevan
Re: [VOTE] geronimo-jpa_2.0_spec first early access release
Geir, any updates on getting item (iii) below removed, so we can release the early spec implementation and a OpenJPA 2.0.0 M1 release? -Donald David Jencks wrote: On Jan 30, 2009, at 2:00 PM, Donald Woods wrote: Any updates on item (iii)? Can we just include the notice for EA-1 and revisit for the next release? My interpretation of Geir's response is that we can't distribute stuff with this restriction, so no, we have to wait until the conditions are changed at which point the existing jar under vote will be OK. thanks david jencks -Donald David Jencks wrote: Looks like a problem. I sent a note to legal-discuss about (iii). I'll work on setting up a new release candidate. thanks david jencks On Jan 29, 2009, at 7:46 AM, Jeremy Bauer wrote: David, While searching the JSR-317 draft for direction regarding early access naming, I found that the notice (page 2) includes the clauses below, notably item iii. Does clause iii need to be added to the NOTICE in the EA jar? Also, should the Geronimo EA NOTICE use "JPA 2.0 EARLY ACCESS" instead of simply "JPA 2.0" in order to meet clause ii? NOTICE ... 2.Distribute implementations of the Specification to third parties for their testing and evaluation use, provided that any such implementation: (i) does not modify, subset, superset or otherwise extend the Licensor Name Space, or include any public or protected packages, classes, Java interfaces, fields or methods within the Licensor Name Space other than those required/authorized by the Specification or Specifications being implemented; (ii)is clearly and prominently marked with the word "UNTESTED" or "EARLY ACCESS" or "INCOMPATIBLE" or "UNSTABLE" or "BETA" in any list of available builds and in proximity to every link initiating its download, where the list or link is under Licensee's control; and (iii)includes the following notice: "This is an implementation of an early-draft specification developed under the Java Community Process (JCP) and is made available for testing and evaluation purposes only. The code is not compatible with any specification of the JCP." -Jeremy On Wed, Jan 28, 2009 at 4:25 PM, David Jencks mailto:david_jen...@yahoo.com>> wrote: I've been working with the OpenJPA project to develop the jpa 2.0 spec jar in our spec repository. They are ready for their first early access milestone release. I've staged the release here: http://people.apache.org/~djencks/staging-repo/specs/geronimo-jpa_2.0_spec/org/apache/geronimo/specs/geronimo-jpa_2.0_spec/1.0-EA-1/ The svn location is here: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jpa_2.0_spec-1.0-EA-1 I haven't staged the site. I don't think its necessary for a early access release, but will reconsider on request. I ran rat on the project, and the autochecking thinks the legal files are ok. Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 thanks david jencks
Plans for a OpenJPA 1.2.1 release?
Have we started planning a OpenJPA 1.2.1 release? The upcoming Geronimo 2.1.4 release would like to include an updated OpenJPA release due to the issue mentioned below. Thanks, Donald Original Message On Jan 27, 2009, at 11:39 AM, Donald Woods wrote: Do we need to upgrade to OpenJPA 1.2.1-SNAPSHOT and approach the OpenJPA team for a release, based on the resolution in - https://issues.apache.org/jira/browse/OPENJPA-872 Yes. I'm in the process of sending them a note... Looks like we could consider using to work-around the problem, if necessary. --kevan
[jira] Commented: (GERONIMODEVTOOLS-535) Add support for installing from update site for IBM RAD v7.5
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669980#action_12669980 ] Delos Dai commented on GERONIMODEVTOOLS-535: Hi Tim, Sorry for my delay! 1) For branding problem missing, I think you're right. We should add the branding in "about eclipse platform" dialog. But it seems branding in RAD is not the same as that in base eclipse, so the branding is missing. I will continue to investigate the branding problem in RAD. 2) About the specific version in tag, in fact, the version is copied from the plugin contained in WTP 2.0.0, for replacing the org.eclipse.jst 2.0.0 3) About the RAD 7.5.1 installation problem, it seems you didn't install GEP with right version. I haven't got a RAD 7.5.1 to reproduce it (I will try RAD 7.5.1). But I suggest you try again. Make sure that uncheck all the other sites in update manager of eclipse, when you install GEP from local site. Thanks very much! > Add support for installing from update site for IBM RAD v7.5 > > > Key: GERONIMODEVTOOLS-535 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-535 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.1.3 > Environment: IBM RAD v7.5 >Reporter: Delos Dai >Assignee: Tim McConnell > Fix For: 2.2.0, 2.1.4 > > Attachments: GERONIMODEVTOOLS-535.patch > > > Now, in feature.xml of GEP, we have this snippet: > >match="greaterOrEqual"/> > > Since no "org.eclipse.jst" feature exist in RAD , we have to replace > "org.eclipse.jst" feature with the sub-features of "org.eclipse.jst". > The section above can be replaced with this snippet: > >version="2.0.0.v200706041905-1007w311817231426" > match="greaterOrEqual"/> >version="2.0.2.v200802150100-77-CT9yJXEkuiKVeQrclqTHQ3648" > match="greaterOrEqual"/> >version="2.0.2.v200802150100-787KE8iDUUEF6GwKwpHEQ" > match="greaterOrEqual"/> >version="2.0.2.v200802150100-7B1DzCkuNa_RPevwkwB1iJ6z-0RH" > match="greaterOrEqual"/> >version="2.0.2.v200802150100-7b7_Es8EU6AXOV9QLJSees1SQoYQ" > match="greaterOrEqual"/> > > The sole plugin of "org.eclipse.jst" feature and optional sub-feature > "org.eclipse.jst.webpageeditor.feature" can't be found in the plugin list of > RAD. GEP doesn't require these two items, then don't need to add them into > the required section. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4404) ActiveMQ connectors default to 0.0.0.0 when ServerHostname is set to localhost or actual IP.
[
https://issues.apache.org/jira/browse/GERONIMO-4404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donald Woods reassigned GERONIMO-4404:
--
Assignee: David Jencks (was: Donald Woods)
David, can you take a look at the AMQ-2094 issue that Shawn opened? Thanks.
> ActiveMQ connectors default to 0.0.0.0 when ServerHostname is set to
> localhost or actual IP.
>
>
> Key: GERONIMO-4404
> URL: https://issues.apache.org/jira/browse/GERONIMO-4404
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: ActiveMQ
>Affects Versions: 2.1.3
>Reporter: Donald Woods
>Assignee: David Jencks
>Priority: Minor
> Fix For: 2.1.4
>
> Attachments: G4404_branch21.patch, G4404_truck.patch
>
>
> Ron Staerker reported that if you change ServerHostname in
> config-substitutions.properties from 0.0.0.0 to 127.0.0.1, the default
> ActiveMQ connectors on 61613 and 61616 will still bind to 0.0.0.0 instead of
> the new ServerHostname value. This seems to b caused by several pom.xml
> problems, where:
> name="ServerUrl">tcp://${PlanServerHostname}:${PlanActiveMQPort}
> where PlanServerHostname is 0.0.0.0 and not in config-substitutions.properties
> #{ServerHostname}
> is being substituted in at build time to be 0.0.0.0 instead of putting
> ${ServerHostname} in the plans.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
