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
+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
On 1/30/07, Rainer Hermanns [EMAIL PROTECTED] 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
Thanks for the info Phil,
we should change xwork accordingly and release a new version very soon.
-Rainer
On 1/30/07, Rainer Hermanns [EMAIL PROTECTED] wrote:
+1 for beta as well.
We might have a problem with xwork and Java 1.4 compliancy as well.
Have a look at:
On 1/30/07, Rainer Hermanns [EMAIL PROTECTED] 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
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
[ ] Leave at test build
[ ] Alpha
[X] Beta
[ ] General Availability (GA)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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
We're already using retrotranslator 1.2.0 with the -advanced switch.
On 1/30/07, Rainer Hermanns [EMAIL PROTECTED] 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
+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
As it stands, we are marking a number of features and plugins
experimental, because they have not had wide enough testing. The 1.4
support should be labeled experimental too, since I don't think many
people have been trying it.
The J4 stuff is also a separate set of JARs, and we decided that the
Thanks for the clarification.
+1 for beta.
Phil
On 1/30/07, Ted Husted [EMAIL PROTECTED] 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
Does this infer that the only jar being voted on is the
struts2-core.jar? And if so, does this make sense - especially given
that all the DI options are in plugins.
/Ian
Ted Husted wrote:
As it stands, we are marking a number of features and plugins
experimental, because they have not had
On 1/30/07, Ian Roughley [EMAIL PROTECTED] wrote:
Does this infer that the only jar being voted on is the
struts2-core.jar? And if so, does this make sense - especially given
that all the DI options are in plugins.
Back in October, we had talked about listing the JARs
*
I have been looking through the s2 maven archetypes, and would like to
propose that we don't include resources that are at a package level
(i.e. validation and conversion). The reason being that maven2
currently does not support this feature (see
http://jira.codehaus.org/browse/ARCHETYPE-54),
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 [EMAIL PROTECTED] wrote:
+1 for beta as well.
We might have a problem with xwork and Java 1.4
If I move my JDK 1.4 project from S1 to S2 I'll keep note of any version
compatibility issues. There is... some resistance here to not using S1
so I make no guarantees, but I may just do it anyway.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Thanks for changing the slashes-in-paths docs
As far as I know, all the configuration settings are still documented
in the struts.properties file,
* http://struts.apache.org/2.x/docs/strutsproperties.html
Though, now, the preferred method is to use constant configuration
to set any of these.
*
From: [EMAIL PROTECTED]
As far as I know, all the configuration settings are still documented
in the struts.properties file,
* http://struts.apache.org/2.x/docs/strutsproperties.html
Though, now, the preferred method is to use constant configuration
to set any of these.
*
David Rupp wrote:
Hi, all.
I've submitted a patch to the XWork project (issue XW-470) that enables
per-method validations when using annotations. This is, IMO, an
improvement over the current behavior, with which all validations are
attached to the class, and *all* fire when *any* method is
It's something I actually will be needing in the near future. If no one
beats me, I'll probably take a look at the patch (late?) next week.
David
Laurie Harper wrote:
David Rupp wrote:
Hi, all.
I've submitted a patch to the XWork project (issue XW-470) that
enables per-method validations
21 matches
Mail list logo
