I'm just mix-and-matching - not using S1 plugin.  But the S2 Filter, mapped
to "/*" ought to catch all requests, because filters execute before
servlets.  Therefore I wonder why the LoginInterceptor doesn't get executed
on S1-generated requests (ie. those with a *.do url, or even with a *.jsp
url).  Perhaps the S2 Filter says "If the Request isn't mapped to *.action,
I won't process it at all".  Does the S2 Filter really behave this way?  If
that is how the filter behaves, is this configurable?  Is there a
recommended way around it?  (In S1 I subclassed the RequestProcessor, I'd
rather not subclass the Filter)

My own feeling is that I can write a filter which redirects all requests
without a login credential to "login.action", to force it thru the S2
processor, and so thru the LoginInterceptor, but then I'd be using a Filter
*AND* an Interceptor to accomplish the login.  Perhaps I'll get rid of the
Interceptor and just do it with a Filter, but there are advantages to the
Interceptor which would be lost that way.

(by the way, Laurie, These are not the Droids you're looking for!)
- Ray C.



Laurie Harper wrote:
> 
> Ray Clough wrote:
>> I've got a large S1 app into which I'm putting S2 features - starting
>> with a
> 
> How? Are you using S2 with the S1 plugin? Or just putting both versions 
> into one WAR and mix'n'matching?
> 
>> LoginInterceptor, because the S1 security-implementation was NG.  The S2
> 
> NG? No Good? Next Generation? Nearly Ganked? ;-)
> 
>> mapping in web.xml is to the url "/*", which I figured would catch all
>> requests, both from S1 actions and from S2 actions.  The S1 Action
>> servlet
> 
> There is no 'from', only 'too'. Too or too not. There is not from. Oops, 
> have I been watching too much Star Wars? The point is, it doesn't matter 
> where a request comes from; once it comes in, it's just a request. What 
> happens next is based on the form of the request; in this case, 
> specifically, the URL that's requested.
> 
>> is mapped to "*.do".  It appears that the S1 actions aren't intercepted,
>> making the LoginInterceptor not work for them.  How is "*.do" bypassing
>> "/*".
> 
> Given the request URL http://host:port/x/y/z.do, which pattern matches: 
> /* or *.do? Obviously both patterns match. I'm not sure if the behaviour 
> in this case is specified or not, but if it is then the order of the 
> mappings is likely what determines which wins.
> 
>> Is this really the case, or can something be done to force S1 actions
>> thru
>> the S2 interceptor.
> 
> Err... not sure I understand the question. You can't have an S2 
> interceptor applied to a request that's being handled by S1, since S1 
> doesn't know about interceptors.
> 
> I think you'd need to post a more concrete example of the sort of 
> process flow you're trying to achieve and the configuration(s) you're 
> trying to get there.
> 
> L.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Interceptor-execution-tf3762074.html#a10645544
Sent from the Struts - User mailing list archive at Nabble.com.


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

Reply via email to