Re: Geronimo 2.0: customize EJB-Container settings
Hi I opened a JIRA and attached an initial patch for a new portlet for displaying information regarding the different ejb containers and the ejbs deployed in them. The JIRA is http://issues.apache.org/jira/browse/GERONIMO-3811. Currently to after changing the properties like pool size etc the portlet prompts you to restart the server as openejb doesn't support dynamic changes of these settings. Suggestions welcome Thanks Manu On Thu, Jan 31, 2008 at 8:16 PM, Kevan Miller <[EMAIL PROTECTED]> wrote: > > On Jan 31, 2008, at 7:36 AM, Manu George wrote: > > > Hi, > > > > What does the community think about having a portlet in the admin > > console for configuring openejb related stuff as well as displaying > > the different containers etc deployed in Geronimo. I think this may > > improve the usability of Geronimo. If there is interest I would like > > to investigate it further. > > Is that a trick question? ;-) Sounds like a great idea. I'd certainly > be interested in seeing console support. Doubt that I'd be able to > help out, though... > > --kevan > >
Re: Geronimo 2.0: customize EJB-Container settings
On Jan 31, 2008, at 7:36 AM, Manu George wrote: Hi, What does the community think about having a portlet in the admin console for configuring openejb related stuff as well as displaying the different containers etc deployed in Geronimo. I think this may improve the usability of Geronimo. If there is interest I would like to investigate it further. Is that a trick question? ;-) Sounds like a great idea. I'd certainly be interested in seeing console support. Doubt that I'd be able to help out, though... --kevan
Re: Geronimo 2.0: customize EJB-Container settings
Hi,
What does the community think about having a portlet in the admin
console for configuring openejb related stuff as well as displaying
the different containers etc deployed in Geronimo. I think this may
improve the usability of Geronimo. If there is interest I would like
to investigate it further.
Regards
Manu
On Jan 29, 2008 3:14 AM, Gianny Damour <[EMAIL PROTECTED]> wrote:
>
> >
> > Hello Mario,
> >
> > I do not know. I forward your email to the OpenEJB user list, where
> > experts should be able to help.
> >
> > Thanks,
> > Gianny
> >
> > On 28/01/2008, at 1:21 AM, the666pack wrote:
> >
> >>
> >> hello,
> >>
> >> thank you, these values are quite helpful already to specify
> >> important
> >> performance values.
> >>
> >> however i am missing some configuration settings.. in particular:
> >>
> >> - container settings for entity beans (maximum pool size, commit
> >> option)
> >> - cache settings (not pool-settings but merely what happens when
> >> the pool is
> >> full)
> >>
> >> is it possible to set such settings in geronimo or openejb?
> >>
> >> thanks very much for helping,
> >>
> >> mario.
> >>
> >>
> >> Gianny Damour wrote:
> >>>
> >>> Hello Mario,
> >>>
> >>> EJB Container properties along with their default values are defined
> >>> by the resource META-INF/org.apache.openejb.embedded/service-jar.xml
> >>> within the openejb-core.jar archive. Here is an URL pointing to this
> >>> resource:
> >>> http://svn.apache.org/repos/asf/openejb/trunk/openejb3/container/
> >>> openejb-core/src/main/resources/META-INF/
> >>> org.apache.openejb.embedded/
> >>> service-jar.xml
> >>>
> >>> I believe you are after the TimeOut and PoolSize properties.
> >>>
> >>> Thanks,
> >>> Gianny
> >>>
> >>> On 26/01/2008, at 10:28 PM, the666pack wrote:
> >>>
>
> thanks,
>
> where can i get a full listing of the possible properties for the
> openejb
> container?
>
> in particular i would need properties like MaxCacheSize for how
> many beans
> can be kept at the same time by the ejb-container or a
> RemoveTimeout which
> defines the time after which the beans are removed from the pool
> when not
> needed.
>
> i didnt find a list where i can see the properties that are
> possible for
> openejb.
>
> thanks for helping,
>
> mario
>
>
> Gianny Damour wrote:
> >
> > Hello,
> >
> > You can change these settings in var/config/config.xml. This file
> > defines overrides for the GBeans, i.e. services such as EJB-
> > Containers, running within Geronimo.
> >
> > EJB Containers are declared by the org.apache.geronimo.configs/
> > openejb//car confiiguration and here are there default
> > configuration:
> >
> > > class="org.apache.geronimo.openejb.EjbContainer">
> > Default Stateless Container > attribute>
> > STATELESS
> >
> > OpenEjbSystem
> >
> >
> > > class="org.apache.geronimo.openejb.EjbContainer">
> > Default Stateful Container > attribute>
> > STATEFUL
> > PoolSize=1000
> >
> > OpenEjbSystem
> >
> >
> > > class="org.apache.geronimo.openejb.EjbContainer">
> > Default BMP Container
> > BMP_ENTITY
> >
> > OpenEjbSystem
> >
> >
> > > class="org.apache.geronimo.openejb.EjbContainer">
> > Default CMP Container
> > CMP_ENTITY
> >
> > OpenEjbSystem
> >
> >
> >
> > To override the PoolSize attribute of DefaultStatefulContainer,
> > you
> > need to update the org.apache.geronimo.configs/openejb//car
> > confiiguration as follows in var/config/config.xm:
> >
> >
> >
> > ${OpenEJBPort + PortOffset} > attribute>
> > ${ServerHostname}
> >
> >
> >
> >PoolSize=100 > attribute>
> >
> >
> >
> >
> > Properties declared there are passed "as-is" to OpenEJB; hence,
> > you
> > can use the same property names defined by OpenEJB.
> >
> > Thanks,
> > Gianny
> >
> >
> > On 25/01/2008, at 6:19 AM, the666pack wrote:
> >
> >>
> >> Hello,
> >>
> >> Can anybody tell me how i can customize the EJB-Container
> >> settings in
> >> Geronimo?
> >>
> >> I dont find an entry in the admin-console and i dont have an idea
> >> which
> >> files i can search for change.
> >>
> >> Basically i would like to set values like Bean-Pool Size or
> >> Maximum
> >> Cache
> >> Size as well as Timeout values.
> >>
> >> I
Re: Geronimo 2.0 Release suspended due to security issue found before release
At this point, I am not really sure. We can always easily move them around. If you have or can envision a lot of CLI tests, we can create a separate testsuite for it. This separate testsuite won't have to start/stop selenium server too since it is cmdline. If you want to drop it under deployment-testsuite for now, that's fine too. Cheers Prasad On 8/14/07, Donald Woods <[EMAIL PROTECTED]> wrote: > > Where were you thinking? Should we start a new subdirectory for cmdline > tests? Or could it go under deployment-testsuite? > > -Donald > > > Prasad Kashyap wrote: > > Good catch Donald. Can you please throw in a small test(s) in our > > testsuite framework so that we can catch things like this ? There are > > a lot of tests there already that can act as a template/example and > > help you with your testcase. > > > > Let me know if you need more help. > > > > Cheers > > Prasad > > > > On 8/13/07, Donald Woods <[EMAIL PROTECTED]> wrote: > >> > >> Matt Hogstrom wrote: > >>> All, > >>> > >>> Earlier today one of the Geronimo committers discovered a bug in the > >>> command line deployer where a null user / password on the deployer > >>> command line will allow a user to deploy modules to a 2.0 server. This > >>> is an unacceptable security exposure and as such we have abandoned the > >>> release of Geronimo 2.0. > >>> > >>> Donald Woods is going to open a JIRA for this issue and Hernan will > >>> create a news item on our web page. > >> GERONIMO-3404 was opened for this. > >> > >>> At this point we need to discuss how to move forward with a 2.0 release. > >>> > >>> I think we should delete the tags/2.0.0 entry and replace it with a text > >>> file that notes the svn rev of the tree before deletion. The purpose of > >>> this is to avoid anyone from picking up that source tree and using it to > >>> build a server with a known security exposure. Unless there is > >>> disagreement I'd like to do that tomorrow allowing some time for > >>> discussion. We can always put it back. > >>> > >>> There are several options for the 2.0 release: > >>> > >>> 1. Use the branches/2.0 to spin up a new release as 2.0.1. > >>> If we do this there are a number of fixes that need to be verified, > >>> We'd need to close out the SNAPSHOT releases again, or at least revisit > >>> them. > >>> Respin and re-tck a new release. > >>> > >>> 2. Take the tags/2.0.0 to create a branches/2.0.1 > >>> This would mean that we need to update branches/2.0 to 2.0.2-SNAPSHOT > >>> Copy the existing tag over and apply the security fixes. Repsin and > >>> release. > >>> > >>> Personally, I vote for option 2. Based on my experience, closing out > >>> the SNAPSHOTs is and introducing little changes will cause us to restart > >>> the release process. > >> +1 on option #2. > >> > >> > >>> I'd like to hear other people's input but having done the release > >>> several times option 2 is the fastest. I think option 1 will cause us > >>> to not release until September. > >>> > >>> > >> > > > > > >
Re: Geronimo 2.0 Release suspended due to security issue found before release
Where were you thinking? Should we start a new subdirectory for cmdline tests? Or could it go under deployment-testsuite? -Donald Prasad Kashyap wrote: > Good catch Donald. Can you please throw in a small test(s) in our > testsuite framework so that we can catch things like this ? There are > a lot of tests there already that can act as a template/example and > help you with your testcase. > > Let me know if you need more help. > > Cheers > Prasad > > On 8/13/07, Donald Woods <[EMAIL PROTECTED]> wrote: >> >> Matt Hogstrom wrote: >>> All, >>> >>> Earlier today one of the Geronimo committers discovered a bug in the >>> command line deployer where a null user / password on the deployer >>> command line will allow a user to deploy modules to a 2.0 server. This >>> is an unacceptable security exposure and as such we have abandoned the >>> release of Geronimo 2.0. >>> >>> Donald Woods is going to open a JIRA for this issue and Hernan will >>> create a news item on our web page. >> GERONIMO-3404 was opened for this. >> >>> At this point we need to discuss how to move forward with a 2.0 release. >>> >>> I think we should delete the tags/2.0.0 entry and replace it with a text >>> file that notes the svn rev of the tree before deletion. The purpose of >>> this is to avoid anyone from picking up that source tree and using it to >>> build a server with a known security exposure. Unless there is >>> disagreement I'd like to do that tomorrow allowing some time for >>> discussion. We can always put it back. >>> >>> There are several options for the 2.0 release: >>> >>> 1. Use the branches/2.0 to spin up a new release as 2.0.1. >>> If we do this there are a number of fixes that need to be verified, >>> We'd need to close out the SNAPSHOT releases again, or at least revisit >>> them. >>> Respin and re-tck a new release. >>> >>> 2. Take the tags/2.0.0 to create a branches/2.0.1 >>> This would mean that we need to update branches/2.0 to 2.0.2-SNAPSHOT >>> Copy the existing tag over and apply the security fixes. Repsin and >>> release. >>> >>> Personally, I vote for option 2. Based on my experience, closing out >>> the SNAPSHOTs is and introducing little changes will cause us to restart >>> the release process. >> +1 on option #2. >> >> >>> I'd like to hear other people's input but having done the release >>> several times option 2 is the fastest. I think option 1 will cause us >>> to not release until September. >>> >>> >> > >
Re: Geronimo 2.0 Release suspended due to security issue found before release
Good catch Donald. Can you please throw in a small test(s) in our testsuite framework so that we can catch things like this ? There are a lot of tests there already that can act as a template/example and help you with your testcase. Let me know if you need more help. Cheers Prasad On 8/13/07, Donald Woods <[EMAIL PROTECTED]> wrote: > > > Matt Hogstrom wrote: > > All, > > > > Earlier today one of the Geronimo committers discovered a bug in the > > command line deployer where a null user / password on the deployer > > command line will allow a user to deploy modules to a 2.0 server. This > > is an unacceptable security exposure and as such we have abandoned the > > release of Geronimo 2.0. > > > > Donald Woods is going to open a JIRA for this issue and Hernan will > > create a news item on our web page. > > GERONIMO-3404 was opened for this. > > > > > At this point we need to discuss how to move forward with a 2.0 release. > > > > I think we should delete the tags/2.0.0 entry and replace it with a text > > file that notes the svn rev of the tree before deletion. The purpose of > > this is to avoid anyone from picking up that source tree and using it to > > build a server with a known security exposure. Unless there is > > disagreement I'd like to do that tomorrow allowing some time for > > discussion. We can always put it back. > > > > There are several options for the 2.0 release: > > > > 1. Use the branches/2.0 to spin up a new release as 2.0.1. > > If we do this there are a number of fixes that need to be verified, > > We'd need to close out the SNAPSHOT releases again, or at least revisit > > them. > > Respin and re-tck a new release. > > > > 2. Take the tags/2.0.0 to create a branches/2.0.1 > > This would mean that we need to update branches/2.0 to 2.0.2-SNAPSHOT > > Copy the existing tag over and apply the security fixes. Repsin and > > release. > > > > Personally, I vote for option 2. Based on my experience, closing out > > the SNAPSHOTs is and introducing little changes will cause us to restart > > the release process. > > +1 on option #2. > > > > > > I'd like to hear other people's input but having done the release > > several times option 2 is the fastest. I think option 1 will cause us > > to not release until September. > > > > > >
Re: Geronimo 2.0 Release suspended due to security issue found before release
Verified that the fixes address the security bug Donald has identified. No
regression is observed in case of GERONIMO-2266 and GERONIMO-2267. I
suggest others verify any scenarios they can think of for possible
regression.
Vamsi
On 8/14/07, David Jencks <[EMAIL PROTECTED]> wrote:
>
> I've now fixed GERONIMO-3407 in trunk, rev 565657. I added new
> methods to ContextManager and removed direct use of LoginContext.
> Among other things this may make implementing jaspi slightly easier.
>
> New methods are:
> public static LoginContext login(String realm, CallbackHandler
> callbackHandler) throws LoginException {
> Subject subject = new Subject();
> LoginContext loginContext = new LoginContext(realm, subject,
> callbackHandler);
> loginContext.login();
> SubjectId id = ContextManager.registerSubject(subject);
> IdentificationPrincipal principal = new
> IdentificationPrincipal(id);
> subject.getPrincipals().add(principal);
> return loginContext;
> }
>
> public static void logout(LoginContext loginContext) throws
> LoginException {
> Subject subject = loginContext.getSubject();
> ContextManager.unregisterSubject(subject);
> loginContext.logout();
> }
>
>
> This revision needs to be ported to branches/2.0 and wherever 2.0.1 is.
>
> thanks
> david jencks
>
> On Aug 13, 2007, at 6:27 PM, David Jencks wrote:
>
> > I think I've fixed GERONIMO-3404 and GERONIMO-3406 in trunk, rev
> > 565599. It might be a good idea for this to get a review before we
> > port it to branches/2.0 and possibly branches/2.0.x.
> >
> > I haven't decided how to fix GERONIMO-3407 yet, and could be talked
> > out of it for 2.0.1. The problem would manifest itself as geronimo
> > not working if anyone tried to use a login module with REQUISITE
> > or (I think) SUFFICIENT flags. I don't think there's any security
> > exposure, it just that you effectively couldn't log in with such a
> > login configuration.
> >
> > On a completely unrelated issue I can't build modules/geronimo-axis-
> > builder in trunk as part of the main build, I get a complaint from
> > javac. I don't have problems building it by itself. Anyone else
> > see this?
> >
> > thanks
> > david jencks
> > On Aug 13, 2007, at 5:03 PM, David Jencks wrote:
> >
> >> So before we all jump onto option 2 maybe we should consider just
> >> how big a change this set of bugs is causing and comparatively how
> >> much branches/2.0 has changed since 2.0.0 was cut.
> >>
> >> It looks like there have been about 15 commits to branches/2.0
> >> that aren't version changes, many of them simple fixes that make
> >> things like the plugin installer actually usable. On the other
> >> hand so far I've modified 16 files working on this security fix
> >> (admittedly most of them either simple fixes and/or documentation)
> >> and still have to figure out a solution to
> >> SubjectRegistrationLoginModule not working (GERONIMO-3407)
> >>
> >> If we go with (2) I would like some of the changes to branches/
> >> 2.0 to be merged in, especially rev 563592. I think r563662 and
> >> r563782 would be good also.
> >>
> >> thanks
> >> david jencks
> >>
> >> On Aug 13, 2007, at 1:59 PM, Matt Hogstrom wrote:
> >>
> >>> All,
> >>>
> >>> Earlier today one of the Geronimo committers discovered a bug in
> >>> the command line deployer where a null user / password on the
> >>> deployer command line will allow a user to deploy modules to a
> >>> 2.0 server. This is an unacceptable security exposure and as
> >>> such we have abandoned the release of Geronimo 2.0.
> >>>
> >>> Donald Woods is going to open a JIRA for this issue and Hernan
> >>> will create a news item on our web page.
> >>>
> >>> At this point we need to discuss how to move forward with a 2.0
> >>> release.
> >>>
> >>> I think we should delete the tags/2.0.0 entry and replace it with
> >>> a text file that notes the svn rev of the tree before deletion.
> >>> The purpose of this is to avoid anyone from picking up that
> >>> source tree and using it to build a server with a known security
> >>> exposure. Unless there is disagreement I'd like to do that
> >>> tomorrow allowing some time for discussion. We can always put it
> >>> back.
> >>>
> >>> There are several options for the 2.0 release:
> >>>
> >>> 1. Use the branches/2.0 to spin up a new release as 2.0.1.
> >>> If we do this there are a number of fixes that need to be
> >>> verified, We'd need to close out the SNAPSHOT releases again, or
> >>> at least revisit them.
> >>> Respin and re-tck a new release.
> >>>
> >>> 2. Take the tags/2.0.0 to create a branches/2.0.1
> >>> This would mean that we need to update branches/2.0 to 2.0.2-
> >>> SNAPSHOT
> >>> Copy the existing tag over and apply the security fixes.
> >>> Repsin and release.
> >>>
> >>> Personally, I vote for option 2. Based on my experience, closing
> >>> out the SNAPSHOTs is and introducing little changes will cau
Re: Geronimo 2.0 Release suspended due to security issue found before release
I've now fixed GERONIMO-3407 in trunk, rev 565657. I added new
methods to ContextManager and removed direct use of LoginContext.
Among other things this may make implementing jaspi slightly easier.
New methods are:
public static LoginContext login(String realm, CallbackHandler
callbackHandler) throws LoginException {
Subject subject = new Subject();
LoginContext loginContext = new LoginContext(realm, subject,
callbackHandler);
loginContext.login();
SubjectId id = ContextManager.registerSubject(subject);
IdentificationPrincipal principal = new
IdentificationPrincipal(id);
subject.getPrincipals().add(principal);
return loginContext;
}
public static void logout(LoginContext loginContext) throws
LoginException {
Subject subject = loginContext.getSubject();
ContextManager.unregisterSubject(subject);
loginContext.logout();
}
This revision needs to be ported to branches/2.0 and wherever 2.0.1 is.
thanks
david jencks
On Aug 13, 2007, at 6:27 PM, David Jencks wrote:
I think I've fixed GERONIMO-3404 and GERONIMO-3406 in trunk, rev
565599. It might be a good idea for this to get a review before we
port it to branches/2.0 and possibly branches/2.0.x.
I haven't decided how to fix GERONIMO-3407 yet, and could be talked
out of it for 2.0.1. The problem would manifest itself as geronimo
not working if anyone tried to use a login module with REQUISITE
or (I think) SUFFICIENT flags. I don't think there's any security
exposure, it just that you effectively couldn't log in with such a
login configuration.
On a completely unrelated issue I can't build modules/geronimo-axis-
builder in trunk as part of the main build, I get a complaint from
javac. I don't have problems building it by itself. Anyone else
see this?
thanks
david jencks
On Aug 13, 2007, at 5:03 PM, David Jencks wrote:
So before we all jump onto option 2 maybe we should consider just
how big a change this set of bugs is causing and comparatively how
much branches/2.0 has changed since 2.0.0 was cut.
It looks like there have been about 15 commits to branches/2.0
that aren't version changes, many of them simple fixes that make
things like the plugin installer actually usable. On the other
hand so far I've modified 16 files working on this security fix
(admittedly most of them either simple fixes and/or documentation)
and still have to figure out a solution to
SubjectRegistrationLoginModule not working (GERONIMO-3407)
If we go with (2) I would like some of the changes to branches/
2.0 to be merged in, especially rev 563592. I think r563662 and
r563782 would be good also.
thanks
david jencks
On Aug 13, 2007, at 1:59 PM, Matt Hogstrom wrote:
All,
Earlier today one of the Geronimo committers discovered a bug in
the command line deployer where a null user / password on the
deployer command line will allow a user to deploy modules to a
2.0 server. This is an unacceptable security exposure and as
such we have abandoned the release of Geronimo 2.0.
Donald Woods is going to open a JIRA for this issue and Hernan
will create a news item on our web page.
At this point we need to discuss how to move forward with a 2.0
release.
I think we should delete the tags/2.0.0 entry and replace it with
a text file that notes the svn rev of the tree before deletion.
The purpose of this is to avoid anyone from picking up that
source tree and using it to build a server with a known security
exposure. Unless there is disagreement I'd like to do that
tomorrow allowing some time for discussion. We can always put it
back.
There are several options for the 2.0 release:
1. Use the branches/2.0 to spin up a new release as 2.0.1.
If we do this there are a number of fixes that need to be
verified, We'd need to close out the SNAPSHOT releases again, or
at least revisit them.
Respin and re-tck a new release.
2. Take the tags/2.0.0 to create a branches/2.0.1
This would mean that we need to update branches/2.0 to 2.0.2-
SNAPSHOT
Copy the existing tag over and apply the security fixes.
Repsin and release.
Personally, I vote for option 2. Based on my experience, closing
out the SNAPSHOTs is and introducing little changes will cause us
to restart the release process.
I'd like to hear other people's input but having done the release
several times option 2 is the fastest. I think option 1 will
cause us to not release until September.
Re: Geronimo 2.0 Release suspended due to security issue found before release
On 8/14/07, David Jencks <[EMAIL PROTECTED]> wrote: > > I think I've fixed GERONIMO-3404 and GERONIMO-3406 in trunk, rev > 565599. It might be a good idea for this to get a review before we > port it to branches/2.0 and possibly branches/2.0.x. We may also want to make sure GERONIMO-2266, GERONIMO-2267 and any similar ones do not recur. I haven't decided how to fix GERONIMO-3407 yet, and could be talked > out of it for 2.0.1. The problem would manifest itself as geronimo > not working if anyone tried to use a login module with REQUISITE or > (I think) SUFFICIENT flags. I don't think there's any security > exposure, it just that you effectively couldn't log in with such a > login configuration. > > On a completely unrelated issue I can't build modules/geronimo-axis- > builder in trunk as part of the main build, I get a complaint from > javac. I don't have problems building it by itself. Anyone else see > this? > > thanks > david jencks > On Aug 13, 2007, at 5:03 PM, David Jencks wrote: > > > So before we all jump onto option 2 maybe we should consider just > > how big a change this set of bugs is causing and comparatively how > > much branches/2.0 has changed since 2.0.0 was cut. > > > > It looks like there have been about 15 commits to branches/2.0 that > > aren't version changes, many of them simple fixes that make things > > like the plugin installer actually usable. On the other hand so > > far I've modified 16 files working on this security fix (admittedly > > most of them either simple fixes and/or documentation) and still > > have to figure out a solution to SubjectRegistrationLoginModule not > > working (GERONIMO-3407) > > > > If we go with (2) I would like some of the changes to branches/2.0 > > to be merged in, especially rev 563592. I think r563662 and > > r563782 would be good also. > > > > thanks > > david jencks > > > > On Aug 13, 2007, at 1:59 PM, Matt Hogstrom wrote: > > > >> All, > >> > >> Earlier today one of the Geronimo committers discovered a bug in > >> the command line deployer where a null user / password on the > >> deployer command line will allow a user to deploy modules to a 2.0 > >> server. This is an unacceptable security exposure and as such we > >> have abandoned the release of Geronimo 2.0. > >> > >> Donald Woods is going to open a JIRA for this issue and Hernan > >> will create a news item on our web page. > >> > >> At this point we need to discuss how to move forward with a 2.0 > >> release. > >> > >> I think we should delete the tags/2.0.0 entry and replace it with > >> a text file that notes the svn rev of the tree before deletion. > >> The purpose of this is to avoid anyone from picking up that source > >> tree and using it to build a server with a known security > >> exposure. Unless there is disagreement I'd like to do that > >> tomorrow allowing some time for discussion. We can always put it > >> back. > >> > >> There are several options for the 2.0 release: > >> > >> 1. Use the branches/2.0 to spin up a new release as 2.0.1. > >> If we do this there are a number of fixes that need to be > >> verified, We'd need to close out the SNAPSHOT releases again, or > >> at least revisit them. > >> Respin and re-tck a new release. > >> > >> 2. Take the tags/2.0.0 to create a branches/2.0.1 > >> This would mean that we need to update branches/2.0 to 2.0.2- > >> SNAPSHOT > >> Copy the existing tag over and apply the security fixes. Repsin > >> and release. > >> > >> Personally, I vote for option 2. Based on my experience, closing > >> out the SNAPSHOTs is and introducing little changes will cause us > >> to restart the release process. > >> > >> I'd like to hear other people's input but having done the release > >> several times option 2 is the fastest. I think option 1 will > >> cause us to not release until September. > > > >
Re: Geronimo 2.0 Release suspended due to security issue found before release
David, Though there are a few other minor fixes (that may not come in the way of TCK, for e.g. R565355) that I would have wanted in 2.0.1, I felt that this may not be the right time to bring up those as we may not "any" additional delays in getting 2.0.1 out, perhaps we may have to think about a 2.0.2 out of the current branches\2.0 and save these for then. As always, it is RMs call. Vamsi On 8/14/07, David Jencks <[EMAIL PROTECTED]> wrote: > > So before we all jump onto option 2 maybe we should consider just how > big a change this set of bugs is causing and comparatively how much > branches/2.0 has changed since 2.0.0 was cut. > > It looks like there have been about 15 commits to branches/2.0 that > aren't version changes, many of them simple fixes that make things > like the plugin installer actually usable. On the other hand so far > I've modified 16 files working on this security fix (admittedly most > of them either simple fixes and/or documentation) and still have to > figure out a solution to SubjectRegistrationLoginModule not working > (GERONIMO-3407) > > If we go with (2) I would like some of the changes to branches/2.0 > to be merged in, especially rev 563592. I think r563662 and r563782 > would be good also. > > thanks > david jencks > > On Aug 13, 2007, at 1:59 PM, Matt Hogstrom wrote: > > > All, > > > > Earlier today one of the Geronimo committers discovered a bug in > > the command line deployer where a null user / password on the > > deployer command line will allow a user to deploy modules to a 2.0 > > server. This is an unacceptable security exposure and as such we > > have abandoned the release of Geronimo 2.0. > > > > Donald Woods is going to open a JIRA for this issue and Hernan will > > create a news item on our web page. > > > > At this point we need to discuss how to move forward with a 2.0 > > release. > > > > I think we should delete the tags/2.0.0 entry and replace it with a > > text file that notes the svn rev of the tree before deletion. The > > purpose of this is to avoid anyone from picking up that source tree > > and using it to build a server with a known security exposure. > > Unless there is disagreement I'd like to do that tomorrow allowing > > some time for discussion. We can always put it back. > > > > There are several options for the 2.0 release: > > > > 1. Use the branches/2.0 to spin up a new release as 2.0.1. > > If we do this there are a number of fixes that need to be > > verified, We'd need to close out the SNAPSHOT releases again, or at > > least revisit them. > > Respin and re-tck a new release. > > > > 2. Take the tags/2.0.0 to create a branches/2.0.1 > > This would mean that we need to update branches/2.0 to 2.0.2- > > SNAPSHOT > > Copy the existing tag over and apply the security fixes. Repsin > > and release. > > > > Personally, I vote for option 2. Based on my experience, closing > > out the SNAPSHOTs is and introducing little changes will cause us > > to restart the release process. > > > > I'd like to hear other people's input but having done the release > > several times option 2 is the fastest. I think option 1 will cause > > us to not release until September. > >
Re: Geronimo 2.0 Release suspended due to security issue found before release
On Aug 13, 2007, at 9:27 PM, David Jencks wrote: I think I've fixed GERONIMO-3404 and GERONIMO-3406 in trunk, rev 565599. It might be a good idea for this to get a review before we port it to branches/2.0 and possibly branches/2.0.x. I'm looking things over now... May take me a bit... Easy to get this logic a bit twisted... I haven't decided how to fix GERONIMO-3407 yet, and could be talked out of it for 2.0.1. The problem would manifest itself as geronimo not working if anyone tried to use a login module with REQUISITE or (I think) SUFFICIENT flags. I don't think there's any security exposure, it just that you effectively couldn't log in with such a login configuration. Hmm. I was thinking the big issue was with the SUFFICIENT flag -- if a SUFFICIENT LoginModule succeeds, authentication does not proceed down the chain of LoginModules. Thus the SubjectLoginRegistrationModule might not be invoked. Likewise, if a REQUISITE LoginModule fails, the SubjectLoginRegistrationModule wouldn't be invoked. Since the login won't succeed, this doesn't seem like a big issue. Am I missing something? On a completely unrelated issue I can't build modules/geronimo-axis- builder in trunk as part of the main build, I get a complaint from javac. I don't have problems building it by itself. Anyone else see this? I'm not having a problem... --kevan
Re: Geronimo 2.0 Release suspended due to security issue found before release
I'll go ahead and update branches/2.0 to 2.0.2-SNAPSHOT as this needs to be done regardless. On Aug 13, 2007, at 8:03 PM, David Jencks wrote: So before we all jump onto option 2 maybe we should consider just how big a change this set of bugs is causing and comparatively how much branches/2.0 has changed since 2.0.0 was cut. It looks like there have been about 15 commits to branches/2.0 that aren't version changes, many of them simple fixes that make things like the plugin installer actually usable. On the other hand so far I've modified 16 files working on this security fix (admittedly most of them either simple fixes and/or documentation) and still have to figure out a solution to SubjectRegistrationLoginModule not working (GERONIMO-3407) If we go with (2) I would like some of the changes to branches/2.0 to be merged in, especially rev 563592. I think r563662 and r563782 would be good also. thanks david jencks On Aug 13, 2007, at 1:59 PM, Matt Hogstrom wrote: All, Earlier today one of the Geronimo committers discovered a bug in the command line deployer where a null user / password on the deployer command line will allow a user to deploy modules to a 2.0 server. This is an unacceptable security exposure and as such we have abandoned the release of Geronimo 2.0. Donald Woods is going to open a JIRA for this issue and Hernan will create a news item on our web page. At this point we need to discuss how to move forward with a 2.0 release. I think we should delete the tags/2.0.0 entry and replace it with a text file that notes the svn rev of the tree before deletion. The purpose of this is to avoid anyone from picking up that source tree and using it to build a server with a known security exposure. Unless there is disagreement I'd like to do that tomorrow allowing some time for discussion. We can always put it back. There are several options for the 2.0 release: 1. Use the branches/2.0 to spin up a new release as 2.0.1. If we do this there are a number of fixes that need to be verified, We'd need to close out the SNAPSHOT releases again, or at least revisit them. Respin and re-tck a new release. 2. Take the tags/2.0.0 to create a branches/2.0.1 This would mean that we need to update branches/2.0 to 2.0.2- SNAPSHOT Copy the existing tag over and apply the security fixes. Repsin and release. Personally, I vote for option 2. Based on my experience, closing out the SNAPSHOTs is and introducing little changes will cause us to restart the release process. I'd like to hear other people's input but having done the release several times option 2 is the fastest. I think option 1 will cause us to not release until September.
Re: Geronimo 2.0 Release suspended due to security issue found before release
+1 to option 2. Let's get 2.0.1 out of the door ASAP. Cheers Prasad On 8/13/07, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > All, > > Earlier today one of the Geronimo committers discovered a bug in the > command line deployer where a null user / password on the deployer > command line will allow a user to deploy modules to a 2.0 server. > This is an unacceptable security exposure and as such we have > abandoned the release of Geronimo 2.0. > > Donald Woods is going to open a JIRA for this issue and Hernan will > create a news item on our web page. > > At this point we need to discuss how to move forward with a 2.0 release. > > I think we should delete the tags/2.0.0 entry and replace it with a > text file that notes the svn rev of the tree before deletion. The > purpose of this is to avoid anyone from picking up that source tree > and using it to build a server with a known security exposure. > Unless there is disagreement I'd like to do that tomorrow allowing > some time for discussion. We can always put it back. > > There are several options for the 2.0 release: > > 1. Use the branches/2.0 to spin up a new release as 2.0.1. >If we do this there are a number of fixes that need to be > verified, We'd need to close out the SNAPSHOT releases again, or at > least revisit them. >Respin and re-tck a new release. > > 2. Take the tags/2.0.0 to create a branches/2.0.1 >This would mean that we need to update branches/2.0 to 2.0.2-SNAPSHOT >Copy the existing tag over and apply the security fixes. Repsin > and release. > > Personally, I vote for option 2. Based on my experience, closing out > the SNAPSHOTs is and introducing little changes will cause us to > restart the release process. > > I'd like to hear other people's input but having done the release > several times option 2 is the fastest. I think option 1 will cause > us to not release until September. >
Re: Geronimo 2.0 Release suspended due to security issue found before release
I think I've fixed GERONIMO-3404 and GERONIMO-3406 in trunk, rev 565599. It might be a good idea for this to get a review before we port it to branches/2.0 and possibly branches/2.0.x. I haven't decided how to fix GERONIMO-3407 yet, and could be talked out of it for 2.0.1. The problem would manifest itself as geronimo not working if anyone tried to use a login module with REQUISITE or (I think) SUFFICIENT flags. I don't think there's any security exposure, it just that you effectively couldn't log in with such a login configuration. On a completely unrelated issue I can't build modules/geronimo-axis- builder in trunk as part of the main build, I get a complaint from javac. I don't have problems building it by itself. Anyone else see this? thanks david jencks On Aug 13, 2007, at 5:03 PM, David Jencks wrote: So before we all jump onto option 2 maybe we should consider just how big a change this set of bugs is causing and comparatively how much branches/2.0 has changed since 2.0.0 was cut. It looks like there have been about 15 commits to branches/2.0 that aren't version changes, many of them simple fixes that make things like the plugin installer actually usable. On the other hand so far I've modified 16 files working on this security fix (admittedly most of them either simple fixes and/or documentation) and still have to figure out a solution to SubjectRegistrationLoginModule not working (GERONIMO-3407) If we go with (2) I would like some of the changes to branches/2.0 to be merged in, especially rev 563592. I think r563662 and r563782 would be good also. thanks david jencks On Aug 13, 2007, at 1:59 PM, Matt Hogstrom wrote: All, Earlier today one of the Geronimo committers discovered a bug in the command line deployer where a null user / password on the deployer command line will allow a user to deploy modules to a 2.0 server. This is an unacceptable security exposure and as such we have abandoned the release of Geronimo 2.0. Donald Woods is going to open a JIRA for this issue and Hernan will create a news item on our web page. At this point we need to discuss how to move forward with a 2.0 release. I think we should delete the tags/2.0.0 entry and replace it with a text file that notes the svn rev of the tree before deletion. The purpose of this is to avoid anyone from picking up that source tree and using it to build a server with a known security exposure. Unless there is disagreement I'd like to do that tomorrow allowing some time for discussion. We can always put it back. There are several options for the 2.0 release: 1. Use the branches/2.0 to spin up a new release as 2.0.1. If we do this there are a number of fixes that need to be verified, We'd need to close out the SNAPSHOT releases again, or at least revisit them. Respin and re-tck a new release. 2. Take the tags/2.0.0 to create a branches/2.0.1 This would mean that we need to update branches/2.0 to 2.0.2- SNAPSHOT Copy the existing tag over and apply the security fixes. Repsin and release. Personally, I vote for option 2. Based on my experience, closing out the SNAPSHOTs is and introducing little changes will cause us to restart the release process. I'd like to hear other people's input but having done the release several times option 2 is the fastest. I think option 1 will cause us to not release until September.
Re: Geronimo 2.0 Release suspended due to security issue found before release
Matt, We could at least release/publish the transaction and connector bits, right? Jarek On 8/13/07, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > All, > > Earlier today one of the Geronimo committers discovered a bug in the > command line deployer where a null user / password on the deployer > command line will allow a user to deploy modules to a 2.0 server. > This is an unacceptable security exposure and as such we have > abandoned the release of Geronimo 2.0. > > Donald Woods is going to open a JIRA for this issue and Hernan will > create a news item on our web page. > > At this point we need to discuss how to move forward with a 2.0 release. > > I think we should delete the tags/2.0.0 entry and replace it with a > text file that notes the svn rev of the tree before deletion. The > purpose of this is to avoid anyone from picking up that source tree > and using it to build a server with a known security exposure. > Unless there is disagreement I'd like to do that tomorrow allowing > some time for discussion. We can always put it back. > > There are several options for the 2.0 release: > > 1. Use the branches/2.0 to spin up a new release as 2.0.1. >If we do this there are a number of fixes that need to be > verified, We'd need to close out the SNAPSHOT releases again, or at > least revisit them. >Respin and re-tck a new release. > > 2. Take the tags/2.0.0 to create a branches/2.0.1 >This would mean that we need to update branches/2.0 to 2.0.2-SNAPSHOT >Copy the existing tag over and apply the security fixes. Repsin > and release. > > Personally, I vote for option 2. Based on my experience, closing out > the SNAPSHOTs is and introducing little changes will cause us to > restart the release process. > > I'd like to hear other people's input but having done the release > several times option 2 is the fastest. I think option 1 will cause > us to not release until September. >
Re: Geronimo 2.0 Release suspended due to security issue found before release
So before we all jump onto option 2 maybe we should consider just how big a change this set of bugs is causing and comparatively how much branches/2.0 has changed since 2.0.0 was cut. It looks like there have been about 15 commits to branches/2.0 that aren't version changes, many of them simple fixes that make things like the plugin installer actually usable. On the other hand so far I've modified 16 files working on this security fix (admittedly most of them either simple fixes and/or documentation) and still have to figure out a solution to SubjectRegistrationLoginModule not working (GERONIMO-3407) If we go with (2) I would like some of the changes to branches/2.0 to be merged in, especially rev 563592. I think r563662 and r563782 would be good also. thanks david jencks On Aug 13, 2007, at 1:59 PM, Matt Hogstrom wrote: All, Earlier today one of the Geronimo committers discovered a bug in the command line deployer where a null user / password on the deployer command line will allow a user to deploy modules to a 2.0 server. This is an unacceptable security exposure and as such we have abandoned the release of Geronimo 2.0. Donald Woods is going to open a JIRA for this issue and Hernan will create a news item on our web page. At this point we need to discuss how to move forward with a 2.0 release. I think we should delete the tags/2.0.0 entry and replace it with a text file that notes the svn rev of the tree before deletion. The purpose of this is to avoid anyone from picking up that source tree and using it to build a server with a known security exposure. Unless there is disagreement I'd like to do that tomorrow allowing some time for discussion. We can always put it back. There are several options for the 2.0 release: 1. Use the branches/2.0 to spin up a new release as 2.0.1. If we do this there are a number of fixes that need to be verified, We'd need to close out the SNAPSHOT releases again, or at least revisit them. Respin and re-tck a new release. 2. Take the tags/2.0.0 to create a branches/2.0.1 This would mean that we need to update branches/2.0 to 2.0.2- SNAPSHOT Copy the existing tag over and apply the security fixes. Repsin and release. Personally, I vote for option 2. Based on my experience, closing out the SNAPSHOTs is and introducing little changes will cause us to restart the release process. I'd like to hear other people's input but having done the release several times option 2 is the fastest. I think option 1 will cause us to not release until September.
Re: Geronimo 2.0 Release suspended due to security issue found before release
+1 to option #2 Cheers! Anita --- Matt Hogstrom <[EMAIL PROTECTED]> wrote: > All, > > Earlier today one of the Geronimo committers discovered a bug in the > > command line deployer where a null user / password on the deployer > command line will allow a user to deploy modules to a 2.0 server. > This is an unacceptable security exposure and as such we have > abandoned the release of Geronimo 2.0. > > Donald Woods is going to open a JIRA for this issue and Hernan will > create a news item on our web page. > > At this point we need to discuss how to move forward with a 2.0 > release. > > I think we should delete the tags/2.0.0 entry and replace it with a > text file that notes the svn rev of the tree before deletion. The > purpose of this is to avoid anyone from picking up that source tree > and using it to build a server with a known security exposure. > Unless there is disagreement I'd like to do that tomorrow allowing > some time for discussion. We can always put it back. > > There are several options for the 2.0 release: > > 1. Use the branches/2.0 to spin up a new release as 2.0.1. >If we do this there are a number of fixes that need to be > verified, We'd need to close out the SNAPSHOT releases again, or at > least revisit them. >Respin and re-tck a new release. > > 2. Take the tags/2.0.0 to create a branches/2.0.1 >This would mean that we need to update branches/2.0 to > 2.0.2-SNAPSHOT >Copy the existing tag over and apply the security fixes. Repsin > and release. > > Personally, I vote for option 2. Based on my experience, closing out > > the SNAPSHOTs is and introducing little changes will cause us to > restart the release process. > > I'd like to hear other people's input but having done the release > several times option 2 is the fastest. I think option 1 will cause > us to not release until September. > Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz
Re: Geronimo 2.0 Release suspended due to security issue found before release
On Aug 13, 2007, at 4:59 PM, Matt Hogstrom wrote: 2. Take the tags/2.0.0 to create a branches/2.0.1 This would mean that we need to update branches/2.0 to 2.0.2- SNAPSHOT Copy the existing tag over and apply the security fixes. Repsin and release. Personally, I vote for option 2. Based on my experience, closing out the SNAPSHOTs is and introducing little changes will cause us to restart the release process. Agreed. --kevan
Re: Geronimo 2.0 Release suspended due to security issue found before release
+1 to option 2 Joe Matt Hogstrom wrote: All, Earlier today one of the Geronimo committers discovered a bug in the command line deployer where a null user / password on the deployer command line will allow a user to deploy modules to a 2.0 server. This is an unacceptable security exposure and as such we have abandoned the release of Geronimo 2.0. Donald Woods is going to open a JIRA for this issue and Hernan will create a news item on our web page. At this point we need to discuss how to move forward with a 2.0 release. I think we should delete the tags/2.0.0 entry and replace it with a text file that notes the svn rev of the tree before deletion. The purpose of this is to avoid anyone from picking up that source tree and using it to build a server with a known security exposure. Unless there is disagreement I'd like to do that tomorrow allowing some time for discussion. We can always put it back. There are several options for the 2.0 release: 1. Use the branches/2.0 to spin up a new release as 2.0.1. If we do this there are a number of fixes that need to be verified, We'd need to close out the SNAPSHOT releases again, or at least revisit them. Respin and re-tck a new release. 2. Take the tags/2.0.0 to create a branches/2.0.1 This would mean that we need to update branches/2.0 to 2.0.2-SNAPSHOT Copy the existing tag over and apply the security fixes. Repsin and release. Personally, I vote for option 2. Based on my experience, closing out the SNAPSHOTs is and introducing little changes will cause us to restart the release process. I'd like to hear other people's input but having done the release several times option 2 is the fastest. I think option 1 will cause us to not release until September.
Re: Geronimo 2.0 Release suspended due to security issue found before release
Here is the link to the dev site home page with the latest update http://cwiki.apache.org/GMOxSITE/ within the next hour geronimo.apache.org should get updated. Cheers! Hernan Hernan Cunico wrote: +1 for option 2, it seems the quickest one. I just put the "News" out, it takes some time to get propagated. Cheers! Hernan Matt Hogstrom wrote: All, Earlier today one of the Geronimo committers discovered a bug in the command line deployer where a null user / password on the deployer command line will allow a user to deploy modules to a 2.0 server. This is an unacceptable security exposure and as such we have abandoned the release of Geronimo 2.0. Donald Woods is going to open a JIRA for this issue and Hernan will create a news item on our web page. At this point we need to discuss how to move forward with a 2.0 release. I think we should delete the tags/2.0.0 entry and replace it with a text file that notes the svn rev of the tree before deletion. The purpose of this is to avoid anyone from picking up that source tree and using it to build a server with a known security exposure. Unless there is disagreement I'd like to do that tomorrow allowing some time for discussion. We can always put it back. There are several options for the 2.0 release: 1. Use the branches/2.0 to spin up a new release as 2.0.1. If we do this there are a number of fixes that need to be verified, We'd need to close out the SNAPSHOT releases again, or at least revisit them. Respin and re-tck a new release. 2. Take the tags/2.0.0 to create a branches/2.0.1 This would mean that we need to update branches/2.0 to 2.0.2-SNAPSHOT Copy the existing tag over and apply the security fixes. Repsin and release. Personally, I vote for option 2. Based on my experience, closing out the SNAPSHOTs is and introducing little changes will cause us to restart the release process. I'd like to hear other people's input but having done the release several times option 2 is the fastest. I think option 1 will cause us to not release until September.
Re: Geronimo 2.0 Release suspended due to security issue found before release
+1 for option 2, it seems the quickest one. I just put the "News" out, it takes some time to get propagated. Cheers! Hernan Matt Hogstrom wrote: All, Earlier today one of the Geronimo committers discovered a bug in the command line deployer where a null user / password on the deployer command line will allow a user to deploy modules to a 2.0 server. This is an unacceptable security exposure and as such we have abandoned the release of Geronimo 2.0. Donald Woods is going to open a JIRA for this issue and Hernan will create a news item on our web page. At this point we need to discuss how to move forward with a 2.0 release. I think we should delete the tags/2.0.0 entry and replace it with a text file that notes the svn rev of the tree before deletion. The purpose of this is to avoid anyone from picking up that source tree and using it to build a server with a known security exposure. Unless there is disagreement I'd like to do that tomorrow allowing some time for discussion. We can always put it back. There are several options for the 2.0 release: 1. Use the branches/2.0 to spin up a new release as 2.0.1. If we do this there are a number of fixes that need to be verified, We'd need to close out the SNAPSHOT releases again, or at least revisit them. Respin and re-tck a new release. 2. Take the tags/2.0.0 to create a branches/2.0.1 This would mean that we need to update branches/2.0 to 2.0.2-SNAPSHOT Copy the existing tag over and apply the security fixes. Repsin and release. Personally, I vote for option 2. Based on my experience, closing out the SNAPSHOTs is and introducing little changes will cause us to restart the release process. I'd like to hear other people's input but having done the release several times option 2 is the fastest. I think option 1 will cause us to not release until September.
Re: Geronimo 2.0 Release suspended due to security issue found before release
On Aug 13, 2007, at 4:59 PM, Matt Hogstrom wrote: 2. Take the tags/2.0.0 to create a branches/2.0.1 This would mean that we need to update branches/2.0 to 2.0.2- SNAPSHOT Copy the existing tag over and apply the security fixes. Repsin and release. +1 for option 2 Best wishes, Paul
Re: Geronimo 2.0 Release suspended due to security issue found before release
Matt Hogstrom wrote: All, Earlier today one of the Geronimo committers discovered a bug in the command line deployer where a null user / password on the deployer command line will allow a user to deploy modules to a 2.0 server. This is an unacceptable security exposure and as such we have abandoned the release of Geronimo 2.0. Donald Woods is going to open a JIRA for this issue and Hernan will create a news item on our web page. GERONIMO-3404 was opened for this. At this point we need to discuss how to move forward with a 2.0 release. I think we should delete the tags/2.0.0 entry and replace it with a text file that notes the svn rev of the tree before deletion. The purpose of this is to avoid anyone from picking up that source tree and using it to build a server with a known security exposure. Unless there is disagreement I'd like to do that tomorrow allowing some time for discussion. We can always put it back. There are several options for the 2.0 release: 1. Use the branches/2.0 to spin up a new release as 2.0.1. If we do this there are a number of fixes that need to be verified, We'd need to close out the SNAPSHOT releases again, or at least revisit them. Respin and re-tck a new release. 2. Take the tags/2.0.0 to create a branches/2.0.1 This would mean that we need to update branches/2.0 to 2.0.2-SNAPSHOT Copy the existing tag over and apply the security fixes. Repsin and release. Personally, I vote for option 2. Based on my experience, closing out the SNAPSHOTs is and introducing little changes will cause us to restart the release process. +1 on option #2. I'd like to hear other people's input but having done the release several times option 2 is the fastest. I think option 1 will cause us to not release until September. smime.p7s Description: S/MIME Cryptographic Signature
Re: Geronimo 2.0 Release suspended due to security issue found before release
+1 for option 2
Re: Geronimo 2.0 Release suspended due to security issue found before release
+1 for option 2. Jarek On 8/13/07, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > All, > > Earlier today one of the Geronimo committers discovered a bug in the > command line deployer where a null user / password on the deployer > command line will allow a user to deploy modules to a 2.0 server. > This is an unacceptable security exposure and as such we have > abandoned the release of Geronimo 2.0. > > Donald Woods is going to open a JIRA for this issue and Hernan will > create a news item on our web page. > > At this point we need to discuss how to move forward with a 2.0 release. > > I think we should delete the tags/2.0.0 entry and replace it with a > text file that notes the svn rev of the tree before deletion. The > purpose of this is to avoid anyone from picking up that source tree > and using it to build a server with a known security exposure. > Unless there is disagreement I'd like to do that tomorrow allowing > some time for discussion. We can always put it back. > > There are several options for the 2.0 release: > > 1. Use the branches/2.0 to spin up a new release as 2.0.1. >If we do this there are a number of fixes that need to be > verified, We'd need to close out the SNAPSHOT releases again, or at > least revisit them. >Respin and re-tck a new release. > > 2. Take the tags/2.0.0 to create a branches/2.0.1 >This would mean that we need to update branches/2.0 to 2.0.2-SNAPSHOT >Copy the existing tag over and apply the security fixes. Repsin > and release. > > Personally, I vote for option 2. Based on my experience, closing out > the SNAPSHOTs is and introducing little changes will cause us to > restart the release process. > > I'd like to hear other people's input but having done the release > several times option 2 is the fastest. I think option 1 will cause > us to not release until September. >
Re: Geronimo 2.0 Release suspended due to security issue found before release
At this point, we will want to get a release out fast and address only those issues (like the security bug Donald has found and hopefully only this) that are blocker. +1 to option 2, create branches\2.0.1 from tags\2.0.0. Vamsi On 8/14/07, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > > All, > > Earlier today one of the Geronimo committers discovered a bug in the > command line deployer where a null user / password on the deployer > command line will allow a user to deploy modules to a 2.0 server. > This is an unacceptable security exposure and as such we have > abandoned the release of Geronimo 2.0. > > Donald Woods is going to open a JIRA for this issue and Hernan will > create a news item on our web page. > > At this point we need to discuss how to move forward with a 2.0 release. > > I think we should delete the tags/2.0.0 entry and replace it with a > text file that notes the svn rev of the tree before deletion. The > purpose of this is to avoid anyone from picking up that source tree > and using it to build a server with a known security exposure. > Unless there is disagreement I'd like to do that tomorrow allowing > some time for discussion. We can always put it back. > > There are several options for the 2.0 release: > > 1. Use the branches/2.0 to spin up a new release as 2.0.1. >If we do this there are a number of fixes that need to be > verified, We'd need to close out the SNAPSHOT releases again, or at > least revisit them. >Respin and re-tck a new release. > > 2. Take the tags/2.0.0 to create a branches/2.0.1 >This would mean that we need to update branches/2.0 to 2.0.2-SNAPSHOT >Copy the existing tag over and apply the security fixes. Repsin > and release. > > Personally, I vote for option 2. Based on my experience, closing out > the SNAPSHOTs is and introducing little changes will cause us to > restart the release process. > > I'd like to hear other people's input but having done the release > several times option 2 is the fastest. I think option 1 will cause > us to not release until September. >
Re: Geronimo 2.0 License and Notice Files
On Jul 11, 2007, at 10:08 PM, Matt Hogstrom wrote: On Jul 11, 2007, at 12:24 PM, Kevan Miller wrote: If some people could review, that would be great. on the Active-IO question there is some coding work to be done. http://issues.apache.org/jira/browse/GERONIMO-2944 Ya. I've started looking into this... All of the OpenEJB mods should be AL 2.0 but it sounds like there is some work to do in OEJB. I'll ping the list. Yes. Would certainly be fixed before OpenEJB could be released. I'm planning on fixing when I have a few minutes... Next steps and pseudo-random license trivia: Many jar archives included by Geronimo do not include LICENSE or NOTICE files. In most cases, I've tracked down the appropriate LICENSE information for the resource, and included a url for the LICENSE file. I haven't always done this. So, some work still remains. Most/all of this remaining work involves Apache projects. So, I don't invision a big problem. In some of the cases, the work is not chasing down the license information, but insuring that appropriate LICENSE/NOTICE files are generated in the original jar archive (e.g. OpenEJB). For the rather long list of jars that don't have any embedded files is there a recommendation ? Unlikely we'll get them fixed. We don't need to insure that all jar files contain license/notice information. That's not our job -- it's the responsibility of the individual projects. One exception might be any jar files which we are generating (e.g. Tomcat). Apache's current policy is that all released artifacts need to include LICENSE/NOTICE files. Jar files used to be bundled in a binary distribution. The binary distribution would contain any LICENSE/NOTICE files, but lots of times the jar files did not. Now-a- days, jar files should be treated as separately "released" artifacts -- they're placed individually in maven repos, etc. So, most projects put LICENSE/NOTICE information into jar files, also. Since we embed so many projects, I must say that this practice is great. To gather license/notice information, we just need to crack open the jars and aggregate the license/notice information. For jars that don't self-document their license, we need to obtain the license/ notice information for the jars we're using. I think that I've done this for all non-apache jar files. We need to do the same research for the apache jars. I'll take this opportunity to point out what I think is good practice -- jar files should contain license/notice information specific to the jar file (i.e. they should not re-use the project-wide license/ notice files). Worst case is those projects (myfaces is an example) who have something like the following in their NOTICE file: See the file LICENSE.txt See licenses for accompanying products in the "/licenses" subdirectory. where there is no "/licenses" subdirectory in the jar. So, we're still forced to download source or the entire binary to obtain the necessary information... We currently include all of our LICENSE information in a single root LICENSE.txt file. Some Apache projects include a licenses/ directory, instead. This directory includes all of the non-ASL licenses for the project. Although it's probably a bit more work, I personally prefer a single file. However, this is a debatable point. If others have an opinion, they are welcome to voice it. One file would be my preference. The root LICENSE.txt and NOTICE.txt files (by "root" I mean the license/notice file in the bottom level directory of our source and binary distributions) contain the license info for the entire assembly. We don't currently have different license/notice files that are specific to our Jetty/Tomcat CXF/Axis distributions. Nor do we attempt to generate license/notice files specific to our minimal assemblies. So current course and speed, our root license/notice files will be a superset of all of our various assemblies. This seems fine, to me. If anyone sees a problem with this, speak now... Perhaps a comment that this assembly includes some or all of That sounds like a good approach... --kevan Once all of the data in the google spreadsheet is complete, and we've had a chance to review. I'll plan on generating new LICENSE.txt, NOTICE.txt, and DISCLAIMER.txt files for our 2.0 release. I'd guess this will be towards the end of the week/over the weekend. If anyone else is interested in grabbing a shovel and pitching in, let me know... --kevan
Re: Geronimo 2.0 License and Notice Files
On Jul 11, 2007, at 12:24 PM, Kevan Miller wrote: If some people could review, that would be great. on the Active-IO question there is some coding work to be done. http://issues.apache.org/jira/browse/GERONIMO-2944 All of the OpenEJB mods should be AL 2.0 but it sounds like there is some work to do in OEJB. I'll ping the list. Next steps and pseudo-random license trivia: Many jar archives included by Geronimo do not include LICENSE or NOTICE files. In most cases, I've tracked down the appropriate LICENSE information for the resource, and included a url for the LICENSE file. I haven't always done this. So, some work still remains. Most/all of this remaining work involves Apache projects. So, I don't invision a big problem. In some of the cases, the work is not chasing down the license information, but insuring that appropriate LICENSE/NOTICE files are generated in the original jar archive (e.g. OpenEJB). For the rather long list of jars that don't have any embedded files is there a recommendation ? Unlikely we'll get them fixed. We currently include all of our LICENSE information in a single root LICENSE.txt file. Some Apache projects include a licenses/ directory, instead. This directory includes all of the non-ASL licenses for the project. Although it's probably a bit more work, I personally prefer a single file. However, this is a debatable point. If others have an opinion, they are welcome to voice it. One file would be my preference. The root LICENSE.txt and NOTICE.txt files (by "root" I mean the license/notice file in the bottom level directory of our source and binary distributions) contain the license info for the entire assembly. We don't currently have different license/notice files that are specific to our Jetty/Tomcat CXF/Axis distributions. Nor do we attempt to generate license/notice files specific to our minimal assemblies. So current course and speed, our root license/notice files will be a superset of all of our various assemblies. This seems fine, to me. If anyone sees a problem with this, speak now... Perhaps a comment that this assembly includes some or all of Once all of the data in the google spreadsheet is complete, and we've had a chance to review. I'll plan on generating new LICENSE.txt, NOTICE.txt, and DISCLAIMER.txt files for our 2.0 release. I'd guess this will be towards the end of the week/over the weekend. If anyone else is interested in grabbing a shovel and pitching in, let me know... --kevan
Re: Geronimo 2.0-M6-rc1 Binaries Up for Review
On Jun 4, 2007, at 7:50 PM, Matt Hogstrom wrote: All, I created a 2.0-M6-rc1 binary set for you to take a look at. This Milestone has passed all CTS tests and is the driver we are looking to make available officially this week. It would be great if everyone can take a look at these and provide some feedback. Remember, this is a milestone which is an increment to having multiple certified server instances but with this Milestone we do have a 100% passing Assembly. A hearty congrats to the entire team as we've accomplished a ton of work in a few very short months. Every committer and contributor has in their own way helped to get to this point. Job well done. We'll be filing paper work for certification in a few days. CTS Complete. What a nice phrase... Great work all! --kevan
Re: Geronimo 2.0-M6-rc1 Binaries Up for Review
Well, the release notes are for the milestone we release. RC1 is just the first candidate, once we vote for that candidate then it will become the official M6 release. Am I correct? Cheers! Hernan Prasad Kashyap wrote: Hernan, Shouldn't it be v2.0-M6-rc1 ? Cheers Prasad On 6/5/07, Hernan Cunico <[EMAIL PROTECTED]> wrote: Fantastic!!! I'll update the release notes to reflect this. Would these lines be OK? Certification Status Apache Geronimo v2.0-M6 (Tomcat assembly with CXF for WebServices and OpenJPA for persistence) have passed SUN's Java Enterprise Edition 5.0 Certification Test Suite. We continue to strive towards certification on the other assemblies. Cheers! Hernan Matt Hogstrom wrote: > All, > > I created a 2.0-M6-rc1 binary set for you to take a look at. This > Milestone has passed all CTS tests and is the driver we are looking to > make available officially this week. It would be great if everyone can > take a look at these and provide some feedback. Remember, this is a > milestone which is an increment to having multiple certified server > instances but with this Milestone we do have a 100% passing Assembly. > > A hearty congrats to the entire team as we've accomplished a ton of work > in a few very short months. Every committer and contributor has in > their own way helped to get to this point. Job well done. We'll be > filing paper work for certification in a few days. > > I'll be posting an official vote shortly once I've gotten some > administrative stuff done. > > Cheers, > > Matt >
Re: Geronimo 2.0-M6-rc1 Binaries Up for Review
Hernan, Shouldn't it be v2.0-M6-rc1 ? Cheers Prasad On 6/5/07, Hernan Cunico <[EMAIL PROTECTED]> wrote: Fantastic!!! I'll update the release notes to reflect this. Would these lines be OK? Certification Status Apache Geronimo v2.0-M6 (Tomcat assembly with CXF for WebServices and OpenJPA for persistence) have passed SUN's Java Enterprise Edition 5.0 Certification Test Suite. We continue to strive towards certification on the other assemblies. Cheers! Hernan Matt Hogstrom wrote: > All, > > I created a 2.0-M6-rc1 binary set for you to take a look at. This > Milestone has passed all CTS tests and is the driver we are looking to > make available officially this week. It would be great if everyone can > take a look at these and provide some feedback. Remember, this is a > milestone which is an increment to having multiple certified server > instances but with this Milestone we do have a 100% passing Assembly. > > A hearty congrats to the entire team as we've accomplished a ton of work > in a few very short months. Every committer and contributor has in > their own way helped to get to this point. Job well done. We'll be > filing paper work for certification in a few days. > > I'll be posting an official vote shortly once I've gotten some > administrative stuff done. > > Cheers, > > Matt >
Re: Geronimo 2.0-M6-rc1 Binaries Up for Review
Fantastic!!! I'll update the release notes to reflect this. Would these lines be OK? Certification Status Apache Geronimo v2.0-M6 (Tomcat assembly with CXF for WebServices and OpenJPA for persistence) have passed SUN's Java Enterprise Edition 5.0 Certification Test Suite. We continue to strive towards certification on the other assemblies. Cheers! Hernan Matt Hogstrom wrote: All, I created a 2.0-M6-rc1 binary set for you to take a look at. This Milestone has passed all CTS tests and is the driver we are looking to make available officially this week. It would be great if everyone can take a look at these and provide some feedback. Remember, this is a milestone which is an increment to having multiple certified server instances but with this Milestone we do have a 100% passing Assembly. A hearty congrats to the entire team as we've accomplished a ton of work in a few very short months. Every committer and contributor has in their own way helped to get to this point. Job well done. We'll be filing paper work for certification in a few days. I'll be posting an official vote shortly once I've gotten some administrative stuff done. Cheers, Matt
Re: Geronimo 2.0-M6-rc1 Binaries Up for Review
Donald Woods wrote: > Congrats to everyone who has been heads down on the TCK. > > BTW - Which assembly is at 100%? Is it the Tomcat+CXF+OpenJPA? Yes. Jeff > > > -Donald > > Matt Hogstrom wrote: >> All, >> >> I created a 2.0-M6-rc1 binary set for you to take a look at. This >> Milestone has passed all CTS tests and is the driver we are looking to >> make available officially this week. It would be great if everyone >> can take a look at these and provide some feedback. Remember, this is >> a milestone which is an increment to having multiple certified server >> instances but with this Milestone we do have a 100% passing Assembly. >> >> A hearty congrats to the entire team as we've accomplished a ton of >> work in a few very short months. Every committer and contributor has >> in their own way helped to get to this point. Job well done. We'll >> be filing paper work for certification in a few days. >> >> I'll be posting an official vote shortly once I've gotten some >> administrative stuff done. >> >> Cheers, >> >> Matt >> >>
Re: Geronimo 2.0-M6-rc1 Binaries Up for Review
Congrats to everyone who has been heads down on the TCK. BTW - Which assembly is at 100%? Is it the Tomcat+CXF+OpenJPA? -Donald Matt Hogstrom wrote: All, I created a 2.0-M6-rc1 binary set for you to take a look at. This Milestone has passed all CTS tests and is the driver we are looking to make available officially this week. It would be great if everyone can take a look at these and provide some feedback. Remember, this is a milestone which is an increment to having multiple certified server instances but with this Milestone we do have a 100% passing Assembly. A hearty congrats to the entire team as we've accomplished a ton of work in a few very short months. Every committer and contributor has in their own way helped to get to this point. Job well done. We'll be filing paper work for certification in a few days. I'll be posting an official vote shortly once I've gotten some administrative stuff done. Cheers, Matt smime.p7s Description: S/MIME Cryptographic Signature
Re: Geronimo 2.0 web services support table
Cool - Question, what is meant by " Could use J2SE or J2ME" under the Client section? AFAIK, the JAX-WS client apis won't ever work on J2ME... Cheers, - Dan On 2/20/07, Lin Sun <[EMAIL PROTECTED]> wrote: Hi there, I have created a table for Geronimo web services support. The page is a child page of the Geronimo Java EE 5.0 report card page, but here is a direct link anyway - http://cwiki.apache.org/GMOxPMGT/geronimo-20-web-services-support.html. Tried to break them down to JAX-WS 2.0, JAX-RPC 1.1, EJB and Client and some of them may just mean test items or stuff we won't implement. I invite you (Jarek, Dims, Lasantha, and others) to edit the page and fill in the missing contents. Thanks, Lin -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
Re: Geronimo 2.0 web services support table
In case you haven't taken a look at the page below, Jarek has updated the page with the CXF portion. In the next few days, I'll be working on updating the table for Axis2 - POJO portion to be accurate. But others are invited to update the page as well. Lin Davanum Srinivas wrote: Excellent! Jarek, Please cross-check when you have a chance. -- dims On 2/21/07, Hernan Cunico <[EMAIL PROTECTED]> wrote: Nice work Lin ! :) Cheers! Hernan Lin Sun wrote: > Hi there, > > I have created a table for Geronimo web services support. The page is > a child page of the Geronimo Java EE 5.0 report card page, but here is a > direct link anyway - > http://cwiki.apache.org/GMOxPMGT/geronimo-20-web-services-support.html. > Tried to break them down to JAX-WS 2.0, JAX-RPC 1.1, EJB and Client and > some of them may just mean test items or stuff we won't implement. I > invite you (Jarek, Dims, Lasantha, and others) to edit the page and fill > in the missing contents. > > Thanks, Lin >
Re: Geronimo 2.0 web services support table
Excellent! Jarek, Please cross-check when you have a chance. -- dims On 2/21/07, Hernan Cunico <[EMAIL PROTECTED]> wrote: Nice work Lin ! :) Cheers! Hernan Lin Sun wrote: > Hi there, > > I have created a table for Geronimo web services support. The page is > a child page of the Geronimo Java EE 5.0 report card page, but here is a > direct link anyway - > http://cwiki.apache.org/GMOxPMGT/geronimo-20-web-services-support.html. > Tried to break them down to JAX-WS 2.0, JAX-RPC 1.1, EJB and Client and > some of them may just mean test items or stuff we won't implement. I > invite you (Jarek, Dims, Lasantha, and others) to edit the page and fill > in the missing contents. > > Thanks, Lin > -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
Re: Geronimo 2.0 web services support table
Nice work Lin ! :) Cheers! Hernan Lin Sun wrote: Hi there, I have created a table for Geronimo web services support. The page is a child page of the Geronimo Java EE 5.0 report card page, but here is a direct link anyway - http://cwiki.apache.org/GMOxPMGT/geronimo-20-web-services-support.html. Tried to break them down to JAX-WS 2.0, JAX-RPC 1.1, EJB and Client and some of them may just mean test items or stuff we won't implement. I invite you (Jarek, Dims, Lasantha, and others) to edit the page and fill in the missing contents. Thanks, Lin
Re: Geronimo 2.0 Milestone's and how were doing
Paul, Nice work.. I just tried geronimo-tomcat-jee5 server. The shutdown exception is same as the one from jetty assembly. Thanks Anita --- Paul McMahan <[EMAIL PROTECTED]> wrote: > On 12/5/06, Paul McMahan <[EMAIL PROTECTED]> wrote: > > On 12/5/06, Kevan Miller <[EMAIL PROTECTED]> wrote: > > > > > > Paul, Tomcat integration might have the most work to do for M1. > How > > > is that looking? > > > > I have the JSP 2.1 and EL 1.0 specs checked in and published to the > > snapshot repo, reversioned to 1.0-SNAPSHOT this morning per Jason's > > advice. The annotation 1.0 and servlet 2.5 specs were already > > available thanks to Joe and Greg. In my local build I have tc6 > > running the web console OK in a new tomcat-jee5 assembly and the > > default app in the tomcat-minimal assembly. Deploying a simple 2.4 > > WAR from the CLI works. I'm pretty confident that I'll be able to > > commit this first stage of tomcat integration this week. > > I just committed stage 2 of the tc6 update. As a reminder here's the > wiki page for the overall game plan with progress indicated: > http://cwiki.apache.org/GMOxDEV/tomcat-v6-game-plan.html > > If anyone sees problems then please let me know. > > > Current issues: > > > > Deploying 2.5 servlets > > While tc6 deploys and runs 2.4 WARs ok I haven't tried deploying a > 2.5 > > WAR yet. All the webapps in the tc6 dist use 2.4 so I really hope > > I'm not the first one trying this :-S I googled up some JEE5 > servlet > > samples but they are tightly coupled with other new JEE5 stuff like > > JPA, EJB 3.0, etc, so I need something simpler. I'll probably end > up > > adding some 2.5 content to our unit test cases and cross my > fingers. > > Worst case scenario is that for M1 we'll have a 2.5 servlet engine > > that you can only deploy <=2.4. servlets to. > > Turns out this works OK. I added a testcase to geronimo-tomcat that > uses a 2.5 web.xml. > > > Failing unit test- > > A unit tests in geronimo-tomcat fails intermittently apparently due > to > > a change in how tc6 handles connections. Still investigating if > its a > > bug in geronimo, tomcat or the unit test. For the initial checkin > I > > may need to disable the unit test. > > I disabled the unit test and am investigating whether the problem is > in geronimo, the test case, or in tomcat. > > > Noise factor- > > Shutdown of the JEE5 assemblies generates a huge stack trace. > Looks > > like tranql/derby is the culpirt and not tomcat but I'm not 100% > sure. > > I'll probably have to commit while the stack trace still appears > so > > others can have a look. > > Others were seeing this stack trace before I committed and it's in > the > jetty assembly as well so apparently not due to tc6. > > > Also I need to figure out how to avoid > > logging tomcat's INFO messages to the command window. Its really > > noisy right now. > > Tomcat is still logging INFO messages in the command window and I > will > fix that asap. I needed to go ahead and check in as-is so others > with > prereqs on tc6 can proceed with their work (plus I was going nuts > keeping up with in trunk :-) > > Best wishes, > Paul > Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index
Re: Geronimo 2.0 Milestone's and how were doing
Hey Paul,
I just gave it a quick look. Things went pretty smoothly. Build fine,
ran fine, and the console seemed to work fine. As you already
mentioned there are a lot of info messages and the stacktraces on
terminating the server but these are not unique to tomcat at the moment.
The one new thing I noticed was that when I deployed a simple web
application (snoop without a plan) via the web console things looked
like they went well but I couldn't connect to the application. The URL
for the web app looked strange ("//snoop" rather than just "/snoop").
Regards,
Joe
Paul McMahan wrote:
On 12/5/06, Paul McMahan <[EMAIL PROTECTED]> wrote:
On 12/5/06, Kevan Miller <[EMAIL PROTECTED]> wrote:
>
> Paul, Tomcat integration might have the most work to do for M1. How
> is that looking?
I have the JSP 2.1 and EL 1.0 specs checked in and published to the
snapshot repo, reversioned to 1.0-SNAPSHOT this morning per Jason's
advice. The annotation 1.0 and servlet 2.5 specs were already
available thanks to Joe and Greg. In my local build I have tc6
running the web console OK in a new tomcat-jee5 assembly and the
default app in the tomcat-minimal assembly. Deploying a simple 2.4
WAR from the CLI works. I'm pretty confident that I'll be able to
commit this first stage of tomcat integration this week.
I just committed stage 2 of the tc6 update. As a reminder here's the
wiki page for the overall game plan with progress indicated:
http://cwiki.apache.org/GMOxDEV/tomcat-v6-game-plan.html
If anyone sees problems then please let me know.
Current issues:
Deploying 2.5 servlets
While tc6 deploys and runs 2.4 WARs ok I haven't tried deploying a 2.5
WAR yet. All the webapps in the tc6 dist use 2.4 so I really hope
I'm not the first one trying this :-S I googled up some JEE5 servlet
samples but they are tightly coupled with other new JEE5 stuff like
JPA, EJB 3.0, etc, so I need something simpler. I'll probably end up
adding some 2.5 content to our unit test cases and cross my fingers.
Worst case scenario is that for M1 we'll have a 2.5 servlet engine
that you can only deploy <=2.4. servlets to.
Turns out this works OK. I added a testcase to geronimo-tomcat that
uses a 2.5 web.xml.
Failing unit test-
A unit tests in geronimo-tomcat fails intermittently apparently due to
a change in how tc6 handles connections. Still investigating if its a
bug in geronimo, tomcat or the unit test. For the initial checkin I
may need to disable the unit test.
I disabled the unit test and am investigating whether the problem is
in geronimo, the test case, or in tomcat.
Noise factor-
Shutdown of the JEE5 assemblies generates a huge stack trace. Looks
like tranql/derby is the culpirt and not tomcat but I'm not 100% sure.
I'll probably have to commit while the stack trace still appears so
others can have a look.
Others were seeing this stack trace before I committed and it's in the
jetty assembly as well so apparently not due to tc6.
Also I need to figure out how to avoid
logging tomcat's INFO messages to the command window. Its really
noisy right now.
Tomcat is still logging INFO messages in the command window and I will
fix that asap. I needed to go ahead and check in as-is so others with
prereqs on tc6 can proceed with their work (plus I was going nuts
keeping up with in trunk :-)
Best wishes,
Paul
Re: Geronimo 2.0 Milestone's and how were doing
On 12/5/06, Paul McMahan <[EMAIL PROTECTED]> wrote: On 12/5/06, Kevan Miller <[EMAIL PROTECTED]> wrote: > > Paul, Tomcat integration might have the most work to do for M1. How > is that looking? I have the JSP 2.1 and EL 1.0 specs checked in and published to the snapshot repo, reversioned to 1.0-SNAPSHOT this morning per Jason's advice. The annotation 1.0 and servlet 2.5 specs were already available thanks to Joe and Greg. In my local build I have tc6 running the web console OK in a new tomcat-jee5 assembly and the default app in the tomcat-minimal assembly. Deploying a simple 2.4 WAR from the CLI works. I'm pretty confident that I'll be able to commit this first stage of tomcat integration this week. I just committed stage 2 of the tc6 update. As a reminder here's the wiki page for the overall game plan with progress indicated: http://cwiki.apache.org/GMOxDEV/tomcat-v6-game-plan.html If anyone sees problems then please let me know. Current issues: Deploying 2.5 servlets While tc6 deploys and runs 2.4 WARs ok I haven't tried deploying a 2.5 WAR yet. All the webapps in the tc6 dist use 2.4 so I really hope I'm not the first one trying this :-S I googled up some JEE5 servlet samples but they are tightly coupled with other new JEE5 stuff like JPA, EJB 3.0, etc, so I need something simpler. I'll probably end up adding some 2.5 content to our unit test cases and cross my fingers. Worst case scenario is that for M1 we'll have a 2.5 servlet engine that you can only deploy <=2.4. servlets to. Turns out this works OK. I added a testcase to geronimo-tomcat that uses a 2.5 web.xml. Failing unit test- A unit tests in geronimo-tomcat fails intermittently apparently due to a change in how tc6 handles connections. Still investigating if its a bug in geronimo, tomcat or the unit test. For the initial checkin I may need to disable the unit test. I disabled the unit test and am investigating whether the problem is in geronimo, the test case, or in tomcat. Noise factor- Shutdown of the JEE5 assemblies generates a huge stack trace. Looks like tranql/derby is the culpirt and not tomcat but I'm not 100% sure. I'll probably have to commit while the stack trace still appears so others can have a look. Others were seeing this stack trace before I committed and it's in the jetty assembly as well so apparently not due to tc6. Also I need to figure out how to avoid logging tomcat's INFO messages to the command window. Its really noisy right now. Tomcat is still logging INFO messages in the command window and I will fix that asap. I needed to go ahead and check in as-is so others with prereqs on tc6 can proceed with their work (plus I was going nuts keeping up with in trunk :-) Best wishes, Paul
Re: Geronimo 2.0 Milestone's and how were doing
+1. Oh yeah, I agree. Let's give it a shot with all the best that we have. Cheers Prasad On 12/5/06, Paul McMahan <[EMAIL PROTECTED]> wrote: Matt, JEE5 is critical to the widespread adoption of Geronimo. We can and should accomplish these milestones. Best wishes, Paul On 12/4/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > While ripping out drywall this weekend I was thinking about our > Geronimo 2.0 and all the work that needs to get done to complete this > monsterous effort. While sifting through the scorecard and thinking > about all the different things that need to be addressed it became a > bit overwhelming. As everyone knows many different projects are > working on their implementations of Java EE 5.0. Some are available > and others are works in progress (as is ours). It seems that from > user perspective people are really interested in the Java EE and have > been asking for several months about where we are. At this point it > would be nice to give them an idea of what we're thinking about. > > I had previously put out a set of milestones and dates. I wanted to > make it a little more formal and of course with all the caveats that > this is open source and our timetables are subject to people's time > and contribution. > > With that, here is an updated timeline and some graphic > representations that represent the Java EE specifications that need > to be completed from a high level. > > I think it was Dain that used the term table stakes when referring to > the specification. Meaning that we need the spec related > functionality to get in the game but innovations beyond the > specification were necessary to make a bigger splash. I don't > capture those here but I'll work on pulling that together as well. > > Take a look at http://people.apache.org/~hogstrom/Geronimo2.0/ and > provide your thoughts on how were doing. > > If we are going to make a Dec 22 Beta 1 then we would have to cut > sometime in the next week and a half. > > What do y'all think? > > Matt Hogstrom > [EMAIL PROTECTED] > > >
Re: Geronimo 2.0 Milestone's and how were doing
This sounds reasonable and achievable to me. A milestone JEE 5 driver would be a great way to close out the year and get some momentum built up for next. I started to work on G-1526 last week and will hopefully like to get this in for the milestone. I've got the server building with using the DeployableModule interface as a replacement for JarFile, and now I'm trying to tweak the interface and try to test out the Eclipse support for it. If it works I'd like to post the patch for review and get it in for M1. On Dec 4, 2006, at 10:54 AM, Matt Hogstrom wrote: While ripping out drywall this weekend I was thinking about our Geronimo 2.0 and all the work that needs to get done to complete this monsterous effort. While sifting through the scorecard and thinking about all the different things that need to be addressed it became a bit overwhelming. As everyone knows many different projects are working on their implementations of Java EE 5.0. Some are available and others are works in progress (as is ours). It seems that from user perspective people are really interested in the Java EE and have been asking for several months about where we are. At this point it would be nice to give them an idea of what we're thinking about. I had previously put out a set of milestones and dates. I wanted to make it a little more formal and of course with all the caveats that this is open source and our timetables are subject to people's time and contribution. With that, here is an updated timeline and some graphic representations that represent the Java EE specifications that need to be completed from a high level. I think it was Dain that used the term table stakes when referring to the specification. Meaning that we need the spec related functionality to get in the game but innovations beyond the specification were necessary to make a bigger splash. I don't capture those here but I'll work on pulling that together as well. Take a look at http://people.apache.org/~hogstrom/Geronimo2.0/ and provide your thoughts on how were doing. If we are going to make a Dec 22 Beta 1 then we would have to cut sometime in the next week and a half. What do y'all think? Matt Hogstrom [EMAIL PROTECTED] -sachin
Re: Geronimo 2.0 Milestone's and how were doing
On Dec 5, 2006, at 10:27 AM, Matt Hogstrom wrote: On Dec 5, 2006, at 1:21 PM, Paul McMahan wrote: On 12/5/06, Kevan Miller <[EMAIL PROTECTED]> wrote: Deploying 2.5 servlets While tc6 deploys and runs 2.4 WARs ok I haven't tried deploying a 2.5 WAR yet. All the webapps in the tc6 dist use 2.4 so I really hope I'm not the first one trying this :-S I googled up some JEE5 servlet samples but they are tightly coupled with other new JEE5 stuff like JPA, EJB 3.0, etc, so I need something simpler. I'll probably end up adding some 2.5 content to our unit test cases and cross my fingers. Worst case scenario is that for M1 we'll have a 2.5 servlet engine that you can only deploy <=2.4. servlets to. I'm looking at getting DayTrader 2.0-SNAPSHOT running now. I'm seeing some problem with the PersistenceUnitRefBuilder misinterpreting the persistence-unit-ref for jpa. I'll be looking into it later today (I hope). I also see a really long stack trace when shutting down the jetty and jetty6 servers, hope to get to that one too. thanks david jencks Perhaps I can add a new WAR with some 2.5 and JSP 2.1 content. Interested? Best wishes, Paul Matt Hogstrom [EMAIL PROTECTED]
Re: Geronimo 2.0 Milestone's and how were doing
Paul McMahan wrote: Noise factor- Shutdown of the JEE5 assemblies generates a huge stack trace. Looks like tranql/derby is the culpirt and not tomcat but I'm not 100% sure. I'll probably have to commit while the stack trace still appears so others can have a look. Also I need to figure out how to avoid logging tomcat's INFO messages to the command window. Its really noisy right now. We get what I assume are similar errors shutting down Jetty 6. I'm not sure if they are the same that you are seeing or not ... but with Jetty it looks like we're in an infinite loop getting "connectionErrorOccured with null SQL Exception" continually until we hit a StackOverflowError. following by a full NPEs trying to deal with that. If that's what you're seeing as well then it probably isn't Tomcat. Joe
Re: Geronimo 2.0 Milestone's and how were doing
On 12/5/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: I'm looking at getting DayTrader 2.0-SNAPSHOT running now. Perhaps I can add a new WAR with some 2.5 and JSP 2.1 content. Interested? that would be great.
Re: Geronimo 2.0 Milestone's and how were doing
On Dec 5, 2006, at 1:21 PM, Paul McMahan wrote: On 12/5/06, Kevan Miller <[EMAIL PROTECTED]> wrote: Deploying 2.5 servlets While tc6 deploys and runs 2.4 WARs ok I haven't tried deploying a 2.5 WAR yet. All the webapps in the tc6 dist use 2.4 so I really hope I'm not the first one trying this :-S I googled up some JEE5 servlet samples but they are tightly coupled with other new JEE5 stuff like JPA, EJB 3.0, etc, so I need something simpler. I'll probably end up adding some 2.5 content to our unit test cases and cross my fingers. Worst case scenario is that for M1 we'll have a 2.5 servlet engine that you can only deploy <=2.4. servlets to. I'm looking at getting DayTrader 2.0-SNAPSHOT running now. Perhaps I can add a new WAR with some 2.5 and JSP 2.1 content. Interested? Best wishes, Paul Matt Hogstrom [EMAIL PROTECTED]
Re: Geronimo 2.0 Milestone's and how were doing
On 12/5/06, Kevan Miller <[EMAIL PROTECTED]> wrote: Paul, Tomcat integration might have the most work to do for M1. How is that looking? I have the JSP 2.1 and EL 1.0 specs checked in and published to the snapshot repo, reversioned to 1.0-SNAPSHOT this morning per Jason's advice. The annotation 1.0 and servlet 2.5 specs were already available thanks to Joe and Greg. In my local build I have tc6 running the web console OK in a new tomcat-jee5 assembly and the default app in the tomcat-minimal assembly. Deploying a simple 2.4 WAR from the CLI works. I'm pretty confident that I'll be able to commit this first stage of tomcat integration this week. Current issues: Deploying 2.5 servlets While tc6 deploys and runs 2.4 WARs ok I haven't tried deploying a 2.5 WAR yet. All the webapps in the tc6 dist use 2.4 so I really hope I'm not the first one trying this :-S I googled up some JEE5 servlet samples but they are tightly coupled with other new JEE5 stuff like JPA, EJB 3.0, etc, so I need something simpler. I'll probably end up adding some 2.5 content to our unit test cases and cross my fingers. Worst case scenario is that for M1 we'll have a 2.5 servlet engine that you can only deploy <=2.4. servlets to. Failing unit test- A unit tests in geronimo-tomcat fails intermittently apparently due to a change in how tc6 handles connections. Still investigating if its a bug in geronimo, tomcat or the unit test. For the initial checkin I may need to disable the unit test. Noise factor- Shutdown of the JEE5 assemblies generates a huge stack trace. Looks like tranql/derby is the culpirt and not tomcat but I'm not 100% sure. I'll probably have to commit while the stack trace still appears so others can have a look. Also I need to figure out how to avoid logging tomcat's INFO messages to the command window. Its really noisy right now. Best wishes, Paul
Re: Geronimo 2.0 Milestone's and how were doing
Hi Matt, I agree as well. I'll have the JSF work completed for M1 (to the extent that MyFaces 1.2 is complete) plus the JSR-88 deployment changes for annotations ready for M2. Thanks much Tim Matt Hogstrom wrote: While ripping out drywall this weekend I was thinking about our Geronimo 2.0 and all the work that needs to get done to complete this monsterous effort. While sifting through the scorecard and thinking about all the different things that need to be addressed it became a bit overwhelming. As everyone knows many different projects are working on their implementations of Java EE 5.0. Some are available and others are works in progress (as is ours). It seems that from user perspective people are really interested in the Java EE and have been asking for several months about where we are. At this point it would be nice to give them an idea of what we're thinking about. I had previously put out a set of milestones and dates. I wanted to make it a little more formal and of course with all the caveats that this is open source and our timetables are subject to people's time and contribution. With that, here is an updated timeline and some graphic representations that represent the Java EE specifications that need to be completed from a high level. I think it was Dain that used the term table stakes when referring to the specification. Meaning that we need the spec related functionality to get in the game but innovations beyond the specification were necessary to make a bigger splash. I don't capture those here but I'll work on pulling that together as well. Take a look at http://people.apache.org/~hogstrom/Geronimo2.0/ and provide your thoughts on how were doing. If we are going to make a Dec 22 Beta 1 then we would have to cut sometime in the next week and a half. What do y'all think? Matt Hogstrom [EMAIL PROTECTED]
Re: Geronimo 2.0 Milestone's and how were doing
On Dec 4, 2006, at 10:54 AM, Matt Hogstrom wrote: If we are going to make a Dec 22 Beta 1 then we would have to cut sometime in the next week and a half. Cool. I've only merged license/notice information from branches/1.2 onto trunk. I haven't reviewed the trunk-unique dependencies. I'll get that done in time for the beta... Paul, Tomcat integration might have the most work to do for M1. How is that looking? Would be good to create proposed M1 release notes. This might drive some good discussion to insure we feel good about the proposal... --kevan
Re: Geronimo 2.0 Milestone's and how were doing
I saw the charts and the timeline looks a bit aggressive but feasible. I personally work better if I know "when" and "what" we are shooting for; personally, I like the challenge. It would be great if we manage to release a JEE5 milestone before the end of the year, it will give G a big push in the right direction -> Release Early, Release Often with the features the users want. Are you planning to put a breakdown roadmap on the wiki? Cheers! Hernan Matt Hogstrom wrote: While ripping out drywall this weekend I was thinking about our Geronimo 2.0 and all the work that needs to get done to complete this monsterous effort. While sifting through the scorecard and thinking about all the different things that need to be addressed it became a bit overwhelming. As everyone knows many different projects are working on their implementations of Java EE 5.0. Some are available and others are works in progress (as is ours). It seems that from user perspective people are really interested in the Java EE and have been asking for several months about where we are. At this point it would be nice to give them an idea of what we're thinking about. I had previously put out a set of milestones and dates. I wanted to make it a little more formal and of course with all the caveats that this is open source and our timetables are subject to people's time and contribution. With that, here is an updated timeline and some graphic representations that represent the Java EE specifications that need to be completed from a high level. I think it was Dain that used the term table stakes when referring to the specification. Meaning that we need the spec related functionality to get in the game but innovations beyond the specification were necessary to make a bigger splash. I don't capture those here but I'll work on pulling that together as well. Take a look at http://people.apache.org/~hogstrom/Geronimo2.0/ and provide your thoughts on how were doing. If we are going to make a Dec 22 Beta 1 then we would have to cut sometime in the next week and a half. What do y'all think? Matt Hogstrom [EMAIL PROTECTED]
Re: Geronimo 2.0 Milestone's and how were doing
Matt, JEE5 is critical to the widespread adoption of Geronimo. We can and should accomplish these milestones. Best wishes, Paul On 12/4/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: While ripping out drywall this weekend I was thinking about our Geronimo 2.0 and all the work that needs to get done to complete this monsterous effort. While sifting through the scorecard and thinking about all the different things that need to be addressed it became a bit overwhelming. As everyone knows many different projects are working on their implementations of Java EE 5.0. Some are available and others are works in progress (as is ours). It seems that from user perspective people are really interested in the Java EE and have been asking for several months about where we are. At this point it would be nice to give them an idea of what we're thinking about. I had previously put out a set of milestones and dates. I wanted to make it a little more formal and of course with all the caveats that this is open source and our timetables are subject to people's time and contribution. With that, here is an updated timeline and some graphic representations that represent the Java EE specifications that need to be completed from a high level. I think it was Dain that used the term table stakes when referring to the specification. Meaning that we need the spec related functionality to get in the game but innovations beyond the specification were necessary to make a bigger splash. I don't capture those here but I'll work on pulling that together as well. Take a look at http://people.apache.org/~hogstrom/Geronimo2.0/ and provide your thoughts on how were doing. If we are going to make a Dec 22 Beta 1 then we would have to cut sometime in the next week and a half. What do y'all think? Matt Hogstrom [EMAIL PROTECTED]
Re: Geronimo 2.0 Milestone's and how were doing
Matt Hogstrom wrote: While ripping out drywall this weekend I was thinking about our Geronimo 2.0 and all the work that needs to get done to complete this monsterous effort. While sifting through the scorecard and thinking about all the different things that need to be addressed it became a bit overwhelming. As everyone knows many different projects are working on their implementations of Java EE 5.0. Some are available and others are works in progress (as is ours). It seems that from user perspective people are really interested in the Java EE and have been asking for several months about where we are. At this point it would be nice to give them an idea of what we're thinking about. I had previously put out a set of milestones and dates. I wanted to make it a little more formal and of course with all the caveats that this is open source and our timetables are subject to people's time and contribution. With that, here is an updated timeline and some graphic representations that represent the Java EE specifications that need to be completed from a high level. I think it was Dain that used the term table stakes when referring to the specification. Meaning that we need the spec related functionality to get in the game but innovations beyond the specification were necessary to make a bigger splash. I don't capture those here but I'll work on pulling that together as well. Take a look at http://people.apache.org/~hogstrom/Geronimo2.0/ and provide your thoughts on how were doing. If we are going to make a Dec 22 Beta 1 then we would have to cut sometime in the next week and a half. What do y'all think? I think it is very ambitious and high risk (esp. the Dec. 22 beta/milestone) ... but I also agree that it's critical for us to support Java EE 5 as quickly as possible. "Table stakes" is a good analogy. We need to support Java EE 5 before we can even be considered in most shops doing new development. These target dates and driver content will put us in good position to deliver along with some and ahead of other choices. Achieving them will ensure that we continue to build on the momentum Geronimo has already gained. These goals also help to unify the community and provide important direction to users that we are seriously moving toward Java EE 5. So I think it's good in several ways but I better stop typing and get busy! ;-) Joe
Re: Geronimo 2.0 Milestone's and how were doing
IMO the M notation here is really confusing for a post-1.0 release. I also don't really get the Dec 22 thing at all... If we are lucky we will get 1.2 out by then. But, I'm not trying to knock any of this ambition... just a comment. --jason On Dec 4, 2006, at 7:54 AM, Matt Hogstrom wrote: While ripping out drywall this weekend I was thinking about our Geronimo 2.0 and all the work that needs to get done to complete this monsterous effort. While sifting through the scorecard and thinking about all the different things that need to be addressed it became a bit overwhelming. As everyone knows many different projects are working on their implementations of Java EE 5.0. Some are available and others are works in progress (as is ours). It seems that from user perspective people are really interested in the Java EE and have been asking for several months about where we are. At this point it would be nice to give them an idea of what we're thinking about. I had previously put out a set of milestones and dates. I wanted to make it a little more formal and of course with all the caveats that this is open source and our timetables are subject to people's time and contribution. With that, here is an updated timeline and some graphic representations that represent the Java EE specifications that need to be completed from a high level. I think it was Dain that used the term table stakes when referring to the specification. Meaning that we need the spec related functionality to get in the game but innovations beyond the specification were necessary to make a bigger splash. I don't capture those here but I'll work on pulling that together as well. Take a look at http://people.apache.org/~hogstrom/Geronimo2.0/ and provide your thoughts on how were doing. If we are going to make a Dec 22 Beta 1 then we would have to cut sometime in the next week and a half. What do y'all think? Matt Hogstrom [EMAIL PROTECTED]
Re: Geronimo 2.0
2006/1/11, Greg Wilkins <[EMAIL PROTECTED]>: > Alan D. Cabrera wrote: > > It's my understading that we're going for JEE 5. I think that our > > re-arch of security should go into that as well. > > > > How do we want to stage this effort in terms of SVN organization? When > > should we cut a 2.0 development branch? > > > Did we decide anything here? Hi Greg, I'd say 'yes'. I think Dave B. summed it up nicely: "We need to follow through on Geronimo 1.x for a few release cycles, get some user feedback, learn the lessons we need to learn for a while, *then* start Geronimo 2.0." with a comment by Jason: "the trunk should be used for feature development for 1.1" and then Dave B again: "All that said, I do think it's a positive thing to explore JEE 5 and experiment with ideas. I just think we need to be absolutely sure that it doesn't overshadow 1.x." So, branch the trunk and move on. When you're done, it will be merged with the trunk. Does it sound good? > Where/How can I start playing with Jetty 6 and servlet 2.5 in geronimo? I can't answer the question, but wonder what you miss before moving on? I think that the deployers would certainly have to be "enhanced" to accept 2.5 deployment descriptors. Jacek
Re: Geronimo 2.0
Alan D. Cabrera wrote: > It's my understading that we're going for JEE 5. I think that our > re-arch of security should go into that as well. > > How do we want to stage this effort in terms of SVN organization? When > should we cut a 2.0 development branch? Did we decide anything here? Where/How can I start playing with Jetty 6 and servlet 2.5 in geronimo? cheers
Re: Geronimo 2.0
On Jan 8, 2006, at 8:47 AM, Alan D. Cabrera wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Blevins wrote, On 1/6/2006 3:24 PM: On Jan 6, 2006, at 11:10 AM, David Jencks wrote: Either I don't understand what is being proposed or I think it is a recipe for disaster. My past experience with open source projects leads me to believe that having more than one main development area that is leading to a release is likely to cause only confusion, not progress towards functionality. In my opinion if we call head 2.0 and start adding JEE 5 features to it, there will never be any more j2ee 1.4 releases with added functionality. We will have a couple bug fix 1.0 releases, then a year or so while we try to finish JEE 5. I don't think this is acceptable. Amen! We can't go from two years of development on 1.x with little to no user interaction then abandon it after the first release and go back into the development hole. We need to follow through on Geronimo 1.x for a few release cycles, get some user feedback, learn the lessons we need to learn for a while, *then* start Geronimo 2.0. Now is not the time to turn our focus to the next shinny ball, now is the time to focus on users of 1.x as they will need our dedication before they can bring it into production. Dave, I don't think that anyone is advocating the abandonment of 1.x. I think we are merely acknowledging the fact that a lot of people will want to work on, to use your choice of words, the next shinny ball. You can't control what people want to work on. We can control how it's done so that we can minimized the impact on 1.x branch. This was the reason for my initial email. I get it, and yes I am shoving words in people's mouths when I say "abandon." And, yes, it's a pretty fine line. But there is no way that just some people can start 2.x, meaning: everyone will feel pressure to get their ideas in before things are so far along and it's too late; people will be land grabbing to get their name on their favorite part of the server. I am pretty hypocritical though from a certain perspective though as I feel it's critical to get OpenEJB 3 into light asap. But in both cases, Geronimo and OpenEJB, I am driven by some level of guilt. In OpenEJB we burned people badly as development on 1.x dried up when 2.x was started. People waited patiently but 2.x never turned out to be something 1.x users could use. The goal for OpenEJB 3 and the promise that we've made to our users is that it will be something they can use. In Geronimo we've told people so many times for so many months "hold on", "just wait", "we're almost there." I feel like there was an unspoken agreement there that it would be "their turn" next to be the focus of our community and it's our turn to be the patient ones; more over that if we don't do this, it will be the ultimate of insults to those that did wait with enduring anticipation at our first major release. The bottom line(s) for me is I feel we need to show people that 1.x is our highest priority for a while if we expect them to make a serious investment in it (and ultimately, Geronimo). And when I say our highest priority I don't mean a high priority, I mean a hot-bed of exciting development and new things. All that said, I do think it's a positive thing to explore JEE 5 and experiment with ideas. I just think we need to be absolutely sure that it doesn't overshadow 1.x. I don't want to make too big of a stink about this as everything is a balancing act and somewhere in the middle is commonly the optimal answer -- I'm sure we can find it if we keep talking -- but there are warning bells going off in my head at the thought of anything that might further retard the procurement of users from our fairly large potential user-base -- by saying that I'm not implying that anyone with a different perspective doesn't share the same concerns. Just trying to explain what's rollin' round my head. -David
Re: Geronimo 2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Blevins wrote, On 1/6/2006 3:24 PM: > > On Jan 6, 2006, at 11:10 AM, David Jencks wrote: > >> Either I don't understand what is being proposed or I think it is a >> recipe for disaster. >> >> My past experience with open source projects leads me to believe that >> having more than one main development area that is leading to a >> release is likely to cause only confusion, not progress towards >> functionality. >> >> In my opinion if we call head 2.0 and start adding JEE 5 features to >> it, there will never be any more j2ee 1.4 releases with added >> functionality. We will have a couple bug fix 1.0 releases, then a >> year or so while we try to finish JEE 5. I don't think this is >> acceptable. >> > > Amen! > > We can't go from two years of development on 1.x with little to no user > interaction then abandon it after the first release and go back into > the development hole. We need to follow through on Geronimo 1.x for a > few release cycles, get some user feedback, learn the lessons we need > to learn for a while, *then* start Geronimo 2.0. > > Now is not the time to turn our focus to the next shinny ball, now is > the time to focus on users of 1.x as they will need our dedication > before they can bring it into production. Dave, I don't think that anyone is advocating the abandonment of 1.x. I think we are merely acknowledging the fact that a lot of people will want to work on, to use your choice of words, the next shinny ball. You can't control what people want to work on. We can control how it's done so that we can minimized the impact on 1.x branch. This was the reason for my initial email. Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDwUIZ1xC6qnMLUpYRArSVAJ4wvd7ZbQhqdkuVnsF0lUaI7lByOACeN0Vu VRh2v9fqbdQWwYlXiFHCHow= =n376 -END PGP SIGNATURE-
Re: Geronimo 2.0
Even if we don't think about 2.0, there are two main ways in which we can handle a stable branch in source control: 1) We can have a 1.0 branch and as new features and bug fixes are tried and tested in the dev area(s), then these patches are moved to the 1.0 branch as patch sets via some QA process. This will give us much better control and stability of our released versions, but it needs effort to control the patches moving into the 1.0 branch. If we look at the Linux kernel development style, they are very much in this style with patches coming from multiple development areas and being QA's into the main kernal branches. 2.0 development would fit nicely in this as it would just be another source of patches to be QA'd into branches. 2) We can continue development on a trunk and then every time we want to make a release we copy the trunk to a branch and have a few weeks stabalizing it and then release it. This is simpler for the developers, but the stability of final releases may suffer as stuff that your really didn't want will make it's way into releases. This means that the trunk can never be more than a few weeks away from a release. It also means that 2.0 cannot be developed in trunk as we can't just copy the whole blob. It also means that having multiple dev areas is difficult as there is no single source to copy a branch from and no culture of merging. We must decide which of these models we want to go with - regardless of 2.0 development. I think that geronimo is of a size and complexity that we should consider the overheads of approach 1). Formal compliance issues also push us towards good QA of all patches to stable releases. But to do so, we need to develop a culture flowing patch sets through a QA process. We will need multiple people responsible for controlling patches into specific subsystems and giving assurances to the main build manager that they have QA's the patches. These will be tough thankless jobs - maybe we should see if Linus wants a change from all that C hacking? cheers
Re: Geronimo 2.0
2006/1/7, David Blevins <[EMAIL PROTECTED]>: > We can't go from two years of development on 1.x with little to no > user interaction then abandon it after the first release and go back > into the development hole. Hi Dave, Who said we would abandon 1.x? I'm pretty sure noone did. The point I see is that many of us (if not all) think that 1.1-SNAPSHOT is more appropriate than 2.0-SNAPSHOT. I don't see any difference, to be honest. The truth is that we all can live with any version as long as we know what we need to achieve in the coming releases. I think JEE 1.5 deserves its own 2.0 release whereas smaller functionalities will go to 1.x releases. AFAIUI, that's what we all agree with. So is mine. But...if someone have implemented a feature of JEE 5 on a separate branch, how (s)he should proceed with regard to the trunk? If it merged with it, will it break our support for 1.0? I don't think so. Would it lower our willingness to add more features to 1.0? I don't think so. So, what are we talking about? I keep wondering what makes me so excited about JEE 5 and arguing about the versions. I think it's Java 5 that will surely make our programming life easier. Generics and annotations seem to be so helpful. The more I think about 1.1 vs 2.0, though, the more I understand Daves' point (Dave B and Dave J). The smaller steps we do the better. That's exactly what DJ had said in his mail and now I got his point (!) "More than one main development area" is about making smaller steps in the trunk rather than doing all at once (and end up with nothing). Thanks everybody for your time and patience while explaining it to me! ;) > We need to follow through on Geronimo 1.x > for a few release cycles, get some user feedback, learn the lessons > we need to learn for a while, *then* start Geronimo 2.0. Ok, ok. We'll see how it goes. I'm not suggesting we call the trunk 2.0-SNAPSHOT and stop supporting our users. I can live with 1.1-SNAPSHOT, too. > Now is not the time to turn our focus to the next shinny ball, now is > the time to focus on users of 1.x as they will need our dedication > before they can bring it into production. Sure. Good point. Users are what make these shinny features implemented in any product, and so does in Geronimo. > There is my $0.02. Add my 0,02 PLN to it ;) > -David Jacek
Re: Geronimo 2.0
My $0.02 inline below... In my opinion if we call head 2.0 and start adding JEE 5 features to it, there will never be any more j2ee 1.4 releases with added functionality. We will have a couple bug fix 1.0 releases, then a year or so while we try to finish JEE 5. I don't think this is acceptable. I strongly recommend against using 2.0 the trunk if 2.0 is to include the JEE 5 features. The trunk should always remain as stable development, as close to the latest supported release as possible. Unstable features, features that take a long time, or prototypes should always be implemented on a development/feature branch, never on the trunk. his point, I think we should label head 1.1-SNAPSHOT and work on any features that require 1.5 in one or more branches, labelled by feature. I agree completely... but would like to mention that the entire tree does not need to be branched, you could have a branch for a single module, or a sub-set of modules. However, this will be much easier once we've moved to Maven 2. * * * I think at this point, the trunk should be used for feature development for 1.1, perhaps even for staging for a switch to Maven 2... though ideally Maven 2 should be done on a dev branch, but Subversion is still not the best at automatically merging, so it may be easier to use the trunk. Um... and I don't think there is any way to avoid managing several active dev & release branches. Just keep the required branches modules to a minimum and it should be manageable. Anyways, just my opinion... not sure that matters :-P --jason
Re: Geronimo 2.0
David Blevins wrote: On Jan 6, 2006, at 11:10 AM, David Jencks wrote: Either I don't understand what is being proposed or I think it is a recipe for disaster. My past experience with open source projects leads me to believe that having more than one main development area that is leading to a release is likely to cause only confusion, not progress towards functionality. In my opinion if we call head 2.0 and start adding JEE 5 features to it, there will never be any more j2ee 1.4 releases with added functionality. We will have a couple bug fix 1.0 releases, then a year or so while we try to finish JEE 5. I don't think this is acceptable. Amen! We can't go from two years of development on 1.x with little to no user interaction then abandon it after the first release and go back into the development hole. We need to follow through on Geronimo 1.x for a few release cycles, get some user feedback, learn the lessons we need to learn for a while, *then* start Geronimo 2.0. Now is not the time to turn our focus to the next shinny ball, now is the time to focus on users of 1.x as they will need our dedication before they can bring it into production. +1 Also, we need to think about when we need to turn to this next shinny ball. At this stage, I think that JEE 5 is still a shiny technology and the mass of the community has not yet started to transition to it. Hence, we need to support what people want now. Having said that, we need to be in an acceptable state, WRT JEE 5 features, when the community will ask for it; this means that we will need to improve the stack from a user perspective. Thanks, Gianny There is my $0.02. -David
Re: Geronimo 2.0
I agree and do not advocate upgrading releases. However, Jetty I think is a requirements as there is a security hole. As far as Tomcat is concerned I'll defer that decision to you :) Matt Alan D. Cabrera wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevan Miller wrote, On 1/6/2006 8:47 AM: On Jan 6, 2006, at 10:07 AM, Matt Hogstrom wrote: I'll summarize what I think I read. HEAD will be 2.0 which includes JEE 5 and other significant work (Maven 2 conversion, etc.) Branches/1.0 will be where the work for 1.0.x will take place. It would be from this code base we'd branch to a 1.1 when appropriate. I'm updating my local copy of the branches/1.0 with a version change for Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15 and Jetty 5.1.10 to incoroporate the latent fixes. I'll build and test to make sure its still working (I'm not going to run TCK). and then commit these changes back when I've confirmed we're ready to go for 1.0.1. Does this sound workable? Matt, Tomcat 5.5.15 is stll in Beta. So, I'd hold off just a bit. Preliminary tests look good. I'm running a more complete test, now. How about you update version and Jetty. I'll cutover Tomcat when appropriate... Good point Keven. Matt, I think that we should avoid version upgrades for a patch release if we can help it. Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDvqTe1xC6qnMLUpYRAuwiAJ0fgGNJpSyxWKop798/EVtM3XLZCgCfQv8J QKSjMpmRG4SFbEg052RmpN0= =aRfh -END PGP SIGNATURE-
Re: Geronimo 2.0
On Jan 6, 2006, at 11:10 AM, David Jencks wrote: Either I don't understand what is being proposed or I think it is a recipe for disaster. My past experience with open source projects leads me to believe that having more than one main development area that is leading to a release is likely to cause only confusion, not progress towards functionality. In my opinion if we call head 2.0 and start adding JEE 5 features to it, there will never be any more j2ee 1.4 releases with added functionality. We will have a couple bug fix 1.0 releases, then a year or so while we try to finish JEE 5. I don't think this is acceptable. Amen! We can't go from two years of development on 1.x with little to no user interaction then abandon it after the first release and go back into the development hole. We need to follow through on Geronimo 1.x for a few release cycles, get some user feedback, learn the lessons we need to learn for a while, *then* start Geronimo 2.0. Now is not the time to turn our focus to the next shinny ball, now is the time to focus on users of 1.x as they will need our dedication before they can bring it into production. There is my $0.02. -David
Re: Geronimo 2.0
2006/1/6, David Jencks <[EMAIL PROTECTED]>: > Either I don't understand what is being proposed or I think it is a > recipe for disaster. Hi Dave, I think there might be the third option ;) > My past experience with open source projects leads me to believe that > having more than one main development area that is leading to a > release is likely to cause only confusion, not progress towards > functionality. Well, the more branches we will have the more headaches it will cause to us. I think that's totally unavoidable when moving towards JEE 5 where Java 5 plays a crucial role. > In my opinion if we call head 2.0 and start adding JEE 5 features to > it, there will never be any more j2ee 1.4 releases with added > functionality. We will have a couple bug fix 1.0 releases, then a > year or so while we try to finish JEE 5. I don't think this is > acceptable. Correct. > I would like to propose a process by which disruptive new feature > development occurs in separate subprojects or feature-specific > branches that can be merged into trunk when feature complete and stable. That's exactly what was said. Noone suggested to work on HEAD and eventually breaks it for weeks. I think one of the reason we switched to svn was the simplicity to create and merge a branch. We can therefore easily experiment in our own branches, but that contradicts what you said above with "more than one main development area". It's unavoidable in such a large project to have only "one main development area". There's going to be lots of branches, imho. As far as EJB 3 is concerned it shouldn't be a big deal. It will be implemented by OpenEJB which is a separate project so appropriate interfaces should do the work nicely. The real pain will be with the other modules that will require separate branches and be merged once finished. > I realize there are some significant problems with this as regards > JEE 5, at least as far as jdk support level, in that JEE 5 requires > use of jdk 1.4 incompatible code. Personally I don't have enough > information about how hard it is to convert to generics to begin to > guess what these problems might be. It would also be useful to know > more about e.g. whether retrotranslator might actually work. I don't understand. Why are you scared of using Java 5? Geronimo 1.0 is on its own branch, and anybody who wants to play with the source code will download that branch. Others who want to be on the cutting edge will work with HEAD. Problems will have to be sorted out for sure, but Geronimo 1.0 is safe and so are their minor descendants (i.e. 1.x.x versions). > I think in order to consider this realistically we need a list of > features we plan to add and to decide for each one of them whether it > requires jdk 1.5 support and whether it can fit into "1.0". For > instance I think the proposed security improvements could fit into > 1.0 written in jdk 1.4. But that wouldn't be 1.0 any more, but a branch called 1.0.x or 1.x. Weren't you worried about having more than one main development area? Aren't you proposing just that? > At this point, I think we should label head 1.1-SNAPSHOT and work on > any features that require 1.5 in one or more branches, labelled by > feature. That's acceptable, but how long do you envision HEAD will survive before migrating to Java 5? Why don't you want to start using Java 5 right away? I don't remember who was it (possibly Dain) who expressed so much enthusiasm about using Java Generics and I really think it will save us a lot of time when developing with Java 5 instead of writing code that will be a nightmare to support. Ok, maybe it won't be a nightmare, but the additional code to support Java 1.4 will add unnecessary burden. > I also think we need to decide on and publish criteria for including > bug fixes in 1.0.1, and indeed if we want to release a 1.0.1 or just > go for 1.1. That's an interesting matter. What changes make 1.x and what does 1.0.x? Anyone could comment on it. I think the security issue of Jetty asks for 1.0.x. > david jencks Jacek
Re: Geronimo 2.0
Once I finish the suddenly-urgent mountain of book work, I have a lot more console and management stuff to work on. There's no reason that has to wait for a rewritten CORBA stack, EJB3 container, security stack, etc., much less all the new specs and JSRs. So I certainly plan to contribute to a 1.1 release. (I'm not sure whether new Jetspeed/Pluto integration would fit into 1.1 or 2.0, though 1.1 would be nice.) I'd prefer to see us draw up as much of a feature list as we can for 1.1 and 2.0, and then based on those think about where we want to put things and how we branch. That may also suggest a time frame for each. Aaron On 1/6/06, David Jencks <[EMAIL PROTECTED]> wrote: > Either I don't understand what is being proposed or I think it is a > recipe for disaster. > > My past experience with open source projects leads me to believe that > having more than one main development area that is leading to a > release is likely to cause only confusion, not progress towards > functionality. > > In my opinion if we call head 2.0 and start adding JEE 5 features to > it, there will never be any more j2ee 1.4 releases with added > functionality. We will have a couple bug fix 1.0 releases, then a > year or so while we try to finish JEE 5. I don't think this is > acceptable. > > I would like to propose a process by which disruptive new feature > development occurs in separate subprojects or feature-specific > branches that can be merged into trunk when feature complete and stable. > > I realize there are some significant problems with this as regards > JEE 5, at least as far as jdk support level, in that JEE 5 requires > use of jdk 1.4 incompatible code. Personally I don't have enough > information about how hard it is to convert to generics to begin to > guess what these problems might be. It would also be useful to know > more about e.g. whether retrotranslator might actually work. > > I think in order to consider this realistically we need a list of > features we plan to add and to decide for each one of them whether it > requires jdk 1.5 support and whether it can fit into "1.0". For > instance I think the proposed security improvements could fit into > 1.0 written in jdk 1.4. > > At this point, I think we should label head 1.1-SNAPSHOT and work on > any features that require 1.5 in one or more branches, labelled by > feature. > > I also think we need to decide on and publish criteria for including > bug fixes in 1.0.1, and indeed if we want to release a 1.0.1 or just > go for 1.1. > > thanks > david jencks > > > > On Jan 6, 2006, at 9:10 AM, Alan D. Cabrera wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Matt Hogstrom wrote, On 1/6/2006 7:07 AM: > >> I'll summarize what I think I read. > >> > >> HEAD will be 2.0 which includes JEE 5 and other significant work > >> (Maven > >> 2 conversion, etc.) > >> > >> Branches/1.0 will be where the work for 1.0.x will take place. It > >> would > >> be from this code base we'd branch to a 1.1 when appropriate. > > > > So, we would eventually have 2 branches and 1 trunk: > > > > branches/1.0 > > branches/1_trunk > > tags/* > > trunk > > > >> I'm updating my local copy of the branches/1.0 with a version > >> change for > >> Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15 and > >> Jetty 5.1.10 to incoroporate the latent fixes. > >> > >> I'll build and test to make sure its still working (I'm not going > >> to run > >> TCK). and then commit these changes back when I've confirmed we're > >> ready > >> to go for 1.0.1. Does this sound workable? > > > > Can we have jira issues assigned to 1.0.1 so that we can see what's > > coming down the pipeline? > > > > > > Regards, > > Alan > > > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.4.2 (MingW32) > > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > > > iD8DBQFDvqSa1xC6qnMLUpYRArhpAJ91d5cSrHGEsY0pG6Jf+Nb+9gNuSgCfR8gH > > m3qYJWEG9Zej/Sg+O5pMPQA= > > =goh1 > > -END PGP SIGNATURE- > > > >
Re: Geronimo 2.0
David has a compelling argument... I am concerned about delivering j2ee 1.4 features and release over the next year while jee5 is written. I don't want to repeat the lesson we all learned with the very very long gap between m3 and m4. With out micro kernel design, don't you think we should be able to develop most of the jee5 new features in plugin modules or subprojects? Regaurdless, I have a few features I'd like to put into 1.x to make transition to 2.x painless, so I will be working on whatever branch is to become 1.1. -dain On Jan 6, 2006, at 11:10 AM, David Jencks wrote: Either I don't understand what is being proposed or I think it is a recipe for disaster. My past experience with open source projects leads me to believe that having more than one main development area that is leading to a release is likely to cause only confusion, not progress towards functionality. In my opinion if we call head 2.0 and start adding JEE 5 features to it, there will never be any more j2ee 1.4 releases with added functionality. We will have a couple bug fix 1.0 releases, then a year or so while we try to finish JEE 5. I don't think this is acceptable. I would like to propose a process by which disruptive new feature development occurs in separate subprojects or feature-specific branches that can be merged into trunk when feature complete and stable. I realize there are some significant problems with this as regards JEE 5, at least as far as jdk support level, in that JEE 5 requires use of jdk 1.4 incompatible code. Personally I don't have enough information about how hard it is to convert to generics to begin to guess what these problems might be. It would also be useful to know more about e.g. whether retrotranslator might actually work. I think in order to consider this realistically we need a list of features we plan to add and to decide for each one of them whether it requires jdk 1.5 support and whether it can fit into "1.0". For instance I think the proposed security improvements could fit into 1.0 written in jdk 1.4. At this point, I think we should label head 1.1-SNAPSHOT and work on any features that require 1.5 in one or more branches, labelled by feature. I also think we need to decide on and publish criteria for including bug fixes in 1.0.1, and indeed if we want to release a 1.0.1 or just go for 1.1. thanks david jencks On Jan 6, 2006, at 9:10 AM, Alan D. Cabrera wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt Hogstrom wrote, On 1/6/2006 7:07 AM: I'll summarize what I think I read. HEAD will be 2.0 which includes JEE 5 and other significant work (Maven 2 conversion, etc.) Branches/1.0 will be where the work for 1.0.x will take place. It would be from this code base we'd branch to a 1.1 when appropriate. So, we would eventually have 2 branches and 1 trunk: branches/1.0 branches/1_trunk tags/* trunk I'm updating my local copy of the branches/1.0 with a version change for Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15 and Jetty 5.1.10 to incoroporate the latent fixes. I'll build and test to make sure its still working (I'm not going to run TCK). and then commit these changes back when I've confirmed we're ready to go for 1.0.1. Does this sound workable? Can we have jira issues assigned to 1.0.1 so that we can see what's coming down the pipeline? Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDvqSa1xC6qnMLUpYRArhpAJ91d5cSrHGEsY0pG6Jf+Nb+9gNuSgCfR8gH m3qYJWEG9Zej/Sg+O5pMPQA= =goh1 -END PGP SIGNATURE-
Re: Geronimo 2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Jencks wrote, On 1/6/2006 11:10 AM: > Either I don't understand what is being proposed or I think it is a > recipe for disaster. > > My past experience with open source projects leads me to believe that > having more than one main development area that is leading to a release > is likely to cause only confusion, not progress towards functionality. > > In my opinion if we call head 2.0 and start adding JEE 5 features to > it, there will never be any more j2ee 1.4 releases with added > functionality. We will have a couple bug fix 1.0 releases, then a year > or so while we try to finish JEE 5. I don't think this is acceptable. > > I would like to propose a process by which disruptive new feature > development occurs in separate subprojects or feature-specific branches > that can be merged into trunk when feature complete and stable. > > I realize there are some significant problems with this as regards JEE > 5, at least as far as jdk support level, in that JEE 5 requires use of > jdk 1.4 incompatible code. Personally I don't have enough information > about how hard it is to convert to generics to begin to guess what > these problems might be. It would also be useful to know more about > e.g. whether retrotranslator might actually work. > > I think in order to consider this realistically we need a list of > features we plan to add and to decide for each one of them whether it > requires jdk 1.5 support and whether it can fit into "1.0". For > instance I think the proposed security improvements could fit into 1.0 > written in jdk 1.4. > > At this point, I think we should label head 1.1-SNAPSHOT and work on > any features that require 1.5 in one or more branches, labelled by > feature. Your assumption is that 1.5 features are compact concise changes. The changes that are required, though, are quite comprehensive. I think we at least need a single 1.5 branch as well as a 1.4 branch. > I also think we need to decide on and publish criteria for including > bug fixes in 1.0.1, and indeed if we want to release a 1.0.1 or just go > for 1.1. We need to pump out 1.0.1 ASAP. Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDvsmc1xC6qnMLUpYRAjisAJ4uYVFdWnt8ZR4Ib/a6hAJgMsDBDgCdGZIc kpoS00XdIBMpN8z5Qsa3Ll4= =6bQl -END PGP SIGNATURE-
Re: Geronimo 2.0
David Jencks wrote: Either I don't understand what is being proposed or I think it is a recipe for disaster. My past experience with open source projects leads me to believe that having more than one main development area that is leading to a release is likely to cause only confusion, not progress towards functionality. In my opinion if we call head 2.0 and start adding JEE 5 features to it, there will never be any more j2ee 1.4 releases with added functionality. We will have a couple bug fix 1.0 releases, then a year or so while we try to finish JEE 5. I don't think this is acceptable. From my experience working on the Apache HTTP Server, I agree with David. Bill
Re: Geronimo 2.0
Either I don't understand what is being proposed or I think it is a recipe for disaster. My past experience with open source projects leads me to believe that having more than one main development area that is leading to a release is likely to cause only confusion, not progress towards functionality. In my opinion if we call head 2.0 and start adding JEE 5 features to it, there will never be any more j2ee 1.4 releases with added functionality. We will have a couple bug fix 1.0 releases, then a year or so while we try to finish JEE 5. I don't think this is acceptable. I would like to propose a process by which disruptive new feature development occurs in separate subprojects or feature-specific branches that can be merged into trunk when feature complete and stable. I realize there are some significant problems with this as regards JEE 5, at least as far as jdk support level, in that JEE 5 requires use of jdk 1.4 incompatible code. Personally I don't have enough information about how hard it is to convert to generics to begin to guess what these problems might be. It would also be useful to know more about e.g. whether retrotranslator might actually work. I think in order to consider this realistically we need a list of features we plan to add and to decide for each one of them whether it requires jdk 1.5 support and whether it can fit into "1.0". For instance I think the proposed security improvements could fit into 1.0 written in jdk 1.4. At this point, I think we should label head 1.1-SNAPSHOT and work on any features that require 1.5 in one or more branches, labelled by feature. I also think we need to decide on and publish criteria for including bug fixes in 1.0.1, and indeed if we want to release a 1.0.1 or just go for 1.1. thanks david jencks On Jan 6, 2006, at 9:10 AM, Alan D. Cabrera wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt Hogstrom wrote, On 1/6/2006 7:07 AM: I'll summarize what I think I read. HEAD will be 2.0 which includes JEE 5 and other significant work (Maven 2 conversion, etc.) Branches/1.0 will be where the work for 1.0.x will take place. It would be from this code base we'd branch to a 1.1 when appropriate. So, we would eventually have 2 branches and 1 trunk: branches/1.0 branches/1_trunk tags/* trunk I'm updating my local copy of the branches/1.0 with a version change for Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15 and Jetty 5.1.10 to incoroporate the latent fixes. I'll build and test to make sure its still working (I'm not going to run TCK). and then commit these changes back when I've confirmed we're ready to go for 1.0.1. Does this sound workable? Can we have jira issues assigned to 1.0.1 so that we can see what's coming down the pipeline? Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDvqSa1xC6qnMLUpYRArhpAJ91d5cSrHGEsY0pG6Jf+Nb+9gNuSgCfR8gH m3qYJWEG9Zej/Sg+O5pMPQA= =goh1 -END PGP SIGNATURE-
Re: Geronimo 2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevan Miller wrote, On 1/6/2006 8:47 AM: > > On Jan 6, 2006, at 10:07 AM, Matt Hogstrom wrote: > >> I'll summarize what I think I read. >> >> HEAD will be 2.0 which includes JEE 5 and other significant work >> (Maven 2 conversion, etc.) >> >> Branches/1.0 will be where the work for 1.0.x will take place. It >> would be from this code base we'd branch to a 1.1 when appropriate. >> >> I'm updating my local copy of the branches/1.0 with a version change >> for Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15 >> and Jetty 5.1.10 to incoroporate the latent fixes. >> >> I'll build and test to make sure its still working (I'm not going to >> run TCK). and then commit these changes back when I've confirmed >> we're ready to go for 1.0.1. Does this sound workable? > > > Matt, > Tomcat 5.5.15 is stll in Beta. So, I'd hold off just a bit. Preliminary > tests look good. I'm running a more complete test, now. How about you > update version and Jetty. I'll cutover Tomcat when appropriate... Good point Keven. Matt, I think that we should avoid version upgrades for a patch release if we can help it. Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDvqTe1xC6qnMLUpYRAuwiAJ0fgGNJpSyxWKop798/EVtM3XLZCgCfQv8J QKSjMpmRG4SFbEg052RmpN0= =aRfh -END PGP SIGNATURE-
Re: Geronimo 2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt Hogstrom wrote, On 1/6/2006 7:07 AM: > I'll summarize what I think I read. > > HEAD will be 2.0 which includes JEE 5 and other significant work (Maven > 2 conversion, etc.) > > Branches/1.0 will be where the work for 1.0.x will take place. It would > be from this code base we'd branch to a 1.1 when appropriate. So, we would eventually have 2 branches and 1 trunk: branches/1.0 branches/1_trunk tags/* trunk > I'm updating my local copy of the branches/1.0 with a version change for > Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15 and > Jetty 5.1.10 to incoroporate the latent fixes. > > I'll build and test to make sure its still working (I'm not going to run > TCK). and then commit these changes back when I've confirmed we're ready > to go for 1.0.1. Does this sound workable? Can we have jira issues assigned to 1.0.1 so that we can see what's coming down the pipeline? Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDvqSa1xC6qnMLUpYRArhpAJ91d5cSrHGEsY0pG6Jf+Nb+9gNuSgCfR8gH m3qYJWEG9Zej/Sg+O5pMPQA= =goh1 -END PGP SIGNATURE-
Re: Geronimo 2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Sisson wrote, On 1/5/2006 7:25 PM: > Will fixes for the 1.0.1 release (hopefully we can get out in a few > weeks) be committed to the 1.0 branch and then we create another tag for > the 1.0.1 release? Yep. Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDvqNG1xC6qnMLUpYRAqDfAJwLH1KV93WiTR21OX+IutEVTttwmQCeP3Kd Tyda15+xRLXJIbwW6pXnNPQ= =LQ8S -END PGP SIGNATURE-
Re: Geronimo 2.0
Thanks Kevan...I was going to ask about TC as 5.1.15 was not found:)...leaving at 5.1.9 for now. Other changes in and building now. Kevan Miller wrote: On Jan 6, 2006, at 10:07 AM, Matt Hogstrom wrote: I'll summarize what I think I read. HEAD will be 2.0 which includes JEE 5 and other significant work (Maven 2 conversion, etc.) Branches/1.0 will be where the work for 1.0.x will take place. It would be from this code base we'd branch to a 1.1 when appropriate. I'm updating my local copy of the branches/1.0 with a version change for Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15 and Jetty 5.1.10 to incoroporate the latent fixes. I'll build and test to make sure its still working (I'm not going to run TCK). and then commit these changes back when I've confirmed we're ready to go for 1.0.1. Does this sound workable? Matt, Tomcat 5.5.15 is stll in Beta. So, I'd hold off just a bit. Preliminary tests look good. I'm running a more complete test, now. How about you update version and Jetty. I'll cutover Tomcat when appropriate... --kevan
Re: Geronimo 2.0
On Jan 6, 2006, at 10:07 AM, Matt Hogstrom wrote: I'll summarize what I think I read. HEAD will be 2.0 which includes JEE 5 and other significant work (Maven 2 conversion, etc.) Branches/1.0 will be where the work for 1.0.x will take place. It would be from this code base we'd branch to a 1.1 when appropriate. I'm updating my local copy of the branches/1.0 with a version change for Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15 and Jetty 5.1.10 to incoroporate the latent fixes. I'll build and test to make sure its still working (I'm not going to run TCK). and then commit these changes back when I've confirmed we're ready to go for 1.0.1. Does this sound workable? Matt, Tomcat 5.5.15 is stll in Beta. So, I'd hold off just a bit. Preliminary tests look good. I'm running a more complete test, now. How about you update version and Jetty. I'll cutover Tomcat when appropriate... --kevan
Re: Geronimo 2.0
2006/1/6, Matt Hogstrom <[EMAIL PROTECTED]>: > HEAD will be 2.0 which includes JEE 5 and other significant work (Maven 2 > conversion, etc.) Hi Matt, That's my understanding, too. > Branches/1.0 will be where the work for 1.0.x will take place. It would be > from > this code base we'd branch to a 1.1 when appropriate. +1 > I'm updating my local copy of the branches/1.0 with a version change for > Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15 and Jetty > 5.1.10 > to incoroporate the latent fixes. Excellent! Let us know when it's finished so we could give it a whirl, esp. those who don't follow scm. > I'll build and test to make sure its still working (I'm not going to run TCK). > and then commit these changes back when I've confirmed we're ready to go for > 1.0.1. Does this sound workable? I wouldn't have said it better ;) I think we should write it down somewhere. Any hints on where it ought to be? On another note, what do others think about creating Grinder (or another tool) scripts to validate a release? It would likely be similar to TCK, but unlike TCK anybody could run it. > Matt Jacek
Re: Geronimo 2.0
I'll summarize what I think I read. HEAD will be 2.0 which includes JEE 5 and other significant work (Maven 2 conversion, etc.) Branches/1.0 will be where the work for 1.0.x will take place. It would be from this code base we'd branch to a 1.1 when appropriate. I'm updating my local copy of the branches/1.0 with a version change for Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15 and Jetty 5.1.10 to incoroporate the latent fixes. I'll build and test to make sure its still working (I'm not going to run TCK). and then commit these changes back when I've confirmed we're ready to go for 1.0.1. Does this sound workable? Matt Jacek Laskowski wrote: 2006/1/6, John Sisson <[EMAIL PROTECTED]>: I agree we don't want too many branches. Hi John, Well, we should get used to them ;) Especially when Java EE 5 work takes off. I think there will be more refactorings than ever before. It's going to be lots of fun (sarcasm). Will fixes for the 1.0.1 release (hopefully we can get out in a few weeks) be committed to the 1.0 branch and then we create another tag for the 1.0.1 release? I'm not too familiar with svn branching/tagging stuff, but AFAIK they're just copies of the HEAD. If so, only the disk space limits us (which is not the case yet). So, if a need to fix something shows up, we will likely have to apply it to HEAD and branch, be it 1.0.1 or 1.1 depending on its value/importance. Do we have any guesstimates on when we would have JEE 5 development completed? I'm pretty sure we don't. Why would that be beneficial? How long it will be before we can deliver a release with some innovations in it, since we previously agreed we want to release frequently? I think we should stick with the 3-months period for small releases (like 1.0.1) and 6-months period for larger ones (like 1.1) or even the most important (like 2.0, 3.0). That could be our goal, and the time will show how we go ;) If this is going to be a while then we should discuss the work that is planned for the near future and whether there are enhancements that can be delivered in a releases before JEE 5, and if so, how that could be managed. Well, we don't have to wait till JEE 5 development is announced. You/anybody can start his/their work on a branch and merge it with the HEAD when completed. Of course, the more talk about it the better. That's my understanding of how it could (ought to?) work. Could some of the planned enhancements impact the stability of head development and therefore should be done in a branch? E.G. would we have stability problems doing JEE 5 development, re-arch of security, maven 1 to maven 2 migration, xbean support, corba impl etc. all in head? Yes, after having it completed and heavily tested on a branch. The views are indeed mine and I would appreciate any comments on it John Jacek
Re: Geronimo 2.0
I think that doing new development on the HEAD is the way to go, i.e. 2.0 development should happen here. Then what goes on the 1.x branch (es) is maintenance and bug fixing. This will certainly serve to stabilize (and perhaps even stall) development on 1.x; but that is not a bad thing. Users will experience that 1.x releases are "more compatible" in many ways because all the creative big changes happen elsewhere. Kresten Krab Thorup [EMAIL PROTECTED] On Jan 6, 2006, at 1:28 AM, Alan D. Cabrera wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruce Snyder wrote, On 1/5/2006 4:26 PM: On 1/5/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: How do we want to stage this effort in terms of SVN organization? When should we cut a 2.0 development branch? I suppose that the JEE 5 work would be best suited to a 2.0 branch. That means that there is a potential to have to do a lot of double work. What I mean to say is that any new innovations being committed to the HEAD will need to be refactored and committed to the 2.0 branch. And this work will increase more with the addition of more branches (e.g., 1.1, 1.2, etc.). You touched on the concern that I had. I'm thinking that once we cut this, there will be no further work on 1.x, because everyone will want to work on 2.x. Then we should probably consider making a decision that the HEAD should contain 2.x work only. If any fixes need to be done to the 1.x code then proper branching and tagging should occur to facilitate that work. Good point. What do others think? Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDvbmY1xC6qnMLUpYRAsEZAJ4hKUKXBCTxkTQfPMXGOr3w1LswAQCbBtpt 0ThTQUdCzTdCaaapV71OgZ8= =L4zh -END PGP SIGNATURE- smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part
Re: Geronimo 2.0
2006/1/6, John Sisson <[EMAIL PROTECTED]>: > I agree we don't want too many branches. Hi John, Well, we should get used to them ;) Especially when Java EE 5 work takes off. I think there will be more refactorings than ever before. It's going to be lots of fun (sarcasm). > Will fixes for the 1.0.1 release (hopefully we can get out in a few > weeks) be committed to the 1.0 branch and then we create another tag for > the 1.0.1 release? I'm not too familiar with svn branching/tagging stuff, but AFAIK they're just copies of the HEAD. If so, only the disk space limits us (which is not the case yet). So, if a need to fix something shows up, we will likely have to apply it to HEAD and branch, be it 1.0.1 or 1.1 depending on its value/importance. > Do we have any guesstimates on when we would have JEE 5 development > completed? I'm pretty sure we don't. Why would that be beneficial? > How long it will be before we can deliver a release with some > innovations in it, since we previously agreed we want to release > frequently? I think we should stick with the 3-months period for small releases (like 1.0.1) and 6-months period for larger ones (like 1.1) or even the most important (like 2.0, 3.0). That could be our goal, and the time will show how we go ;) > If this is going to be a while then we should discuss the work that is > planned for the near future and whether there are enhancements that can > be delivered in a releases before JEE 5, and if so, how that could be > managed. Well, we don't have to wait till JEE 5 development is announced. You/anybody can start his/their work on a branch and merge it with the HEAD when completed. Of course, the more talk about it the better. That's my understanding of how it could (ought to?) work. > Could some of the planned enhancements impact the stability of head > development and therefore should be done in a branch? E.G. would we have > stability problems doing JEE 5 development, re-arch of security, maven 1 > to maven 2 migration, xbean support, corba impl etc. all in head? Yes, after having it completed and heavily tested on a branch. The views are indeed mine and I would appreciate any comments on it > John Jacek
Re: Geronimo 2.0
2006/1/6, Alan D. Cabrera <[EMAIL PROTECTED]>: > Bruce Snyder wrote, On 1/5/2006 4:26 PM: > > Then we should probably consider making a decision that the HEAD > > should contain 2.x work only. If any fixes need to be done to the 1.x > > code then proper branching and tagging should occur to facilitate that > > work. > > Good point. What do others think? Hi, That's exactly what I had already proposed in my previous response. There's no need to complicate things unless some need arises. I remember when Alan stated that patches will be applied to a branch and would eventually end up as 1.0.1 or 1.1 and on. I think HEAD should always reflect the state of the main releases of Apache Geronimo, i.e. Apache Geronimo 2.0, 3.0 and on. The numbers after the dots would be in branches. > Alan Jacek
Re: Geronimo 2.0
Bruce Snyder wrote:
On 1/5/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
How do we want to stage this effort in terms of SVN organization? When
should we cut a 2.0 development branch?
I suppose that the JEE 5 work would be best suited to a 2.0 branch.
That means that there is a potential to have to do a lot of double
work. What I mean to say is that any new innovations being committed
to the HEAD will need to be refactored and committed to the 2.0
branch. And this work will increase more with the addition of more
branches (e.g., 1.1, 1.2, etc.).
You touched on the concern that I had. I'm thinking that once we cut
this, there will be no further work on 1.x, because everyone will want
to work on 2.x.
Then we should probably consider making a decision that the HEAD
should contain 2.x work only. If any fixes need to be done to the 1.x
code then proper branching and tagging should occur to facilitate that
work.
I agree we don't want too many branches.
Will fixes for the 1.0.1 release (hopefully we can get out in a few
weeks) be committed to the 1.0 branch and then we create another tag for
the 1.0.1 release?
My thoughts..
Do we have any guesstimates on when we would have JEE 5 development
completed?
How long it will be before we can deliver a release with some
innovations in it, since we previously agreed we want to release
frequently?
If this is going to be a while then we should discuss the work that is
planned for the near future and whether there are enhancements that can
be delivered in a releases before JEE 5, and if so, how that could be
managed.
Could some of the planned enhancements impact the stability of head
development and therefore should be done in a branch? E.G. would we have
stability problems doing JEE 5 development, re-arch of security, maven 1
to maven 2 migration, xbean support, corba impl etc. all in head?
John
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)
Re: Geronimo 2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruce Snyder wrote, On 1/5/2006 4:26 PM: > On 1/5/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > > How do we want to stage this effort in terms of SVN organization? When should we cut a 2.0 development branch? >>> >>> >>>I suppose that the JEE 5 work would be best suited to a 2.0 branch. >>>That means that there is a potential to have to do a lot of double >>>work. What I mean to say is that any new innovations being committed >>>to the HEAD will need to be refactored and committed to the 2.0 >>>branch. And this work will increase more with the addition of more >>>branches (e.g., 1.1, 1.2, etc.). >> >>You touched on the concern that I had. I'm thinking that once we cut >>this, there will be no further work on 1.x, because everyone will want >>to work on 2.x. > > > Then we should probably consider making a decision that the HEAD > should contain 2.x work only. If any fixes need to be done to the 1.x > code then proper branching and tagging should occur to facilitate that > work. Good point. What do others think? Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDvbmY1xC6qnMLUpYRAsEZAJ4hKUKXBCTxkTQfPMXGOr3w1LswAQCbBtpt 0ThTQUdCzTdCaaapV71OgZ8= =L4zh -END PGP SIGNATURE-
Re: Geronimo 2.0
On 1/5/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
> >>How do we want to stage this effort in terms of SVN organization? When
> >>should we cut a 2.0 development branch?
> >
> >
> > I suppose that the JEE 5 work would be best suited to a 2.0 branch.
> > That means that there is a potential to have to do a lot of double
> > work. What I mean to say is that any new innovations being committed
> > to the HEAD will need to be refactored and committed to the 2.0
> > branch. And this work will increase more with the addition of more
> > branches (e.g., 1.1, 1.2, etc.).
>
> You touched on the concern that I had. I'm thinking that once we cut
> this, there will be no further work on 1.x, because everyone will want
> to work on 2.x.
Then we should probably consider making a decision that the HEAD
should contain 2.x work only. If any fixes need to be done to the 1.x
code then proper branching and tagging should occur to facilitate that
work.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)
Re: Geronimo 2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruce Snyder wrote, On 1/5/2006 3:43 PM: > On 1/5/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > > >>It's my understading that we're going for JEE 5. I think that our >>re-arch of security should go into that as well. > > > Agreed. > > >>How do we want to stage this effort in terms of SVN organization? When >>should we cut a 2.0 development branch? > > > I suppose that the JEE 5 work would be best suited to a 2.0 branch. > That means that there is a potential to have to do a lot of double > work. What I mean to say is that any new innovations being committed > to the HEAD will need to be refactored and committed to the 2.0 > branch. And this work will increase more with the addition of more > branches (e.g., 1.1, 1.2, etc.). You touched on the concern that I had. I'm thinking that once we cut this, there will be no further work on 1.x, because everyone will want to work on 2.x. Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDvba11xC6qnMLUpYRAuAEAJ9c0uQDLeGgIzcqqR/iKv2l99QC5wCdGhVB foYWLFogfXXWxoMY/OEXtI8= =zGE8 -END PGP SIGNATURE-
Re: Geronimo 2.0
On 1/5/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
> It's my understading that we're going for JEE 5. I think that our
> re-arch of security should go into that as well.
Agreed.
> How do we want to stage this effort in terms of SVN organization? When
> should we cut a 2.0 development branch?
I suppose that the JEE 5 work would be best suited to a 2.0 branch.
That means that there is a potential to have to do a lot of double
work. What I mean to say is that any new innovations being committed
to the HEAD will need to be refactored and committed to the 2.0
branch. And this work will increase more with the addition of more
branches (e.g., 1.1, 1.2, etc.).
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)
Re: Geronimo 2.0
2006/1/5, Alan D. Cabrera <[EMAIL PROTECTED]>: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > It's my understading that we're going for JEE 5. I think that our > re-arch of security should go into that as well. > > How do we want to stage this effort in terms of SVN organization? When > should we cut a 2.0 development branch? Hi Alan, I think there's no point holding it any longer. Since the 1.0 release is on its own branch, we can safely change all of the build artefacts to 2.0-SNAPSHOT. > Alan Jacek
Re: Geronimo 2.0
+1...I really like this idea. Alan D. Cabrera wrote: > It's my understading that we're going for JEE 5. I think that our > re-arch of security should go into that as well. > > How do we want to stage this effort in terms of SVN organization? When > should we cut a 2.0 development branch? > > > Regards, > Alan >
