I have a war file that I deployed to a jboss 4.3.0.cp02 server.
This war file contains a couple of jar files inside it.
However, for some reason these jar files also appear on the same directory as the war file as well. (i.e war file is in server/myserver/deploy) containing the above mentioned jars. These are also also physically present in server/myserver/deploy
The problem we encountered is this - in the lower environment the war file is using the jar files that are contained within the war.
But in production it is getting loaded from the physical directory for some reason.
I do not know why that jar files are even physically present there, but management is not allowing deleting them until I can figure out why this is happening.
It could be that in the development environment that classes in the jar are not loaded until something in the war asks for them, in which case you would probably end up with the classes from the jar in the war. In production, however, another app might be asking for the classes in which case they get loaded from the lib directory; then when the war needs those same classes it uses the ones already loaded.
One way to monitor this is to add the -verbose:classes JVM option to the command line (add it to JAVA_OPTS in the run script). This option forces the JVM to list each class loaded and declare which jar it came from. This might help you determine what is going on.
If that doesn't help you, post the jboss-web.xml file for your web app, and the output from 'jar -tf xxx.war", and the jboss_home-relative location(s) of the duplicate jar files.
I added -verbose:classes to the run.conf file under jboss-as/server/myserver.
I looked in the server.log file after starting the server but I do not see any details. Could you please explain what I need to look for?
Pick one of the classes in your common JAR file. Then look that class up in the -verbose:class output for both the production and dev environments. Then also look at the few classes that were loaded before that class. That might give you some clue. If that doesn't help, the other thing you could try is edit the constructors(s) of that class to create an Exception and then print the stack trace. That should tell you who is first instantiating the class.