Announcement Announcement Module
No announcement yet.
why ContextHolder invalid: 'null' Page Title Module
Move Remove Collapse
This topic is closed
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • why ContextHolder invalid: 'null'

    I am getting the following error and I'm not sure why.

    Internal error: ContextHolder invalid: 'null': are your filters ordered correctly? HttpSessionContextIntegrationFilter should have already executed by this time (look for it in the stack dump below)
    java.lang.IllegalStateException: ContextHolder invalid: 'null': are your filters ordered correctly? HttpSessionContextIntegrationFilter should have already executed by this time (look for it in the stack dump below) at tUtils.getSecureContext( ) at net.sf.acegisecurity.ui.AbstractProcessingFilter.s uccessfulAuthentication(AbstractProcessingFilter.j ava:368) at net.sf.acegisecurity.ui.AbstractProcessingFilter.d oFilter( at net.sf.acegisecurity.util.FilterToBeanProxy.doFilt er( at ternalDoFilter( at Filter( at org.apache.catalina.core.StandardWrapperValve.invo ke( at org.apache.catalina.core.StandardContextValve.invo ke( at org.apache.catalina.core.StandardHostValve.invoke( at org.apache.catalina.valves.ErrorReportValve.invoke ( at org.apache.catalina.core.StandardEngineValve.invok e( at org.apache.catalina.connector.CoyoteAdapter.servic e( at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyo at org.apache.jk.common.HandlerRequest.invoke(Handler at org.apache.jk.common.ChannelSocket.invoke(ChannelS at org.apache.jk.common.ChannelSocket.processConnecti on( at org.apache.jk.common.ChannelSocket$SocketConnectio n.runIt( at org.apache.tomcat.util.threads.ThreadPool$ControlR at

    I *have* defined the HttpSessionContextIntegrationFilter like so:
    <bean id="httpSessionContextIntegrationFilter" class="net.sf.acegisecurity.context.HttpSessionCon textIntegrationFilter">
    <property name="context" value=" eContextImpl"/>

    and while I have done this, I've seen in many other examples where the following apparently works:
    <bean id="httpSessionContextIntegrationFilter" class="net.sf.acegisecurity.context.HttpSessionCon textIntegrationFilter"/>
    but this likewise gives me an error. Is there something more to defining it than the default settings as shown above? I was under the impression that by default, if the context were null, it would define a default one of type tImpl.

    Oh and the filterInvocationDefinitionSource is:
    /**=httpSessionContextIntegrationFilter,authenticat ionProcessingFilter,securityEnforcementFilter

    It's just driving me crazy. I'm not sure why it's still null.
    Last edited by jeromatron; May 10th, 2006, 05:26 PM.

  • #2
    I figured out through various and sundry online entries why the HttpSessionContextIntegrationFilter was null, even though I had defined it with a context in the applicationContext as well as put it at the beginning of the filter chain.

    Apparently, you also have to define it in the web.xml file so that it will be executed along with the other filters. Maybe that should be obvious, but to me, it was more like a punch in the face, hard.

    So after adding the following in the web.xml it worked:
    <filter-name>Acegi Integration Filter</filter-name>
    <param-value>net.sf.acegisecurity.context.HttpSessionCont extIntegrationFilter</param-value>
    <filter-name>Acegi Integration Filter</filter-name>

    I guess one of the confusing things to me was that the sample application just had the Acegi Filter Chain Proxy defined in the web.xml and didn't define the integration filter, the authentication processing filter, nor the security filter in the web.xml. It also didn't define a context for the integration filter in the applicationContext, yet it still worked.

    I'm probably configuration-file challenged in some ways, but it would sure be nice to have a set of default recipes for each version, a set of samples for distinct purposes. I was finding that even though I found information on the HttpSessionIntegrationFilter and the Auth something or other, those no longer apply in version .9. Also, the sample application is nice as it is to demonstrate a few different uses of Acegi, but if you only need to do one thing and have configuration problems, it would be nice to have a simple base case to draw from.

    Whew, it's pretty nice to have it working though.


    • #3
      FilterToBean proxy allows you to use a single bean from your app context as a filter.

      It is easiest to use it with a FilterChainProxy as the single Acegi entry in your web.xml:

              <filter-name>Acegi Filter Chain Proxy</filter-name>
      and configure a FilterChainProxy in you app context to manage a separate filter chain of the various Acegi filters, which is what the sample application does.


      • #4
        Thanks for the response Luke. I will try that alternate and more streamlined way when I can get my head above water again.
        Thanks for the great work on this project.