Classloading:
You're right, put the .jars to JBOSS/server/<configuration>/lib, or JBOSS/lib.
JBoss AS comes with bundled Hibernate libs which are tested with that AS version.
See 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>
Also see:
Difference between WEB-INF/lib and JBOSS/server/default/lib:
Libs in WEB/lib come with your WAR and are only visible within that WAR.
If you have other module, e.g. EJB JAR, they will not be visible from it and you'll get ClassNotFoundException or (if you have the class in multiple places) ClassCastException.
Libs in JBOSS-AS/server/<config>/lib are visible for whole server, thus all deployed apps and their modules. However (IIRC) they don't have precedence, so if you bring that lib e.g. in a WAR, but not in EJB jar, you can end up using two different versions, which is undesirable (will likely lead to aforementioned ClassCastException).
Class loading behavior may be tweaked several ways, see e.g. JBoss wiki.
Static data:
Don't rely on static fields in Java EE, that brings troubles. For instance,. the same class can be loaded by different classloaders, so there will be multiple instances of these static values.
If you want to share data amongst more WARs, use an external storage - a database, a file (with synchronization if you write to it), JBoss Cache, etc.
