tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship (JIRA)" <tapestry-...@jakarta.apache.org>
Subject [jira] Commented: (TAPESTRY-695) WebRequestServicerFilter lacks support for tapestry.globals.*
Date Fri, 07 Oct 2005 13:14:48 GMT
    [ http://issues.apache.org/jira/browse/TAPESTRY-695?page=comments#action_12331588 ] 

Howard M. Lewis Ship commented on TAPESTRY-695:
-----------------------------------------------

What you really seem to want is a filter pipeline before the globals are set up, and one after,
and then delegate out to the engine for main processing.

The intent of the filter before the pipeline is to allow the kind of work you want to do,
but base it on the parameters, not the globals. In some cases, a filter may want to substitute
the HttpServletRequest or WebRequest, and this is its opportunity.

Another option would be to make setting up the globals a filter (not a terminator) such that
other filters could be scheduled before or after it.

> 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

>
> 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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


Mime
View raw message