Have you tried to put the war files inside the ear, but as an exploded directory?
I'm not sure if the JBoss deployment scanner is smart enough to redeploy a webapp contained in an ear, but it's worth a shot as it would give you the isolation you require.
Also, even if the deployment scanner can't do it, there might be a way to do it through a script which calls JBoss JMX management beans.
Sorry, I meant:
I would like the code in the wars to be able to see and use the code in the ear, but I would not like the code in the ear to be able to see the code in the wars.
The code in the ear will not be able to see the classes in the war by default. The war classloader is isolated.
1 application containing common code deployed as an ear.
Common code should ideally go in a jar file and that jar file can either be packaged in the individual war files or (although not recommended) can be put in JBOSS_HOME/server/< servername>/lib folder.
I wanted to avoid deploying the shared code into each war because of the large number of webapps we have. Any updates to the shared code would mean a re-build and re-deploy of 50+ apps.
I was thanking that sharing the code via an ear instead of the /lib folder that would give me the ability to hot deploy updates to that code (it's my understanding that updates to jars in the /lib need a boot of jboss to take effect).
In the end I've punted and gone with an exploded ear that contains both the shared code, as well as the wars. It's not ideal since it requires a reload of the entire ear when a new version of a webapp is deployed, but it's better than a complete restart of jboss.
Thanks for your time.
I was thanking that sharing the code via an ear instead of the /lib folder that would give me the ability to hot deploy updates to that code
This can cause issues with classloading. See these wiki links (pay special attention to the "Sharing classes" section in the first wiki):