Re: struts/xwork patch submission. Please Review.

[Aymeric Levaux]

I reported a similar issue in Xwork JIRA months ago :
http://jira.opensymphony.com/browse/XW-521
The fix is identical.

-- 
Aymeric 

PS: I'm not able to reply threads from my mail account, they're just ignored 
(no errors). Any suggestions?


MassimoH wrote:
> 
> I've isolated a Struts 2 bug and I would like to suggest a code fix. The
> code fix is in an xwork class. I'm don't fully understand the xwork/struts
> distinction, but I assume I'm posting to the right list.
> 
> Here is the error scenario:
> 
> - DefaultActionInvocation calls all Interceptors which wind onto the Java
> call stack. Then DefaultActionInvocation calls the actual action itself.
> The action returns "success"
> - DefaultActionInvocation creates result object from this result code and
> executes the result
> - There is a problem in my FTL template, so FreeMarker throws a
> ParseException
> - Call stack unwinds to ExceptionMappingInterceptor which catches the
> exception, adds to OGNL value stack and returns "unhandledException"
> - DefaultActionInvocation simply re-executes the already created result
> object based on the original Action result.
> - The caching mechanism within FreeMarker detects a current timestamp and
> will either throw a FileNotFoundException (if the page isn't cached) or
> returns cached and out-of-date results. In either case, the original
> exception is lost and never logged. My exception action is also never
> executed.
> 
> This seems to be...
> 
> A small FreeMarker bug: it should rethrow ParseException when called a
> second time.
> A larger Struts 2 (or xwork) bug: Struts shouldn't ignore the first
> exception and simply rerun the result object. When Struts catches the
> original exception from the result, it should call the defined exception
> action.
> 
> 
> I suggest that the following three lines be removed from
> DefaultActionInvocation.java, line 174:
> 
>   if (result != null) {
>   return result;
>   }
> 
> I've tested this and I get the desired behavior. My exception action is
> called for the original exception. The xwork build reports no additional
> automated test failures. I got four test failures trying to build the
> standard xwork 2.0.4 distribution before making any changes, however my
> code change didn't affect these results. 
> 
> 
> Version Info
> Java 1.6.0_02
> Struts 2.0.9
> xwork 2.0.4
> 

-- 
View this message in context: 
http://www.nabble.com/struts-xwork-patch-submission.-Please-Review.-tf4558415.html#a13014849
Sent from the Struts - Dev mailing list archive at Nabble.com.


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

Re: 2.1.0 Build/Release Plan

[Ted Husted]

Thanks for keeping this going, Don. Decoupling OGNL as you've outlined
here and on the XWork Developers Forum is an important step forward.
And now that we have an XWork Developers forum, I'll start watching it
:)

On 10/2/07, Don Brown <[EMAIL PROTECTED]> wrote:
> I'm pretty much done, actually.   The only other major thing I was
> considering, but probably won't get to, was removing commons-logging.
> I'll try to spend some time to help close out 2.1 issues.
>
> Don
>
> On 10/2/07, Rainer Hermanns <[EMAIL PROTECTED]> wrote:
> > Don is busy with some important refactorings and enhancements for XWork 2.1.
> > But I think that until these already commited changes are fully tested and
> > stabilized, no xwork 2.1 release will happen.
> >
> > There are some other open xwork issues, that need to be addressed prior to
> > a release.
> >
> > cheers,
> > Rainer
> >
> > > 2007/9/28, Ted Husted <[EMAIL PROTECTED]>:
> > >>
> > >> I'd like to propose 7 Oct 2007 as a tag date for the 2.1.0 version. If
> > >> anyone would be interested in helping with the build, please don't be
> > >> shy!
> > >
> > >
> > >
> > > Ted, sincerely I wish to wait until XWork 2.1 is released, so we don't
> > > have
> > > any snapshot dependency.
> > >
> > > Antonio

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

Re: struts/xwork patch submission. Please Review.

[MassimoH]

Yes, that is the exact same issue and fix.

I take it that this issue wasn't high enough priority to be included in
previous xwork patch releases?


Aymeric Levaux wrote:
> 
> I reported a similar issue in Xwork JIRA months ago :
> http://jira.opensymphony.com/browse/XW-521
> The fix is identical.
> 
> -- 
> Aymeric 
> 
> PS: I'm not able to reply threads from my mail account, they're just
> ignored  (no errors). Any suggestions?
> 
> 
> MassimoH wrote:
>> 
>> I've isolated a Struts 2 bug and I would like to suggest a code fix. The
>> code fix is in an xwork class. I'm don't fully understand the
>> xwork/struts distinction, but I assume I'm posting to the right list.
>> 
>> Here is the error scenario:
>> 
>> - DefaultActionInvocation calls all Interceptors which wind onto the Java
>> call stack. Then DefaultActionInvocation calls the actual action itself.
>> The action returns "success"
>> - DefaultActionInvocation creates result object from this result code and
>> executes the result
>> - There is a problem in my FTL template, so FreeMarker throws a
>> ParseException
>> - Call stack unwinds to ExceptionMappingInterceptor which catches the
>> exception, adds to OGNL value stack and returns "unhandledException"
>> - DefaultActionInvocation simply re-executes the already created result
>> object based on the original Action result.
>> - The caching mechanism within FreeMarker detects a current timestamp and
>> will either throw a FileNotFoundException (if the page isn't cached) or
>> returns cached and out-of-date results. In either case, the original
>> exception is lost and never logged. My exception action is also never
>> executed.
>> 
>> This seems to be...
>> 
>> A small FreeMarker bug: it should rethrow ParseException when called a
>> second time.
>> A larger Struts 2 (or xwork) bug: Struts shouldn't ignore the first
>> exception and simply rerun the result object. When Struts catches the
>> original exception from the result, it should call the defined exception
>> action.
>> 
>> 
>> I suggest that the following three lines be removed from
>> DefaultActionInvocation.java, line 174:
>> 
>>  if (result != null) {
>>  return result;
>>  }
>> 
>> I've tested this and I get the desired behavior. My exception action is
>> called for the original exception. The xwork build reports no additional
>> automated test failures. I got four test failures trying to build the
>> standard xwork 2.0.4 distribution before making any changes, however my
>> code change didn't affect these results. 
>> 
>> 
>> Version Info
>> Java 1.6.0_02
>> Struts 2.0.9
>> xwork 2.0.4
>> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/struts-xwork-patch-submission.-Please-Review.-tf4558415.html#a13020278
Sent from the Struts - Dev mailing list archive at Nabble.com.


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

[ANN] Three Struts Tutorials or Presentations at ApacheCon US 2007 Atlanta GA

[Ted Husted]

Just a reminder that there will be several presentations of direct
interest to Struts developers at ApacheCon US 2007 Atlanta GA,
November 12-16.

 * http://apachecon.com/multi/index.html

Struts Courses (you must pre-register to attend!)

* Migrating to Ajax (Ted Husted), 12 Nov @10a (five-hour training course)
* Using Groovy with Struts 2 (Mark Menard), 13 Nov @10a (five-hour
training course)

Struts Presentation

* Go Light with Apache Struts 2 and REST (Don Brown), 15 Nov
@5:30p (one-hour presentation)

Also of interest (among many others!):

* Apache Roller and Blogs as a Web Development Platform (Dave
Johnson), 14 Nov @10:30a (one hour presentation)
* Apache Harmony - Building Java SE in Open source (Geir Magnusson
Jr.), 14 Nov @4:30p (one hour presentation)
* Comparing Java Web Frameworks (Matt Raible), 15 Nov @9a (one
hour presentation)

If you've been following dev@, you also know that several Struts
committers will be in Atlanta GA for the convention this year.

Hope to see you there!

-Ted.


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

Re: Exploring actionPackage-based configuration issues

[Eric D Nielsen]

I'm happy with a hybrid mix of XML and annotations; however 
something feels very wrong about using the package-info.java file 
for holding the XWork package level annotations, so I'm trying to 
think of alternatives.

I can understand the difficultly in using a new language concept that has
little mindshare but I think that this is the standard location for 
that kind of configuration according to the Java language. Besides, 
this is the only clean way to ensure a single location of package 
level annotations and documentation.

Yes, you're right.  I had just read some faulty tutorials explaining that new
feature only in the context of the "new" JavaDoc convention.  I didn't 
see that

it was added precisely for this type of use.



I think the root problem is that I'm not 100% comfortable with model of
the XWork Package.  As I see it so far, its a container for configuration
information and for some reason that bothers me.  I feel that there is an
application developer-exposed class waiting to be discovered.  This 
is probably more of a struts 2.1++ issue, but I think the notion of 
an XWork package is missing something.  (It might also be advisable 
over several releases to consider renaming the XWork package concept 
so its not as confusable with the java package, but that's an 
orthogonal issue.)
I definitely agree on the whole naming issue. It is difficult to talk 
to new developers about XWork packages without confusion. Are you 
suggesting that the XWork package needs more configuration control or 
that the concepts

need to be separated or something else entirely? You sorta lost me here.


I sorta lose myself here too, that's the problem.  An XWork package 
doesn't seem
to exist, other than ethereally.  See below, since I think my 
explanation makes

more sense in context with your next response.


This feeling of unease is slightly exacerbated by some of the 
difficulties I have debugging package issues -- ie when playing with 
zero configuration annotations and xml, there's does seem to be any 
good way to check what package an action has been assigned to 
confirm that defaults or annotations are working. config-browser 
exposes the namespace of an action, but not its package, for 
instance.  This leads to the feeling that the XWork package is a 
second-class citizen in the framework, but I know its not.

This is an interesting dilemma because the way XWork is configured implies
reuse at the Action level and that Actions should not be coupled to 
the interceptor chain (to some degree). However, this is usually not 
the case. Most Actions I write are highly dependent on the 
interceptor chain and nearly never dependent on the namespace and 
often never reused (that's what I usually place in the service tier). 
However, most times it is a
95%/5% situation where I use the same interceptor chain for 95% of 
the application and a different chain for 5% (or less). Therefore, 
global defaults usually work best for me.
This might not the norm, but my experience to date with 5 or so 
applications. Therefore, setting good global or XWork package 
defaults makes sense to me.


Not sure what I'm getting at but it seems that the current 
configuration model makes good sense and works for all the cases I've 
had.


In my admittedly limited experience, I tend to agree.  The original 
problem that

sparked this thread was that, outside of SmartURLs, there doesn't seem to be
good support (or documentation if there is support) for setting application
level defaults.  And this support really should be in core, regardless of the
plugin landscape.

Back to the general philosophical issue: If I'm reading your response 
correctly,
it sounds like your basically saying that good defaults + per action 
annotation
overrides covers almost all of your needs.  This to me, starts to make 
it sound
like the XWork package is a useless construct.  Or its bundling the 
wrong items

at the wrong level to allow the re-use it should.

It feels like while an XWork package might be an internal XWork 
abstraction, its

not one that should be exposed to the application developer -- some other
configuration/"action-configuration-template" mechanism should be 
created. What it should look like, I'm not sure.  It feels like we'd 
like to be able to

define global interceptor stacks as non-package contained entities, we'd like
to do the same for global results.  We'd like to be able to set a defined
global interceptor stack as the default stack.  Now there will be times 
when we

have some variants (your 5%) -- often alot of these will be singletons, each
different in their own way, but we probably still have a few clumps that need
identical tweaks ... this is where the XWork package concept could be useful,
possibly even as is, if the global/application-wide setup worked,



While I can see wanting some configuration control over the package --
changing namespaces; or the root of web content, in the case of 
SmartURLs; changing naming stra

Re: [struts-dev] [ANN] Three Struts Tutorials or Presentations at ApacheCon US 2007 Atlanta GA

[Dale Newfield]

Ted Husted wrote:

ApacheCon US 2007 Atlanta GA, November 12-16.


While I'm not rich enough to attend this event, I do live in Atlanta, 
and I'd welcome the opportunity to buy a round of beers for the folks 
responsible for Struts2 and AppFuse (Matt, do you read the struts-dev 
list?)...


...is this the type of convention where people spend the evenings out 
having nice meals/drinks with colleagues, or where people spend the 
evenings quietly hacking away on laptops?


-Dale Newfield
 [EMAIL PROTECTED]

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

Re: [struts-dev] [ANN] Three Struts Tutorials or Presentations at ApacheCon US 2007 Atlanta GA

[Frank W. Zammetti]

On Wed, October 3, 2007 1:33 pm, Dale Newfield wrote:
> ...is this the type of convention where people spend the evenings out
> having nice meals/drinks with colleagues, or where people spend the
> evenings quietly hacking away on laptops?

You say that as if they're mutually exclusive :)  True geeks can do both
at the same time without a problem! LOL

> -Dale Newfield
>   [EMAIL PROTECTED]

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Author of "Practical Ajax Projects With Java Technology"
 (2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
 (2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
 Supplying the wheel, so you don't have to reinvent it!

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

Re: [struts-dev] [ANN] Three Struts Tutorials or Presentations at ApacheCon US 2007 Atlanta GA

[Dave Newton]

"Frank W. Zammetti" wrote:
> Dale Newfield wrote:
>> ...is this the type of convention where people
>> spend the evenings out having nice meals/drinks 
>> with colleagues, or where people spend the
>> evenings quietly hacking away on laptops?
> You say that as if they're mutually exclusive :) 
> True geeks can do both at the same time without a 
> problem! LOL

Oh... I've usually spent them quietly hacking away on
my colleagues and having nice meals with my laptop.

This explains a lot.

d.


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

Re: [struts-dev] [ANN] Three Struts Tutorials or Presentations at ApacheCon US 2007 Atlanta GA

[Musachy Barroso]

Friends don't let friends drink and code. Is it friday yet?

musachy

On 10/3/07, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> On Wed, October 3, 2007 1:33 pm, Dale Newfield wrote:
> > ...is this the type of convention where people spend the evenings out
> > having nice meals/drinks with colleagues, or where people spend the
> > evenings quietly hacking away on laptops?
>
> You say that as if they're mutually exclusive :)  True geeks can do both
> at the same time without a problem! LOL
>
> > -Dale Newfield
> >   [EMAIL PROTECTED]
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM/Yahoo: fzammetti
> MSN: [EMAIL PROTECTED]
> Author of "Practical Ajax Projects With Java Technology"
>  (2006, Apress, ISBN 1-59059-695-1)
> and "JavaScript, DOM Scripting and Ajax Projects"
>  (2007, Apress, ISBN 1-59059-816-4)
> Java Web Parts - http://javawebparts.sourceforge.net
>  Supplying the wheel, so you don't have to reinvent it!
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
"Hey you! Would you help me to carry the stone?" Pink Floyd

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

Re: [struts-dev] [ANN] Three Struts Tutorials or Presentations at ApacheCon US 2007 Atlanta GA

[Dave Newton]

--- Musachy Barroso <[EMAIL PROTECTED]> wrote:
> Friends don't let friends drink and code.

Au contraire!

http://xkcd.com/323/

d.


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

Re: [struts-dev] [ANN] Three Struts Tutorials or Presentations at ApacheCon US 2007 Atlanta GA

[Wes Wannemacher]

On 10/3/07, Musachy Barroso <[EMAIL PROTECTED]> wrote:
> Friends don't let friends drink and code. Is it friday yet?
>
> musachy
>

That's right, Musachy, otherwise you'll end up with WindowsME

http://imgs.xkcd.com/comics/ballmer_peak.png


-- 
Wesley Wannemacher
President, Head Engineer/Consultant
WanTii, Inc.
http://www.wantii.com

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

Re: [struts-dev] [ANN] Three Struts Tutorials or Presentations at ApacheCon US 2007 Atlanta GA

[Matt Raible]

On 10/3/07, Dale Newfield <[EMAIL PROTECTED]> wrote:
> Ted Husted wrote:
> > ApacheCon US 2007 Atlanta GA, November 12-16.
>
> While I'm not rich enough to attend this event, I do live in Atlanta,
> and I'd welcome the opportunity to buy a round of beers for the folks
> responsible for Struts2 and AppFuse (Matt, do you read the struts-dev
> list?)...

I do read this list and would love to have a beer - especially if
you're buying. ;-)

Is there a Struts BOF planned? If so, we should find a sponsor to
provide beers. I've done this in the past and it's always been well
received.

Matt

>
> ...is this the type of convention where people spend the evenings out
> having nice meals/drinks with colleagues, or where people spend the
> evenings quietly hacking away on laptops?
>
> -Dale Newfield
>   [EMAIL PROTECTED]
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
http://raibledesigns.com

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

Re: Exploring actionPackage-based configuration issues

[Eric D Nielsen]

[Please excuse if this appears twice, the copy I sent several hours ago seems to
have gotten lost and my webmail client does drop emails at times]

>> I'm happy with a hybrid mix of XML and annotations; however
>> something feels very wrong about using the package-info.java file
>> for holding the XWork package level annotations, so I'm trying to
>> think of alternatives.
> I can understand the difficultly in using a new language concept that has
> little mindshare but I think that this is the standard location for
> that kind of configuration according to the Java language. Besides,
> this is the only clean way to ensure a single location of package
> level annotations and documentation.
Yes, you're right.  I had just read some faulty tutorials explaining that new
feature only in the context of the "new" JavaDoc convention.  I didn't
see that it was added precisely for this type of use.


>> I think the root problem is that I'm not 100% comfortable with model of
>> the XWork Package.  As I see it so far, its a container for configuration
>> information and for some reason that bothers me.  I feel that there is an
>> application developer-exposed class waiting to be discovered.  This
>> is probably more of a struts 2.1++ issue, but I think the notion of
>> an XWork package is missing something.  (It might also be advisable
>> over several releases to consider renaming the XWork package concept
>> so its not as confusable with the java package, but that's an
>> orthogonal issue.)
> I definitely agree on the whole naming issue. It is difficult to talk
> to new developers about XWork packages without confusion. Are you
> suggesting that the XWork package needs more configuration control or
> that the concepts
> need to be separated or something else entirely? You sorta lost me here.

I sorta lose myself here too, that's the problem.  An XWork package
doesn't seem to exist, other than ethereally.  See below, since I think my
explanation makes more sense in context with your next response.


>> This feeling of unease is slightly exacerbated by some of the
>> difficulties I have debugging package issues -- ie when playing with
>> zero configuration annotations and xml, there's does seem to be any
>> good way to check what package an action has been assigned to
>> confirm that defaults or annotations are working. config-browser
>> exposes the namespace of an action, but not its package, for
>> instance.  This leads to the feeling that the XWork package is a
>> second-class citizen in the framework, but I know its not.
> This is an interesting dilemma because the way XWork is configured implies
> reuse at the Action level and that Actions should not be coupled to
> the interceptor chain (to some degree). However, this is usually not
> the case. Most Actions I write are highly dependent on the
> interceptor chain and nearly never dependent on the namespace and
> often never reused (that's what I usually place in the service tier).
> However, most times it is a
> 95%/5% situation where I use the same interceptor chain for 95% of
> the application and a different chain for 5% (or less). Therefore,
> global defaults usually work best for me.
> This might not the norm, but my experience to date with 5 or so
> applications. Therefore, setting good global or XWork package
> defaults makes sense to me.
>
> Not sure what I'm getting at but it seems that the current
> configuration model makes good sense and works for all the cases I've
> had.

In my admittedly limited experience, I tend to agree.  The original
problem that sparked this thread was that, outside of SmartURLs, there doesn't
seem to be good support (or documentation if there is support) for setting
application level defaults.  And this support really should be in core,
regardless of the plugin landscape.

Back to the general philosophical issue: If I'm reading your response
correctly, it sounds like your basically saying that good defaults + per action
annotation overrides covers almost all of your needs.  This to me, starts to
make it sound like the XWork package is a useless construct.  Or its bundling
the wrong items at the wrong level to allow the re-use it should.

It feels like while an XWork package might be an internal XWork
abstraction, its not one that should be exposed to the application developer --
some other configuration/"action-configuration-template" mechanism should be
created. What it should look like, I'm not sure.  It feels like we'd
like to be able to define global interceptor stacks as non-package contained
entities, we'd like to do the same for global results.  We'd like to be able to
set a defined global interceptor stack as the default stack.  Now there will be
times  when we have some variants (your 5%) -- often alot of these will be
singletons, each different in their own way, but we probably still have a few
clumps that need identical tweaks ... this is where the XWork package concept
could be useful, possibly even as is, if the gl