Obvious: Because you can't access the HttpServletRequest from within the
RequestFilter to access methods such as getRequestUri() (needed by 3rd party
library being called in the filter).
If I didn't have access to the ASO manager, then I could write up the filter
as a traditional Servlet filter. Why bother with the Tapestry filter chain
in the first place? Or do I need to configure my servletRequestFilter to be
"after" some other filter? If so, where do I find the list of these "after"
"before" definitions?
----- Original Message -----
From: "Robert Zeigler" <[EMAIL PROTECTED]>
To: "Tapestry users" <users@tapestry.apache.org>
Sent: Tuesday, May 13, 2008 10:43 AM
Subject: Re: T5: ASO in HttpServletRequestFilter
Why not use a RequestFilter, instead?
You can access the ApplicationStateManager from withing a RequestFilter.
Robert
On May 13, 2008, at 5/139:41 AM , kranga wrote:
Version: 5.0.11
It appears that if you inject an application state manager into an
HttpServletRequestFilter and try to access an ASO, you get a null
pointer exception since the Tapestry Request object has still not been
set up. This means that if you do need to access an ASO, you are forced
to use the session directly (and hence the session from within your
pages too).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
