• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1752
  • Last Modified:

Servlet filter isn't working correctly in Websphere 7

Hi,
     
       I have a java servlet filter intercepting the JSP (html) response and converting in to PDF. The code works when deployed in WAS 5.1 but not when deployed to WAS 7 .
 
The following is my filter code, http servlet response wrapper and parts of web.xml.

//ShoppingFilter

GenericResponseWrapper wrapper = new GenericResponseWrapper((HttpServletResponse) resp);
chain.doFilter(req, wrapper);

The issue  in WAS 7 is wrapper.getData() is empty
-----------------------------------------------------------------------------------------------------------------
// Wrapper class
public class GenericResponseWrapper extends HttpServletResponseWrapper {
      private ByteArrayOutputStream output;
      private int contentLength;
      private String contentType;

      public GenericResponseWrapper(HttpServletResponse response) {
            super(response);
            output = new ByteArrayOutputStream();
      }

      public byte[] getData() {
            return output.toByteArray();
      }

      public ServletOutputStream getOutputStream() {
            return new FilterServletOutputStream(output);
      }

      public PrintWriter getWriter() throws IOException {
            return new PrintWriter(getOutputStream(), true);
      }

      public void setContentLength(int length) {
            this.contentLength = length;
            super.setContentLength(length);
      }

      public int getContentLength() {
            return contentLength;
      }

      public void setContentType(String type) {
            this.contentType = type;
            super.setContentType(type);
      }

      public String getContentType() {
            return contentType;
      }
}
-----------------------------------------------------------------------------------------------------------------------
web.xml
    <filter>
          <filter-name>ShoppingFilter</filter-name>
          <display-name>ShoppingFilter</display-name>
          <filter-class>com.xx.yy.ShoppingFilter</filter-class>
    </filter>
      <filter-mapping>
            <filter-name>ShoppingFilter</filter-name>
            <url-pattern>/ggc/shoppingFilter.do</url-pattern>
      </filter-mapping>

Any suggestions on how to make this work in WAS 7 please?
Thanks.
0
ram7098
Asked:
ram7098
  • 5
  • 3
  • 2
1 Solution
 
Sathish David Kumar NCommented:
whether you have some other filter's in your web.xml ??
Works only if you have the <filter-mapping> tag appear after the<filter> tag.
0
 
Sathish David Kumar NCommented:
deployment descriptor(web.xml) work different for every server
0
 
mrcoffee365Commented:
Your definitions for the filter look okay.  However, I found this answer on EE about what Websphere does with the order of tags in web.xml -- forcing it to use the web.xml as you have defined it might be the solution:
http://www.experts-exchange.com/Software/Server_Software/Application_Servers/Java/IBM_Websphere/Q_26625087.html
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
ram7098Author Commented:
Thanks for the replies. The issue isn't servlet filter isn't being invoked but chain.doFilter isn't copying the html response to the wrapper response object.

GenericResponseWrapper wrapper = new GenericResponseWrapper((HttpServletResponse) resp);
chain.doFilter(req, wrapper);

I think WAS 5.1 is using Server 2.3 whereas WAS 7 is probably using Servlet 2.5. We are doing an upgrade with existing code and our web.xml is still using 2.3 dtd. We are using struts version 1.3.  I read for servlet 2.5 the filters have a property called dispatcher which can be configured. If not configured, then default I guess is REQUEST. I am not sure, if that is the reason why it isn't working? I can try creating a different version of web.xml, just for testing on the server......
 
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app id="WebApp">

Any thoughts please?

Thanks.
0
 
mrcoffee365Commented:
I think using 2.3 for the servlet version should be fine.  I've read of people using 2.4 with WAS 7, so 2.3 should be okay, too.

In addition to an id, you might try the metadata tag, like:
<web-app metadata-complete="true" id="mywebapp">

I'm not sure id="WebApp" will be distinctive enough -- but maybe it's okay.  The metadata-complete is actually a way of avoiding startup scanning costs, but the person in the other EE question did it, so you might try it.  It's supposed to be related to servlet spec 3.0, so it really shouldn't matter one way or another, but shouldn't hurt.

Another thing to try is mentioned in this post:
http://greatwebguy.com/programming/java/urlrewritefilter-servlet-filter-problem-in-websphere-6105-and-greater/

Apparently if a url is not directly mapped, IBM changed WAS in 6 to not send the url through your filters.  There's a workaround.  Weird choice on IBM's part.
0
 
ram7098Author Commented:
I tried changing the web.xml and adding custom IBM properties to the web container but the result has been the same. Is there any work around please?
0
 
mrcoffee365Commented:
0
 
mrcoffee365Commented:
Great -- does that mean that was the problem you had?  IBM changing how it sends urls through filters sounds like a subtle change, but you're not the only person caught by it.
0
 
ram7098Author Commented:
The real issue was in the wrapper implementation. The above mentioned response wrapper doesn't work in WAS 7 / Java 6 (with Servlet 2.5 API). Instead of wracking my brain too much, I modified the wrapper (did a code work around) to get it working. Your mentioned web.xml changes where really helpful. Thank you.
0
 
mrcoffee365Commented:
Good, glad to help even if indirectly.
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

  • 5
  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now