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 "cargo.cont
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 c
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:
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 liv
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?
./alex
--
.w( the_mindstorm )p.
---
(http://themindstorms.blogspot.com)
On 6/30/06, Don Brown <[EMAIL PROTECTED]> wrote:
If Struts
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 B
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 migrati
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 PROT
Missing AbstractInterceptor. Anybody have any clues?
Bob
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]
> Se
> -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
> questi
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 spar
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 V
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?
Second, placing the logic in a SetLocale command is fine, but it would be
nothing more than de
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 anyo
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
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
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
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
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.
Do
> 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 co
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 decis
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.
--
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
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
questi
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 P
It looks like it requires Java 5. Has there been a decision to move
SAF2 to Java 5?
Hubert
On 6/30/06, Niall Pemberton <[EMAIL PROTECTED]> wrote:
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
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?
http://mes
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 i
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 any
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
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
http://svn.apache.org/viewvc/struts/action2/trunk/core/src/main/j
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".
>
>
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 want
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 y
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
* http://svn.apache
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 by
(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, T
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
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 o
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 und
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 us
42 matches
Mail list logo
