Websphere 8.5 и SpringServletContainerInitializer

Недавно мы преобразовали наше приложение с сервлета 2.5 на сервлет 3.0, чтобы мы могли использовать динамическую конфигурацию сервлета.

Мы используем SpringServletContainerInitializer Spring для инициализации нашего приложения соответствующим экземпляром WebApplicationInitializer, который находится в нашем коде. Этот подход работает в Tomcat, но при развертывании в Websphere 8.5.0.1 SpringServletContainerInitializer не может найти реализацию интерфейса WebApplicationInitializer в нашем коде, поэтому наш сервлет-диспетчер Spring MVC не создается.

Мы обнаружили в Интернете одно сообщение в блоге, автор которого мог не заставить его работать.

Мы пытались возиться с загрузчиком классов, порядками загрузки классов и проверять, что сервлет 3.0 работает в контейнере другими способами, и, похоже, с этим все в порядке. Используя средство просмотра загрузчика классов WAS, мы видим, что загружаются класс SpringServletContainerInitializer и интерфейс WebApplicationInitializer, но не наша реализация WebApplicationInitializer.

Кто-нибудь пробовал это в Websphere? Мы думаем, что это может быть проблема с загрузчиком классов, но в конечном итоге ничего не знаем.


java spring-mvc websphere servlet-3.0
person Kyle    schedule 03.04.2013    source источник
comment
Вы пробовали форум WebSphere? ibm.com/developerworks/ сообщество/форумы/html/   -  person dbreaux    schedule 28.04.2013
comment
Похоже, мы можем избавиться от WebSphere. Это стоило нам недель продуктивности (по таким вопросам, как эта) и, похоже, дает очень мало пользы, которую организация планирует использовать.   -  person Kyle    schedule 29.04.2013
comment
Однако я знаю, что это старый комментарий - иметь веб-сферу в наши дни, если вы на самом деле не находитесь в какой-то очень деловой и обязательно сертифицированной среде (банки и т. Д.), Совершенно бесполезно. Это просто замедляет работу разработчиков, а также IBM RAD не помогает. Вы решили проблему? У меня такая же проблема при запуске приложения spring boot + vaadin в websphere 8.5.   -  person Mejmo    schedule 27.10.2015
comment
решил проблему, наконец убедив людей перейти на встроенный кот.   -  person Kyle    schedule 02.11.2015

Ответы (2)


arrow_upward
1
arrow_downward

У меня была точно такая же проблема. Проблема связана с дефектом WebSphere, исправленным с помощью следующего APAR http://www-01.ibm.com/support/docview.wss?uid=swg1PM85177. WebSphere создает кеш аннотаций и из-за дефекта, когда кеш заполнен, он отбрасывает ранее кэшированные аннотации, в результате чего SpringServletContainerInitializer не находит все реализации WebApplicationInitializer.

Этот APAR уже выпущен в версии 8.0.0.8 и запланирован для версии 8.5.5.2, которая, в свою очередь, запланирована на 28 апреля. Тем временем мне удалось увеличить размер кеша с 2000 по умолчанию до 16000 (он не работает при 4000 и 8000), после чего мое приложение начало работать. Один размер не подходит всем, поскольку размер кеша переопределяется системным свойством JVM для узла WebSphere. Подходящий размер будет зависеть от того, какие приложения работают на этом узле и как они (и их JAR) используют аннотации, поэтому он будет Важно поиграть с этим параметром, пока не будет определено правильное значение для вашего приложения (приложений).

Я использовал системное свойство JVM: -Dclassinfocachesize=16000.

person techienglishguy    schedule 19.03.2014

arrow_upward
3
arrow_downward

Я только что увидел эту публикацию. При отладке проблем с загрузчиком классов WebSphere обеспечивает трассировку, которая, если она включена, может дать более подробную информацию о том, что происходит, а что нет. Он предоставляется в обязательном порядке для сбора данных, которые служба поддержки IBM запросит, если вы откроете PMR. Но его достаточно легко прочитать и понять вывод.

http://www-01.ibm.com/support/docview.wss?uid=swg21196187#show-hide в разделе «Сбор данных вручную» используемая строка трассировки:

com.ibm.ws.classloader.*=все

person Alexandre Polozoff    schedule 19.06.2013