God yes, Don. Please don't let them go nuts again. Here you are in the
reach of sanity. Stay the course!
On 6/28/06, Don Brown [EMAIL PROTECTED] wrote:
I'm against official code names. We have had enough confusion in Struts
with
different names meaning different things, and we shouldn't
Heh, you voted him in. He is all yours.
On 6/28/06, Michael Jouravlev [EMAIL PROTECTED] wrote:
You mean, Struts 2.0 version 2.0, then Struts 2.0 version 2.1, Struts
2.0 version 2.2, ..., Struts 2.0 version 3.0, ..., Struts 2.0 version
4.0
:-)
2.0 is a version number, while we are choosing
Heh, what about Struts? That might work? And, then, like the rest of the
world, you could have versions like 1.* and 2.*, and 3.*. Oh, that was the
proposal which the newly knighted can't seem to stomach. Too rational.
On 6/28/06, Paul Benedict [EMAIL PROTECTED] wrote:
I am very much
Things will never be simple with MJ on the team. This is typical. Learn to
live with it.
On 6/28/06, Michael Jouravlev [EMAIL PROTECTED] wrote:
In this case we are returning to a half-year old situation, that is,
Struts 2 is a new crown holder of a single unified project. Consider
the
Heh, yah, almost like real versioning, eh?
On 6/28/06, Paul Benedict [EMAIL PROTECTED] wrote:
My two cents: I am okay with 1.x and 2.x numbering. It doesn't bother me.
I look at them in terms of generations; different people who can live
together in one family (webapp).
Michael Jouravlev
Yah, engineers will understand this. In fact, the only people in the world
that seem to have trouble with it are Struts committers. The fact that
people can seriously debate the efficacy of standard versioning is amazing.
On 6/28/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:
That's a good
Give it up! Lord! What nonsense. Do you hate versioning, Paul?
On 6/28/06, Paul Benedict [EMAIL PROTECTED] wrote:
I am guessing the winner is going to be struts1/struts2
So if struts1 is:
org.apache.struts
If struts2:
org.apache.struts2
?
Niall Pemberton [EMAIL PROTECTED] wrote: On
Joe,
Could Struts 1.3 set up to have a separate chain per module? Suppose you
wanted to partition your app so that certain parts use one chain
configuration and other parts use another. In 1.2 you'd use separate
subclasses of RequestProcessor. With Struts 1.3, ideally you should be
able to
That's exactly what Struts 2 does with interceptors, and S2 takes it a
step farther by allowing each action to have its own sequence, if you
like.
An important question is whether we want to stick with Chain in the
Struts 1.x series or consider moving to Interceptors for Struts 1.4.
I didn't
At 9:07 AM +0100 6/30/06, Phil Zoio wrote:
Joe,
Could Struts 1.3 set up to have a separate chain per module?
Phil: I thought we discussed this two weeks ago. In short, the
answer is yes. Looking back at what I wrote, perhaps I gave too
much detail at the wrong time. Here is the core of
On 6/28/06, Don Brown [EMAIL PROTECTED] wrote:
Ted Husted wrote:
Though, there's no reason why we couldn't use
repos/asf/struts/struts1
repos/asf/struts/struts2
Or
repos/asf/struts/framework
repos/asf/struts/framework2
I like struts1/struts2.
Or, in the interest of brevity,
(from the peanut gallery)
How about:
repos/asf/struts/branches/struts-1.3/...
repos/asf/struts/trunk (2.0, 2.1, 3.0 goes here)
It's not like you're the first project here to have had a 1.3 v 2.0 issue :)
http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/
Cheers,
Brett
On 30/06/06,
If we do not have different package names, we cannot run both Struts 1 and
Struts 2 in the same web application. So it's very important to encode the
version into the pacakge structure. Otherwise, the migration path to Struts 2
is all or none. This is not a unique idea; this has been espoused
On 6/30/06, Brett Porter [EMAIL PROTECTED] wrote:
(from the peanut gallery)
How about:
repos/asf/struts/branches/struts-1.3/...
repos/asf/struts/trunk (2.0, 2.1, 3.0 goes here)
Yep, and different teams have tried different approaches :)
Maven has maven-1 under the root
*
Cool...I'll try that and see how it goes. Many thanks...
If I might ask though, is there a specific opposition to having the
standard ActionServlet clean up the RequestProcessor instances from the
ServletContext as it does plugins and ModuleConfigs?
Paul Benedict wrote:
Andy:
Use this as
On Jun 30, 2006, at 9:58 AM, Ted Husted wrote:
Now, in place of Tapestry4 and Tapestry5. we now have
struts-action and struts-action2
* http://svn.apache.org/viewvc/struts/
which we could just rename to struts1 and struts2.
That sounds good to me.
I was just asking if we wanted to make
Greg Reddin sagely replied:
On Jun 30, 2006, at 9:58 AM, Ted Husted wrote:
Now, in place of Tapestry4 and Tapestry5. we now have
struts-action and struts-action2
* http://svn.apache.org/viewvc/struts/
which we could just rename to struts1 and struts2.
That sounds good to me.
On 6/29/06, Paul Benedict [EMAIL PROTECTED] wrote:
I am guessing the winner is going to be struts1/struts2
So if struts1 is:
org.apache.struts
If struts2:
org.apache.struts2
?
Yes, the other piece of surgery would be moving
I only have an inclination against s1/s2. Otherwise, struts/struts2 or
struts1/struts2 or action1/action2 is fine by me.
Ted Husted [EMAIL PROTECTED] wrote: On 6/30/06, Brett Porter
wrote:
(from the peanut gallery)
How about:
repos/asf/struts/branches/struts-1.3/...
repos/asf/struts/trunk
Joe Germuska [EMAIL PROTECTED] wrote:That said, I don't think you should not
do the work you describe,
just because you may have to leave the Localizer (or whatever you
call it) in the ServletContext under a well known key. It's just
that it feels so outdated!
Here's my solution. Unless
On 6/30/06, Paul Benedict [EMAIL PROTECTED] wrote:
Joe Germuska [EMAIL PROTECTED] wrote:That said, I don't think you should not
do the work you describe,
just because you may have to leave the Localizer (or whatever you
call it) in the ServletContext under a well known key. It's just
that it
From memory (WW in Action) there seems to be similar concepts in
Cintoo messages that WW/SAF2 has - but I was hoping someone who knows
would comment.
The license is Apache 2 and it looks good to me - is this something
that SAF2 would benefit from or is that area already well covered?
Actually, I take that back -- the sample code on their page uses Java
5. I don't know if the library itself requires it.
Hubert
On 6/30/06, Hubert Rabago [EMAIL PROTECTED] wrote:
It looks like it requires Java 5. Has there been a decision to move
SAF2 to Java 5?
Hubert
On 6/30/06, Niall
Some further reflections:
WW and SPR both use ThreadLocal to store the locale of the thread's request.
However, there still needs to be a shared object that can set/retrieve the
local across web frameworks.
So I 100% agree with the ThreadLocal use, but it is not directly relevant to my
No, but there was talk of doing it and using retro-do-dah
(translator/weaver) I think. Can't remember where that discussion
went.
Niall
On 6/30/06, Hubert Rabago [EMAIL PROTECTED] wrote:
It looks like it requires Java 5. Has there been a decision to move
SAF2 to Java 5?
Hubert
On 6/30/06,
On 6/30/06, Hubert Rabago [EMAIL PROTECTED] wrote:
It looks like it requires Java 5. Has there been a decision to move
SAF2 to Java 5?
* http://wiki.apache.org/struts/StrutsActionRelease200
The platform for SAF 2.0.x is Java 1.5, with Java 1.4 compatibity
provided by Retroweaver.
-T.
Ahh, ok. Thanks for clarifying that.
I was not able to follow that discussion to the end.
(Looks like I'm not the only one.)
Hubert
On 6/30/06, Ted Husted [EMAIL PROTECTED] wrote:
On 6/30/06, Hubert Rabago [EMAIL PROTECTED] wrote:
It looks like it requires Java 5. Has there been a decision
From memory (WW in Action) there seems to be similar
concepts in
Cintoo messages that WW/SAF2 has - but I was hoping
someone who knows
would comment.
The license is Apache 2 and it looks good to me - is
this something
that SAF2 would benefit from or is that area already
well covered?
If Struts 1 decided to go with Cintoo, I think it would be good for Struts 2 to
adopt it as well, as it would make migration easier, and reduce the number of
differences between the two versions. I'd like to take that approach with other
areas like validation and annotations in the future.
Does anyone know how to setup the roadmap on JIRA so we can see all the
fixed/outstanding defects that are going into 1.3.5? Right now the roadmap
contains Struts 0.5 and the nightly build.
Paul
-
How low will we go? Check out Yahoo! Messengers
You need to click on the All Versions link, as JIRA thinks those three are the
next versions to be released.
Don
Paul Benedict wrote:
Does anyone know how to setup the roadmap on JIRA so we can see all the
fixed/outstanding defects that are going into 1.3.5? Right now the roadmap
contains
At 11:36 AM -0700 6/30/06, Paul Benedict wrote:
Some further reflections:
WW and SPR both use ThreadLocal to store the locale of the thread's
request. However, there still needs to be a shared object that can
set/retrieve the local across web frameworks.
So I 100% agree with the ThreadLocal
On 6/30/06, Paul Benedict [EMAIL PROTECTED] wrote:
Does anyone know how to setup the roadmap on JIRA so we can see all the
fixed/outstanding defects that are going into 1.3.5? Right now the roadmap
contains Struts 0.5 and the nightly build.
Link?
On the 1.3.5 release plan, there is a link
Sorry for the question. I should have seen the next 3 versions thing. I guess
my question was because I was looking for the next 3 versions -- hoping 1.3.5
would be there. Any idea why that's not within the 3?
Wendy Smoak [EMAIL PROTECTED] wrote: On 6/30/06, Paul Benedict
wrote:
Does anyone
On 6/30/06, Paul Benedict [EMAIL PROTECTED] wrote:
I should have seen the next 3 versions thing. I guess my question was because I
was looking for the next 3 versions -- hoping 1.3.5 would be there. Any idea
why that's not within the 3?
My guess is that it has something to do with Manage
At 1:01 PM -0700 6/30/06, Paul Benedict wrote:
Joe,
First, thanks for pointing out cintoo. I looked at the source and it
seems like it could be something s1/2 could share together. Are you
interested in investigating this with me? Is anyone else?
that wasn't me :) I don't have a ton of
-Original Message-
From: Wendy Smoak [mailto:[EMAIL PROTECTED]
Sent: 30. juni 2006 22:31
To: Struts Developers List
Subject: Re: Struts JIRA Roadmap
On 6/30/06, Paul Benedict [EMAIL PROTECTED] wrote:
I should have seen the next 3 versions thing. I guess my
question was
Would it be good practice to link to the JIRA version report on each release in
the release notes? This has the best bug listing I've seen; bugzilla is not
nearly as nice.
Anders Steinlein [EMAIL PROTECTED] wrote: -Original Message-
From: Wendy Smoak [mailto:[EMAIL PROTECTED]
Sent:
Missing AbstractInterceptor. Anybody have any clues?
Bob
That's a file I put in xwork, but it says it was checked in. I'll look into it
more later when I get home.
Don
Bob Lee wrote:
Missing AbstractInterceptor. Anybody have any clues?
Bob
-
To unsubscribe, e-mail: [EMAIL
Yes, but we should let one framework go first, and prove something
works in practices, before adopting something new in both
On 6/30/06, Don Brown [EMAIL PROTECTED] wrote:
If Struts 1 decided to go with Cintoo, I think it would be good for Struts 2 to
adopt it as well, as it would make
What does Clintoo do that standard ThreadLocal cannot? I am trying to
understand the benefit here of this package.
Ted Husted [EMAIL PROTECTED] wrote: Yes, but we should let one framework go
first, and prove something
works in practices, before adopting something new in both
On 6/30/06, Don
On 6/30/06, Paul Benedict [EMAIL PROTECTED] wrote:
Would it be good practice to link to the JIRA version report on each release in
the release
notes? This has the best bug listing I've seen; bugzilla is not nearly as nice.
With Confluence, you can embed a JIRA report in the web page as a live
On 6/30/06, Alexandru Popescu [EMAIL PROTECTED] wrote:
I am not sure I understand this proposal. As far as I know this is
already supported by WW and quite nicely. So, why would we want to add
just another dependency?
Well,
Naill asked if Clintoo did anything that Struts 2 didn't already do
On 6/30/06, Paul Benedict [EMAIL PROTECTED] wrote:
What does Clintoo do that standard ThreadLocal cannot? I am trying to
understand the benefit here of this package.
For one thing, it introduces funky syntax that I personally dislike. ;-)
Using '$' and '_' as method names isn't my idea of
On 6/29/06, Craig McClanahan [EMAIL PROTECTED] wrote:
The CargoTestSetup class that you added to the test framework (was this
Wendy's first commit of Java code? :-) nicely leverages the fact that Cargo
will figure out which container to use based on system properties
(specifically
46 matches
Mail list logo
