Re: accessing ognl from jsp 2.0 el?

[John M Flinchbaugh <jo...@hjsoft.com>]

Synopsis:
FilterDispatcher may not cleanup completely and causes the
StrutsRequestWrapper to be omitted in some executions (race condition).
Adding ActionContextCleanUp filter seems to alleviate the issue.  As
advertized, I'd expect FilterDispatcher to be able to function on its
own.

Long story:
In a previous message (which I linked/included below), I expressed my
trouble with accessing values from the ValueStack from JSP 2.0 EL.  Upon
reloading, the EL values would come back null sometimes, and other times
populated.

After a bit of debugging, I found that the StrutsRequestWrapper was not
always being wrapped around the request object we get from tomcat.  When
this was missing, I'd obviously not have access to the value stack.

It seemed to be a bit of a race condition where the FilterDispatcher
would decide we already had a Dispatcher (du) object (see
FilterDispatcher, line 311).  Firefox requesting both the action and the
stylesheet (2 requests) seemed to trigger the race where one request
would initialize the null Dispatcher (possibly incompletely clean it up),
and the other request would get the old Dispatcher instance so it
would just proceed with the unwrapped request object.

I was using the FilterDispatcher by itself, and I think it may have
failed to cleanup everything for itself and sometimes that incomplete
Dispatcher would leak into the other request.

When I added the ActionContextCleanUp filter to the web.xml, the
StrutsRequestWrapper seems to be used reliably.

-- 
John M Flinchbaugh
john@hjsoft.com

http://www.nabble.com/accessing-ognl-from-jsp-2.0-el--tf3671805.html
-- cut --

In webwork, I had become accustomed to having a getXyz() method on an
action, and being able to just access it in jsp as ${xyz}.  The ability
was just built in, per:
http://wiki.opensymphony.com/display/WW/Using+WebWork+and+XWork+with+JSP+2.
0+and+JSTL+1.1

Struts 2 has this same page without the note about it being automatic:
http://struts.apache.org/2.x/docs/using-struts-and-xwork-with-jsp-20-and-js
tl-11.html

Is the Struts doc up-to-date?  Is it really required that I expose them
manually?  Here's where it gets wierd:

I've had to look this all up, because I've seen in Struts 2.0.6 evaluate
${xyz} just fine without any extra work, just as I had seen in webwork,
but it doesn't work reliably.  At times, I'll reload, and see all the
ognl values (referenced as el) disappear from the screen!  What is
happening?!  Reload a couple more times, and they come back!  It's quite
perplexing.  

Putting a <s:set name = "xyz" value = "xyz"/> makes it stick reliably.  
Using ognl-aware tags also work reliably.  I found this hint here:
http://struts.apache.org/2.x/docs/exposing-framework-objects-to-jstl-with-a
-jstl-and-displaytag-example.html

Thanks for any help you may be able to provide. 

Re: accessing ognl from jsp 2.0 el?

[Bryan Taylor <br...@yahoo.com>]

Could this be related to WW-1816 FitlerDispatcher not always calling
ActionContextCleanUp.cleanUp(Request)?

--- John M Flinchbaugh <jo...@hjsoft.com> wrote:

> Synopsis:
> FilterDispatcher may not cleanup completely and causes the
> StrutsRequestWrapper to be omitted in some executions (race condition).
> Adding ActionContextCleanUp filter seems to alleviate the issue.  As
> advertized, I'd expect FilterDispatcher to be able to function on its
> own.
> 
> Long story:
> In a previous message (which I linked/included below), I expressed my
> trouble with accessing values from the ValueStack from JSP 2.0 EL.  Upon
> reloading, the EL values would come back null sometimes, and other times
> populated.
> 
> After a bit of debugging, I found that the StrutsRequestWrapper was not
> always being wrapped around the request object we get from tomcat.  When
> this was missing, I'd obviously not have access to the value stack.
> 
> It seemed to be a bit of a race condition where the FilterDispatcher
> would decide we already had a Dispatcher (du) object (see
> FilterDispatcher, line 311).  Firefox requesting both the action and the
> stylesheet (2 requests) seemed to trigger the race where one request
> would initialize the null Dispatcher (possibly incompletely clean it up),
> and the other request would get the old Dispatcher instance so it
> would just proceed with the unwrapped request object.
> 
> I was using the FilterDispatcher by itself, and I think it may have
> failed to cleanup everything for itself and sometimes that incomplete
> Dispatcher would leak into the other request.
> 
> When I added the ActionContextCleanUp filter to the web.xml, the
> StrutsRequestWrapper seems to be used reliably.
> 
> -- 
> John M Flinchbaugh
> john@hjsoft.com


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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