[ http://issues.apache.org/jira/browse/TAPESTRY-695?page=all ]
Howard M. Lewis Ship resolved TAPESTRY-695:
-------------------------------------------
Resolution: Won't Fix
Assign To: Howard M. Lewis Ship
The reason the behavior is the way it is, is that the intent of the pipelines
is that a filter may *substitute* a different instance of WebRequest or
WebResponse. This happens in the ServletRequestServicerPipeline, for example,
with multipart form submissions (a new request is provided that includes the
query parameters and values from the multipart request). Therefore, the intent
is that the request and response are not "final" until the terminator is
reached, and it is the pipeline terminator that installs these final objects
into the RequestGlobals.
Perhaps what we need is a *third* pipeline, between setting the globals, and
invoking the engine.
However, between this rationale (alas, only documented here) and the evident
workaround, there is no *pressing* need to fix this bug.
> WebRequestServicerFilter lacks support for tapestry.globals.*
> -------------------------------------------------------------
>
> Key: TAPESTRY-695
> URL: http://issues.apache.org/jira/browse/TAPESTRY-695
> Project: Tapestry
> Type: Bug
> Components: Framework, Web
> Reporter: Peter Ertl
> Assignee: Howard M. Lewis Ship
>
> problem description:
> step 1: let there be an "Authenticator" service which uses the current
> request (for credentials lookup)
> // ----------------------------------------------------------
> <service-point id="Authenticator">
> <invoke-factory model="threaded">
> <construct class="AuthenticatorImpl">
> <set-service property="request"
> service-id="tapestry.globals.WebRequest" />
> </construct>
> </invoke-factory>
> </service-point>
> // ----------------------------------------------------------
> public class AuthenticatorImpl implements Authenticator
> {
> private WebRequest request; // injected
> // setters + other stuff omitted
>
> public boolean isAuthenticated()
> {
> if(request.getSession(false) == null)
> return false;
>
> // more stuff comes here...
> }
> }
> // ----------------------------------------------------------
> step 2: now inject the authenticator into a request filter
> // ----------------------------------------------------------
> <service-point id="AuthenticationFilter"
> interface="org.apache.tapestry.services.WebRequestServicerFilter">
> <invoke-factory>
> <construct class="AuthenticationFilter">
> <set-service property="authenticator" service-id="Authenticator" />
> </construct>
> </invoke-factory>
> </service-point>
>
> <contribution
> configuration-id="tapestry.request.WebRequestServicerPipeline">
> <filter name="auth" object="service:AuthenticationFilter" />
> </contribution>
>
> // ----------------------------------------------------------
> public class AuthenticationFilter implements WebRequestServicerFilter
> {
> private Authenticator authenticator; // injected
>
> // setters + other stuff omitted
>
> public void service(WebRequest request, WebResponse response,
> WebRequestServicer servicer) throws IOException
> {
> if(authenticator.isAuthenticated())
> {
> // *****************************************************
> // the above operation "isAuthenticated()" will fail !!!
> // request == NULL
> // *****************************************************
> }
> }
>
> }
> // ----------------------------------------------------------
> Property 'webRequest' of <OuterProxy for
> tapestry.globals.RequestGlobals(org.apache.tapestry.services.RequestGlobals)>
> is null.
> this should not happen as the request is available at this time (it's a
> parameter of the service method)
> however, I do not want to handle the request to the authenticator as it's
> used not only in the filter
> but also in the login page.
> I think this is a general problem with filters being called before
> tapestry.globals is fully initialized
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
