You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2005/10/05 05:24:04 UTC
What do we do about fixable problems in M5?
Stefan Schmidt has found our first configuration problem in M5, namely
that the listener name in the ejb builder in config.tomcat.xml points
half to tomcat and half to jetty. This is easy to fix by hand (change
JettyWebContainer to TomcatWebContainer). However I doubt we want to
rerelease M5 to fix this. What do we want to do about issues like
this? One possibility is to have an "errata" page clearly linked from
the download page. There must be some other possibilities, any ideas?
thanks
david jencks
Re: What do we do about fixable problems in M5?
Posted by anita kulshreshtha <a_...@yahoo.com>.
I apologize for being so sloppy today. :-( I do see
config.xml.bak in the zip distribution.
--- anita kulshreshtha <a_...@yahoo.com> wrote:
> Never mind, it is being created later.
>
> Thanks
> Anita
>
> --- anita kulshreshtha <a_...@yahoo.com> wrote:
>
> >
> >
> > --- "Geir Magnusson Jr." <ge...@apache.org> wrote:
> >
> > >
> > > On Oct 5, 2005, at 11:29 AM, Joe Bohn wrote:
> > >
> > > >
> > > >
> > > > Geir Magnusson Jr. wrote:
> > > >
> > > >> On Oct 5, 2005, at 11:01 AM, Joe Bohn wrote:
> > > >>
> > > >>> I think there's two different types of
> > problems
> > > here that are
> > > >>> being confused.
> > > >>>
> > > >>> The first is a few configuration issues with
> > the
> > > zip image that
> > > >>> Stefan (in the tomcat config.xml) and Matt
> > (with
> > > the TranQL and
> > > >>> DB2) have discovered. There may be more of
> > > these but these
> > > >>> types of issues that arise but they are
> *not*
> > > issues which 100%
> > > >>> of customers will hit. For these types of
> > > problems I think that
> > > >>> an errata on the download page should
> suffice
> > > (with individual
> > > >>> replacement modules and directions).
> >
> > In geronimo-1.0-M5.zip I see a
> > config.xml.bak!
> > This issue will not affect anyone one.
> >
> > Thanks
> > Anita
> >
> >
> > > >>>
> > > >>> The second is another issue that Stefan
> > > discovered which
> > > >>> involves the installer. This is the type
> of
> > > thing that can
> > > >>> affect a lot of users and may be something
> > that
> > > would cause us
> > > >>> to create an M6. However, since the
> > installer
> > > is itself a
> > > >>> unique download do we really have to build
> > > another M6 to replace
> > > >>> it? Can't we just build a new installer
> off
> > > the M5 image with
> > > >>> changes to the installer alone that should
> > not
> > > affect the TCK
> > > >>> results? If possible I think this would be
> a
> > > better solution
> > > >>> than dropping it completely from M5.
> > > >>>
> > > >> I don't think we're advocating dropping it -
> > just
> > > redoing it...
> > > >>
> > > >
> > > > I meant potentially dropping it from M5 (as
> > Kevan
> > > alluded to) ...
> > > > not from history. :-)
> > > >
> > > >
> > > >>>
> > > >>> Another idea would be to just add some very
> > "in
> > > your face"
> > > >>> statements around the download link for the
> > > installer itself.
> > > >>> Does Apache regulate what you can and
> cannot
> > > include on the
> > > >>> download page?
> > > >>>
> > > >>>
> > > >> The geronimo download page is governed by the
> > > project. How "in
> > > >> your face" are you thinking here?
> > > >> Probably don't want "If you use this, your
> > > (@!#@!@-ed, and if you
> > > >> don't like it, you can go *(@#!@*@!#)!@#"
> > > >> :D
> > > >>
> > > >
> > > > I wasn't thinking that kind of "in your face"
> > :-)
> > > Rather,
> > > > something along the lines of:
> > > > %link% this is an executable JAR, so install
> > it
> > > using java -jar
> > > > geronimo-1.0-M5-installer.jar.
> > > > WARNING: If no selections are made in the
> > > installation both
> > > > containers will be included with common
> > > (colliding) port numbers.
> > > > It is recommended that you choose either
> > > Tomcat-only, Jetty-only,
> > > > or explicitly specify the ports for each
> > > container.
> > >
> > > Sure! That's easy. But isn't there another
> > problem
> > > w/ the
> > > installer? Can we put the additional errata
> > there?
> > >
> > > geir
> > >
> > > >
> > > >
> > > >> geir
> > > >>
> > > >>> Joe
> > > >>>
> > > >>> Kevan Miller wrote:
> > > >>>
> > > >>>
> > > >>>> Without a really big disclaimer on the
> > download
> > > page, my guess
> > > >>>> is that approximately 100% of
> > new-to-Geronimo
> > > M5 Installer
> > > >>>> users will run into this problem. All you
> > have
> > > to do is keep
> > > >>>> hitting "Next". I did. I just never
> started
> > my
> > > "installed"
> > > >>>> server, because I'd already tested the
> > > zipped/tarred version of
> > > >>>> code (my mistake).
> > > >>>> I don't think an errata is sufficient and I
> > > don't see how we
> > > >>>> can ignore such a visible issue. This may
> be
> > a
> > > bit heretical,
> > > >>>> but one option is not to release the
> > > installer. Although this
> > > >>>> is a server issue, you don't hit this
> > problem
> > > in normal usage
> > > >>>> when running from an zip/tar "install" (at
> > > least I haven't run
> > > >>>> into any other problems, am I missing
> > > something?).
> > > >>>> Most first-time users will choose the
> install
> > > download thinking
> > > >>>> they're making their lives easier, when
> > > actually, they've just
> > > >>>> made their lives more difficult. Although
> > some
> > > last-minute hard
> > > >>>> work went into the installer, IMO, the M5
> > > installer is of
> > > >>>> limited value for first-time Geronimo
> users.
> > I
> > > also think that
> > > >>>> the current installer is actually a
> > > configuration utility in
> > > >>>> disguise -- we should start separating
> > > concerns...
> > > >>>> BTW, I assume that actually fixing the
> > > underlying problem means
> > > >>>> rerunning the TCK tests? Thus the reticence
> > for
> > > fixing?
> > > >>>> --kevan
> > > >>>> On 10/5/05, *Geir Magnusson Jr.*
> > > <geirm@apache.org
> > > >>>> <ma...@apache.org>> wrote:
> > > >>>> On Oct 5, 2005, at 8:30 AM, Matt
> Hogstrom
>
=== message truncated ===
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
Re: What do we do about fixable problems in M5?
Posted by anita kulshreshtha <a_...@yahoo.com>.
Never mind, it is being created later.
Thanks
Anita
--- anita kulshreshtha <a_...@yahoo.com> wrote:
>
>
> --- "Geir Magnusson Jr." <ge...@apache.org> wrote:
>
> >
> > On Oct 5, 2005, at 11:29 AM, Joe Bohn wrote:
> >
> > >
> > >
> > > Geir Magnusson Jr. wrote:
> > >
> > >> On Oct 5, 2005, at 11:01 AM, Joe Bohn wrote:
> > >>
> > >>> I think there's two different types of
> problems
> > here that are
> > >>> being confused.
> > >>>
> > >>> The first is a few configuration issues with
> the
> > zip image that
> > >>> Stefan (in the tomcat config.xml) and Matt
> (with
> > the TranQL and
> > >>> DB2) have discovered. There may be more of
> > these but these
> > >>> types of issues that arise but they are *not*
> > issues which 100%
> > >>> of customers will hit. For these types of
> > problems I think that
> > >>> an errata on the download page should suffice
> > (with individual
> > >>> replacement modules and directions).
>
> In geronimo-1.0-M5.zip I see a
> config.xml.bak!
> This issue will not affect anyone one.
>
> Thanks
> Anita
>
>
> > >>>
> > >>> The second is another issue that Stefan
> > discovered which
> > >>> involves the installer. This is the type of
> > thing that can
> > >>> affect a lot of users and may be something
> that
> > would cause us
> > >>> to create an M6. However, since the
> installer
> > is itself a
> > >>> unique download do we really have to build
> > another M6 to replace
> > >>> it? Can't we just build a new installer off
> > the M5 image with
> > >>> changes to the installer alone that should
> not
> > affect the TCK
> > >>> results? If possible I think this would be a
> > better solution
> > >>> than dropping it completely from M5.
> > >>>
> > >> I don't think we're advocating dropping it -
> just
> > redoing it...
> > >>
> > >
> > > I meant potentially dropping it from M5 (as
> Kevan
> > alluded to) ...
> > > not from history. :-)
> > >
> > >
> > >>>
> > >>> Another idea would be to just add some very
> "in
> > your face"
> > >>> statements around the download link for the
> > installer itself.
> > >>> Does Apache regulate what you can and cannot
> > include on the
> > >>> download page?
> > >>>
> > >>>
> > >> The geronimo download page is governed by the
> > project. How "in
> > >> your face" are you thinking here?
> > >> Probably don't want "If you use this, your
> > (@!#@!@-ed, and if you
> > >> don't like it, you can go *(@#!@*@!#)!@#"
> > >> :D
> > >>
> > >
> > > I wasn't thinking that kind of "in your face"
> :-)
> > Rather,
> > > something along the lines of:
> > > %link% this is an executable JAR, so install
> it
> > using java -jar
> > > geronimo-1.0-M5-installer.jar.
> > > WARNING: If no selections are made in the
> > installation both
> > > containers will be included with common
> > (colliding) port numbers.
> > > It is recommended that you choose either
> > Tomcat-only, Jetty-only,
> > > or explicitly specify the ports for each
> > container.
> >
> > Sure! That's easy. But isn't there another
> problem
> > w/ the
> > installer? Can we put the additional errata
> there?
> >
> > geir
> >
> > >
> > >
> > >> geir
> > >>
> > >>> Joe
> > >>>
> > >>> Kevan Miller wrote:
> > >>>
> > >>>
> > >>>> Without a really big disclaimer on the
> download
> > page, my guess
> > >>>> is that approximately 100% of
> new-to-Geronimo
> > M5 Installer
> > >>>> users will run into this problem. All you
> have
> > to do is keep
> > >>>> hitting "Next". I did. I just never started
> my
> > "installed"
> > >>>> server, because I'd already tested the
> > zipped/tarred version of
> > >>>> code (my mistake).
> > >>>> I don't think an errata is sufficient and I
> > don't see how we
> > >>>> can ignore such a visible issue. This may be
> a
> > bit heretical,
> > >>>> but one option is not to release the
> > installer. Although this
> > >>>> is a server issue, you don't hit this
> problem
> > in normal usage
> > >>>> when running from an zip/tar "install" (at
> > least I haven't run
> > >>>> into any other problems, am I missing
> > something?).
> > >>>> Most first-time users will choose the install
> > download thinking
> > >>>> they're making their lives easier, when
> > actually, they've just
> > >>>> made their lives more difficult. Although
> some
> > last-minute hard
> > >>>> work went into the installer, IMO, the M5
> > installer is of
> > >>>> limited value for first-time Geronimo users.
> I
> > also think that
> > >>>> the current installer is actually a
> > configuration utility in
> > >>>> disguise -- we should start separating
> > concerns...
> > >>>> BTW, I assume that actually fixing the
> > underlying problem means
> > >>>> rerunning the TCK tests? Thus the reticence
> for
> > fixing?
> > >>>> --kevan
> > >>>> On 10/5/05, *Geir Magnusson Jr.*
> > <geirm@apache.org
> > >>>> <ma...@apache.org>> wrote:
> > >>>> On Oct 5, 2005, at 8:30 AM, Matt Hogstrom
> > wrote:
> > >>>> > I think that will work but users won't
> > find Geronimo
> > >>>> incredibly
> > >>>> > useful if they have to pull a whole
> new
> > build to fix a
> > >>>> single
> > >>>> problem.
> > >>>> Which will work?
> > >>>> i think the errata is necessary so people
> > will know what to
> > >>>> do. As
> > >>>> for a quick M6? I think it depends on
> the
> > %-age of people
> > >>>> that will
>
=== message truncated ===
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
Re: What do we do about fixable problems in M5?
Posted by anita kulshreshtha <a_...@yahoo.com>.
--- "Geir Magnusson Jr." <ge...@apache.org> wrote:
>
> On Oct 5, 2005, at 11:29 AM, Joe Bohn wrote:
>
> >
> >
> > Geir Magnusson Jr. wrote:
> >
> >> On Oct 5, 2005, at 11:01 AM, Joe Bohn wrote:
> >>
> >>> I think there's two different types of problems
> here that are
> >>> being confused.
> >>>
> >>> The first is a few configuration issues with the
> zip image that
> >>> Stefan (in the tomcat config.xml) and Matt (with
> the TranQL and
> >>> DB2) have discovered. There may be more of
> these but these
> >>> types of issues that arise but they are *not*
> issues which 100%
> >>> of customers will hit. For these types of
> problems I think that
> >>> an errata on the download page should suffice
> (with individual
> >>> replacement modules and directions).
In geronimo-1.0-M5.zip I see a config.xml.bak!
This issue will not affect anyone one.
Thanks
Anita
> >>>
> >>> The second is another issue that Stefan
> discovered which
> >>> involves the installer. This is the type of
> thing that can
> >>> affect a lot of users and may be something that
> would cause us
> >>> to create an M6. However, since the installer
> is itself a
> >>> unique download do we really have to build
> another M6 to replace
> >>> it? Can't we just build a new installer off
> the M5 image with
> >>> changes to the installer alone that should not
> affect the TCK
> >>> results? If possible I think this would be a
> better solution
> >>> than dropping it completely from M5.
> >>>
> >> I don't think we're advocating dropping it - just
> redoing it...
> >>
> >
> > I meant potentially dropping it from M5 (as Kevan
> alluded to) ...
> > not from history. :-)
> >
> >
> >>>
> >>> Another idea would be to just add some very "in
> your face"
> >>> statements around the download link for the
> installer itself.
> >>> Does Apache regulate what you can and cannot
> include on the
> >>> download page?
> >>>
> >>>
> >> The geronimo download page is governed by the
> project. How "in
> >> your face" are you thinking here?
> >> Probably don't want "If you use this, your
> (@!#@!@-ed, and if you
> >> don't like it, you can go *(@#!@*@!#)!@#"
> >> :D
> >>
> >
> > I wasn't thinking that kind of "in your face" :-)
> Rather,
> > something along the lines of:
> > %link% this is an executable JAR, so install it
> using java -jar
> > geronimo-1.0-M5-installer.jar.
> > WARNING: If no selections are made in the
> installation both
> > containers will be included with common
> (colliding) port numbers.
> > It is recommended that you choose either
> Tomcat-only, Jetty-only,
> > or explicitly specify the ports for each
> container.
>
> Sure! That's easy. But isn't there another problem
> w/ the
> installer? Can we put the additional errata there?
>
> geir
>
> >
> >
> >> geir
> >>
> >>> Joe
> >>>
> >>> Kevan Miller wrote:
> >>>
> >>>
> >>>> Without a really big disclaimer on the download
> page, my guess
> >>>> is that approximately 100% of new-to-Geronimo
> M5 Installer
> >>>> users will run into this problem. All you have
> to do is keep
> >>>> hitting "Next". I did. I just never started my
> "installed"
> >>>> server, because I'd already tested the
> zipped/tarred version of
> >>>> code (my mistake).
> >>>> I don't think an errata is sufficient and I
> don't see how we
> >>>> can ignore such a visible issue. This may be a
> bit heretical,
> >>>> but one option is not to release the
> installer. Although this
> >>>> is a server issue, you don't hit this problem
> in normal usage
> >>>> when running from an zip/tar "install" (at
> least I haven't run
> >>>> into any other problems, am I missing
> something?).
> >>>> Most first-time users will choose the install
> download thinking
> >>>> they're making their lives easier, when
> actually, they've just
> >>>> made their lives more difficult. Although some
> last-minute hard
> >>>> work went into the installer, IMO, the M5
> installer is of
> >>>> limited value for first-time Geronimo users. I
> also think that
> >>>> the current installer is actually a
> configuration utility in
> >>>> disguise -- we should start separating
> concerns...
> >>>> BTW, I assume that actually fixing the
> underlying problem means
> >>>> rerunning the TCK tests? Thus the reticence for
> fixing?
> >>>> --kevan
> >>>> On 10/5/05, *Geir Magnusson Jr.*
> <geirm@apache.org
> >>>> <ma...@apache.org>> wrote:
> >>>> On Oct 5, 2005, at 8:30 AM, Matt Hogstrom
> wrote:
> >>>> > I think that will work but users won't
> find Geronimo
> >>>> incredibly
> >>>> > useful if they have to pull a whole new
> build to fix a
> >>>> single
> >>>> problem.
> >>>> Which will work?
> >>>> i think the errata is necessary so people
> will know what to
> >>>> do. As
> >>>> for a quick M6? I think it depends on the
> %-age of people
> >>>> that will
> >>>> hit the problem.
> >>>> > I discovered a similar problem in TranQL
> that the 1.1
> >>>> SNAPSHOT
> >>>> > doesn't generate the right SQL syntax
> for DB2 and had to
> >>>> tweak the
> >>>> > Syntax Generator. So the option going
> forward is for
> >>>> someone to
> >>>> > pull TranQL 1.2-SNAPSHOT which wil most
> likely break
> >>>> their build
> >>>> > too because of the serialization problem
> (probably not
> >>>> likely with
> >>>> > my example but a high probability for
> other types of fixes).
> >>>> Does this mean as of now, we have a problem
> w/ DB2?
> >>>> >
> >>>> > Sachin had the right idea of
> highlighting the issues with
> >>>> > serialVersionUIDs but that was part of a
> larger
> >>>> problem. I'll open
> >>>> > a feature JIRA that focuses on improved
> serviceability
> >>>> which would
> >>>> > encompass these recurring issues and
> we'll look for
> >>>> someone to step
> >>>> > up to the plate and put a strategy
> together.
> >>>> >
> >>>> yes, I think that's a different (but very
> important) issue
>
=== message truncated ===
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
Re: What do we do about fixable problems in M5?
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Oct 5, 2005, at 11:29 AM, Joe Bohn wrote:
>
>
> Geir Magnusson Jr. wrote:
>
>> On Oct 5, 2005, at 11:01 AM, Joe Bohn wrote:
>>
>>> I think there's two different types of problems here that are
>>> being confused.
>>>
>>> The first is a few configuration issues with the zip image that
>>> Stefan (in the tomcat config.xml) and Matt (with the TranQL and
>>> DB2) have discovered. There may be more of these but these
>>> types of issues that arise but they are *not* issues which 100%
>>> of customers will hit. For these types of problems I think that
>>> an errata on the download page should suffice (with individual
>>> replacement modules and directions).
>>>
>>> The second is another issue that Stefan discovered which
>>> involves the installer. This is the type of thing that can
>>> affect a lot of users and may be something that would cause us
>>> to create an M6. However, since the installer is itself a
>>> unique download do we really have to build another M6 to replace
>>> it? Can't we just build a new installer off the M5 image with
>>> changes to the installer alone that should not affect the TCK
>>> results? If possible I think this would be a better solution
>>> than dropping it completely from M5.
>>>
>> I don't think we're advocating dropping it - just redoing it...
>>
>
> I meant potentially dropping it from M5 (as Kevan alluded to) ...
> not from history. :-)
>
>
>>>
>>> Another idea would be to just add some very "in your face"
>>> statements around the download link for the installer itself.
>>> Does Apache regulate what you can and cannot include on the
>>> download page?
>>>
>>>
>> The geronimo download page is governed by the project. How "in
>> your face" are you thinking here?
>> Probably don't want "If you use this, your (@!#@!@-ed, and if you
>> don't like it, you can go *(@#!@*@!#)!@#"
>> :D
>>
>
> I wasn't thinking that kind of "in your face" :-) Rather,
> something along the lines of:
> %link% this is an executable JAR, so install it using java -jar
> geronimo-1.0-M5-installer.jar.
> WARNING: If no selections are made in the installation both
> containers will be included with common (colliding) port numbers.
> It is recommended that you choose either Tomcat-only, Jetty-only,
> or explicitly specify the ports for each container.
Sure! That's easy. But isn't there another problem w/ the
installer? Can we put the additional errata there?
geir
>
>
>> geir
>>
>>> Joe
>>>
>>> Kevan Miller wrote:
>>>
>>>
>>>> Without a really big disclaimer on the download page, my guess
>>>> is that approximately 100% of new-to-Geronimo M5 Installer
>>>> users will run into this problem. All you have to do is keep
>>>> hitting "Next". I did. I just never started my "installed"
>>>> server, because I'd already tested the zipped/tarred version of
>>>> code (my mistake).
>>>> I don't think an errata is sufficient and I don't see how we
>>>> can ignore such a visible issue. This may be a bit heretical,
>>>> but one option is not to release the installer. Although this
>>>> is a server issue, you don't hit this problem in normal usage
>>>> when running from an zip/tar "install" (at least I haven't run
>>>> into any other problems, am I missing something?).
>>>> Most first-time users will choose the install download thinking
>>>> they're making their lives easier, when actually, they've just
>>>> made their lives more difficult. Although some last-minute hard
>>>> work went into the installer, IMO, the M5 installer is of
>>>> limited value for first-time Geronimo users. I also think that
>>>> the current installer is actually a configuration utility in
>>>> disguise -- we should start separating concerns...
>>>> BTW, I assume that actually fixing the underlying problem means
>>>> rerunning the TCK tests? Thus the reticence for fixing?
>>>> --kevan
>>>> On 10/5/05, *Geir Magnusson Jr.* <geirm@apache.org
>>>> <ma...@apache.org>> wrote:
>>>> On Oct 5, 2005, at 8:30 AM, Matt Hogstrom wrote:
>>>> > I think that will work but users won't find Geronimo
>>>> incredibly
>>>> > useful if they have to pull a whole new build to fix a
>>>> single
>>>> problem.
>>>> Which will work?
>>>> i think the errata is necessary so people will know what to
>>>> do. As
>>>> for a quick M6? I think it depends on the %-age of people
>>>> that will
>>>> hit the problem.
>>>> > I discovered a similar problem in TranQL that the 1.1
>>>> SNAPSHOT
>>>> > doesn't generate the right SQL syntax for DB2 and had to
>>>> tweak the
>>>> > Syntax Generator. So the option going forward is for
>>>> someone to
>>>> > pull TranQL 1.2-SNAPSHOT which wil most likely break
>>>> their build
>>>> > too because of the serialization problem (probably not
>>>> likely with
>>>> > my example but a high probability for other types of fixes).
>>>> Does this mean as of now, we have a problem w/ DB2?
>>>> >
>>>> > Sachin had the right idea of highlighting the issues with
>>>> > serialVersionUIDs but that was part of a larger
>>>> problem. I'll open
>>>> > a feature JIRA that focuses on improved serviceability
>>>> which would
>>>> > encompass these recurring issues and we'll look for
>>>> someone to step
>>>> > up to the plate and put a strategy together.
>>>> >
>>>> yes, I think that's a different (but very important) issue
>>>> altogether.
>>>> > Thoughts?
>>>> >
>>>> Go man, go...
>>>> > - Matt
>>>> >
>>>> > Geir Magnusson Jr. wrote:
>>>> >
>>>> >> On Oct 4, 2005, at 11:24 PM, David Jencks wrote:
>>>> >>
>>>> >>> Stefan Schmidt has found our first configuration
>>>> problem in M5,
>>>> >>> namely that the listener name in the ejb builder in
>>>> >>> config.tomcat.xml points half to tomcat and half to
>>>> jetty. This
>>>> >>> is easy to fix by hand (change JettyWebContainer to
>>>> >>> TomcatWebContainer). However I doubt we want to
>>>> rerelease M5 to
>>>> >>> fix this. What do we want to do about issues like
>>>> this? One
>>>> >>> possibility is to have an "errata" page clearly linked
>>>> from the
>>>> >>> download page.
>>>> >>>
>>>> >> That's a great idea.
>>>> >>
>>>> >>> There must be some other possibilities, any ideas?
>>>> >>>
>>>> >> 1) Can we capture this as some kind of functional test
>>>> to prevent
>>>> >> from happening again?
>>>> >> 2) how long would it take to fix on branch/m5 (and
>>>> head) and do a
>>>> >> M6 tag off of branch/m5 (if people don't find that too
>>>> >> nauseating) and release that?
>>>> >> geir
>>>> >>
>>>> >
>>>> >
>>>> --
>>>> Geir Magnusson Jr
>>>> +1-203-665-6437
>>>> geirm@apache.org <ma...@apache.org>
>>>>
>>>>
>>>
>>> --
>>> Joe Bohn
>>> joe.bohn@earthlink.net
>>>
>>> "He is no fool who gives what he cannot keep, to gain what he
>>> cannot lose." -- Jim Elliot
>>>
>>>
>>>
>
> --
> Joe Bohn
> joe.bohn@earthlink.net
>
> "He is no fool who gives what he cannot keep, to gain what he
> cannot lose." -- Jim Elliot
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: What do we do about fixable problems in M5?
Posted by Joe Bohn <jo...@earthlink.net>.
Geir Magnusson Jr. wrote:
>
> On Oct 5, 2005, at 11:01 AM, Joe Bohn wrote:
>
>> I think there's two different types of problems here that are being
>> confused.
>>
>> The first is a few configuration issues with the zip image that
>> Stefan (in the tomcat config.xml) and Matt (with the TranQL and DB2)
>> have discovered. There may be more of these but these types of
>> issues that arise but they are *not* issues which 100% of customers
>> will hit. For these types of problems I think that an errata on the
>> download page should suffice (with individual replacement modules and
>> directions).
>>
>> The second is another issue that Stefan discovered which involves the
>> installer. This is the type of thing that can affect a lot of users
>> and may be something that would cause us to create an M6. However,
>> since the installer is itself a unique download do we really have to
>> build another M6 to replace it? Can't we just build a new installer
>> off the M5 image with changes to the installer alone that should not
>> affect the TCK results? If possible I think this would be a better
>> solution than dropping it completely from M5.
>
>
> I don't think we're advocating dropping it - just redoing it...
I meant potentially dropping it from M5 (as Kevan alluded to) ... not
from history. :-)
>
>>
>> Another idea would be to just add some very "in your face" statements
>> around the download link for the installer itself. Does Apache
>> regulate what you can and cannot include on the download page?
>>
>
> The geronimo download page is governed by the project. How "in your
> face" are you thinking here?
>
> Probably don't want "If you use this, your (@!#@!@-ed, and if you don't
> like it, you can go *(@#!@*@!#)!@#"
>
> :D
I wasn't thinking that kind of "in your face" :-) Rather, something
along the lines of:
%link% this is an executable JAR, so install it using java -jar
geronimo-1.0-M5-installer.jar.
WARNING: If no selections are made in the installation both containers
will be included with common (colliding) port numbers. It is recommended
that you choose either Tomcat-only, Jetty-only, or explicitly specify
the ports for each container.
>
> geir
>
>
>> Joe
>>
>> Kevan Miller wrote:
>>
>>> Without a really big disclaimer on the download page, my guess is
>>> that approximately 100% of new-to-Geronimo M5 Installer users will
>>> run into this problem. All you have to do is keep hitting "Next". I
>>> did. I just never started my "installed" server, because I'd already
>>> tested the zipped/tarred version of code (my mistake).
>>> I don't think an errata is sufficient and I don't see how we can
>>> ignore such a visible issue. This may be a bit heretical, but one
>>> option is not to release the installer. Although this is a server
>>> issue, you don't hit this problem in normal usage when running from
>>> an zip/tar "install" (at least I haven't run into any other
>>> problems, am I missing something?).
>>> Most first-time users will choose the install download thinking
>>> they're making their lives easier, when actually, they've just made
>>> their lives more difficult. Although some last-minute hard work went
>>> into the installer, IMO, the M5 installer is of limited value for
>>> first-time Geronimo users. I also think that the current installer
>>> is actually a configuration utility in disguise -- we should start
>>> separating concerns...
>>> BTW, I assume that actually fixing the underlying problem means
>>> rerunning the TCK tests? Thus the reticence for fixing?
>>> --kevan
>>> On 10/5/05, *Geir Magnusson Jr.* <geirm@apache.org
>>> <ma...@apache.org>> wrote:
>>> On Oct 5, 2005, at 8:30 AM, Matt Hogstrom wrote:
>>> > I think that will work but users won't find Geronimo incredibly
>>> > useful if they have to pull a whole new build to fix a single
>>> problem.
>>> Which will work?
>>> i think the errata is necessary so people will know what to do. As
>>> for a quick M6? I think it depends on the %-age of people that
>>> will
>>> hit the problem.
>>> > I discovered a similar problem in TranQL that the 1.1 SNAPSHOT
>>> > doesn't generate the right SQL syntax for DB2 and had to
>>> tweak the
>>> > Syntax Generator. So the option going forward is for someone to
>>> > pull TranQL 1.2-SNAPSHOT which wil most likely break their build
>>> > too because of the serialization problem (probably not likely
>>> with
>>> > my example but a high probability for other types of fixes).
>>> Does this mean as of now, we have a problem w/ DB2?
>>> >
>>> > Sachin had the right idea of highlighting the issues with
>>> > serialVersionUIDs but that was part of a larger problem.
>>> I'll open
>>> > a feature JIRA that focuses on improved serviceability which
>>> would
>>> > encompass these recurring issues and we'll look for someone
>>> to step
>>> > up to the plate and put a strategy together.
>>> >
>>> yes, I think that's a different (but very important) issue
>>> altogether.
>>> > Thoughts?
>>> >
>>> Go man, go...
>>> > - Matt
>>> >
>>> > Geir Magnusson Jr. wrote:
>>> >
>>> >> On Oct 4, 2005, at 11:24 PM, David Jencks wrote:
>>> >>
>>> >>> Stefan Schmidt has found our first configuration problem in
>>> M5,
>>> >>> namely that the listener name in the ejb builder in
>>> >>> config.tomcat.xml points half to tomcat and half to jetty.
>>> This
>>> >>> is easy to fix by hand (change JettyWebContainer to
>>> >>> TomcatWebContainer). However I doubt we want to rerelease
>>> M5 to
>>> >>> fix this. What do we want to do about issues like this? One
>>> >>> possibility is to have an "errata" page clearly linked from
>>> the
>>> >>> download page.
>>> >>>
>>> >> That's a great idea.
>>> >>
>>> >>> There must be some other possibilities, any ideas?
>>> >>>
>>> >> 1) Can we capture this as some kind of functional test to
>>> prevent
>>> >> from happening again?
>>> >> 2) how long would it take to fix on branch/m5 (and head) and
>>> do a
>>> >> M6 tag off of branch/m5 (if people don't find that too
>>> >> nauseating) and release that?
>>> >> geir
>>> >>
>>> >
>>> >
>>> --
>>> Geir Magnusson Jr +1-203-665-6437
>>> geirm@apache.org <ma...@apache.org>
>>>
>>
>> --
>> Joe Bohn
>> joe.bohn@earthlink.net
>>
>> "He is no fool who gives what he cannot keep, to gain what he cannot
>> lose." -- Jim Elliot
>>
>>
>
--
Joe Bohn
joe.bohn@earthlink.net
"He is no fool who gives what he cannot keep, to gain what he cannot
lose." -- Jim Elliot
Re: What do we do about fixable problems in M5?
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Oct 5, 2005, at 11:01 AM, Joe Bohn wrote:
> I think there's two different types of problems here that are being
> confused.
>
> The first is a few configuration issues with the zip image that
> Stefan (in the tomcat config.xml) and Matt (with the TranQL and
> DB2) have discovered. There may be more of these but these types
> of issues that arise but they are *not* issues which 100% of
> customers will hit. For these types of problems I think that an
> errata on the download page should suffice (with individual
> replacement modules and directions).
>
> The second is another issue that Stefan discovered which involves
> the installer. This is the type of thing that can affect a lot of
> users and may be something that would cause us to create an M6.
> However, since the installer is itself a unique download do we
> really have to build another M6 to replace it? Can't we just build
> a new installer off the M5 image with changes to the installer
> alone that should not affect the TCK results? If possible I think
> this would be a better solution than dropping it completely from M5.
I don't think we're advocating dropping it - just redoing it...
>
> Another idea would be to just add some very "in your face"
> statements around the download link for the installer itself. Does
> Apache regulate what you can and cannot include on the download page?
>
The geronimo download page is governed by the project. How "in your
face" are you thinking here?
Probably don't want "If you use this, your (@!#@!@-ed, and if you
don't like it, you can go *(@#!@*@!#)!@#"
:D
geir
> Joe
>
> Kevan Miller wrote:
>
>> Without a really big disclaimer on the download page, my guess is
>> that approximately 100% of new-to-Geronimo M5 Installer users will
>> run into this problem. All you have to do is keep hitting "Next".
>> I did. I just never started my "installed" server, because I'd
>> already tested the zipped/tarred version of code (my mistake).
>> I don't think an errata is sufficient and I don't see how we can
>> ignore such a visible issue. This may be a bit heretical, but one
>> option is not to release the installer. Although this is a server
>> issue, you don't hit this problem in normal usage when running
>> from an zip/tar "install" (at least I haven't run into any other
>> problems, am I missing something?).
>> Most first-time users will choose the install download thinking
>> they're making their lives easier, when actually, they've just
>> made their lives more difficult. Although some last-minute hard
>> work went into the installer, IMO, the M5 installer is of limited
>> value for first-time Geronimo users. I also think that the current
>> installer is actually a configuration utility in disguise -- we
>> should start separating concerns...
>> BTW, I assume that actually fixing the underlying problem means
>> rerunning the TCK tests? Thus the reticence for fixing?
>> --kevan
>> On 10/5/05, *Geir Magnusson Jr.* <geirm@apache.org
>> <ma...@apache.org>> wrote:
>> On Oct 5, 2005, at 8:30 AM, Matt Hogstrom wrote:
>> > I think that will work but users won't find Geronimo
>> incredibly
>> > useful if they have to pull a whole new build to fix a single
>> problem.
>> Which will work?
>> i think the errata is necessary so people will know what to
>> do. As
>> for a quick M6? I think it depends on the %-age of people
>> that will
>> hit the problem.
>> > I discovered a similar problem in TranQL that the 1.1 SNAPSHOT
>> > doesn't generate the right SQL syntax for DB2 and had to
>> tweak the
>> > Syntax Generator. So the option going forward is for
>> someone to
>> > pull TranQL 1.2-SNAPSHOT which wil most likely break their
>> build
>> > too because of the serialization problem (probably not
>> likely with
>> > my example but a high probability for other types of fixes).
>> Does this mean as of now, we have a problem w/ DB2?
>> >
>> > Sachin had the right idea of highlighting the issues with
>> > serialVersionUIDs but that was part of a larger problem.
>> I'll open
>> > a feature JIRA that focuses on improved serviceability
>> which would
>> > encompass these recurring issues and we'll look for someone
>> to step
>> > up to the plate and put a strategy together.
>> >
>> yes, I think that's a different (but very important) issue
>> altogether.
>> > Thoughts?
>> >
>> Go man, go...
>> > - Matt
>> >
>> > Geir Magnusson Jr. wrote:
>> >
>> >> On Oct 4, 2005, at 11:24 PM, David Jencks wrote:
>> >>
>> >>> Stefan Schmidt has found our first configuration problem
>> in M5,
>> >>> namely that the listener name in the ejb builder in
>> >>> config.tomcat.xml points half to tomcat and half to
>> jetty. This
>> >>> is easy to fix by hand (change JettyWebContainer to
>> >>> TomcatWebContainer). However I doubt we want to
>> rerelease M5 to
>> >>> fix this. What do we want to do about issues like this?
>> One
>> >>> possibility is to have an "errata" page clearly linked
>> from the
>> >>> download page.
>> >>>
>> >> That's a great idea.
>> >>
>> >>> There must be some other possibilities, any ideas?
>> >>>
>> >> 1) Can we capture this as some kind of functional test to
>> prevent
>> >> from happening again?
>> >> 2) how long would it take to fix on branch/m5 (and head)
>> and do a
>> >> M6 tag off of branch/m5 (if people don't find that too
>> >> nauseating) and release that?
>> >> geir
>> >>
>> >
>> >
>> --
>> Geir Magnusson Jr
>> +1-203-665-6437
>> geirm@apache.org <ma...@apache.org>
>>
>
> --
> Joe Bohn
> joe.bohn@earthlink.net
>
> "He is no fool who gives what he cannot keep, to gain what he
> cannot lose." -- Jim Elliot
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: What do we do about fixable problems in M5?
Posted by Joe Bohn <jo...@earthlink.net>.
I think there's two different types of problems here that are being
confused.
The first is a few configuration issues with the zip image that Stefan
(in the tomcat config.xml) and Matt (with the TranQL and DB2) have
discovered. There may be more of these but these types of issues that
arise but they are *not* issues which 100% of customers will hit. For
these types of problems I think that an errata on the download page
should suffice (with individual replacement modules and directions).
The second is another issue that Stefan discovered which involves the
installer. This is the type of thing that can affect a lot of users and
may be something that would cause us to create an M6. However, since
the installer is itself a unique download do we really have to build
another M6 to replace it? Can't we just build a new installer off the
M5 image with changes to the installer alone that should not affect the
TCK results? If possible I think this would be a better solution than
dropping it completely from M5.
Another idea would be to just add some very "in your face" statements
around the download link for the installer itself. Does Apache regulate
what you can and cannot include on the download page?
Joe
Kevan Miller wrote:
> Without a really big disclaimer on the download page, my guess is that
> approximately 100% of new-to-Geronimo M5 Installer users will run into
> this problem. All you have to do is keep hitting "Next". I did. I just
> never started my "installed" server, because I'd already tested the
> zipped/tarred version of code (my mistake).
>
> I don't think an errata is sufficient and I don't see how we can ignore
> such a visible issue. This may be a bit heretical, but one option is not
> to release the installer. Although this is a server issue, you don't hit
> this problem in normal usage when running from an zip/tar "install" (at
> least I haven't run into any other problems, am I missing something?).
>
> Most first-time users will choose the install download thinking they're
> making their lives easier, when actually, they've just made their lives
> more difficult. Although some last-minute hard work went into the
> installer, IMO, the M5 installer is of limited value for first-time
> Geronimo users. I also think that the current installer is actually a
> configuration utility in disguise -- we should start separating concerns...
>
> BTW, I assume that actually fixing the underlying problem means
> rerunning the TCK tests? Thus the reticence for fixing?
>
> --kevan
>
> On 10/5/05, *Geir Magnusson Jr.* <geirm@apache.org
> <ma...@apache.org>> wrote:
>
>
> On Oct 5, 2005, at 8:30 AM, Matt Hogstrom wrote:
>
> > I think that will work but users won't find Geronimo incredibly
> > useful if they have to pull a whole new build to fix a single
> problem.
>
> Which will work?
>
> i think the errata is necessary so people will know what to do. As
> for a quick M6? I think it depends on the %-age of people that will
> hit the problem.
>
> > I discovered a similar problem in TranQL that the 1.1 SNAPSHOT
> > doesn't generate the right SQL syntax for DB2 and had to tweak the
> > Syntax Generator. So the option going forward is for someone to
> > pull TranQL 1.2-SNAPSHOT which wil most likely break their build
> > too because of the serialization problem (probably not likely with
> > my example but a high probability for other types of fixes).
>
> Does this mean as of now, we have a problem w/ DB2?
>
> >
> > Sachin had the right idea of highlighting the issues with
> > serialVersionUIDs but that was part of a larger problem. I'll open
> > a feature JIRA that focuses on improved serviceability which would
> > encompass these recurring issues and we'll look for someone to step
> > up to the plate and put a strategy together.
> >
>
> yes, I think that's a different (but very important) issue altogether.
>
>
> > Thoughts?
> >
>
> Go man, go...
>
> > - Matt
> >
> > Geir Magnusson Jr. wrote:
> >
> >> On Oct 4, 2005, at 11:24 PM, David Jencks wrote:
> >>
> >>> Stefan Schmidt has found our first configuration problem in M5,
> >>> namely that the listener name in the ejb builder in
> >>> config.tomcat.xml points half to tomcat and half to jetty. This
> >>> is easy to fix by hand (change JettyWebContainer to
> >>> TomcatWebContainer). However I doubt we want to rerelease M5 to
> >>> fix this. What do we want to do about issues like this? One
> >>> possibility is to have an "errata" page clearly linked from the
> >>> download page.
> >>>
> >> That's a great idea.
> >>
> >>> There must be some other possibilities, any ideas?
> >>>
> >> 1) Can we capture this as some kind of functional test to prevent
> >> from happening again?
> >> 2) how long would it take to fix on branch/m5 (and head) and do a
> >> M6 tag off of branch/m5 (if people don't find that too
> >> nauseating) and release that?
> >> geir
> >>
> >
> >
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org <ma...@apache.org>
>
>
>
--
Joe Bohn
joe.bohn@earthlink.net
"He is no fool who gives what he cannot keep, to gain what he cannot
lose." -- Jim Elliot
Re: What do we do about fixable problems in M5?
Posted by Kevan Miller <ke...@gmail.com>.
As Joe has pointed out, I've pulled the installer issue into this discussion
and improperly associated it with the config.tomcat.xml issue.
The reticence I remarked upon was from the original posts on this thread. I
wasn't attempting to be critical. Any reticence would be only natural and in
fact proper -- we can't ship a new Milestone for every problem we find.
In answer to your question -- AFAIK, the stop-the-presses issue lies solely
with the Installer. I'm not familiar with the implementation/configuration
of the installer, but I assume that changing the default port number for
Tomcat would fix the problem. Perhaps this is already in process? I'm not
able to download the installer, now...
There are known issues with M5 (now including Stefan's issue). However,
they're issues properly handled via errata, build-from-HEAD, nightly build,
etc.
--kevan
On 10/5/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>
>
> On Oct 5, 2005, at 10:18 AM, Kevan Miller wrote:
>
> > Without a really big disclaimer on the download page, my guess is
> > that approximately 100% of new-to-Geronimo M5 Installer users will
> > run into this problem. All you have to do is keep hitting "Next". I
> > did. I just never started my "installed" server, because I'd
> > already tested the zipped/tarred version of code (my mistake).
> >
> > I don't think an errata is sufficient and I don't see how we can
> > ignore such a visible issue. This may be a bit heretical, but one
> > option is not to release the installer. Although this is a server
> > issue, you don't hit this problem in normal usage when running from
> > an zip/tar "install" (at least I haven't run into any other
> > problems, am I missing something?).
> >
> > Most first-time users will choose the install download thinking
> > they're making their lives easier, when actually, they've just made
> > their lives more difficult. Although some last-minute hard work
> > went into the installer, IMO, the M5 installer is of limited value
> > for first-time Geronimo users. I also think that the current
> > installer is actually a configuration utility in disguise -- we
> > should start separating concerns...
> >
> > BTW, I assume that actually fixing the underlying problem means
> > rerunning the TCK tests? Thus the reticence for fixing?
>
> I'm not sure where you are seeing reticence.
>
> If just fixing the installer fixes it, then that's easy. If the
> problem is only in the installer, we'll just remove that link for now
> from the download page immediately. Please confirm that it's only
> the installer.
>
> geir
>
>
> >
> > --kevan
> >
> > On 10/5/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
> > On Oct 5, 2005, at 8:30 AM, Matt Hogstrom wrote:
> >
> > > I think that will work but users won't find Geronimo incredibly
> > > useful if they have to pull a whole new build to fix a single
> > problem.
> >
> > Which will work?
> >
> > i think the errata is necessary so people will know what to do. As
> > for a quick M6? I think it depends on the %-age of people that will
> > hit the problem.
> >
> > > I discovered a similar problem in TranQL that the 1.1 SNAPSHOT
> > > doesn't generate the right SQL syntax for DB2 and had to tweak the
> > > Syntax Generator. So the option going forward is for someone to
> > > pull TranQL 1.2-SNAPSHOT which wil most likely break their build
> > > too because of the serialization problem (probably not likely with
> > > my example but a high probability for other types of fixes).
> >
> > Does this mean as of now, we have a problem w/ DB2?
> >
> > >
> > > Sachin had the right idea of highlighting the issues with
> > > serialVersionUIDs but that was part of a larger problem. I'll open
> > > a feature JIRA that focuses on improved serviceability which would
> > > encompass these recurring issues and we'll look for someone to step
> > > up to the plate and put a strategy together.
> > >
> >
> > yes, I think that's a different (but very important) issue altogether.
> >
> >
> > > Thoughts?
> > >
> >
> > Go man, go...
> >
> > > - Matt
> > >
> > > Geir Magnusson Jr. wrote:
> > >
> > >> On Oct 4, 2005, at 11:24 PM, David Jencks wrote:
> > >>
> > >>> Stefan Schmidt has found our first configuration problem in M5,
> > >>> namely that the listener name in the ejb builder in
> > >>> config.tomcat.xml points half to tomcat and half to jetty. This
> > >>> is easy to fix by hand (change JettyWebContainer to
> > >>> TomcatWebContainer). However I doubt we want to rerelease M5 to
> > >>> fix this. What do we want to do about issues like this? One
> > >>> possibility is to have an "errata" page clearly linked from the
> > >>> download page.
> > >>>
> > >> That's a great idea.
> > >>
> > >>> There must be some other possibilities, any ideas?
> > >>>
> > >> 1) Can we capture this as some kind of functional test to prevent
> > >> from happening again?
> > >> 2) how long would it take to fix on branch/m5 (and head) and do a
> > >> M6 tag off of branch/m5 (if people don't find that too
> > >> nauseating) and release that?
> > >> geir
> > >>
> > >
> > >
> >
> > --
> > Geir Magnusson Jr +1-203-665-6437
> > geirm@apache.org
> >
> >
> >
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
>
Re: What do we do about fixable problems in M5?
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Oct 5, 2005, at 10:18 AM, Kevan Miller wrote:
> Without a really big disclaimer on the download page, my guess is
> that approximately 100% of new-to-Geronimo M5 Installer users will
> run into this problem. All you have to do is keep hitting "Next". I
> did. I just never started my "installed" server, because I'd
> already tested the zipped/tarred version of code (my mistake).
>
> I don't think an errata is sufficient and I don't see how we can
> ignore such a visible issue. This may be a bit heretical, but one
> option is not to release the installer. Although this is a server
> issue, you don't hit this problem in normal usage when running from
> an zip/tar "install" (at least I haven't run into any other
> problems, am I missing something?).
>
> Most first-time users will choose the install download thinking
> they're making their lives easier, when actually, they've just made
> their lives more difficult. Although some last-minute hard work
> went into the installer, IMO, the M5 installer is of limited value
> for first-time Geronimo users. I also think that the current
> installer is actually a configuration utility in disguise -- we
> should start separating concerns...
>
> BTW, I assume that actually fixing the underlying problem means
> rerunning the TCK tests? Thus the reticence for fixing?
I'm not sure where you are seeing reticence.
If just fixing the installer fixes it, then that's easy. If the
problem is only in the installer, we'll just remove that link for now
from the download page immediately. Please confirm that it's only
the installer.
geir
>
> --kevan
>
> On 10/5/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
> On Oct 5, 2005, at 8:30 AM, Matt Hogstrom wrote:
>
> > I think that will work but users won't find Geronimo incredibly
> > useful if they have to pull a whole new build to fix a single
> problem.
>
> Which will work?
>
> i think the errata is necessary so people will know what to do. As
> for a quick M6? I think it depends on the %-age of people that will
> hit the problem.
>
> > I discovered a similar problem in TranQL that the 1.1 SNAPSHOT
> > doesn't generate the right SQL syntax for DB2 and had to tweak the
> > Syntax Generator. So the option going forward is for someone to
> > pull TranQL 1.2-SNAPSHOT which wil most likely break their build
> > too because of the serialization problem (probably not likely with
> > my example but a high probability for other types of fixes).
>
> Does this mean as of now, we have a problem w/ DB2?
>
> >
> > Sachin had the right idea of highlighting the issues with
> > serialVersionUIDs but that was part of a larger problem. I'll open
> > a feature JIRA that focuses on improved serviceability which would
> > encompass these recurring issues and we'll look for someone to step
> > up to the plate and put a strategy together.
> >
>
> yes, I think that's a different (but very important) issue altogether.
>
>
> > Thoughts?
> >
>
> Go man, go...
>
> > - Matt
> >
> > Geir Magnusson Jr. wrote:
> >
> >> On Oct 4, 2005, at 11:24 PM, David Jencks wrote:
> >>
> >>> Stefan Schmidt has found our first configuration problem in M5,
> >>> namely that the listener name in the ejb builder in
> >>> config.tomcat.xml points half to tomcat and half to jetty. This
> >>> is easy to fix by hand (change JettyWebContainer to
> >>> TomcatWebContainer). However I doubt we want to rerelease M5 to
> >>> fix this. What do we want to do about issues like this? One
> >>> possibility is to have an "errata" page clearly linked from the
> >>> download page.
> >>>
> >> That's a great idea.
> >>
> >>> There must be some other possibilities, any ideas?
> >>>
> >> 1) Can we capture this as some kind of functional test to prevent
> >> from happening again?
> >> 2) how long would it take to fix on branch/m5 (and head) and do a
> >> M6 tag off of branch/m5 (if people don't find that too
> >> nauseating) and release that?
> >> geir
> >>
> >
> >
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: What do we do about fixable problems in M5?
Posted by Matt Hogstrom <ma...@hogstrom.org>.
> <87...@apache.org> <b8...@mail.gmail.com>
In-Reply-To: <b8...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-MMS-Smtp-Program: Macallan-Mail-Solution; Version 4.6.0.1
X-MMS-Smtp-Auth: Authenticated As matt@hogstrom.org
X-MMS-Smtp-Mailer-Program: Macallan-Mail-Solution; Version 4.6.0.1
I probably screwed up and viewed any problem that required the customer to do
something as fixable issue. If this is the case my bad.
Matt
Kevan Miller wrote:
> As Joe has pointed out, I've pulled the installer issue into this discussion
> and improperly associated it with the config.tomcat.xml issue.
>
> The reticence I remarked upon was from the original posts on this thread. I
> wasn't attempting to be critical. Any reticence would be only natural and in
> fact proper -- we can't ship a new Milestone for every problem we find.
>
> In answer to your question -- AFAIK, the stop-the-presses issue lies solely
> with the Installer. I'm not familiar with the implementation/configuration
> of the installer, but I assume that changing the default port number for
> Tomcat would fix the problem. Perhaps this is already in process? I'm not
> able to download the installer, now...
>
> There are known issues with M5 (now including Stefan's issue). However,
> they're issues properly handled via errata, build-from-HEAD, nightly build,
> etc.
>
> --kevan
>
> On 10/5/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>
>>
>>On Oct 5, 2005, at 10:18 AM, Kevan Miller wrote:
>>
>>
>>>Without a really big disclaimer on the download page, my guess is
>>>that approximately 100% of new-to-Geronimo M5 Installer users will
>>>run into this problem. All you have to do is keep hitting "Next". I
>>>did. I just never started my "installed" server, because I'd
>>>already tested the zipped/tarred version of code (my mistake).
>>>
>>>I don't think an errata is sufficient and I don't see how we can
>>>ignore such a visible issue. This may be a bit heretical, but one
>>>option is not to release the installer. Although this is a server
>>>issue, you don't hit this problem in normal usage when running from
>>>an zip/tar "install" (at least I haven't run into any other
>>>problems, am I missing something?).
>>>
>>>Most first-time users will choose the install download thinking
>>>they're making their lives easier, when actually, they've just made
>>>their lives more difficult. Although some last-minute hard work
>>>went into the installer, IMO, the M5 installer is of limited value
>>>for first-time Geronimo users. I also think that the current
>>>installer is actually a configuration utility in disguise -- we
>>>should start separating concerns...
>>>
>>>BTW, I assume that actually fixing the underlying problem means
>>>rerunning the TCK tests? Thus the reticence for fixing?
>>
>>I'm not sure where you are seeing reticence.
>>
>>If just fixing the installer fixes it, then that's easy. If the
>>problem is only in the installer, we'll just remove that link for now
>>from the download page immediately. Please confirm that it's only
>>the installer.
>>
>>geir
>>
>>
>>
>>>--kevan
>>>
>>>On 10/5/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>>>On Oct 5, 2005, at 8:30 AM, Matt Hogstrom wrote:
>>>
>>>
>>>>I think that will work but users won't find Geronimo incredibly
>>>>useful if they have to pull a whole new build to fix a single
>>>
>>>problem.
>>>
>>>Which will work?
>>>
>>>i think the errata is necessary so people will know what to do. As
>>>for a quick M6? I think it depends on the %-age of people that will
>>>hit the problem.
>>>
>>>
>>>>I discovered a similar problem in TranQL that the 1.1 SNAPSHOT
>>>>doesn't generate the right SQL syntax for DB2 and had to tweak the
>>>>Syntax Generator. So the option going forward is for someone to
>>>>pull TranQL 1.2-SNAPSHOT which wil most likely break their build
>>>>too because of the serialization problem (probably not likely with
>>>>my example but a high probability for other types of fixes).
>>>
>>>Does this mean as of now, we have a problem w/ DB2?
>>>
>>>
>>>>Sachin had the right idea of highlighting the issues with
>>>>serialVersionUIDs but that was part of a larger problem. I'll open
>>>>a feature JIRA that focuses on improved serviceability which would
>>>>encompass these recurring issues and we'll look for someone to step
>>>>up to the plate and put a strategy together.
>>>>
>>>
>>>yes, I think that's a different (but very important) issue altogether.
>>>
>>>
>>>
>>>>Thoughts?
>>>>
>>>
>>>Go man, go...
>>>
>>>
>>>>- Matt
>>>>
>>>>Geir Magnusson Jr. wrote:
>>>>
>>>>
>>>>>On Oct 4, 2005, at 11:24 PM, David Jencks wrote:
>>>>>
>>>>>
>>>>>>Stefan Schmidt has found our first configuration problem in M5,
>>>>>>namely that the listener name in the ejb builder in
>>>>>>config.tomcat.xml points half to tomcat and half to jetty. This
>>>>>>is easy to fix by hand (change JettyWebContainer to
>>>>>>TomcatWebContainer). However I doubt we want to rerelease M5 to
>>>>>>fix this. What do we want to do about issues like this? One
>>>>>>possibility is to have an "errata" page clearly linked from the
>>>>>>download page.
>>>>>>
>>>>>
>>>>>That's a great idea.
>>>>>
>>>>>
>>>>>>There must be some other possibilities, any ideas?
>>>>>>
>>>>>
>>>>>1) Can we capture this as some kind of functional test to prevent
>>>>>from happening again?
>>>>>2) how long would it take to fix on branch/m5 (and head) and do a
>>>>>M6 tag off of branch/m5 (if people don't find that too
>>>>>nauseating) and release that?
>>>>>geir
>>>>>
>>>>
>>>>
>>>--
>>>Geir Magnusson Jr +1-203-665-6437
>>>geirm@apache.org
>>>
>>>
>>>
>>
>>--
>>Geir Magnusson Jr +1-203-665-6437
>>geirm@apache.org
>>
>>
>>
>
>
Re: What do we do about fixable problems in M5?
Posted by Kevan Miller <ke...@gmail.com>.
Without a really big disclaimer on the download page, my guess is that
approximately 100% of new-to-Geronimo M5 Installer users will run into this
problem. All you have to do is keep hitting "Next". I did. I just never
started my "installed" server, because I'd already tested the zipped/tarred
version of code (my mistake).
I don't think an errata is sufficient and I don't see how we can ignore such
a visible issue. This may be a bit heretical, but one option is not to
release the installer. Although this is a server issue, you don't hit this
problem in normal usage when running from an zip/tar "install" (at least I
haven't run into any other problems, am I missing something?).
Most first-time users will choose the install download thinking they're
making their lives easier, when actually, they've just made their lives more
difficult. Although some last-minute hard work went into the installer, IMO,
the M5 installer is of limited value for first-time Geronimo users. I also
think that the current installer is actually a configuration utility in
disguise -- we should start separating concerns...
BTW, I assume that actually fixing the underlying problem means rerunning
the TCK tests? Thus the reticence for fixing?
--kevan
On 10/5/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>
>
> On Oct 5, 2005, at 8:30 AM, Matt Hogstrom wrote:
>
> > I think that will work but users won't find Geronimo incredibly
> > useful if they have to pull a whole new build to fix a single problem.
>
> Which will work?
>
> i think the errata is necessary so people will know what to do. As
> for a quick M6? I think it depends on the %-age of people that will
> hit the problem.
>
> > I discovered a similar problem in TranQL that the 1.1 SNAPSHOT
> > doesn't generate the right SQL syntax for DB2 and had to tweak the
> > Syntax Generator. So the option going forward is for someone to
> > pull TranQL 1.2-SNAPSHOT which wil most likely break their build
> > too because of the serialization problem (probably not likely with
> > my example but a high probability for other types of fixes).
>
> Does this mean as of now, we have a problem w/ DB2?
>
> >
> > Sachin had the right idea of highlighting the issues with
> > serialVersionUIDs but that was part of a larger problem. I'll open
> > a feature JIRA that focuses on improved serviceability which would
> > encompass these recurring issues and we'll look for someone to step
> > up to the plate and put a strategy together.
> >
>
> yes, I think that's a different (but very important) issue altogether.
>
>
> > Thoughts?
> >
>
> Go man, go...
>
> > - Matt
> >
> > Geir Magnusson Jr. wrote:
> >
> >> On Oct 4, 2005, at 11:24 PM, David Jencks wrote:
> >>
> >>> Stefan Schmidt has found our first configuration problem in M5,
> >>> namely that the listener name in the ejb builder in
> >>> config.tomcat.xml points half to tomcat and half to jetty. This
> >>> is easy to fix by hand (change JettyWebContainer to
> >>> TomcatWebContainer). However I doubt we want to rerelease M5 to
> >>> fix this. What do we want to do about issues like this? One
> >>> possibility is to have an "errata" page clearly linked from the
> >>> download page.
> >>>
> >> That's a great idea.
> >>
> >>> There must be some other possibilities, any ideas?
> >>>
> >> 1) Can we capture this as some kind of functional test to prevent
> >> from happening again?
> >> 2) how long would it take to fix on branch/m5 (and head) and do a
> >> M6 tag off of branch/m5 (if people don't find that too
> >> nauseating) and release that?
> >> geir
> >>
> >
> >
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
>
Re: What do we do about fixable problems in M5?
Posted by Matt Hogstrom <ma...@hogstrom.org>.
Geir Magnusson Jr. wrote:
>
> On Oct 5, 2005, at 8:30 AM, Matt Hogstrom wrote:
>
>> I think that will work but users won't find Geronimo incredibly
>> useful if they have to pull a whole new build to fix a single problem.
>
>
> Which will work?
>
> i think the errata is necessary so people will know what to do. As for
> a quick M6? I think it depends on the %-age of people that will hit
> the problem.
>
Tactically this is the right answer...no question.
>> I discovered a similar problem in TranQL that the 1.1 SNAPSHOT
>> doesn't generate the right SQL syntax for DB2 and had to tweak the
>> Syntax Generator. So the option going forward is for someone to pull
>> TranQL 1.2-SNAPSHOT which wil most likely break their build too
>> because of the serialization problem (probably not likely with my
>> example but a high probability for other types of fixes).
>
>
> Does this mean as of now, we have a problem w/ DB2?
Only for one type EJB 2.1 CMP interaction. Testing the fix as we speak. Its a
one class (non-disruptive :) change.
>
>>
>> Sachin had the right idea of highlighting the issues with
>> serialVersionUIDs but that was part of a larger problem. I'll open a
>> feature JIRA that focuses on improved serviceability which would
>> encompass these recurring issues and we'll look for someone to step
>> up to the plate and put a strategy together.
>>
>
> yes, I think that's a different (but very important) issue altogether.
>
Service is hard and not a lot of fun. Kind of pushing a boulder up hill. But
sooooo important :)
>
>> Thoughts?
>>
>
> Go man, go...
>
>> - Matt
>>
>> Geir Magnusson Jr. wrote:
>>
>>> On Oct 4, 2005, at 11:24 PM, David Jencks wrote:
>>>
>>>> Stefan Schmidt has found our first configuration problem in M5,
>>>> namely that the listener name in the ejb builder in
>>>> config.tomcat.xml points half to tomcat and half to jetty. This is
>>>> easy to fix by hand (change JettyWebContainer to
>>>> TomcatWebContainer). However I doubt we want to rerelease M5 to
>>>> fix this. What do we want to do about issues like this? One
>>>> possibility is to have an "errata" page clearly linked from the
>>>> download page.
>>>>
>>> That's a great idea.
>>>
>>>> There must be some other possibilities, any ideas?
>>>>
>>> 1) Can we capture this as some kind of functional test to prevent
>>> from happening again?
>>> 2) how long would it take to fix on branch/m5 (and head) and do a
>>> M6 tag off of branch/m5 (if people don't find that too nauseating)
>>> and release that?
>>> geir
>>>
>>
>>
>
Re: What do we do about fixable problems in M5?
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Oct 5, 2005, at 8:30 AM, Matt Hogstrom wrote:
> I think that will work but users won't find Geronimo incredibly
> useful if they have to pull a whole new build to fix a single problem.
Which will work?
i think the errata is necessary so people will know what to do. As
for a quick M6? I think it depends on the %-age of people that will
hit the problem.
> I discovered a similar problem in TranQL that the 1.1 SNAPSHOT
> doesn't generate the right SQL syntax for DB2 and had to tweak the
> Syntax Generator. So the option going forward is for someone to
> pull TranQL 1.2-SNAPSHOT which wil most likely break their build
> too because of the serialization problem (probably not likely with
> my example but a high probability for other types of fixes).
Does this mean as of now, we have a problem w/ DB2?
>
> Sachin had the right idea of highlighting the issues with
> serialVersionUIDs but that was part of a larger problem. I'll open
> a feature JIRA that focuses on improved serviceability which would
> encompass these recurring issues and we'll look for someone to step
> up to the plate and put a strategy together.
>
yes, I think that's a different (but very important) issue altogether.
> Thoughts?
>
Go man, go...
> - Matt
>
> Geir Magnusson Jr. wrote:
>
>> On Oct 4, 2005, at 11:24 PM, David Jencks wrote:
>>
>>> Stefan Schmidt has found our first configuration problem in M5,
>>> namely that the listener name in the ejb builder in
>>> config.tomcat.xml points half to tomcat and half to jetty. This
>>> is easy to fix by hand (change JettyWebContainer to
>>> TomcatWebContainer). However I doubt we want to rerelease M5 to
>>> fix this. What do we want to do about issues like this? One
>>> possibility is to have an "errata" page clearly linked from the
>>> download page.
>>>
>> That's a great idea.
>>
>>> There must be some other possibilities, any ideas?
>>>
>> 1) Can we capture this as some kind of functional test to prevent
>> from happening again?
>> 2) how long would it take to fix on branch/m5 (and head) and do a
>> M6 tag off of branch/m5 (if people don't find that too
>> nauseating) and release that?
>> geir
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: What do we do about fixable problems in M5?
Posted by Matt Hogstrom <ma...@hogstrom.org>.
I think that will work but users won't find Geronimo incredibly useful if they
have to pull a whole new build to fix a single problem. I discovered a similar
problem in TranQL that the 1.1 SNAPSHOT doesn't generate the right SQL syntax
for DB2 and had to tweak the Syntax Generator. So the option going forward is
for someone to pull TranQL 1.2-SNAPSHOT which wil most likely break their build
too because of the serialization problem (probably not likely with my example
but a high probability for other types of fixes).
Sachin had the right idea of highlighting the issues with serialVersionUIDs but
that was part of a larger problem. I'll open a feature JIRA that focuses on
improved serviceability which would encompass these recurring issues and we'll
look for someone to step up to the plate and put a strategy together.
Thoughts?
- Matt
Geir Magnusson Jr. wrote:
>
> On Oct 4, 2005, at 11:24 PM, David Jencks wrote:
>
>> Stefan Schmidt has found our first configuration problem in M5,
>> namely that the listener name in the ejb builder in config.tomcat.xml
>> points half to tomcat and half to jetty. This is easy to fix by hand
>> (change JettyWebContainer to TomcatWebContainer). However I doubt we
>> want to rerelease M5 to fix this. What do we want to do about issues
>> like this? One possibility is to have an "errata" page clearly
>> linked from the download page.
>
>
> That's a great idea.
>
>> There must be some other possibilities, any ideas?
>
>
> 1) Can we capture this as some kind of functional test to prevent from
> happening again?
>
> 2) how long would it take to fix on branch/m5 (and head) and do a M6
> tag off of branch/m5 (if people don't find that too nauseating) and
> release that?
>
> geir
>
Re: What do we do about fixable problems in M5?
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Oct 4, 2005, at 11:24 PM, David Jencks wrote:
> Stefan Schmidt has found our first configuration problem in M5,
> namely that the listener name in the ejb builder in
> config.tomcat.xml points half to tomcat and half to jetty. This is
> easy to fix by hand (change JettyWebContainer to
> TomcatWebContainer). However I doubt we want to rerelease M5 to
> fix this. What do we want to do about issues like this? One
> possibility is to have an "errata" page clearly linked from the
> download page.
That's a great idea.
> There must be some other possibilities, any ideas?
1) Can we capture this as some kind of functional test to prevent
from happening again?
2) how long would it take to fix on branch/m5 (and head) and do a M6
tag off of branch/m5 (if people don't find that too nauseating) and
release that?
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: What do we do about fixable problems in M5?
Posted by David Blevins <da...@visi.com>.
On Oct 4, 2005, at 8:24 PM, David Jencks wrote:
> Stefan Schmidt has found our first configuration problem in M5,
> namely that the listener name in the ejb builder in
> config.tomcat.xml points half to tomcat and half to jetty. This is
> easy to fix by hand (change JettyWebContainer to
> TomcatWebContainer). However I doubt we want to rerelease M5 to
> fix this. What do we want to do about issues like this? One
> possibility is to have an "errata" page clearly linked from the
> download page. There must be some other possibilities, any ideas?
>
I can also put a little work into getting unstable builds going
again. Actually, we have them for the most part, just no way to
update the geronimo version number in an easy fashion like 'maven -
Dgeronimo.version=1.0-234534'
As far as an errata, we can pull a mini-changelog from Jira. I do a
similar thing at OpenEJB: http://www.openejb.org/Latest+Unstable.
Ted Husted was very nice and setup a confluence space for us at
http://opensource2.atlassian.com/confluence/oss/display/GERONIMO.
Maybe we can be pragmatic and avoid a long discussion on which wiki
to use and agree for now only to use the confluence one for specific
things like tapping into JIRA.
Anyway, those are just some options. More thoughts welcome.
-David