Re: [DISCUSS] G 2.0.2 Release plan
All, I've updated the versions in branches/2.0.2 from 2.0.2-SNAPSHOT to 2.0.2. No code changes should be going into 2.0.2. I'm going to be finalizing the release notes and building binaries later tonight. The ibiblio repo is having problems this afternoon. To build successfully, I had to add the following to my settings.xml: mirrors mirror idibiblio.org/id nameMirror of http://repo1.maven.org/maven2//name urlhttp://repo1.maven.org/maven2/url mirrorOfcentral/mirrorOf /mirror /mirrors In case these problems persist, I intend to add this information to the 2.0.2 release notes and the building geronimo page on our wiki. --kevan
Re: [DISCUSS] G 2.0.2 Release plan
Kevan Miller wrote: All, I've created a 2.0.2 release branch -- https://svn.apache.org/repos/asf/geronimo/server/branches/2.0.2 And have updated the branches/2.0 version to be 2.0.3-SNAPSHOT (with a helping hand from Donald :) Vamsi is working on an update to the CA Helper in the console. Joe B is working on a JNDI mapped name problem for MEJB. The JNDI mapped name for MEJB is fixed. Joe Beyond those two, I don't think there is any more work to do on 2.0.2. As soon as they are complete, I'll start working on spinning up an RC. Oh, there is one more thing... We need to release the 2.0.2 versions of geronimo-transaction and geronimo-connector. I starting to work on this now. I'll either start release proceedings prior to, or concurrently with G 2.0.2. --kevan
Re: [DISCUSS] G 2.0.2 Release plan
On Oct 10, 2007, at 6:16 AM, Joe Bohn wrote: Kevan Miller wrote: All, I've created a 2.0.2 release branch -- https://svn.apache.org/ repos/asf/geronimo/server/branches/2.0.2 And have updated the branches/2.0 version to be 2.0.3-SNAPSHOT (with a helping hand from Donald :) Vamsi is working on an update to the CA Helper in the console. Joe B is working on a JNDI mapped name problem for MEJB. The JNDI mapped name for MEJB is fixed. Excellent. Thanks Joe! I'll start pulling things together... --kevan
Geronimo v2.0.2 Release Notes - was {Re: [DISCUSS] G 2.0.2 Release plan}
Hi Vamsi, can you summarize what are the updates on the CA Helper so we can add it to the 2.0.2 release notes http://cwiki.apache.org/GMOxDOC20/release-notes-202txt.html There have also been some updates on MEJB and JNDI. For those of you folks who worked directly on these areas could you please reply with a few lines as well. Cheers! Hernan Vamsavardhana Reddy wrote: On 10/8/07, *Kevan Miller* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: All, I've created a 2.0.2 release branch -- https://svn.apache.org/repos/ asf/geronimo/server/branches/2.0.2 And have updated the branches/2.0 version to be 2.0.3-SNAPSHOT (with a helping hand from Donald :) Vamsi is working on an update to the CA Helper in the console. I am done with the CA Helper app. Joe B is working on a JNDI mapped name problem for MEJB. Beyond those two, I don't think there is any more work to do on 2.0.2. As soon as they are complete, I'll start working on spinning up an RC. Oh, there is one more thing... We need to release the 2.0.2 versions of geronimo-transaction and geronimo-connector. I starting to work on this now. I'll either start release proceedings prior to, or concurrently with G 2.0.2. --kevan -- Vamsi ([EMAIL PROTECTED] mailto:[EMAIL PROTECTED]) (Committer and Member of Apache Geronimo PMC) Blog: http://vamsic007.livejournal.com/ One-stop-shop for configuring JEE Application security in Geronimo ApacheCon US 2007 http://us.apachecon.com/us2007/program/talk/1977 http://us.apachecon.com/us2007/program/talk/1977 OS Summit Asia 2007 http://www.ossummit.com/2007/program/talk/15
Re: [DISCUSS] G 2.0.2 Release plan
I just set the default ThreadPool size back to 500, so the Jetty problem should be solved. -Donald Kevan Miller wrote: All, I've created a 2.0.2 release branch -- https://svn.apache.org/repos/asf/geronimo/server/branches/2.0.2 And have updated the branches/2.0 version to be 2.0.3-SNAPSHOT (with a helping hand from Donald :) Vamsi is working on an update to the CA Helper in the console. Joe B is working on a JNDI mapped name problem for MEJB. Beyond those two, I don't think there is any more work to do on 2.0.2. As soon as they are complete, I'll start working on spinning up an RC. Oh, there is one more thing... We need to release the 2.0.2 versions of geronimo-transaction and geronimo-connector. I starting to work on this now. I'll either start release proceedings prior to, or concurrently with G 2.0.2. --kevan
Re: [DISCUSS] G 2.0.2 Release plan
All, I've created a 2.0.2 release branch -- https://svn.apache.org/repos/ asf/geronimo/server/branches/2.0.2 And have updated the branches/2.0 version to be 2.0.3-SNAPSHOT (with a helping hand from Donald :) Vamsi is working on an update to the CA Helper in the console. Joe B is working on a JNDI mapped name problem for MEJB. Beyond those two, I don't think there is any more work to do on 2.0.2. As soon as they are complete, I'll start working on spinning up an RC. Oh, there is one more thing... We need to release the 2.0.2 versions of geronimo-transaction and geronimo-connector. I starting to work on this now. I'll either start release proceedings prior to, or concurrently with G 2.0.2. --kevan
Re: [DISCUSS] G 2.0.2 Release plan
On 10/8/07, Kevan Miller [EMAIL PROTECTED] wrote: All, I've created a 2.0.2 release branch -- https://svn.apache.org/repos/ asf/geronimo/server/branches/2.0.2 And have updated the branches/2.0 version to be 2.0.3-SNAPSHOT (with a helping hand from Donald :) Vamsi is working on an update to the CA Helper in the console. I am done with the CA Helper app. Joe B is working on a JNDI mapped name problem for MEJB. Beyond those two, I don't think there is any more work to do on 2.0.2. As soon as they are complete, I'll start working on spinning up an RC. Oh, there is one more thing... We need to release the 2.0.2 versions of geronimo-transaction and geronimo-connector. I starting to work on this now. I'll either start release proceedings prior to, or concurrently with G 2.0.2. --kevan -- Vamsi ([EMAIL PROTECTED]) (Committer and Member of Apache Geronimo PMC) Blog: http://vamsic007.livejournal.com/ One-stop-shop for configuring JEE Application security in Geronimo ApacheCon US 2007 http://us.apachecon.com/us2007/program/talk/1977 OS Summit Asia 2007 http://www.ossummit.com/2007/program/talk/15
Re: [DISCUSS] G 2.0.2 Release plan
Kevan, I just verified that the tranql mysql wrapper works at least a little bit and published it. Could you update a couple pom versions before branching? Index: pom.xml === --- pom.xml (revision 580497) +++ pom.xml (working copy) @@ -858,13 +858,13 @@ dependency groupIdorg.tranql/groupId artifactIdtranql-connector-mysql-local/artifactId -version1.1-SNAPSHOT/version +version1.1/version typerar/type /dependency dependency groupIdorg.tranql/groupId artifactIdtranql-connector-mysql-xa/artifactId -version1.1-SNAPSHOT/version +version1.1/version typerar/type /dependency dependency @@ -882,13 +882,13 @@ dependency groupIdorg.tranql/groupId artifactIdtranql-connector-postgresql-local/ artifactId -version1.1-SNAPSHOT/version +version1.1/version typerar/type /dependency dependency groupIdorg.tranql/groupId artifactIdtranql-connector-postgresql-xa/ artifactId -version1.1-SNAPSHOT/version +version1.1/version typerar/type /dependency dependency thanks david jencks On Oct 5, 2007, at 9:15 AM, Kevan Miller wrote: On Oct 5, 2007, at 8:42 AM, Donald Woods wrote: What's the plan for creating a 2.0.2 branch in preparation of closing down the release? Matt sent a note earlier today, while I was in a jet-lagged impose slumber... I'll plan on creating a branches/2.0.2 for finalizing release activity on Saturday morning... --kevan
Re: [DISCUSS] G 2.0.2 Release plan
What's the plan for creating a 2.0.2 branch in preparation of closing down the release? -Donald Kevan Miller wrote: All, I think it's time to start rolling out a 2.0.2 release. There have been a number of fixes in response to user issues, since 2.0.1. Time, I think, to make these available in a release. We'd also be able to make use of released versions of OpenJPA, Axis2, and hopefully OpenEjb, whittling away at our local builds... I think we have one must-fix problem that is outstanding -- the MEJB security issue. Assuming we resolve this problem, are there any other issues which must be resolved prior to a 2.0.2 release? Assuming we're in general agreement, I'd set a goal of creating a release candidate by next Friday (Sept 21). I'm volunteering to be the release manager. Thoughts? --kevan smime.p7s Description: S/MIME Cryptographic Signature
Re: [DISCUSS] G 2.0.2 Release plan
Can the following be removed from the JEE5 config.xml files, now that we have the MEJB fix in? !-- See GERONIMO-3461 for why this is disabled by default -- gbean load=false name=ejb/mgmt/MEJB/ -Donald Kevan Miller wrote: All, I think it's time to start rolling out a 2.0.2 release. There have been a number of fixes in response to user issues, since 2.0.1. Time, I think, to make these available in a release. We'd also be able to make use of released versions of OpenJPA, Axis2, and hopefully OpenEjb, whittling away at our local builds... I think we have one must-fix problem that is outstanding -- the MEJB security issue. Assuming we resolve this problem, are there any other issues which must be resolved prior to a 2.0.2 release? Assuming we're in general agreement, I'd set a goal of creating a release candidate by next Friday (Sept 21). I'm volunteering to be the release manager. Thoughts? --kevan smime.p7s Description: S/MIME Cryptographic Signature
Re: [DISCUSS] G 2.0.2 Release plan
On Oct 5, 2007, at 8:42 AM, Donald Woods wrote: What's the plan for creating a 2.0.2 branch in preparation of closing down the release? Matt sent a note earlier today, while I was in a jet-lagged impose slumber... I'll plan on creating a branches/2.0.2 for finalizing release activity on Saturday morning... --kevan
Re: [DISCUSS] G 2.0.2 Release plan
go for it.. Anita --- Donald Woods [EMAIL PROTECTED] wrote: Can the following be removed from the JEE5 config.xml files, now that we have the MEJB fix in? !-- See GERONIMO-3461 for why this is disabled by default -- gbean load=false name=ejb/mgmt/MEJB/ -Donald Kevan Miller wrote: All, I think it's time to start rolling out a 2.0.2 release. There have been a number of fixes in response to user issues, since 2.0.1. Time, I think, to make these available in a release. We'd also be able to make use of released versions of OpenJPA, Axis2, and hopefully OpenEjb, whittling away at our local builds... I think we have one must-fix problem that is outstanding -- the MEJB security issue. Assuming we resolve this problem, are there any other issues which must be resolved prior to a 2.0.2 release? Assuming we're in general agreement, I'd set a goal of creating a release candidate by next Friday (Sept 21). I'm volunteering to be the release manager. Thoughts? --kevan Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/
Re: [DISCUSS] G 2.0.2 Release plan
Done. Anita Kulshreshtha wrote: go for it.. Anita --- Donald Woods [EMAIL PROTECTED] wrote: Can the following be removed from the JEE5 config.xml files, now that we have the MEJB fix in? !-- See GERONIMO-3461 for why this is disabled by default -- gbean load=false name=ejb/mgmt/MEJB/ -Donald Kevan Miller wrote: All, I think it's time to start rolling out a 2.0.2 release. There have been a number of fixes in response to user issues, since 2.0.1. Time, I think, to make these available in a release. We'd also be able to make use of released versions of OpenJPA, Axis2, and hopefully OpenEjb, whittling away at our local builds... I think we have one must-fix problem that is outstanding -- the MEJB security issue. Assuming we resolve this problem, are there any other issues which must be resolved prior to a 2.0.2 release? Assuming we're in general agreement, I'd set a goal of creating a release candidate by next Friday (Sept 21). I'm volunteering to be the release manager. Thoughts? --kevan Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/ smime.p7s Description: S/MIME Cryptographic Signature
Re: Jndi names, need input (Re: [DISCUSS] G 2.0.2 Release plan)
On Oct 2, 2007, at 7:02 PM, David Blevins wrote:
Ok, I made the following changes:
- Set the deployment id format to {appId}/{moduleId}/{ejbName}
(fixes GERONIMO-3199)
- Set jndiname format to {ejbName}{interfaceType.annotationName}
(this MUST go in the release notes as it will be a significant change)
- Setup jndi name binding of non-javaee clients to not fail a
deployment if a name is taken (just logs an ERROR as usual).
I also slurped in the OpenEJB documentation on this subject to a
new page here:
http://cwiki.apache.org/GMOxSBOX/client-jndi-names.html
Moved the page to GMOxDEV per Hernan's request.
-David
Re: Jndi names, need input (Re: [DISCUSS] G 2.0.2 Release plan)
On Oct 1, 2007, at 4:24 PM, David Jencks wrote:
I talked with david a bit on irc and he tells me there is a flag so
we can set it so if there is a non-javaee jndi name conflict we log
an error instead of throwing an exception.
I'm happy with a simple default format for non-javaee jndi ejb
names if collisions result in loud logging rather than exceptions.
I'd like it to be possible for people only using javaee to deploy
lots of copies of the same app without exceptions from name
collisions, even if this means some random copy of the app wins in
the non-javaee jndi. If someone wants to do this AND use non-
javaee jndi they should read the instructions and figure out a
sufficiently complicate name format so they avoid collisions.
IIUC the proposed simple name format above that one would be just
fine.
Ok, I made the following changes:
- Set the deployment id format to {appId}/{moduleId}/{ejbName}
(fixes GERONIMO-3199)
- Set jndiname format to {ejbName}{interfaceType.annotationName}
(this MUST go in the release notes as it will be a significant change)
- Setup jndi name binding of non-javaee clients to not fail a
deployment if a name is taken (just logs an ERROR as usual).
I also slurped in the OpenEJB documentation on this subject to a new
page here:
http://cwiki.apache.org/GMOxSBOX/client-jndi-names.html
.. primarily because it didn't seem possible to include part of it
and have the updated Geronimo specific info that:
1. we won't fail the deployment on conflict and that this can be
changed.
2. the default openejb.jndiname.format is actually {ejbName}
{interfaceType.annotationName} rather than {deploymentId}
{interfaceType.annotationName}. The openejb.deploymentId.format in
Geronimo is intentionally complex as to not have any conflicts.
3. the re recommended way to set a system property is likely via
the config.xml which we should show in this document. Unless of
course we add a gbean property to OpenEjbSystemGBean, in which case
it's still via the config.xml but in a different way.
Anyway, this doc needs #3 to get updated and we also need to find a
place for it in one the main docco spaces for 2.0.2.
-David
Re: Jndi names, need input (Re: [DISCUSS] G 2.0.2 Release plan)
On Sep 29, 2007, at 3:06 PM, David Blevins wrote:
On Sep 29, 2007, at 12:31 AM, David Jencks wrote:
On Sep 28, 2007, at 8:40 PM, David Blevins wrote:
On Sep 25, 2007, at 3:40 PM, David Blevins wrote:
On Sep 25, 2007, at 7:38 AM, Kevan Miller wrote:
One thing I've noticed -- the default JNDI name for EJB's has
been changed in OpenEJB. So, there is a compatibility issue
with 2.0.1. We might be able to configure how OpenEJB generates
this default to maintain backward compatibility. Better, IMO,
to go ahead and match OpenEJB's behavior.
There are no compatibility issues as it was explicitly set in
Geronimo 2.0.1 to be essentially {moduleId}/{ejbName}/
{interfaceClass} (actually it's {deploymentId}/{interfaceClass}
and deploymentId will be {moduleId}/{ejbName}). It'll still be
the same in Geronimo 2.0.2, just now it can be changed to
something shorter.
I'd be fine with Geronimo using the OpenEJB default of
essentially {ejbName}{interfaceType.annotationName} (it's
{deploymentId}{interfaceType.annotation} where deploymentId
defaults to {ejbName}), but it's definitely a default that
targets people with just a couple apps. People in bigger
environments would have to set the jndiname and deploymentId
formats to something less likely to conflict.
Does anyone have any thoughts or preferences on this one? Need
to get some input from the group.
My opinion on what to do depends a bit on whether this name format
can result in name collisions for javaee clients as well as non-
javaee clients.
Javaee client names and the non-javaee client now use different
trees, so the jndiformat has no impact on javaee client functionality.
I talked with david a bit on irc and he tells me there is a flag so
we can set it so if there is a non-javaee jndi name conflict we log
an error instead of throwing an exception.
I'm happy with a simple default format for non-javaee jndi ejb names
if collisions result in loud logging rather than exceptions. I'd
like it to be possible for people only using javaee to deploy lots of
copies of the same app without exceptions from name collisions, even
if this means some random copy of the app wins in the non-javaee
jndi. If someone wants to do this AND use non-javaee jndi they
should read the instructions and figure out a sufficiently complicate
name format so they avoid collisions.
IIUC the proposed simple name format above that one would be just fine.
thanks
david jencks
-David
Re: Jndi names, need input (Re: [DISCUSS] G 2.0.2 Release plan)
On Sep 28, 2007, at 8:40 PM, David Blevins wrote:
On Sep 25, 2007, at 3:40 PM, David Blevins wrote:
On Sep 25, 2007, at 7:38 AM, Kevan Miller wrote:
One thing I've noticed -- the default JNDI name for EJB's has
been changed in OpenEJB. So, there is a compatibility issue with
2.0.1. We might be able to configure how OpenEJB generates this
default to maintain backward compatibility. Better, IMO, to go
ahead and match OpenEJB's behavior.
There are no compatibility issues as it was explicitly set in
Geronimo 2.0.1 to be essentially {moduleId}/{ejbName}/
{interfaceClass} (actually it's {deploymentId}/{interfaceClass}
and deploymentId will be {moduleId}/{ejbName}). It'll still be
the same in Geronimo 2.0.2, just now it can be changed to
something shorter.
I'd be fine with Geronimo using the OpenEJB default of essentially
{ejbName}{interfaceType.annotationName} (it's {deploymentId}
{interfaceType.annotation} where deploymentId defaults to
{ejbName}), but it's definitely a default that targets people with
just a couple apps. People in bigger environments would have to
set the jndiname and deploymentId formats to something less likely
to conflict.
Does anyone have any thoughts or preferences on this one? Need to
get some input from the group.
My opinion on what to do depends a bit on whether this name format
can result in name collisions for javaee clients as well as non-
javaee clients. My impression is that it can result in name
collisions for both if you pick a name format that is not
sufficiently unique. Assuming this is true I would prefer to have a
default name format that minimizes the chance of name collisions
together with easy-to-follow instructions for those with only one app
or who can modify all their apps to avoid name collisions as needed.
thanks
david jencks
-David
Re: Jndi names, need input (Re: [DISCUSS] G 2.0.2 Release plan)
On Sep 29, 2007, at 12:31 AM, David Jencks wrote:
On Sep 28, 2007, at 8:40 PM, David Blevins wrote:
On Sep 25, 2007, at 3:40 PM, David Blevins wrote:
On Sep 25, 2007, at 7:38 AM, Kevan Miller wrote:
One thing I've noticed -- the default JNDI name for EJB's has
been changed in OpenEJB. So, there is a compatibility issue with
2.0.1. We might be able to configure how OpenEJB generates this
default to maintain backward compatibility. Better, IMO, to go
ahead and match OpenEJB's behavior.
There are no compatibility issues as it was explicitly set in
Geronimo 2.0.1 to be essentially {moduleId}/{ejbName}/
{interfaceClass} (actually it's {deploymentId}/{interfaceClass}
and deploymentId will be {moduleId}/{ejbName}). It'll still be
the same in Geronimo 2.0.2, just now it can be changed to
something shorter.
I'd be fine with Geronimo using the OpenEJB default of
essentially {ejbName}{interfaceType.annotationName} (it's
{deploymentId}{interfaceType.annotation} where deploymentId
defaults to {ejbName}), but it's definitely a default that
targets people with just a couple apps. People in bigger
environments would have to set the jndiname and deploymentId
formats to something less likely to conflict.
Does anyone have any thoughts or preferences on this one? Need to
get some input from the group.
My opinion on what to do depends a bit on whether this name format
can result in name collisions for javaee clients as well as non-
javaee clients.
Javaee client names and the non-javaee client now use different
trees, so the jndiformat has no impact on javaee client functionality.
-David
Jndi names, need input (Re: [DISCUSS] G 2.0.2 Release plan)
On Sep 25, 2007, at 3:40 PM, David Blevins wrote:
On Sep 25, 2007, at 7:38 AM, Kevan Miller wrote:
One thing I've noticed -- the default JNDI name for EJB's has been
changed in OpenEJB. So, there is a compatibility issue with 2.0.1.
We might be able to configure how OpenEJB generates this default
to maintain backward compatibility. Better, IMO, to go ahead and
match OpenEJB's behavior.
There are no compatibility issues as it was explicitly set in
Geronimo 2.0.1 to be essentially {moduleId}/{ejbName}/
{interfaceClass} (actually it's {deploymentId}/{interfaceClass}
and deploymentId will be {moduleId}/{ejbName}). It'll still be the
same in Geronimo 2.0.2, just now it can be changed to something
shorter.
I'd be fine with Geronimo using the OpenEJB default of essentially
{ejbName}{interfaceType.annotationName} (it's {deploymentId}
{interfaceType.annotation} where deploymentId defaults to
{ejbName}), but it's definitely a default that targets people with
just a couple apps. People in bigger environments would have to
set the jndiname and deploymentId formats to something less likely
to conflict.
Does anyone have any thoughts or preferences on this one? Need to
get some input from the group.
-David
Re: [DISCUSS] G 2.0.2 Release plan
On Sep 26, 2007, at 7:30 PM, Kevan Miller wrote: On Sep 25, 2007, at 4:08 PM, Donald Woods wrote: OK, I'm done updating the 2.0.x closed issues (sorry for all the JIRA emails.) The only one I couldn't figure out, was: https://issues.apache.org/jira/browse/GERONIMO-3423 Donald, Thanks a bunch for going through all of those Jiras! David Blevins, Are we missing 3423 in branches/2.0? Heh. Looks like I merged the change to branches/2.0 in revision 570950 -- http://svn.apache.org/viewvc?view=revrevision=570950. --kevan
Re: [DISCUSS] G 2.0.2 Release plan
On Sep 26, 2007, at 4:01 PM, Kevan Miller wrote:
On Sep 25, 2007, at 6:40 PM, David Blevins wrote:
On Sep 25, 2007, at 7:38 AM, Kevan Miller wrote:
One thing I've noticed -- the default JNDI name for EJB's has
been changed in OpenEJB. So, there is a compatibility issue with
2.0.1. We might be able to configure how OpenEJB generates this
default to maintain backward compatibility. Better, IMO, to go
ahead and match OpenEJB's behavior.
There are no compatibility issues as it was explicitly set in
Geronimo 2.0.1 to be essentially {moduleId}/{ejbName}/
{interfaceClass} (actually it's {deploymentId}/{interfaceClass}
and deploymentId will be {moduleId}/{ejbName}). It'll still be
the same in Geronimo 2.0.2, just now it can be changed to
something shorter.
Well, that's encouraging. However, something has changed between
2.0.1 and 2.0.2. Can you help explain the following?
INFO log during 2.0.1 deploy:
18:45:13,785 INFO [config] Configuring app: GeneralEJB.jar
18:45:13,849 INFO [OpenEJB] Auto-deploying ejb My: EjbDeployment
(deployment-id=GeneralEJB.jar/My, container-id=null)
18:45:14,066 INFO [config] Loaded Module: GeneralEJB.jar
18:45:16,653 INFO [Enhance] You have enabled runtime enhancement,
but have not specified the set of persistent classes. OpenJPA must
look for metadata for every loaded class, which might increase
class load times significantly.
18:45:17,021 INFO [startup] Assembling app: /geronimo-jetty6-
jee5-2.0.1/var/temp/geronimo-deploymentUtil24358.jar
18:45:17,375 INFO [startup] Jndi(name=GeneralEJB.jar/My/ejbs.My)
18:45:17,375 INFO [startup] Created Ejb(deployment-
id=GeneralEJB.jar/My, ejb-name=My, container=Default Stateless
Container)
INFO log during 2.0.2-SNAPSHOT deploy:
18:52:08,701 INFO [config] Configuring app: sibc/ejb/7.0.0/ear
18:52:08,936 INFO [OpenEJB] Auto-deploying ejb My: EjbDeployment
(deployment-id=GeneralEJB.jar/My)
18:52:09,281 INFO [config] Loaded Module: sibc/ejb/7.0.0/ear
18:52:11,467 INFO [Enhance] You have enabled runtime enhancement,
but have not specified the set of persistent classes. OpenJPA must
look for metadata for every loaded class, which might increase
class load times significantly.
18:52:11,977 INFO [startup] Assembling app: /Users/kevan/geronimo/
server/branches/2.0/target/geronimo-jetty6-jee5-2.0.2-SNAPSHOT/var/
temp/geronimo-deploymentUtil14898.jar
18:52:12,440 INFO [startup] Jndi(name=GeneralEJB.jar/My/
ejbs.MyHome) -- Ejb(deployment-id=GeneralEJB.jar/My)
18:52:12,447 INFO [startup] Created Ejb(deployment-
id=GeneralEJB.jar/My, ejb-name=My, container=Default Stateless
Container)
Note the different JNDI names...
Looks like there's a change there (value of interfaceClass) I had
thought went in before 2.0.1 was shipped. The interfaceClass
variable now refers to the interface you get when you do a lookup, so
the EJBHome, EJBLocalHome or business interface such that if you set
your jndiname format to simply {interfaceClass} and did something
like this in code:
MyHome home = (MyHome) ctx.lookup(MyHome.class.getName());
It would work. Or if you wanted to implement a java generic service-
locator in you could set your jndiname format to something like
{ejbName}/{interfaceClass} you could do:
public T T getComponent(String ejbName, ClassT type) {
return (T)ctx.lookup(ejbName+/+type.getName());
}
MyHome home = getComponent(FooBean, MyHome.class);
You get the idea.
Anyway, it's up to us how we want to deal with this in Geronimo.
It's actually possible for us to replace this part of the system and
plugin in something that does whatever we like. We could go with the
change now and warn users, we could grab a copy of the old formatter
and plug it in replacing the updated formatter and use it till 2.0.x
is done (or longer i guess), or provide some other custom option.
(fyi, all of this is doable with trunk or 3.0-beta-1)
Anyone have any preferences or thoughts?
-David
Re: [DISCUSS] G 2.0.2 Release plan
On Sep 27, 2007, at 4:13 PM, Kevan Miller wrote: On Sep 26, 2007, at 7:30 PM, Kevan Miller wrote: On Sep 25, 2007, at 4:08 PM, Donald Woods wrote: OK, I'm done updating the 2.0.x closed issues (sorry for all the JIRA emails.) The only one I couldn't figure out, was: https://issues.apache.org/jira/browse/GERONIMO-3423 Donald, Thanks a bunch for going through all of those Jiras! David Blevins, Are we missing 3423 in branches/2.0? Heh. Looks like I merged the change to branches/2.0 in revision 570950 -- http://svn.apache.org/viewvc?view=revrevision=570950. :) -David
Re: [DISCUSS] G 2.0.2 Release plan
On Sep 25, 2007, at 6:40 PM, David Blevins wrote:
On Sep 25, 2007, at 7:38 AM, Kevan Miller wrote:
One thing I've noticed -- the default JNDI name for EJB's has been
changed in OpenEJB. So, there is a compatibility issue with 2.0.1.
We might be able to configure how OpenEJB generates this default
to maintain backward compatibility. Better, IMO, to go ahead and
match OpenEJB's behavior.
There are no compatibility issues as it was explicitly set in
Geronimo 2.0.1 to be essentially {moduleId}/{ejbName}/
{interfaceClass} (actually it's {deploymentId}/{interfaceClass}
and deploymentId will be {moduleId}/{ejbName}). It'll still be the
same in Geronimo 2.0.2, just now it can be changed to something
shorter.
Well, that's encouraging. However, something has changed between
2.0.1 and 2.0.2. Can you help explain the following?
INFO log during 2.0.1 deploy:
18:45:13,785 INFO [config] Configuring app: GeneralEJB.jar
18:45:13,849 INFO [OpenEJB] Auto-deploying ejb My: EjbDeployment
(deployment-id=GeneralEJB.jar/My, container-id=null)
18:45:14,066 INFO [config] Loaded Module: GeneralEJB.jar
18:45:16,653 INFO [Enhance] You have enabled runtime enhancement,
but have not specified the set of persistent classes. OpenJPA must
look for metadata for every loaded class, which might increase class
load times significantly.
18:45:17,021 INFO [startup] Assembling app: /geronimo-jetty6-
jee5-2.0.1/var/temp/geronimo-deploymentUtil24358.jar
18:45:17,375 INFO [startup] Jndi(name=GeneralEJB.jar/My/ejbs.My)
18:45:17,375 INFO [startup] Created Ejb(deployment-id=GeneralEJB.jar/
My, ejb-name=My, container=Default Stateless Container)
INFO log during 2.0.2-SNAPSHOT deploy:
18:52:08,701 INFO [config] Configuring app: sibc/ejb/7.0.0/ear
18:52:08,936 INFO [OpenEJB] Auto-deploying ejb My: EjbDeployment
(deployment-id=GeneralEJB.jar/My)
18:52:09,281 INFO [config] Loaded Module: sibc/ejb/7.0.0/ear
18:52:11,467 INFO [Enhance] You have enabled runtime enhancement,
but have not specified the set of persistent classes. OpenJPA must
look for metadata for every loaded class, which might increase class
load times significantly.
18:52:11,977 INFO [startup] Assembling app: /Users/kevan/geronimo/
server/branches/2.0/target/geronimo-jetty6-jee5-2.0.2-SNAPSHOT/var/
temp/geronimo-deploymentUtil14898.jar
18:52:12,440 INFO [startup] Jndi(name=GeneralEJB.jar/My/ejbs.MyHome)
-- Ejb(deployment-id=GeneralEJB.jar/My)
18:52:12,447 INFO [startup] Created Ejb(deployment-id=GeneralEJB.jar/
My, ejb-name=My, container=Default Stateless Container)
Note the different JNDI names...
--kevan
Re: [DISCUSS] G 2.0.2 Release plan
On Sep 25, 2007, at 4:08 PM, Donald Woods wrote: OK, I'm done updating the 2.0.x closed issues (sorry for all the JIRA emails.) The only one I couldn't figure out, was: https://issues.apache.org/jira/browse/GERONIMO-3423 Donald, Thanks a bunch for going through all of those Jiras! David Blevins, Are we missing 3423 in branches/2.0? --kevan
Re: [DISCUSS] G 2.0.2 Release plan
I've committed to branches/2.0 also. thanks david jencks On Sep 25, 2007, at 1:47 AM, David Jencks wrote: On Sep 24, 2007, at 8:52 AM, Anita Kulshreshtha wrote: --- Kevan Miller [EMAIL PROTECTED] wrote: On Sep 20, 2007, at 8:38 AM, Donald Woods wrote: I see that Anita has attached some patches for the MEJB problem. We need to get some eyes on these... David J's changes to openejb and geronimo-openejb-builder [1] are required for MEJB to work on trunk. I will commit MEJB stuff after these changes are committed. I opened a new jira 3484 for the specific openejb-deployer to openejb dependency problem and committed my fix in trunk. i expect to commit it in branches/2.0 sometime tuesday. thanks david jencks [1] https://issues.apache.org/jira/browse/GERONIMO-3481 Thanks Anita _ ___ Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mailp=graduation +giftscs=bz
Re: [DISCUSS] G 2.0.2 Release plan
On Sep 25, 2007, at 8:51 AM, David Jencks wrote: I've committed to branches/2.0 also. Thanks David! I think this leaves us with: * integration of the MEJB code itself * release of OpenEJB 3.0-Beta One thing I've noticed -- the default JNDI name for EJB's has been changed in OpenEJB. So, there is a compatibility issue with 2.0.1. We might be able to configure how OpenEJB generates this default to maintain backward compatibility. Better, IMO, to go ahead and match OpenEJB's behavior. --kevan
Re: [DISCUSS] G 2.0.2 Release plan
BTW - I'm going through JIRA today and updating any Fix For: 2.0.x closed/resolved issues to use the correct release attribute, so we can generate a valid list of fixes for the 2.0.2 release notes -Donald Kevan Miller wrote: All, I think it's time to start rolling out a 2.0.2 release. There have been a number of fixes in response to user issues, since 2.0.1. Time, I think, to make these available in a release. We'd also be able to make use of released versions of OpenJPA, Axis2, and hopefully OpenEjb, whittling away at our local builds... I think we have one must-fix problem that is outstanding -- the MEJB security issue. Assuming we resolve this problem, are there any other issues which must be resolved prior to a 2.0.2 release? Assuming we're in general agreement, I'd set a goal of creating a release candidate by next Friday (Sept 21). I'm volunteering to be the release manager. Thoughts? --kevan smime.p7s Description: S/MIME Cryptographic Signature
Re: [DISCUSS] G 2.0.2 Release plan
OK, I'm done updating the 2.0.x closed issues (sorry for all the JIRA emails.) The only one I couldn't figure out, was: https://issues.apache.org/jira/browse/GERONIMO-3423 -Donald Donald Woods wrote: BTW - I'm going through JIRA today and updating any Fix For: 2.0.x closed/resolved issues to use the correct release attribute, so we can generate a valid list of fixes for the 2.0.2 release notes -Donald Kevan Miller wrote: All, I think it's time to start rolling out a 2.0.2 release. There have been a number of fixes in response to user issues, since 2.0.1. Time, I think, to make these available in a release. We'd also be able to make use of released versions of OpenJPA, Axis2, and hopefully OpenEjb, whittling away at our local builds... I think we have one must-fix problem that is outstanding -- the MEJB security issue. Assuming we resolve this problem, are there any other issues which must be resolved prior to a 2.0.2 release? Assuming we're in general agreement, I'd set a goal of creating a release candidate by next Friday (Sept 21). I'm volunteering to be the release manager. Thoughts? --kevan smime.p7s Description: S/MIME Cryptographic Signature
Re: [DISCUSS] G 2.0.2 Release plan
I guess it is rev 570242 in trunk. Vamsi On 9/26/07, Donald Woods [EMAIL PROTECTED] wrote: OK, I'm done updating the 2.0.x closed issues (sorry for all the JIRA emails.) The only one I couldn't figure out, was: https://issues.apache.org/jira/browse/GERONIMO-3423 -Donald Donald Woods wrote: BTW - I'm going through JIRA today and updating any Fix For: 2.0.x closed/resolved issues to use the correct release attribute, so we can generate a valid list of fixes for the 2.0.2 release notes -Donald Kevan Miller wrote: All, I think it's time to start rolling out a 2.0.2 release. There have been a number of fixes in response to user issues, since 2.0.1. Time, I think, to make these available in a release. We'd also be able to make use of released versions of OpenJPA, Axis2, and hopefully OpenEjb, whittling away at our local builds... I think we have one must-fix problem that is outstanding -- the MEJB security issue. Assuming we resolve this problem, are there any other issues which must be resolved prior to a 2.0.2 release? Assuming we're in general agreement, I'd set a goal of creating a release candidate by next Friday (Sept 21). I'm volunteering to be the release manager. Thoughts? --kevan
Re: [DISCUSS] G 2.0.2 Release plan
On Sep 25, 2007, at 7:38 AM, Kevan Miller wrote:
One thing I've noticed -- the default JNDI name for EJB's has been
changed in OpenEJB. So, there is a compatibility issue with 2.0.1.
We might be able to configure how OpenEJB generates this default to
maintain backward compatibility. Better, IMO, to go ahead and match
OpenEJB's behavior.
There are no compatibility issues as it was explicitly set in
Geronimo 2.0.1 to be essentially {moduleId}/{ejbName}/
{interfaceClass} (actually it's {deploymentId}/{interfaceClass} and
deploymentId will be {moduleId}/{ejbName}). It'll still be the same
in Geronimo 2.0.2, just now it can be changed to something shorter.
I'd be fine with Geronimo using the OpenEJB default of essentially
{ejbName}{interfaceType.annotationName} (it's {deploymentId}
{interfaceType.annotation} where deploymentId defaults to {ejbName}),
but it's definitely a default that targets people with just a couple
apps. People in bigger environments would have to set the jndiname
and deploymentId formats to something less likely to conflict.
-David
Re: [DISCUSS] G 2.0.2 Release plan
--- Kevan Miller [EMAIL PROTECTED] wrote: On Sep 20, 2007, at 8:38 AM, Donald Woods wrote: I see that Anita has attached some patches for the MEJB problem. We need to get some eyes on these... David J's changes to openejb and geronimo-openejb-builder [1] are required for MEJB to work on trunk. I will commit MEJB stuff after these changes are committed. [1] https://issues.apache.org/jira/browse/GERONIMO-3481 Thanks Anita Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mailp=graduation+giftscs=bz
Re: [DISCUSS] G 2.0.2 Release plan
On Sep 24, 2007, at 8:52 AM, Anita Kulshreshtha wrote: --- Kevan Miller [EMAIL PROTECTED] wrote: On Sep 20, 2007, at 8:38 AM, Donald Woods wrote: I see that Anita has attached some patches for the MEJB problem. We need to get some eyes on these... David J's changes to openejb and geronimo-openejb-builder [1] are required for MEJB to work on trunk. I will commit MEJB stuff after these changes are committed. I opened a new jira 3484 for the specific openejb-deployer to openejb dependency problem and committed my fix in trunk. i expect to commit it in branches/2.0 sometime tuesday. thanks david jencks [1] https://issues.apache.org/jira/browse/GERONIMO-3481 Thanks Anita __ __ Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mailp=graduation+giftscs=bz
Re: [DISCUSS] G 2.0.2 Release plan
Donald Woods wrote: Agree. There are some recent fixes in txmanager and javamail which we should also try to include. The Genesis project should also be updated, as it sets maven-compiler-plugin to 1.4 for the JDK src and targets. Are you referring to the javamail changes I checked in over the last couple of days? I'm not sure sure those are worthy of spinning a new release of the specs just to pick up those fixes. The one change was just additional javadoc, the other change was something that won't have an impact on anything until the IMAP support is complete. Rick I've got one or two patches that I'd like to get in, which I'm not going to get to until early next week If you need help releasing any of the dependent Geronimo artifacts (like txmanager or specs) let me know and I'd be glad to help out on those, so I can start learning the release ropes :-) -Donald Kevan Miller wrote: All, I think it's time to start rolling out a 2.0.2 release. There have been a number of fixes in response to user issues, since 2.0.1. Time, I think, to make these available in a release. We'd also be able to make use of released versions of OpenJPA, Axis2, and hopefully OpenEjb, whittling away at our local builds... I think we have one must-fix problem that is outstanding -- the MEJB security issue. Assuming we resolve this problem, are there any other issues which must be resolved prior to a 2.0.2 release? Assuming we're in general agreement, I'd set a goal of creating a release candidate by next Friday (Sept 21). I'm volunteering to be the release manager. Thoughts? --kevan
Re: [DISCUSS] G 2.0.2 Release plan
OK, thanks for the clarification. Guess it can wait for a future release when there are more updates included. -Donald Rick McGuire wrote: Donald Woods wrote: Agree. There are some recent fixes in txmanager and javamail which we should also try to include. The Genesis project should also be updated, as it sets maven-compiler-plugin to 1.4 for the JDK src and targets. Are you referring to the javamail changes I checked in over the last couple of days? I'm not sure sure those are worthy of spinning a new release of the specs just to pick up those fixes. The one change was just additional javadoc, the other change was something that won't have an impact on anything until the IMAP support is complete. Rick I've got one or two patches that I'd like to get in, which I'm not going to get to until early next week If you need help releasing any of the dependent Geronimo artifacts (like txmanager or specs) let me know and I'd be glad to help out on those, so I can start learning the release ropes :-) -Donald Kevan Miller wrote: All, I think it's time to start rolling out a 2.0.2 release. There have been a number of fixes in response to user issues, since 2.0.1. Time, I think, to make these available in a release. We'd also be able to make use of released versions of OpenJPA, Axis2, and hopefully OpenEjb, whittling away at our local builds... I think we have one must-fix problem that is outstanding -- the MEJB security issue. Assuming we resolve this problem, are there any other issues which must be resolved prior to a 2.0.2 release? Assuming we're in general agreement, I'd set a goal of creating a release candidate by next Friday (Sept 21). I'm volunteering to be the release manager. Thoughts? --kevan smime.p7s Description: S/MIME Cryptographic Signature
Re: [DISCUSS] G 2.0.2 Release plan
Also, the changes in txmanager aren't enough to warrant another components release. The txmanager change was only to fix a misspelling in an exception message... -Donald Donald Woods wrote: Agree. There are some recent fixes in txmanager and javamail which we should also try to include. The Genesis project should also be updated, as it sets maven-compiler-plugin to 1.4 for the JDK src and targets. I've got one or two patches that I'd like to get in, which I'm not going to get to until early next week If you need help releasing any of the dependent Geronimo artifacts (like txmanager or specs) let me know and I'd be glad to help out on those, so I can start learning the release ropes :-) -Donald Kevan Miller wrote: All, I think it's time to start rolling out a 2.0.2 release. There have been a number of fixes in response to user issues, since 2.0.1. Time, I think, to make these available in a release. We'd also be able to make use of released versions of OpenJPA, Axis2, and hopefully OpenEjb, whittling away at our local builds... I think we have one must-fix problem that is outstanding -- the MEJB security issue. Assuming we resolve this problem, are there any other issues which must be resolved prior to a 2.0.2 release? Assuming we're in general agreement, I'd set a goal of creating a release candidate by next Friday (Sept 21). I'm volunteering to be the release manager. Thoughts? --kevan smime.p7s Description: S/MIME Cryptographic Signature
Re: [DISCUSS] G 2.0.2 Release plan
On Sep 20, 2007, at 8:38 AM, Donald Woods wrote: Also, the changes in txmanager aren't enough to warrant another components release. The txmanager change was only to fix a misspelling in an exception message... Ya. However, there was a Transaction Recovery jira opened. I'm going to have a quick look. We may have dropped a fix between M6 and 2.0... I see that Anita has attached some patches for the MEJB problem. We need to get some eyes on these... Finally, we need to get some TCK issues cleaned up. We have some EJB- related issues to resolve... Oh. One more thing... OpenEJB is nearing a 3.0 beta release. We have a choice of creating a new private build of OpenEJB. Or lining up with their Beta release. I'd rather grab their beta release. However, if they have a significant delay, will need to reconsider... --kevan
Re: [DISCUSS] G 2.0.2 Release plan
Agree. There are some recent fixes in txmanager and javamail which we should also try to include. The Genesis project should also be updated, as it sets maven-compiler-plugin to 1.4 for the JDK src and targets. I've got one or two patches that I'd like to get in, which I'm not going to get to until early next week If you need help releasing any of the dependent Geronimo artifacts (like txmanager or specs) let me know and I'd be glad to help out on those, so I can start learning the release ropes :-) -Donald Kevan Miller wrote: All, I think it's time to start rolling out a 2.0.2 release. There have been a number of fixes in response to user issues, since 2.0.1. Time, I think, to make these available in a release. We'd also be able to make use of released versions of OpenJPA, Axis2, and hopefully OpenEjb, whittling away at our local builds... I think we have one must-fix problem that is outstanding -- the MEJB security issue. Assuming we resolve this problem, are there any other issues which must be resolved prior to a 2.0.2 release? Assuming we're in general agreement, I'd set a goal of creating a release candidate by next Friday (Sept 21). I'm volunteering to be the release manager. Thoughts? --kevan smime.p7s Description: S/MIME Cryptographic Signature
Re: [DISCUSS] G 2.0.2 Release plan
Can we also get an updated TranQL release, to pickup Lin's updated Oracle fix in GERONIMO-2188 and finally release the DB2 vendor files? I'd be glad to help with those, too. -Donald Kevan Miller wrote: All, I think it's time to start rolling out a 2.0.2 release. There have been a number of fixes in response to user issues, since 2.0.1. Time, I think, to make these available in a release. We'd also be able to make use of released versions of OpenJPA, Axis2, and hopefully OpenEjb, whittling away at our local builds... I think we have one must-fix problem that is outstanding -- the MEJB security issue. Assuming we resolve this problem, are there any other issues which must be resolved prior to a 2.0.2 release? Assuming we're in general agreement, I'd set a goal of creating a release candidate by next Friday (Sept 21). I'm volunteering to be the release manager. Thoughts? --kevan smime.p7s Description: S/MIME Cryptographic Signature
Re: [DISCUSS] G 2.0.2 Release plan
I thought of verifying whether 2.0.2 will have the fix for https://issues.apache.org/jira/browse/GERONIMO-3380 (Derby embedded database pool created from console doesn't work) but I am getting too late. Thanks, Shiva On 9/14/07, Kevan Miller [EMAIL PROTECTED] wrote: All, I think it's time to start rolling out a 2.0.2 release. There have been a number of fixes in response to user issues, since 2.0.1. Time, I think, to make these available in a release. We'd also be able to make use of released versions of OpenJPA, Axis2, and hopefully OpenEjb, whittling away at our local builds... I think we have one must-fix problem that is outstanding -- the MEJB security issue. Assuming we resolve this problem, are there any other issues which must be resolved prior to a 2.0.2 release? Assuming we're in general agreement, I'd set a goal of creating a release candidate by next Friday (Sept 21). I'm volunteering to be the release manager. Thoughts? --kevan
Re: [DISCUSS] G 2.0.2 Release plan
On Sep 14, 2007, at 2:55 AM, Kevan Miller wrote: All, I think it's time to start rolling out a 2.0.2 release. There have been a number of fixes in response to user issues, since 2.0.1. Time, I think, to make these available in a release. We'd also be able to make use of released versions of OpenJPA, Axis2, and hopefully OpenEjb, whittling away at our local builds... I think we have one must-fix problem that is outstanding -- the MEJB security issue. Assuming we resolve this problem, are there any other issues which must be resolved prior to a 2.0.2 release? Assuming we're in general agreement, I'd set a goal of creating a release candidate by next Friday (Sept 21). I'm volunteering to be the release manager. +1 to Kevan being RM. Thoughts? --kevan
Re: [DISCUSS] G 2.0.2 Release plan
+1 on the release +1 on Kevan as RM Also, I'd like to help out on TCK testing. I've never done it before but I have sent in my NDA. Matt Hogstrom wrote: On Sep 14, 2007, at 2:55 AM, Kevan Miller wrote: All, I think it's time to start rolling out a 2.0.2 release. There have been a number of fixes in response to user issues, since 2.0.1. Time, I think, to make these available in a release. We'd also be able to make use of released versions of OpenJPA, Axis2, and hopefully OpenEjb, whittling away at our local builds... I think we have one must-fix problem that is outstanding -- the MEJB security issue. Assuming we resolve this problem, are there any other issues which must be resolved prior to a 2.0.2 release? Assuming we're in general agreement, I'd set a goal of creating a release candidate by next Friday (Sept 21). I'm volunteering to be the release manager. +1 to Kevan being RM. Thoughts? --kevan
Re: [DISCUSS] G 2.0.2 Release plan
Moved from another mail thread... On 9/17/07, David Jencks [EMAIL PROTECTED] wrote: I'm starting to wonder what the goal for 2.0.2 is. I kinda thought that a x.y.z where z 0 was a bugfix-only release of x.y.z-1 but I think some new features are going into 2.0.2... IIUC Vamsi is applying an enhancement to allow specifying work directory per-web- app and donald is encouraging me to apply my proposal to GERONIMO-2925 to the branch. Though small these are definitely new features. The goal of 2.0.2 is to get fixes into user's hands. In general, I agree with you. 2.0.x releases are bug-fix releases. You're raising two questions: 1) what is a bug fix? and 2) how dogmatic do we want to be in our bug-fix release management? Regarding 1), I think we'd agree that there isn't necessarily an objective measure for determining what is or isn't a bug fix. Re: 2), we could be pretty conservative on our interpretation of bug fix or we can be a bit more permissive on what we interpret as a bug fix. Personally, I probably fall into a more permissive side of that decision (at least at this point in time of our 2.x lifetime -- I expect I'll have a different answer when 2.4 rolls around...). In the meantime, if users are encountering issues or experiencing pain because of missing features (perhaps features that were overlooked), then I'm not averse to alleviating this pain in a 2.0.x release. More important metric, IMO, is are we helping our users? I haven't looked closely at either of the issues that you highlight. If you'd like me to, I'll evaluate and give my opinion with a release manager hat on -- barring objections...) Personally I would prefer to minimize such feature creep and have more focus on getting 2.1 out in a less than geological time frame, in particular before apachecon atlanta. I haven't seen a discussion or proposal for a 2.1 release. So, it's hard for me to evaluate if ApacheCon is a reasonable date for 2.1. I don't think that a 2.1 schedule is, by itself, a reason to not do work in 2.0.x -- especially at this point. When we have a target 2.1 release date and are getting closer to that date, then I'm sure I'd feel differently... --kevan
[DISCUSS] G 2.0.2 Release plan
All, I think it's time to start rolling out a 2.0.2 release. There have been a number of fixes in response to user issues, since 2.0.1. Time, I think, to make these available in a release. We'd also be able to make use of released versions of OpenJPA, Axis2, and hopefully OpenEjb, whittling away at our local builds... I think we have one must-fix problem that is outstanding -- the MEJB security issue. Assuming we resolve this problem, are there any other issues which must be resolved prior to a 2.0.2 release? Assuming we're in general agreement, I'd set a goal of creating a release candidate by next Friday (Sept 21). I'm volunteering to be the release manager. Thoughts? --kevan
Re: [DISCUSS] G 2.0.2 Release plan
On 9/14/07, Kevan Miller [EMAIL PROTECTED] wrote: All, I think it's time to start rolling out a 2.0.2 release. There have been a number of fixes in response to user issues, since 2.0.1. Time, I think, to make these available in a release. We'd also be able to make use of released versions of OpenJPA, Axis2, and hopefully OpenEjb, whittling away at our local builds... I think we have one must-fix problem that is outstanding -- the MEJB security issue. Agreed. Assuming we resolve this problem, are there any other issues which must be resolved prior to a 2.0.2 release? Assuming we're in general agreement, I'd set a goal of creating a release candidate by next Friday (Sept 21). I'm volunteering to be the release manager. +1 to Kevan as RM (whether or not there is a vote). Thoughts? --kevan
Re: [DISCUSS] G 2.0.2 Release plan
Kevan, I have one remaining task to do for 2.0.2. I would like to update the version of CXF to 2.0.1 (or 2.0.2 if it is released really soon). Just need to verify first if it is all good from TCK standpoint. Jarek On 9/14/07, Kevan Miller [EMAIL PROTECTED] wrote: All, I think it's time to start rolling out a 2.0.2 release. There have been a number of fixes in response to user issues, since 2.0.1. Time, I think, to make these available in a release. We'd also be able to make use of released versions of OpenJPA, Axis2, and hopefully OpenEjb, whittling away at our local builds... I think we have one must-fix problem that is outstanding -- the MEJB security issue. Assuming we resolve this problem, are there any other issues which must be resolved prior to a 2.0.2 release? Assuming we're in general agreement, I'd set a goal of creating a release candidate by next Friday (Sept 21). I'm volunteering to be the release manager. Thoughts? --kevan
Re: [DISCUSS] G 2.0.2 Release plan
Kevan Miller wrote: All, I think it's time to start rolling out a 2.0.2 release. There have been a number of fixes in response to user issues, since 2.0.1. Time, I think, to make these available in a release. We'd also be able to make use of released versions of OpenJPA, Axis2, and hopefully OpenEjb, whittling away at our local builds... I think we have one must-fix problem that is outstanding -- the MEJB security issue. Yup, need this one fixed before releasing 2.0.2 Assuming we resolve this problem, are there any other issues which must be resolved prior to a 2.0.2 release? Assuming we're in general agreement, I'd set a goal of creating a release candidate by next Friday (Sept 21). I'm volunteering to be the release manager. Thoughts? --kevan Cheers! Hernan
