Неполная загрузка JSP на Websphere Application Server 8.5

Я планирую перейти с Websphere Application Server (WAS) 7 на версию 8.5. Я развернул приложение, которое отлично работает на WAS 7, и я не вносил в него никаких изменений с момента миграции.

Однако в WAS 8.5 страницы JSP загружаются не полностью. Когда я просматриваю эти страницы через "Просмотр исходного кода", я вижу, что содержимое HTML загружено только наполовину. В частности, сам HTML не завершается закрывающими тегами.

В WAS 7 результат "Просмотр источника" выглядит следующим образом:

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

Но то же самое в WAS 8.5 выглядит так:

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

До сих пор я сделал следующее:

  1. Я сравнил файлы классов скомпилированной JSP на WAS 7 и WAS 8.5. Они почти одинаковы, поэтому я предполагаю, что компиляция выполнена правильно. Однако отображение страницы в HTML не выполняется должным образом.
  2. Я попытался включить отладку JavaScript в IE, но он не показывал никаких ошибок при загрузке.
  3. В журналах приложений и серверах нет ошибок, которые я вижу.

Мои вопросы:

  1. Набор <td> Приведенные выше теги создаются с помощью пользовательских тегов JSP. Должен ли я проверить код тегов?
  2. Есть ли какое-либо пользовательское свойство в настройках веб-контейнера в Websphere, которое контролирует такое поведение?
  3. Есть ли свойство тайм-аута, которое заставляет страницу перестать загружаться на полпути?

Пожалуйста, предложите, что еще я должен проверить.

Источник

1 ответ

Это хорошо известное поведение, которое происходит, когда выдается исключение, и ответ уже передан.

обычно исключение регистрируется, но в некоторых случаях это не так.

Я читал, как вы обходили решение удаления EncodingFilter, но если вы все еще хотите найти проблему, вы можете попытаться закодировать фильтр, который должен быть выполнен ДО EncodingFilter, который устанавливает response.setBufferSize в больший размер.

это может быть такой фильтр:

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;
    }
}

и это отображение:

<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>

это не решит проблему, но, по крайней мере, оно должно разрешить журнал исключений, так или иначе, если таковые имеются.

Источник
Другие вопросы по тегам