Interceptor + putting information on the request
Hello,
I am using struts 2.0.6. I wrote an interceptor to use with Acegi
security to place the UserDetails object on the request so I could
access it on my JSP page. However when I tried to access the object on
the page, it was not found.
I then instead placed it on the session using the following which
worked:
[code]
final ActionContext context = invocation.getInvocationContext();
HttpServletRequest request = (HttpServletRequest)
context.get(HTTP_REQUEST);
HttpSession session = request.getSession();
Authentication auth =
SecurityContextHolder.getContext().getAuthentication();
if(auth != null)
{
if(auth.getPrincipal() instanceof UserDetails)
{
IrUser user = (IrUser)auth.getPrincipal();
session.setAttribute(user, user);
}
}
return invocation.invoke();
[/code]
I was wondering is there any way to place this information on the
request in an interceptor.
Thanks for the help.
-Nate
Re: Interceptor + putting information on the request
I am actually doing something similar inside a couple of struts 2
applications I've written and I am able to populate the value stack and or
request just fine.
I do the following,
code
/*
* Interceptor
*/
public String intercept(ActionInvocation _invocation) throws
Exception {
MenuContext menuContext = new MenuContext();
_invocation.getStack().set(menuContext, menuContext);
String response = null;
try {
response = _invocation.invoke();
} catch(Exception e){
ISFLogger.error(Error invoking action,
getClass(), intercept(ActionInvocation),e);
throw e;
}
return response;
}
/*
* JSP
* The menucontext object has a list named sectionMenu declared
on it that is being used for iteration.
*/
struts:iterator id=statusLink status=barIteratorStatus value=
menuContext.sectionMenu
!-- Do a bunch of stuff --
/struts:iterator
/code
I really suggst you dont make the ActionContext final. Because the context
changes for each request (its mutable) and making it final is a misleading
statement.
I also suggest you use the value stack and not the session or request, its
just easier to get the information with struts tags when you do.
Matt Filion
CSC - GTS -- Raytheon - ISF
(818) 468-6271
[EMAIL PROTECTED]
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit
written agreement or government initiative expressly permitting the use of
e-mail for such purpose.
Sarr, Nathan [EMAIL PROTECTED]
03/07/2007 08:39 AM
Please respond to
Struts Users Mailing List user@struts.apache.org
To
user@struts.apache.org
cc
Subject
Interceptor + putting information on the request
Hello,
I am using struts 2.0.6. I wrote an interceptor to use with Acegi
security to place the UserDetails object on the request so I could
access it on my JSP page. However when I tried to access the object on
the page, it was not found.
I then instead placed it on the session using the following which
worked:
[code]
final ActionContext context = invocation.getInvocationContext();
HttpServletRequest request = (HttpServletRequest)
context.get(HTTP_REQUEST);
HttpSession session = request.getSession();
Authentication auth =
SecurityContextHolder.getContext().getAuthentication();
if(auth != null)
{
if(auth.getPrincipal() instanceof UserDetails)
{
IrUser user = (IrUser)auth.getPrincipal();
session.setAttribute(user, user);
}
}
return invocation.invoke();
[/code]
I was wondering is there any way to place this information on the
request in an interceptor.
Thanks for the help.
-Nate
[OT] Re: Interceptor + putting information on the request
--- Matt Filion [EMAIL PROTECTED] wrote: I really suggst you dont make the ActionContext final. Because the context changes for each request (its mutable) and making it final is a misleading statement. Making local parameters that will not change 'final' is a reasonably typical coding practice and may help prevent stupid PEBKAC problems. I don't think making a local variable 'final' will confuse anybody. d. We won't tell. Get more on shows you hate to love (and love to hate): Yahoo! TV's Guilty Pleasures list. http://tv.yahoo.com/collections/265 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Interceptor + putting information on the request
Hi Matt, Thanks very much, that fixed it. -Nate - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: Interceptor + putting information on the request
Dave, This is all symantics I guess, but I dont mind a good discussion :) To me with the way the relationship is between the 2 objects, ActionContext is not a PART of the Interceptor, it is something the Interceptor uses. So for me it should be neither final or even a member variable. Just a referance within the scope of the executed method. It creates an unatural relationship that could potential complicate the frameworks control of the ActionContext. Matt Filion CSC - GTS -- Raytheon - ISF (818) 468-6271 [EMAIL PROTECTED] This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. Dave Newton [EMAIL PROTECTED] 03/07/2007 01:15 PM Please respond to Struts Users Mailing List user@struts.apache.org To Struts Users Mailing List user@struts.apache.org cc Subject [OT] Re: Interceptor + putting information on the request --- Matt Filion [EMAIL PROTECTED] wrote: I really suggst you dont make the ActionContext final. Because the context changes for each request (its mutable) and making it final is a misleading statement. Making local parameters that will not change 'final' is a reasonably typical coding practice and may help prevent stupid PEBKAC problems. I don't think making a local variable 'final' will confuse anybody. d. We won't tell. Get more on shows you hate to love (and love to hate): Yahoo! TV's Guilty Pleasures list. http://tv.yahoo.com/collections/265 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: Interceptor + putting information on the request
--- Matt Filion [EMAIL PROTECTED] wrote: So for me it should be neither final or even a member variable. Just a referance within the scope of the executed method. It creates an unatural relationship that could potential complicate the frameworks control of the ActionContext. IIRC as posted it was a local final variable in the method... There's no relationship created by that, it's for convenient access, declared final to avoid PEBKACs. All declaring it final does is make the compiler spew an error if the hapless programmer mistakingly does something like context = foobar... It does not affect the framework's control at all. d. Food fight? Enjoy some healthy debate in the Yahoo! Answers Food Drink QA. http://answers.yahoo.com/dir/?link=listsid=396545367 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: Interceptor + putting information on the request
Dave, My mistake, I misread it. Though the different situation seems like overkill. How about expecting a programmer to look at the code becore they modify it? :) Matt Filion CSC - GTS -- Raytheon - ISF (818) 468-6271 [EMAIL PROTECTED] This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. Dave Newton [EMAIL PROTECTED] 03/07/2007 02:01 PM Please respond to Struts Users Mailing List user@struts.apache.org To Struts Users Mailing List user@struts.apache.org cc Subject Re: [OT] Re: Interceptor + putting information on the request --- Matt Filion [EMAIL PROTECTED] wrote: So for me it should be neither final or even a member variable. Just a referance within the scope of the executed method. It creates an unatural relationship that could potential complicate the frameworks control of the ActionContext. IIRC as posted it was a local final variable in the method... There's no relationship created by that, it's for convenient access, declared final to avoid PEBKACs. All declaring it final does is make the compiler spew an error if the hapless programmer mistakingly does something like context = foobar... It does not affect the framework's control at all. d. Food fight? Enjoy some healthy debate in the Yahoo! Answers Food Drink QA. http://answers.yahoo.com/dir/?link=listsid=396545367 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: Interceptor + putting information on the request
--- Matt Filion [EMAIL PROTECTED] wrote: Though the different situation seems like overkill. I don't make my local vars 'final' either, but I know enough people that do. How about expecting a programmer to look at the code becore they modify it? :) Works great in theory ;) But seriously, making local vars 'final' is to express *intent* whether or not the code was looked at--sort of a If you *really* want to that, fine, but you must explicitly remove the protections I have set in place. d. It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: Interceptor + putting information on the request
Dave, I completely agree, I guess I'm just much more of an optomist about my peers :) Matt Filion CSC - GTS -- Raytheon - ISF (818) 468-6271 [EMAIL PROTECTED] This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. Dave Newton [EMAIL PROTECTED] 03/07/2007 02:20 PM Please respond to Struts Users Mailing List user@struts.apache.org To Struts Users Mailing List user@struts.apache.org cc Subject Re: [OT] Re: Interceptor + putting information on the request --- Matt Filion [EMAIL PROTECTED] wrote: Though the different situation seems like overkill. I don't make my local vars 'final' either, but I know enough people that do. How about expecting a programmer to look at the code becore they modify it? :) Works great in theory ;) But seriously, making local vars 'final' is to express *intent* whether or not the code was looked at--sort of a If you *really* want to that, fine, but you must explicitly remove the protections I have set in place. d. It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
