Although the decorator names I posted here are different, I did test with
same and different names for same request patterns.
I skimmed through the code. I do not understand how this could have worked
since the PathMapper always returns the last decorator for which the request
pattern matches. And if the user is not in role of that last decorator, good
luck. It is hard w/o log statements and dont want to step through debug.
So I just overrode, the getNamedDecorator method in ConfigDecoratorMapper.
public Decorator getNamedDecorator(HttpServletRequest request, String name)
{
System.out.println("getNamedDecorator..1"+name);
Decorator result = null;
GrantedAuthority[] authorities =
SecurityContextHolder.getContext().getAuthentication().getAuthorities();
try {
for (GrantedAuthority authority : authorities) {
result =
configLoader.getDecoratorByName(name+authority.getAuthority());
if (result != null) {
return result;
}
}
result = configLoader.getDecoratorByName(name);
} catch (ServletException e) {
e.printStackTrace();
}
if (result == null || (result.getRole() != null &&
!request.isUserInRole(result.getRole()))) {
// if the result is null or the user is not in the role
Decorator temp = super.getNamedDecorator(request, name);
return super.getNamedDecorator(request, name);
} else {
return result;
}
}
Although it is a dumb and dirty hack, it does what I want as long as the
last decorator is the one w/o any roles.
I anyone figures out the right way, I'll be glad to hear it.
Thanks
Ram R
--
View this message in context:
http://www.nabble.com/Sitemesh-decorator-based-on-ROLE-tf4864780s2369.html#a13930773
Sent from the AppFuse - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
