4
votes

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.

1
Do you have a DOCTYPE set in your JSPs?Uooo
Hi Uooo, we are not using DOCTYPE in JSPsBlack Dranzer
What happens if you add one?Uooo
Hi,we tried with DOCTYPE,but the same issue is coming. The DOCTYPE we used is : <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">Black Dranzer
@Uooo can you please suggest if there is any problem with above DOCTYPE statementBlack Dranzer

1 Answers

0
votes

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.