<p>I've just solved another *I-though-I-was-using-this-version-of-a-library-but-apparently-my-app-server-has-already-loaded-an-older-version-of-this-library-*issue (sigh).</p>

<p>Does anybody know a good way to verify (or monitor) whether your application has access to all the appropriate jar-files, or loaded class-versions?</p>

<p>Thanks in advance!</p>

<p>[P.S. A very good reason to start using the <a href="http://en.wikipedia.org/wiki/OSGi#Architecture" rel="noreferrer">OSGi module architecture</a> in my view!]</p>

<p><strong>Update</strong>: <a href="http://www.jboss.org/community/docs/DOC-9697" rel="noreferrer">This</a> article helped as well! It gave me insight which classes JBoss' classloader loaded by writing it to a log file.</p>

I don't think there is a good way to check that. And I'm not sure you want to do that. What you need to do  is get familiar with your app-server's class loading architecture, and understand how that works.
A simplified explanation of how it works is: an EJB or a web-app will first look for a class or a resource in  libraries declared in its own module (ejb-jar or war). if the class is not found there, the class loader forwards the request to the its parent class loader which is either a declared dependency (usualy an ejb) or the the application class loader which is responsible to load libraries and resources declared in the ear package. If the class or the resource is still not found the request is forwarded to the app server which will look in its own classpath.
This being said, you should remember that a Java EE module (web-app, ejb) will always load classes from a jar that is in the nearest scope. For example if you package log4j v1 in the war file, log4j v2 at ear level and you put log4j v3 in your app-server's class path, the module will use the jar in its own module. take that away and it'll use the one at ear level. take that out and it will use the one in the app-server's classpath. Things get more tricky when you have complex dependencies between modules.
Best is to put application global libraries at ear level.