Ответ 1
загрузки классов:
Вы правы, поставьте .jar
в JBOSS/server/<configuration>/lib
или JBOSS/lib
.
JBoss AS поставляется со связанными библиотеками Hibernate, которые протестированы с этой версией AS.
См. jboss-6.0.0-SNAPSHOT\server\default\conf\jboss-service.xml
:
<server>
<!-- Load all jars from the JBOSS_HOME/server/<config>/lib directory and
the shared JBOSS_HOME/common/lib directory. This can be restricted to
specific jars by specifying them in the archives attribute.
TODO: Move this configuration elsewhere
-->
<classpath codebase="${jboss.server.lib.url}" archives="*"/>
<classpath codebase="${jboss.common.lib.url}" archives="*"/>
</server>
Также смотрите:
- http://community.jboss.org/wiki/classloadingconfiguration
- http://community.jboss.org/wiki/JbossClassLoadingUseCases
Разница между WEB-INF/lib
и JBOSS/server/default/lib
:
Либы в WEB/lib
идут с вашей ВОЙНОЙ и видны только в этой WAR.
Если у вас есть другой модуль, например. EJB JAR, они не будут видны из него, и вы получите ClassNotFoundException
или (если у вас есть класс в нескольких местах) ClassCastException
.
Libs в JBOSS-AS/server/<config>/lib
видны для всего сервера, таким образом, все развернутые приложения и их модули. Однако (IIRC) у них нет приоритета, поэтому, если вы принесете этот lib, например. в WAR, но не в банке EJB, вы можете использовать две разные версии, что нежелательно (вероятно, приведет к вышеупомянутому ClassCastException
).
Поведение загрузки класса может быть изменено несколькими способами, см., например, JBoss wiki.
Статические данные:
Не полагайтесь на статические поля в Java EE, которые приносят проблемы. Например,. один и тот же класс может быть загружен разными загрузчиками классов, поэтому будет множество экземпляров этих статических значений.
Если вы хотите обмениваться данными с другими WAR, используйте внешнюю память - базу данных, файл (с синхронизацией, если вы ему пишете), JBoss Cache и т.д.