Re: Time for Geronimo 2.1.4 release?
We have done some test here with the tranql SQLServer 2000 and 2005 XA connector (https://issues.apache.org/jira/browse/GERONIMO-4279), and TranQL Informix XA connector (https://issues.apache.org/jira/browse/GERONIMO-4365), both look good. So they should be ready to get into Geronimo 2.1.4. Still trying with the TranQL connector for Oracle RAC - not easy to set up the environment... -Jack 2009/2/6 Jarek Gawor jga...@gmail.com Jay, Updating OpenEJB 3.0.1 to xbean 3.5 will require 2.0.3 and 2.1.4 to update the asm 3.1 library (and that will need even more changes). I know some other libs have deps on the asm lib so we might run into problems later on. How about we only upgrade xbean-naming to 3.5 first and leave other xbean dependencies on 3.4.1? If that doesn't work we can try 3.5 for everything. Jarek On Wed, Feb 4, 2009 at 9:55 AM, Jay D. McHugh jaydmch...@gmail.com wrote: All of the 2.0.3 build issues are fixed. I will try building 2.0.3 with XBeans 3.5 now and let you all know what happens. If it will build, then I might take a look to see whether I can figure out what changes are necessary for OpenEJB 3.0.1 to use XBeans 3.5 too. 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
Re: Time for Geronimo 2.1.4 release?
Jay, Updating OpenEJB 3.0.1 to xbean 3.5 will require 2.0.3 and 2.1.4 to update the asm 3.1 library (and that will need even more changes). I know some other libs have deps on the asm lib so we might run into problems later on. How about we only upgrade xbean-naming to 3.5 first and leave other xbean dependencies on 3.4.1? If that doesn't work we can try 3.5 for everything. Jarek On Wed, Feb 4, 2009 at 9:55 AM, Jay D. McHugh jaydmch...@gmail.com wrote: All of the 2.0.3 build issues are fixed. I will try building 2.0.3 with XBeans 3.5 now and let you all know what happens. If it will build, then I might take a look to see whether I can figure out what changes are necessary for OpenEJB 3.0.1 to use XBeans 3.5 too. 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?
+1 Thanks Manu On Wed, Feb 4, 2009 at 1:13 AM, Jarek Gawor jga...@gmail.com 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?
Jay, Please run all tests including the integration tests before committing. Looks like deployment of some apps is failing after the recent changes, for example see: http://people.apache.org/builds/geronimo/server/binaries/2.0/20090204/logs-0200-tomcat/test.log Jarek On Wed, Feb 4, 2009 at 9:55 AM, Jay D. McHugh jaydmch...@gmail.com wrote: All of the 2.0.3 build issues are fixed. I will try building 2.0.3 with XBeans 3.5 now and let you all know what happens. If it will build, then I might take a look to see whether I can figure out what changes are necessary for OpenEJB 3.0.1 to use XBeans 3.5 too. 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?
All of the 2.0.3 build issues are fixed. I will try building 2.0.3 with XBeans 3.5 now and let you all know what happens. If it will build, then I might take a look to see whether I can figure out what changes are necessary for OpenEJB 3.0.1 to use XBeans 3.5 too. 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?
Jarek, I got spoiled by having the integration tests automatically run on 2.2. I had hoped that the tests were broken before I started - but unfortunately, it really was me that broke them. I will find and fix the problem. Thanks for alerting me to it. Jay Jarek Gawor wrote: Jay, Please run all tests including the integration tests before committing. Looks like deployment of some apps is failing after the recent changes, for example see: http://people.apache.org/builds/geronimo/server/binaries/2.0/20090204/logs-0200-tomcat/test.log Jarek On Wed, Feb 4, 2009 at 9:55 AM, Jay D. McHugh jaydmch...@gmail.com wrote: All of the 2.0.3 build issues are fixed. I will try building 2.0.3 with XBeans 3.5 now and let you all know what happens. If it will build, then I might take a look to see whether I can figure out what changes are necessary for OpenEJB 3.0.1 to use XBeans 3.5 too. 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?
+1 Thanks for volunteering to be the release manager! Lin On Tue, Feb 3, 2009 at 2:43 PM, Jarek Gawor jga...@gmail.com 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?
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?
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?
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?
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?
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 jga...@gmail.com 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
