[VOTE] Struts 2.0.4 Quality

[Ted Husted]

Since the Struts 2.0.4 build is essentially the 2.0.3 build with Maven
fixes, I thought we might as well start the vote. If after three days
anyone needs more time, or we don't have a quorum, then we can just
leave the vote open for as long as it takes.

Release notes:
    * http://struts.apache.org/2.x/docs/release-notes-204.html
    * http://struts.apache.org/2.x/docs/release-notes-203.html

Distribution:
     * http://people.apache.org/builds/struts/2.0.4/

Maven 2 staging repository:
    * http://people.apache.org/builds/struts/2.0.4/m2-staging-repository/

Once you have had a chance to review the test build, please respond
with a vote as to its quality:

    [ ] Leave at test build
    [ ] Alpha
    [ ] Beta
    [ ] General Availability (GA)

Everyone who has tested the build is invited to vote. Votes by PMC
members are considered binding. A vote passes if there are at least
three binding +1s and more +1s than -1s.

Please remember that a binding +1 for GA implies that you intend to
support the release by applying patches and responding to posts to the
user and dev lists.

Unless we decide otherwise, a beta vote implies that we will announce
the build to the user list, to encourage wider testing.

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Ted Husted]

On 1/29/07, Ted Husted <husted@...> wrote:
>     [ ] Leave at test build
>     [ ] Alpha
>     [X] Beta
>     [ ] General Availability (GA)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Don Brown-2]

+1 for GA.  I've been pretty happy with this build and while there are
certainly things to improve (aren't there always?), I don't see anything
major that should prevent production applications from being built upon it.

Even if the final result is beta, will this release finally be put into
the public maven repository?

Don

Ted Husted wrote:

> Since the Struts 2.0.4 build is essentially the 2.0.3 build with Maven
> fixes, I thought we might as well start the vote. If after three days
> anyone needs more time, or we don't have a quorum, then we can just
> leave the vote open for as long as it takes.
>
> Release notes:
>    * http://struts.apache.org/2.x/docs/release-notes-204.html
>    * http://struts.apache.org/2.x/docs/release-notes-203.html
>
> Distribution:
>     * http://people.apache.org/builds/struts/2.0.4/
>
> Maven 2 staging repository:
>    * http://people.apache.org/builds/struts/2.0.4/m2-staging-repository/
>
> Once you have had a chance to review the test build, please respond
> with a vote as to its quality:
>
>    [ ] Leave at test build
>    [ ] Alpha
>    [ ] Beta
>    [ ] General Availability (GA)
>
> Everyone who has tested the build is invited to vote. Votes by PMC
> members are considered binding. A vote passes if there are at least
> three binding +1s and more +1s than -1s.
>
> Please remember that a binding +1 for GA implies that you intend to
> support the release by applying patches and responding to posts to the
> user and dev lists.
>
> Unless we decide otherwise, a beta vote implies that we will announce
> the build to the user list, to encourage wider testing.
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Ted Husted]

Yes, infrastructure prefers that all "releases" be mirrored, so I
expect that means the Maven equivalents should also be distributed via
the public repository.

Did we withhold 2.0.1 from the public repository?

And, there's no reason to believe that the "final result" would be
beta. We can upgrade (or downgrade) the quality whenever we like. The
reason 2.0.1 had a "final result" at beta was because of the XWork
dependency, which isn't a problem now.

-Ted.

On 1/29/07, Don Brown <mrdon@...> wrote:

> +1 for GA.  I've been pretty happy with this build and while there are
> certainly things to improve (aren't there always?), I don't see anything
> major that should prevent production applications from being built upon it.
>
> Even if the final result is beta, will this release finally be put into
> the public maven repository?
>
> Don
>
> Ted Husted wrote:
> > Since the Struts 2.0.4 build is essentially the 2.0.3 build with Maven
> > fixes, I thought we might as well start the vote. If after three days
> > anyone needs more time, or we don't have a quorum, then we can just
> > leave the vote open for as long as it takes.
> >
> > Release notes:
> >    * http://struts.apache.org/2.x/docs/release-notes-204.html
> >    * http://struts.apache.org/2.x/docs/release-notes-203.html
> >
> > Distribution:
> >     * http://people.apache.org/builds/struts/2.0.4/
> >
> > Maven 2 staging repository:
> >    * http://people.apache.org/builds/struts/2.0.4/m2-staging-repository/
> >
> > Once you have had a chance to review the test build, please respond
> > with a vote as to its quality:
> >
> >    [ ] Leave at test build
> >    [ ] Alpha
> >    [ ] Beta
> >    [ ] General Availability (GA)
> >
> > Everyone who has tested the build is invited to vote. Votes by PMC
> > members are considered binding. A vote passes if there are at least
> > three binding +1s and more +1s than -1s.
> >
> > Please remember that a binding +1 for GA implies that you intend to
> > support the release by applying patches and responding to posts to the
> > user and dev lists.
> >
> > Unless we decide otherwise, a beta vote implies that we will announce
> > the build to the user list, to encourage wider testing.
> >
> > -Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Niall Pemberton-2]

On 1/30/07, Ted Husted <husted@...> wrote:

> Yes, infrastructure prefers that all "releases" be mirrored, so I
> expect that means the Maven equivalents should also be distributed via
> the public repository.
>
> Did we withhold 2.0.1 from the public repository?
>
> And, there's no reason to believe that the "final result" would be
> beta. We can upgrade (or downgrade) the quality whenever we like. The
> reason 2.0.1 had a "final result" at beta was because of the XWork
> dependency, which isn't a problem now.

...and its far better to upgrade the quality later than classify it as
"ga" first and have to downgrade later. The Struts 1.2.2 experience
shows that once a "ga" label is attached it gets out into the
eco-system whatever happens after. IMO the main thing is having an
official ASF release and given the effort and time to get to this
point having it sit at beta for a short while makes little difference
if it does go GA given the lifespan of usage for ga versions.

Niall

P.S. sorry won't be voting, just cheering from the sidelines, as I'm
not currently using Struts2

> -Ted.
>
> On 1/29/07, Don Brown <mrdon@...> wrote:
> > +1 for GA.  I've been pretty happy with this build and while there are
> > certainly things to improve (aren't there always?), I don't see anything
> > major that should prevent production applications from being built upon it.
> >
> > Even if the final result is beta, will this release finally be put into
> > the public maven repository?
> >
> > Don
> >
> > Ted Husted wrote:
> > > Since the Struts 2.0.4 build is essentially the 2.0.3 build with Maven
> > > fixes, I thought we might as well start the vote. If after three days
> > > anyone needs more time, or we don't have a quorum, then we can just
> > > leave the vote open for as long as it takes.
> > >
> > > Release notes:
> > >    * http://struts.apache.org/2.x/docs/release-notes-204.html
> > >    * http://struts.apache.org/2.x/docs/release-notes-203.html
> > >
> > > Distribution:
> > >     * http://people.apache.org/builds/struts/2.0.4/
> > >
> > > Maven 2 staging repository:
> > >    * http://people.apache.org/builds/struts/2.0.4/m2-staging-repository/
> > >
> > > Once you have had a chance to review the test build, please respond
> > > with a vote as to its quality:
> > >
> > >    [ ] Leave at test build
> > >    [ ] Alpha
> > >    [ ] Beta
> > >    [ ] General Availability (GA)
> > >
> > > Everyone who has tested the build is invited to vote. Votes by PMC
> > > members are considered binding. A vote passes if there are at least
> > > three binding +1s and more +1s than -1s.
> > >
> > > Please remember that a binding +1 for GA implies that you intend to
> > > support the release by applying patches and responding to posts to the
> > > user and dev lists.
> > >
> > > Unless we decide otherwise, a beta vote implies that we will announce
> > > the build to the user list, to encourage wider testing.
> > >
> > > -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[mraible]

I tried upgrading AppFuse to use 2.0.4 and I'm still experiencing the following issue with fileupload:

java.lang.RuntimeException: Unable to load bean org.apache.struts2.dispatcher.multipart.MultiPartRequest (jakarta) - [unknown location]
        com.opensymphony.xwork2.inject.ContainerBuilder$4.create(ContainerBuilder.java:136)
        com.opensymphony.xwork2.inject.ContainerImpl.getInstance(ContainerImpl.java:473)
        com.opensymphony.xwork2.inject.ContainerImpl.getInstance(ContainerImpl.java:483)
        com.opensymphony.xwork2.inject.ContainerImpl$9.call(ContainerImpl.java:514)
        com.opensymphony.xwork2.inject.ContainerImpl.callInContext(ContainerImpl.java:539)
        com.opensymphony.xwork2.inject.ContainerImpl.getInstance(ContainerImpl.java:512)
        org.apache.struts2.dispatcher.Dispatcher.wrapRequest(Dispatcher.java:701)
        org.apache.struts2.dispatcher.FilterDispatcher.prepareDispatcherAndWrapRequest(FilterDispatcher.java:327)
        org.apache.struts2.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:390)

I've added some comments to the following issue, but still don't have a resolution:

http://issues.apache.org/struts/browse/WW-1642

Here's my JSP: http://tinyurl.com/yt8xy9

And here's my Action: http://tinyurl.com/yw3rd4

Hopefully I'm just doing something wrong.

Matt

Ted Husted-3 wrote:

Since the Struts 2.0.4 build is essentially the 2.0.3 build with Maven
fixes, I thought we might as well start the vote. If after three days
anyone needs more time, or we don't have a quorum, then we can just
leave the vote open for as long as it takes.

Release notes:
    * http://struts.apache.org/2.x/docs/release-notes-204.html
    * http://struts.apache.org/2.x/docs/release-notes-203.html

Distribution:
     * http://people.apache.org/builds/struts/2.0.4/

Maven 2 staging repository:
    * http://people.apache.org/builds/struts/2.0.4/m2-staging-repository/

Once you have had a chance to review the test build, please respond
with a vote as to its quality:

    [ ] Leave at test build
    [ ] Alpha
    [ ] Beta
    [ ] General Availability (GA)

Everyone who has tested the build is invited to vote. Votes by PMC
members are considered binding. A vote passes if there are at least
three binding +1s and more +1s than -1s.

Please remember that a binding +1 for GA implies that you intend to
support the release by applying patches and responding to posts to the
user and dev lists.

Unless we decide otherwise, a beta vote implies that we will announce
the build to the user list, to encourage wider testing.

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: [e-mail]
For additional commands, e-mail: [e-mail]

[Philip Luppens]

Can a problem in a dependency hold back a GA ? I'm talking about
WW-1615 [1] (OGNL race condition). The bugfix is trivial, but we need
a new release for that. Patrick should have set up Jesse by now (its
new maintainer), so we can expect an official bugfix release rather
soon.

I guess I have some troubles with pushing a GA if such an important
dependency is having a known bug. We're already aware of S2 being
slower than S1, let's not kill whatever performance we have left with
a race condition, even if it's caused by a dependency rather than the
actual framework.

Of course, if this has nothing to do with it, then just disregard this message.

Cheers,

Phil

[1] https://issues.apache.org/struts/browse/WW-1615

On 1/30/07, Don Brown <mrdon@...> wrote:

> +1 for GA.  I've been pretty happy with this build and while there are
> certainly things to improve (aren't there always?), I don't see anything
> major that should prevent production applications from being built upon it.
>
> Even if the final result is beta, will this release finally be put into
> the public maven repository?
>
> Don
>
> Ted Husted wrote:
> > Since the Struts 2.0.4 build is essentially the 2.0.3 build with Maven
> > fixes, I thought we might as well start the vote. If after three days
> > anyone needs more time, or we don't have a quorum, then we can just
> > leave the vote open for as long as it takes.
> >
> > Release notes:
> >    * http://struts.apache.org/2.x/docs/release-notes-204.html
> >    * http://struts.apache.org/2.x/docs/release-notes-203.html
> >
> > Distribution:
> >     * http://people.apache.org/builds/struts/2.0.4/
> >
> > Maven 2 staging repository:
> >    * http://people.apache.org/builds/struts/2.0.4/m2-staging-repository/
> >
> > Once you have had a chance to review the test build, please respond
> > with a vote as to its quality:
> >
> >    [ ] Leave at test build
> >    [ ] Alpha
> >    [ ] Beta
> >    [ ] General Availability (GA)
> >
> > Everyone who has tested the build is invited to vote. Votes by PMC
> > members are considered binding. A vote passes if there are at least
> > three binding +1s and more +1s than -1s.
> >
> > Please remember that a binding +1 for GA implies that you intend to
> > support the release by applying patches and responding to posts to the
> > user and dev lists.
> >
> > Unless we decide otherwise, a beta vote implies that we will announce
> > the build to the user list, to encourage wider testing.
> >
> > -Ted.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
iDTV System Engineer
"Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live." - John F. Woods

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Rainer Hermanns-2]

+1 for beta as well.
We might have a problem with xwork and Java 1.4 compliancy as well.

Have a look at: http://jira.opensymphony.com/browse/XW-463

It looks like retroweaver does not translate ThreadLocal.remove() correctly.
We need to investigate retrotranslator for correct translation, since
retroweaver seems not to be working correctly here.

Does this problem effect Struts2 as well?

-Rainer

> On 1/30/07, Philip Luppens <philip.luppens@...> wrote:
>>
>> Can a problem in a dependency hold back a GA ? I'm talking about
>> WW-1615 [1] (OGNL race condition). The bugfix is trivial, but we need
>> a new release for that. Patrick should have set up Jesse by now (its
>> new maintainer), so we can expect an official bugfix release rather
>> soon.
>
>
> I would definitely say so, especially given OGNL's centrality to Struts 2,
> and given the way that using Maven to manage transitive dependencies would
> make it unclear at best as to how to guide people to use Struts 2.0.4 with
> a
> fixed version of OGNL.
>
> +1 beta
>
>
> --
> Joe Germuska
> Joe@... * http://blog.germuska.com
>
> "The truth is that we learned from João forever to be out of tune."
> -- Caetano Veloso
>

--
Rainer Hermanns
aixcept
Neupforte 16
52062 Aachen - Germany
w: http://aixcept.de/
t:    [phone]
m:  [phone]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Rainer Hermanns-2]

Thanks for the info Phil,
we should change xwork accordingly and release a new version very soon.

-Rainer

> On 1/30/07, Rainer Hermanns <hermanns@...> wrote:
>> +1 for beta as well.
>> We might have a problem with xwork and Java 1.4 compliancy as well.
>>
>> Have a look at: http://jira.opensymphony.com/browse/XW-463
>>
>> It looks like retroweaver does not translate ThreadLocal.remove()
>> correctly.
>> We need to investigate retrotranslator for correct translation, since
>> retroweaver seems not to be working correctly here.
>
> Sorry for going O/T here, but the Stripes guys appearantly hit the
> same issue [1].
>
> "Changed two uses of ThreadLocal.remove() to ThreadLocal.set(null).
> Done because
> these are basically the only major things not supported by Retroweaver in
> Stripes, and having made this change Stripes can be successfully run under
> Java
> 1.4 with Retroweaver."
>
> I've added a note to the Jira issue.
>
> Phil
>
> [1]
> http://www.mail-archive.com/stripes-development@.../msg00063.html
>
>>
>> Does this problem effect Struts2 as well?
>>
>> -Rainer
>>
>> > On 1/30/07, Philip Luppens <philip.luppens@...> wrote:
>> >>
>> >> Can a problem in a dependency hold back a GA ? I'm talking about
>> >> WW-1615 [1] (OGNL race condition). The bugfix is trivial, but we need
>> >> a new release for that. Patrick should have set up Jesse by now (its
>> >> new maintainer), so we can expect an official bugfix release rather
>> >> soon.
>> >
>> >
>> > I would definitely say so, especially given OGNL's centrality to
>> Struts 2,
>> > and given the way that using Maven to manage transitive dependencies
>> would
>> > make it unclear at best as to how to guide people to use Struts 2.0.4
>> with
>> > a
>> > fixed version of OGNL.
>> >
>> > +1 beta
>> >
>> >
>> > --
>> > Joe Germuska
>> > Joe@... * http://blog.germuska.com
>> >
>> > "The truth is that we learned from João forever to be out of tune."
>> > -- Caetano Veloso
>> >
>>
>>
>> --
>> Rainer Hermanns
>> aixcept
>> Neupforte 16
>> 52062 Aachen - Germany
>> w: http://aixcept.de/
>> t:    [phone]
>> m:  [phone]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
>
> --
> iDTV System Engineer
> "Always code as if the guy who ends up maintaining your code will be a
> violent psychopath who knows where you live." - John F. Woods
>

--
Rainer Hermanns
aixcept
Neupforte 16
52062 Aachen - Germany
w: http://aixcept.de/
t:    [phone]
m:  [phone]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Joe Germuska]

On 1/30/07, Philip Luppens <philip.luppens@...> wrote:
>
> Can a problem in a dependency hold back a GA ? I'm talking about
> WW-1615 [1] (OGNL race condition). The bugfix is trivial, but we need
> a new release for that. Patrick should have set up Jesse by now (its
> new maintainer), so we can expect an official bugfix release rather
> soon.


I would definitely say so, especially given OGNL's centrality to Struts 2,
and given the way that using Maven to manage transitive dependencies would
make it unclear at best as to how to guide people to use Struts 2.0.4 with a
fixed version of OGNL.

+1 beta


--
Joe Germuska
Joe@... * http://blog.germuska.com

"The truth is that we learned from João forever to be out of tune."
-- Caetano Veloso

[Philip Luppens]

On 1/30/07, Rainer Hermanns <hermanns@...> wrote:
> +1 for beta as well.
> We might have a problem with xwork and Java 1.4 compliancy as well.
>
> Have a look at: http://jira.opensymphony.com/browse/XW-463
>
> It looks like retroweaver does not translate ThreadLocal.remove() correctly.
> We need to investigate retrotranslator for correct translation, since
> retroweaver seems not to be working correctly here.

Sorry for going O/T here, but the Stripes guys appearantly hit the
same issue [1].

"Changed two uses of ThreadLocal.remove() to ThreadLocal.set(null).
Done because
these are basically the only major things not supported by Retroweaver in
Stripes, and having made this change Stripes can be successfully run under Java
1.4 with Retroweaver."

I've added a note to the Jira issue.

Phil

[1] http://www.mail-archive.com/stripes-development@.../msg00063.html

>
> Does this problem effect Struts2 as well?
>
> -Rainer
>
> > On 1/30/07, Philip Luppens <philip.luppens@...> wrote:
> >>
> >> Can a problem in a dependency hold back a GA ? I'm talking about
> >> WW-1615 [1] (OGNL race condition). The bugfix is trivial, but we need
> >> a new release for that. Patrick should have set up Jesse by now (its
> >> new maintainer), so we can expect an official bugfix release rather
> >> soon.
> >
> >
> > I would definitely say so, especially given OGNL's centrality to Struts 2,
> > and given the way that using Maven to manage transitive dependencies would
> > make it unclear at best as to how to guide people to use Struts 2.0.4 with
> > a
> > fixed version of OGNL.
> >
> > +1 beta
> >
> >
> > --
> > Joe Germuska
> > Joe@... * http://blog.germuska.com
> >
> > "The truth is that we learned from João forever to be out of tune."
> > -- Caetano Veloso
> >
>
>
> --
> Rainer Hermanns
> aixcept
> Neupforte 16
> 52062 Aachen - Germany
> w: http://aixcept.de/
> t:    [phone]
> m:  [phone]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
iDTV System Engineer
"Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live." - John F. Woods

[Tom Schneider]

I agree with Phil--we need an updated version of OGNL.  Last week I was
able to reproduce the OGNL race condition under JBoss on windows with
JDK 1.5.  If it was strictly limited to Websphere 5.1 under
Linux/Windows, I wouldn't be pushing so hard.  However, it looks like
it's more widespread than that.  (Phil's patched version of OGNL
resolved the issue)
Tom

Philip Luppens wrote:

> Can a problem in a dependency hold back a GA ? I'm talking about
> WW-1615 [1] (OGNL race condition). The bugfix is trivial, but we need
> a new release for that. Patrick should have set up Jesse by now (its
> new maintainer), so we can expect an official bugfix release rather
> soon.
>
> I guess I have some troubles with pushing a GA if such an important
> dependency is having a known bug. We're already aware of S2 being
> slower than S1, let's not kill whatever performance we have left with
> a race condition, even if it's caused by a dependency rather than the
> actual framework.
>
> Of course, if this has nothing to do with it, then just disregard this
> message.
>
> Cheers,
>
> Phil
>
> [1] https://issues.apache.org/struts/browse/WW-1615
>
> On 1/30/07, Don Brown <mrdon@...> wrote:
>> +1 for GA.  I've been pretty happy with this build and while there are
>> certainly things to improve (aren't there always?), I don't see anything
>> major that should prevent production applications from being built
>> upon it.
>>
>> Even if the final result is beta, will this release finally be put into
>> the public maven repository?
>>
>> Don
>>
>> Ted Husted wrote:
>> > Since the Struts 2.0.4 build is essentially the 2.0.3 build with Maven
>> > fixes, I thought we might as well start the vote. If after three days
>> > anyone needs more time, or we don't have a quorum, then we can just
>> > leave the vote open for as long as it takes.
>> >
>> > Release notes:
>> >    * http://struts.apache.org/2.x/docs/release-notes-204.html
>> >    * http://struts.apache.org/2.x/docs/release-notes-203.html
>> >
>> > Distribution:
>> >     * http://people.apache.org/builds/struts/2.0.4/
>> >
>> > Maven 2 staging repository:
>> >    *
>> http://people.apache.org/builds/struts/2.0.4/m2-staging-repository/
>> >
>> > Once you have had a chance to review the test build, please respond
>> > with a vote as to its quality:
>> >
>> >    [ ] Leave at test build
>> >    [ ] Alpha
>> >    [ ] Beta
>> >    [ ] General Availability (GA)
>> >
>> > Everyone who has tested the build is invited to vote. Votes by PMC
>> > members are considered binding. A vote passes if there are at least
>> > three binding +1s and more +1s than -1s.
>> >
>> > Please remember that a binding +1 for GA implies that you intend to
>> > support the release by applying patches and responding to posts to the
>> > user and dev lists.
>> >
>> > Unless we decide otherwise, a beta vote implies that we will announce
>> > the build to the user list, to encourage wider testing.
>> >
>> > -Ted.
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@...
>> > For additional commands, e-mail: dev-help@...
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[David H. DeWolf]

>    [ ] Leave at test build
>    [ ] Alpha
>    [X] Beta
>    [ ] General Availability (GA)
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Ted Husted]

The key notion behind "General Availability" is that we believe the
product is safe for the general public to use. By now, most of us know
that this set of bits work well in production, at least under the
configurations that we ourselves are using. General Availability means
that, as far as we know, there are not going to be any surprises
running it under any common configuration.

If a good portion of the general public is going to have problems
deploying this set of bits, then, yes, the reasonable thing would be
to not vote this release GA. But, that doesn't mean we can't
distribute it as a beta with known issues. The key question is whether
we want to encourage wider testing of the distribution by announcing
it to the user list.

We do have the release process down pat at this point, and I'd be
happy to roll 2.0.5 on any day of the week. We just need to get these
dependencies updated and other fixes applied. But, in the meantime,
that doesn't mean 2.0.4 can't go onto beta, to see if there's anything
else we should tweak.

-Ted.

On 1/30/07, Philip Luppens <philip.luppens@...> wrote:

> Can a problem in a dependency hold back a GA ? I'm talking about
> WW-1615 [1] (OGNL race condition). The bugfix is trivial, but we need
> a new release for that. Patrick should have set up Jesse by now (its
> new maintainer), so we can expect an official bugfix release rather
> soon.
>
> I guess I have some troubles with pushing a GA if such an important
> dependency is having a known bug. We're already aware of S2 being
> slower than S1, let's not kill whatever performance we have left with
> a race condition, even if it's caused by a dependency rather than the
> actual framework.
>
> Of course, if this has nothing to do with it, then just disregard this message.
>
> Cheers,
>
> Phil
>
> [1] https://issues.apache.org/struts/browse/WW-1615
>
> On 1/30/07, Don Brown <mrdon@...> wrote:
> > +1 for GA.  I've been pretty happy with this build and while there are
> > certainly things to improve (aren't there always?), I don't see anything
> > major that should prevent production applications from being built upon it.
> >
> > Even if the final result is beta, will this release finally be put into
> > the public maven repository?
> >
> > Don
> >
> > Ted Husted wrote:
> > > Since the Struts 2.0.4 build is essentially the 2.0.3 build with Maven
> > > fixes, I thought we might as well start the vote. If after three days
> > > anyone needs more time, or we don't have a quorum, then we can just
> > > leave the vote open for as long as it takes.
> > >
> > > Release notes:
> > >    * http://struts.apache.org/2.x/docs/release-notes-204.html
> > >    * http://struts.apache.org/2.x/docs/release-notes-203.html
> > >
> > > Distribution:
> > >     * http://people.apache.org/builds/struts/2.0.4/
> > >
> > > Maven 2 staging repository:
> > >    * http://people.apache.org/builds/struts/2.0.4/m2-staging-repository/
> > >
> > > Once you have had a chance to review the test build, please respond
> > > with a vote as to its quality:
> > >
> > >    [ ] Leave at test build
> > >    [ ] Alpha
> > >    [ ] Beta
> > >    [ ] General Availability (GA)
> > >
> > > Everyone who has tested the build is invited to vote. Votes by PMC
> > > members are considered binding. A vote passes if there are at least
> > > three binding +1s and more +1s than -1s.
> > >
> > > Please remember that a binding +1 for GA implies that you intend to
> > > support the release by applying patches and responding to posts to the
> > > user and dev lists.
> > >
> > > Unless we decide otherwise, a beta vote implies that we will announce
> > > the build to the user list, to encourage wider testing.
> > >
> > > -Ted.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@...
> > > For additional commands, e-mail: dev-help@...
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
>
>
> --
> iDTV System Engineer
> "Always code as if the guy who ends up maintaining your code will be a
> violent psychopath who knows where you live." - John F. Woods
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
HTH, Ted.
* http://www.husted.com/struts/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Ted Husted]

We're already using retrotranslator 1.2.0 with the -advanced switch.

On 1/30/07, Rainer Hermanns <hermanns@...> wrote:

> +1 for beta as well.
> We might have a problem with xwork and Java 1.4 compliancy as well.
>
> Have a look at: http://jira.opensymphony.com/browse/XW-463
>
> It looks like retroweaver does not translate ThreadLocal.remove() correctly.
> We need to investigate retrotranslator for correct translation, since
> retroweaver seems not to be working correctly here.
>
> Does this problem effect Struts2 as well?
>
> -Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Ian Roughley]

+1 beta



Ted Husted wrote:

> Since the Struts 2.0.4 build is essentially the 2.0.3 build with Maven
> fixes, I thought we might as well start the vote. If after three days
> anyone needs more time, or we don't have a quorum, then we can just
> leave the vote open for as long as it takes.
>
> Release notes:
>    * http://struts.apache.org/2.x/docs/release-notes-204.html
>    * http://struts.apache.org/2.x/docs/release-notes-203.html
>
> Distribution:
>     * http://people.apache.org/builds/struts/2.0.4/
>
> Maven 2 staging repository:
>    * http://people.apache.org/builds/struts/2.0.4/m2-staging-repository/
>
> Once you have had a chance to review the test build, please respond
> with a vote as to its quality:
>
>    [ ] Leave at test build
>    [ ] Alpha
>    [ ] Beta
>    [ ] General Availability (GA)
>
> Everyone who has tested the build is invited to vote. Votes by PMC
> members are considered binding. A vote passes if there are at least
> three binding +1s and more +1s than -1s.
>
> Please remember that a binding +1 for GA implies that you intend to
> support the release by applying patches and responding to posts to the
> user and dev lists.
>
> Unless we decide otherwise, a beta vote implies that we will announce
> the build to the user list, to encourage wider testing.
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Philip Luppens]

Thanks for the clarification.

+1 for beta.

Phil

On 1/30/07, Ted Husted <husted@...> wrote:

> The key notion behind "General Availability" is that we believe the
> product is safe for the general public to use. By now, most of us know
> that this set of bits work well in production, at least under the
> configurations that we ourselves are using. General Availability means
> that, as far as we know, there are not going to be any surprises
> running it under any common configuration.
>
> If a good portion of the general public is going to have problems
> deploying this set of bits, then, yes, the reasonable thing would be
> to not vote this release GA. But, that doesn't mean we can't
> distribute it as a beta with known issues. The key question is whether
> we want to encourage wider testing of the distribution by announcing
> it to the user list.
>
> We do have the release process down pat at this point, and I'd be
> happy to roll 2.0.5 on any day of the week. We just need to get these
> dependencies updated and other fixes applied. But, in the meantime,
> that doesn't mean 2.0.4 can't go onto beta, to see if there's anything
> else we should tweak.
>
> -Ted.
>
> On 1/30/07, Philip Luppens <philip.luppens@...> wrote:
> > Can a problem in a dependency hold back a GA ? I'm talking about
> > WW-1615 [1] (OGNL race condition). The bugfix is trivial, but we need
> > a new release for that. Patrick should have set up Jesse by now (its
> > new maintainer), so we can expect an official bugfix release rather
> > soon.
> >
> > I guess I have some troubles with pushing a GA if such an important
> > dependency is having a known bug. We're already aware of S2 being
> > slower than S1, let's not kill whatever performance we have left with
> > a race condition, even if it's caused by a dependency rather than the
> > actual framework.
> >
> > Of course, if this has nothing to do with it, then just disregard this message.
> >
> > Cheers,
> >
> > Phil
> >
> > [1] https://issues.apache.org/struts/browse/WW-1615
> >
> > On 1/30/07, Don Brown <mrdon@...> wrote:
> > > +1 for GA.  I've been pretty happy with this build and while there are
> > > certainly things to improve (aren't there always?), I don't see anything
> > > major that should prevent production applications from being built upon it.
> > >
> > > Even if the final result is beta, will this release finally be put into
> > > the public maven repository?
> > >
> > > Don
> > >
> > > Ted Husted wrote:
> > > > Since the Struts 2.0.4 build is essentially the 2.0.3 build with Maven
> > > > fixes, I thought we might as well start the vote. If after three days
> > > > anyone needs more time, or we don't have a quorum, then we can just
> > > > leave the vote open for as long as it takes.
> > > >
> > > > Release notes:
> > > >    * http://struts.apache.org/2.x/docs/release-notes-204.html
> > > >    * http://struts.apache.org/2.x/docs/release-notes-203.html
> > > >
> > > > Distribution:
> > > >     * http://people.apache.org/builds/struts/2.0.4/
> > > >
> > > > Maven 2 staging repository:
> > > >    * http://people.apache.org/builds/struts/2.0.4/m2-staging-repository/
> > > >
> > > > Once you have had a chance to review the test build, please respond
> > > > with a vote as to its quality:
> > > >
> > > >    [ ] Leave at test build
> > > >    [ ] Alpha
> > > >    [ ] Beta
> > > >    [ ] General Availability (GA)
> > > >
> > > > Everyone who has tested the build is invited to vote. Votes by PMC
> > > > members are considered binding. A vote passes if there are at least
> > > > three binding +1s and more +1s than -1s.
> > > >
> > > > Please remember that a binding +1 for GA implies that you intend to
> > > > support the release by applying patches and responding to posts to the
> > > > user and dev lists.
> > > >
> > > > Unless we decide otherwise, a beta vote implies that we will announce
> > > > the build to the user list, to encourage wider testing.
> > > >
> > > > -Ted.
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@...
> > > > For additional commands, e-mail: dev-help@...
> > > >
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@...
> > > For additional commands, e-mail: dev-help@...
> > >
> > >
> >
> >
> > --
> > iDTV System Engineer
> > "Always code as if the guy who ends up maintaining your code will be a
> > violent psychopath who knows where you live." - John F. Woods
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
>
>
> --
> HTH, Ted.
> * http://www.husted.com/struts/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
iDTV System Engineer
"Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live." - John F. Woods

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Rainer Hermanns-2]

Oki, so I change the xwork profile to use retrotranslater instead.
Thanks for the update,
Rainer

> We're already using retrotranslator 1.2.0 with the -advanced switch.
>
> On 1/30/07, Rainer Hermanns <hermanns@...> wrote:
>> +1 for beta as well.
>> We might have a problem with xwork and Java 1.4 compliancy as well.
>>
>> Have a look at: http://jira.opensymphony.com/browse/XW-463
>>
>> It looks like retroweaver does not translate ThreadLocal.remove()
>> correctly.
>> We need to investigate retrotranslator for correct translation, since
>> retroweaver seems not to be working correctly here.
>>
>> Does this problem effect Struts2 as well?
>>
>> -Rainer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
Rainer Hermanns
aixcept
Neupforte 16
52062 Aachen - Germany
w: http://aixcept.de/
t:    [phone]
m:  [phone]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Rene Gielen]

Hey guys,

a few minutes ago I came to the opinion that we have some major issues
with portlet integration, which imo should be fixed before rolling out
current build:

- Annotation based configuration for actions seems to fail at least in
my portlet environment (Liferay 4.2.1), resulting in infinite loop while
scanning for action classes in configured packages. Had no time to dig
deeper yet, but the issue is reproducible. I'll file an issue.

- ServletConfigInterceptor, along with PrincipalAware / PrincipalProxy
are not portlet aware. The implementation relies on access to
HttpServletRequest, but the Jsr168Dispatcher fails to put the
HttpServletRequest into action context (in fact there is a TODO in the
code!?!). The other (better: additional) option would be to make
PrincipalProxy HttpServletRequest independent, to deliver Principal
related information from PorletRequest, if applicable. We should really
consider this a major issue, preventing us from considering portlet
intergration (and therefore core) "ready for public". I'll file an issue
on that, too.

For that reason, currently my vote is:
 >    [x] Leave at test build
 >    [ ] Alpha
 >    [ ] Beta
 >    [ ] General Availability (GA)

- Rene

--
Rene Gielen  | http://it-neering.net/
Aachen       | PGP-ID: BECB785A
Germany      | gielen at it-neering.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Don Brown-2]

I believe we currently have portlet support as "experimental", so it
shouldn't affect the quality vote.

Don

Rene Gielen wrote:

> Hey guys,
>
> a few minutes ago I came to the opinion that we have some major issues
> with portlet integration, which imo should be fixed before rolling out
> current build:
>
> - Annotation based configuration for actions seems to fail at least in
> my portlet environment (Liferay 4.2.1), resulting in infinite loop
> while scanning for action classes in configured packages. Had no time
> to dig deeper yet, but the issue is reproducible. I'll file an issue.
>
> - ServletConfigInterceptor, along with PrincipalAware / PrincipalProxy
> are not portlet aware. The implementation relies on access to
> HttpServletRequest, but the Jsr168Dispatcher fails to put the
> HttpServletRequest into action context (in fact there is a TODO in the
> code!?!). The other (better: additional) option would be to make
> PrincipalProxy HttpServletRequest independent, to deliver Principal
> related information from PorletRequest, if applicable. We should
> really consider this a major issue, preventing us from considering
> portlet intergration (and therefore core) "ready for public". I'll
> file an issue on that, too.
>
> For that reason, currently my vote is:
> >    [x] Leave at test build
> >    [ ] Alpha
> >    [ ] Beta
> >    [ ] General Availability (GA)
>
> - Rene
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...