4

I am planning to migrate from Websphere Application Server (WAS) 7 to version 8.5. I have deployed an application which runs fine on WAS 7 and I have not made any changes to it since migration.

However, on WAS 8.5, the JSP pages are not being getting loaded completely. When I examine these pages through "View Source," I can see that the HTML content is only half-loaded. Specifically, the HTML itself is not completed with closing tags.

In WAS 7, the result of "View Source" looks like this:

<html>
...
...
<td..../>
<td..../>
<td..../>
...
...
</html>

But the same in WAS 8.5 looks like:

<html>
...
...
<td..../>
<td..../>
<td..

I have done the following so far:

  1. I compared the class files of compiled JSP on WAS 7 and WAS 8.5. They are almost same, so I assume that the compilation is done properly. However, displaying the page with in HTML is not getting done properly.
  2. I tried enabling JavaScript debugging on IE, but it did not show any errors while loading.
  3. There are no errors in application logs and server logs that I can see.

My questions:

  1. The set of <td> tags above is generated through JSP custom tags. Should I check code of the tags?
  2. Is there any Custom property in Web Container Settings in Websphere which control such behaviour?
  3. Is there any timeout property which is causing page to stop loading half-way?

Please suggest what else should I check.

nmagerko
  • 6,586
  • 12
  • 46
  • 71
  • Do you have a `DOCTYPE` set in your JSPs? – Uooo Oct 29 '13 at 08:35
  • Hi Uooo, we are not using DOCTYPE in JSPs – Black Dranzer Oct 29 '13 at 09:45
  • What happens if you add one? – Uooo Oct 29 '13 at 09:51
  • Hi,we tried with DOCTYPE,but the same issue is coming. The DOCTYPE we used is : ` ` – Black Dranzer Oct 29 '13 at 10:51
  • @Uooo can you please suggest if there is any problem with above DOCTYPE statement – Black Dranzer Oct 29 '13 at 12:19
  • Doctype seems fine. It is just the first thing I check if something does not work - many issues just resolve by adding a doctype. The problem here, however, seems to be somewhere else. – Uooo Oct 29 '13 at 12:29
  • On WAS 8.5, are you using the same version of libraries (Servlet, Taglibs, ...) which you were using before? – Uooo Oct 29 '13 at 12:32
  • @Uooo Yes, I have deployed exactly same application on WAS 8.5, that I used to deploy on WAS 7 – Black Dranzer Oct 29 '13 at 14:06
  • Of course, the built-in libraries are different. Does every JSP fail? Only large ones? Always at the exact same character, even if you change the size of the file above that spot? – dbreaux Nov 08 '13 at 16:35
  • I'd try validating your original html, if you have unclosed tags or other errors it may be causing the page to stop loading – Matt Lambert Nov 27 '13 at 10:04
  • @Uooo I have got a temporary solution fir this: The problem was with EncodingFilter. When I removed encoding filter from web.xml, the problem was resolved. Then found out that real problem was with a Wrapper class we were using for encoding filter. When I used direct methods of api instead of methods of wrapper class, then also problem got resolved, Question remains is why wrapper class methods were not working properly. Need to find it out now. – Black Dranzer Dec 01 '13 at 08:55

1 Answers1

0

this is a well known behavior that happens when an Exception is thrown and Response has already been commited.

generally the exception is logged, but in some particular case it is not.

i read you workarounded removing EncodingFilter, but if you still want to find the problem you can try to code a Filter, that must be executed BEFORE EncodingFilter, wich sets response.setBufferSize to a larger size.

this can be such a filter:

public class ResponseBufferFilter implements Filter
{
    private FilterConfig filterConfig;

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException
    {
        try
        {
            // or better take the value from filterConfig.getInitParameter
            response.setBufferSize(100000000);

            chain.doFilter(request, response);
        }
        catch(Exception e)
        {
            e.printStackTrace();
            throw new ServletException(e.getMessage(), e);
        }
    }

    @Override
    public void init(FilterConfig filterConfig) throws ServletException
    {
        this.filterConfig = filterConfig;
    }

    @Override
    public void destroy()
    {
        filterConfig = null;
    }
}

and this is the mapping:

<filter>
    <filter-name>Response Buffer Filter</filter-name>
    <filter-class>test.example.filter.ResponseBufferFilter</filter-class>
</filter>
<filter-mapping>
    <filter-name>Response Buffer Filter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>
<filter>
    <filter-name>SetCharacterEncoding</filter-name>
    <!-- provide the class causing unwanted behavior -->
    <filter-class>org.apache.catalina.filters.SetCharacterEncodingFilter</filter-class>
    <init-param>
        <param-name>encoding</param-name>
        <param-value>UTF-8</param-value>
    </init-param>
</filter>
<filter-mapping> 
    <filter-name>SetCharacterEncoding</filter-name> 
    <url-pattern>/*</url-pattern> 
</filter-mapping> 

this will not solve the problem, but at least it should allow log of exception, one way or another, if any.

Michele Mariotti
  • 7,372
  • 5
  • 41
  • 73