Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    NullPointerException in CompressionFilter wrapped by Spring DelegatingFilterProxy

    I get a NullPointerException in CompressionFilter when proxying it with an org.springframework.web.filter.DelegatingFilterProxy. (See: http://forum.springsource.org/showthread.php?20230-Howto-The-joy-that-is-DelegatingFilterProxy.)

    CompressionFilter works fine when I declare it the standard way in web.xml.

    My Spring version is 3.0.6.RELEASE. I've been meaning to upgrade to 3.1.1.RELEASE, so I'll try that tomorrow, but any tips on what might be missing at CompressionFilter.java:392 would be most appreciated. I've never had an issue with DelegatingFilterProxy (or my own DelegatingServletProxy as derived from DelegatingFilterProxy) before.

    Details follow...

    Be sure your post includes:

    1. the SmartGWT or SmartClient version from the lower left-hand corner of the Developer Console (see FAQ for how to open Developer Console)

    v8.2p_2012-04-06/EVAL Development Only

    2. browser(s) and version(s) involved

    Any

    3. for a server-side problem, the *complete* logs generated during processing of the failing request (do *not* trim to just the error message)

    Code:
    2012-04-10 18:07:23,406 ERROR [[default]] [http-bio-localhost/127.0.0.1-8080-exec-9]: Servlet.service() for servlet [default] in context with path [] threw exception
    java.lang.NullPointerException
    	at com.isomorphic.servlet.CompressionFilter.doFilter(CompressionFilter.java:392)
    	at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
    	at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
    	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
    	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
    	at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:162)
    	at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
    	at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
    	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
    	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
    	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
    	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
    	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
    	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
    	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:851)
    	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
    	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:405)
    	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:278)
    	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:515)
    	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:300)
    	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    	at java.lang.Thread.run(Thread.java:680)
    4. for any problem processing a server response, the actual response as shown in the RPC tab in the Developer Console

    n/a

    5. if there is a JavaScript error, the stack trace logged in the Developer Console (see FAQ)

    n/a

    6. sample code if applicable

    web.xml:

    Code:
    	<filter>
    		<filter-name>smartClientCompressionFilter</filter-name>
    		<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
    	</filter>
    	<filter-mapping>
    		<filter-name>smartClientCompressionFilter</filter-name>
    		<url-pattern>*.css</url-pattern>
    	</filter-mapping>
    spring-smartclient-context.xml (imported from my main spring-context.xml):

    Code:
    <?xml version="1.0" encoding="UTF-8"?>
    <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    	xsi:schemaLocation="
    		http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">
    
    	<bean id="smartClientCompressionFilter" class="com.isomorphic.servlet.CompressionFilter" />
    
    	<bean id="smartClientInitServlet" class="com.isomorphic.base.Init" />
    
    	<bean id="smartClientPreCacheServlet" class="com.isomorphic.servlet.PreCache" />
    
    	<bean id="smartClientIdaCallServlet" class="com.isomorphic.servlet.IDACall" />
    
    	<bean id="smartClientFileDownloadServlet" class="com.isomorphic.servlet.FileDownload" />
    </beans>
    Posts with incomplete information are much more likely to be ignored.

    #2
    That doesn't make a lot of sense - the only way it looks like it could happen is if CompressionFilter.doFilter() was somehow called without CompressionFilter.init(FilterConfig) having been called, which would be a huge violation of the Filter lifecycle.

    Comment


      #3
      Originally posted by Isomorphic
      That doesn't make a lot of sense - the only way it looks like it could happen is if CompressionFilter.doFilter() was somehow called without CompressionFilter.init(FilterConfig) having been called, which would be a huge violation of the Filter lifecycle.
      Ah yes, I completely forgot about:

      NOTE: The lifecycle methods defined by the Servlet Filter interface will by default not be delegated to the target bean, relying on the Spring application context to manage the lifecycle of that bean. Specifying the "targetFilterLifecycle" filter init-param as "true" will enforce invocation of the Filter.init and Filter.destroy lifecycle methods on the target bean, letting the servlet container manage the filter lifecycle. (http://static.springsource.org/sprin...lterProxy.html)
      This fixed it right up:

      Code:
      <filter>
      	<filter-name>smartClientCompressionFilter</filter-name>
      	<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
      	<init-param>
      		<param-name>targetFilterLifecycle</param-name>
      		<param-value>true</param-value>
      	</init-param>
      </filter>
      <filter-mapping>
      	<filter-name>smartClientCompressionFilter</filter-name>
      	<url-pattern>*.css</url-pattern>
      </filter-mapping>
      I went ahead and did the same for all the proxied Servlets, e.g.:

      Code:
      <servlet>
      	<servlet-name>smartClientInitServlet</servlet-name>
      	<servlet-class>com.mycompany.common.web.spring.servlet.DelegatingServletProxy</servlet-class>
      	<load-on-startup>1</load-on-startup>
      	<init-param>
      		<param-name>targetServletLifecycle</param-name>
      		<param-value>true</param-value>
      	</init-param>
      </servlet>
      Thanks for the quick reply!

      Comment

      Working...
      X