classloading:
Tienes razón, poner los .jar
s a JBOSS/server/<configuration>/lib
o JBOSS/lib
.
JBoss AS viene con paquetes de Hibernate libs que se prueban con esa versión AS.
Ver 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>
Véase también:
Diferencia entre WEB-INF/lib
y JBOSS/server/default/lib
:
Libs en WEB/lib
vienen con su WAR y solo son visibles dentro de esa GUERRA. Si tiene otro módulo, p. EJB JAR, no serán visibles desde allí y obtendrás ClassNotFoundException
o (si tienes la clase en varios lugares) ClassCastException
.
Libs en JBOSS-AS/server/<config>/lib
son visibles para todo el servidor, por lo tanto, todas las aplicaciones implementadas y sus módulos. Sin embargo (IIRC) no tienen precedencia, así que si traes esa lib, p. en un WAR, pero no en el jar EJB, puede terminar usando dos versiones diferentes, lo cual es indeseable (probablemente conduzca al ClassCastException
antes mencionado).
El comportamiento de carga de clases se puede modificar de varias formas, ver p. Ej. JBoss wiki.
datos estáticos:
no se basan en los campos estáticos en Java EE, que trae problemas. Por ejemplo,. la misma clase puede ser cargada por diferentes clasificadores, por lo que habrá múltiples instancias de estos valores estáticos.
Si desea compartir datos entre más WAR, utilice un almacenamiento externo: una base de datos, un archivo (con sincronización si escribe en él), JBoss Cache, etc.
1 Yo prefiero un directorio dedicado propia para mi propio frasco compartida de esto hace que sea más fácil de mantener – stacker