Я играл с последней Mojarra и, чтобы не заменять какие-либо существующие версии на уровне серверного модуля, я попытался упаковать его в свои приложения. Я не должен был этого делать. Вот небольшой рассказ.
Я люблю серверы приложений. Особенно GlassFish и WebLogic. Ты это знаешь. Но есть одна вещь, которая начинает беспокоить меня все больше и больше с последними выпусками. Это цикл выпуска связанных компонентов. Вы помните старые добрые времена, когда вы просто добавляли новую библиотеку в свой пакет приложений и (почти) все работало нормально? Эти дни принадлежат прошлому. На сегодняшний день у вас возникает много проблем, если вы пытаетесь обновить и заменить отдельные ссылочные реализации или компоненты вашего сервера приложений, связав их с вашими приложениями. Недавним примером была
Мохарра. Некоторые ошибки в
Mojarra 2.1.5, который поставляется с последней версией GlassFish 3.1.2-b22, не позволили мне обновить приложение. Вот я и подумала дать последнюю
2.1.10 (31.05.2012) снимок, который обещал решить эти проблемы. Я очень благодарен за частые выпуски здесь и очень очень ждал, что это решится буквально за несколько секунд.
Погуглив немного на предмет специфики процесса обновления, я попал в блог Аруна. Четыре года вход указал мне на основы. Пакет Impl и API-банки для вашего приложения. Добавьте несколько строк в ваш sun-web.xml.
Вот и ты. Это должно быть все. Хорошо. Очевидно, имя дескриптора развертывания изменилось. Его новое имя — glassfish-web.xml, а также изменилось имя свойства с useMyFaces на useBundledJsf. Не большой сюрприз и очень приветствуется.
<class-loader delegate="false"/> <property name="useBundledJsf" value="false"/>
Если вы сейчас попытаетесь найти зависимости jsf-impl и jsf-api для версии 2.1.10, вы начнете бороться. С 2.1.3 Mojarra начала применять Oracle для
именования и управления версиями Java EE Maven и OSGi . Это означает, что теперь у вас есть только одна зависимость для обоих:
<dependency> <groupId>org.glassfish</groupId> <artifactId>javax.faces</artifactId> <version>2.1.10</version> <scope>compile</scope> </dependency>
Также хорошо для меня. Давайте проведем тест-драйв. UPS:
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! org.glassfish.weld.jsf.WeldFacesConfigProvider cannot be cast to com.sun.faces.spi.ConfigurationResourceProvider
Это не сработало!
Что произошло?
Кажется, проблема в том, что в пути к классам есть две версии ConfigurationResourceProvider: одна на уровне веб-приложения (ваш файл jar в комплекте) и вторая на уровне загрузчика родительского класса (предоставляется GlassFish). WeldFacesConfigProvider расширяет ConfigurationResourceProvider в загрузчике родительского класса, но в конечном итоге приводит его к ConfigurationResourceProvider в загрузчике классов веб-приложения.
Обходной путь: Замена Мохарры в GlassFish
Как обойти это? Легко, если тебе нравится, будет легко. Просто
скачайте последнюю стабильную версиюMojarra из проекта java.net и замените glassfish3 \ glassfish \ modules \ javax.faces.jar загруженной версией. Обязательно сохраните резервную копию исходного файла, а также не забудьте удалить кэш osgi glassfish3 \ glassfish \ osgi, чтобы изменения вступили в силу. Также убедитесь, что вы используете только версию Mojarra
2.1
и не пытайтесь использовать 2.2, даже если она есть. Во-первых, потому что он реализует новые функции EE 7, а во-вторых, потому что это все еще снимок. Держись подальше! Пока что.
Почему вам может не понравиться такой подход. Представьте, что вы платный клиент Oracle GlassFish Server. Что вы думаете? Вы все еще получаете поддержку, если заменяете основной модуль на более новую версию? Я не проверял условия лицензирования и поддержки. Но я верю, что вы не будете. И это может быть правильно с точки зрения продукта, потому что вы просто не можете протестировать каждую возможную комбинацию модулей для каждого выпуска.
Обходной путь: добавление отсутствующей зависимости в ваше приложение
Если вы не можете использовать классовые загрузчики, вы должны сделать недостающую часть доступной для правильного загрузчика классов. Отсутствие замены javax.faces.jar в модулях вашего сервера приводит к добавлению волшебного WeldFacesConfigProvider в ваше приложение. Он содержится в файле glassfish3 \ glassfish \ modules \ weld -gration.jar, и, просто добавив его в качестве дополнительной библиотеки в свое приложение, вы также решите проблему.
В Интернете есть даже версия mavenized. Но это влечет за собой множество дополнительных зависимостей, которые вы должны исключить, и, похоже, это только сборка снимков. Таким образом, вы в конечном итоге поместите эту банку в свой локальный или корпоративный репозиторий Maven. Поступая таким образом, вы все равно должны получать поддержку вашей версии коммерческого приложения. Даже если интеграция сварки, очевидно, не думала о том, что она будет развертываться с вашими приложениями каждый раз снова и снова. Но с 77KB это тоже не слишком большая проблема.
Хорошие новости
Команда JSF и GlassFish работает над этим. И я надеюсь, что они исправят это в одном из следующих выпусков GlassFish. Спасибо
Энди и
Эду за поддержку здесь и за заботу.
Модуляризация и переходящие обновления
Как я уже говорил во введении, это только один пример. Я верю, что вы могли бы придумать больше. И голоса становятся громче, что требует повсеместной лучшей модульности. И они правы. Если бы я или вы разработали сложный проект со всеми этими взаимозависимостями, нас бы сильно не пнуло. Либо нашими клиентами, либо нашими коллегами. Таким образом, даже если мы исключим это из области EE 7, я с нетерпением жду возможности интегрировать это в EE 8 последней версии. Еще одним моментом здесь являются циклы выпуска и политики обновления для поставщиков. Даже если GlassFish не работает по умолчанию и в целом это очень стабильный сервер, у вас есть другие примеры: давайте посмотрим на последнюю версию WebLogic 12c. Он был выпущен довольно поздно по сравнению с другими EE 6-совместимыми серверами.Внесение некоторых ошибок и принуждение Oracle доставить
переупакованный дистрибутив позже. И даже это не совсем пригодно для использования (
проблема ,
проблема ), заставляя вас быть либо платящим клиентом, чтобы получать исправления, либо не использовать продукт. Нижняя линия? Я не знаю. Что-то не так, как сегодня. Нам нужно больше работать, чтобы сделать EE спецификацией, которую можно использовать, обновлять и использовать. И я считаю, что следующая версия должна быть ориентирована не на опыт разработчиков первого уровня, а на поставщиков и качество. Какая машина стоит того, чтобы на ней легко было ездить всем, но она часто ломалась из-за ошибок и отсутствующих запчастей?