Webwork+Velocity+Acegi config

Honestly, it's really a no-brainer. As what other Acegi's advocates are talking about, that Acegi should work with any frameworks. That's correct and adding to that, there's isn't much to code. I experienced getting some surprisingly erratic redirection behaviours after login. But I know there's nothing wrong with controller(action) classes so I was firm about my suspicion that what was happening was just a misconfiguration on my context files. The assumption was right. After following tightly the Contacts example, there's something that needs to be modified in the redirection if anyone intends to use Webwork+Velocity with Acegi Security framework.

Listing 1: applicationContext-acegi-security.xml

   <!-- ===================== HTTP REQUEST SECURITY ==================== -->

   <bean id="securityEnforcementFilter"
  class="net.sf.acegisecurity.intercept.web.SecurityEnforcementFilter">
      <property name="filterSecurityInterceptor"><ref
  local="filterInvocationInterceptor"/>
      </property>
      <property name="authenticationEntryPoint"><ref
local="authenticationProcessingFilterEntryPoint"/></property>
   </bean>

   <bean id="authenticationProcessingFilter"
class="net.sf.acegisecurity.ui.webapp.AuthenticationProcessingFilter">
      <property name="authenticationManager">
<ref bean="authenticationManager"/>
</property>
      <property name="authenticationFailureUrl">
 <value>/showlogin.action?loginerror=true</value></property>
      <property name="defaultTargetUrl"><value>/readuser.action</value></property>
      <property name="filterProcessesUrl"><value>/j_acegi_security_check</value></property>
      <property name="rememberMeServices"><ref local="rememberMeServices"/></property>
   </bean>

   <bean id="authenticationProcessingFilterEntryPoint"
  class="net.sf.acegisecurity.ui.webapp.AuthenticationProcessingFilterEntryPoint">
      <!--<property name="loginFormUrl"><value>/acegilogin.jsp</value></property>-->
   <property name="loginFormUrl"><value>/login.vm</value></property>    
      <property name="forceHttps"><value>false</value></property>
   </bean>

   <bean id="httpRequestAccessDecisionManager"
   class="net.sf.acegisecurity.vote.AffirmativeBased">
      <property name="allowIfAllAbstainDecisions"><value>false</value></property>
      <property name="decisionVoters">
         <list>
            <ref bean="roleVoter"/>
         </list>
      </property>
   </bean>

   <!-- Note the order that entries are placed against the objectDefinitionSource is critical.
        The FilterSecurityInterceptor will work from the top of the list down to the FIRST pattern that matches the request URL.
        Accordingly, you should place MOST SPECIFIC (ie a/b/c/d.*) expressions first, with LEAST SPECIFIC (ie a/.*) expressions last -->
   <bean id="filterInvocationInterceptor" class="net.sf.acegisecurity.intercept.web.FilterSecurityInterceptor">
      <property name="authenticationManager"><ref bean="authenticationManager"/></property>
      <property name="accessDecisionManager"><ref local="httpRequestAccessDecisionManager"/></property>
      <property name="objectDefinitionSource">
         <value>
                      CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
        PATTERN_TYPE_APACHE_ANT       
        /index.vm=ROLE_ANONYMOUS,ROLE_USER
        /login.vm*=ROLE_ANONYMOUS,ROLE_USER       
        /readuser.action*=ROLE_USER
         </value>

      </property>
   </bean>

From the "filterInvocationInterceptor" id, I removed the "/**=ROLE_USER" and replace it with my actual pattern based that is also the default redirection URL if authentication is successful. This reduces the "candidates" within the filter invocation interception to be matched.

Acegi Security is a very comprehensive security framework that is usable to almost any applications including non-web apps(Swing, SWT etc.) and is straightforward to customize. I don't see any reason why would anyone build an authentication and ACL framework from scratch again.