[EMAIL PROTECTED] wrote:
If you have \A/secure/.*\Z=ROLE_SUPERVISOR,ROLE_TELLER in
I want to get rid of this line in filterInvocationInterceptor. If ROLE_ABC
is included in this line, then things work out smoothly, but then it means
that in future If I will be adding a new role in descriptor I have
Shishir K. Singh wrote:
Ben,
Even if I use ContextLoaderServlet, won't the filters get created before
ContextLoaderListener. In that case, the "init" of the filters will be
called even before the Spring context is available and thus, the
WebApplicationContextUtils.getRequiredWebApplicationContext
Ben,
Even if I use ContextLoaderServlet, won't the filters get created before
ContextLoaderListener. In that case, the "init" of the filters will be
called even before the Spring context is available and thus, the
WebApplicationContextUtils.getRequiredWebApplicationContext will fail in
the filter
Ben Wrote :
If you have \A/secure/.*\Z=ROLE_SUPERVISOR,ROLE_TELLER in
filterInvocationInterceptor, it is entirely correct that a user only
holding ROLE_ABC should receive a 404 error. Add a comma and the
ROLE_ABC if you want to allow users holding ROLE_ABC to access the
/secure URIs. If that doesn'
Shishir K. Singh wrote:
Hi,
I am running into issues when deploying the contacts.war on Jrun. It
works fine when deployed on tomcat. Here's starting the stack trace from
the Jrun console.
This is a Spring-specific issue. I think you'll need to use
ContextLoaderServlet rather than ContextLoa
Hi,
I am running into issues when deploying the contacts.war on Jrun. It
works fine when deployed on tomcat. Here's starting the stack trace from
the Jrun console.
