This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Tomcats suggested scheme for shared resources is to put them in <CATALINA_HOME>/lib where they will be on the classpath of all deployed webapps.
I'm wondering how organizations manage 'shared' resources. In my organization we are constantly having problems with jar files in <CATALINA_HOME>/lib being updated and breaking other dependent apps. For example, a developer downloads the latest version of a jar to do development. When the project is deployed as a war the shared jars have to be manually copied to <CATALINA_HOME>/lib. In many instances, the newer version of the jar will cause applications that had a dependency on an older version to stop working.
Could you describe how your organization deals with these issues?
1. How are shared files managed in one developers development environment?
2. What is the process for deploying shared files in a development environment if deployment is being done with a war file?
3. How are shared files deployed to a production environment where there are already versions of the jars in <CATALINA_HOME>/lib ?
4. How do you do configuration management on shared files being deployed to production, e.x. how to prevent an older library from replacing a newer one?
Thanks for any help, guidance or sage advice,
Many webapp servers have some equivalent to Tomcat's lib directory. However, the fundamental J2EE/JEE stricture remains the same: webapps are supposed to be self-contained, not dependent on code that has been jammed into the server. The Tomcat lib directory is for things that plug into Tomcat itself. It should not be containing application code.
Code executed from TOMCAT_HOME/lib is operating in what is effectively a non-JEE environment, and the normal JEE rules don't apply. The most obvious case in point is thread safety, but code placed in this directory is also at risk for conflicts with server state, and even more so should that code attempt to spawn its own threads. Likewise, code placed here is more at-risk for architectural changes within Tomcat itself. And Tomcat has made some significant changes over the years.
There are a number of ways to share resources and functionalities in JEE that don't involve cramming code in the server's internal library space. One old and well-supported way is to use Enterprise JavaBeans. Yes, I realize that it has been fashionable to sneer at EJBs for uncounted years and yes, I know that EJB support is one of the functions of JEE that doesn't come as part of Tomcat. But EJBs have become a lot more civilized and there are ways to shoehorn EJB support into Tomcat, and if the shoehorning gets too extreme, it's probably a sign that you need a full-stack JEE server anyway,
EJBs are not the only possibility. Mechanisms like JMS (also addable to a Tomcat system), web services, specialized RMI servers and more can all make resources more available to more apps. Not to mention make them more sharable between copies of the same app running in multiple cluster nodes.
So, in answer to your question, I don't use shared files. I build components. Since my builds are Maven-managed, if I just need the same code operating independently in multiple webapps, I make it a Maven dependency; the extra copies of the code in each WAR is rarely a major memory hit and I don't get hamstrung by the need to vigilantly ensure that no unplanned leakage occurs between apps, and one of Maven's signature attributes is to make sure that you don't build with the wrong version of a module.
If I specifically need shared resources, I look to the industry-standard resource-sharing mechanisms.
An IDE is no substitute for an Intelligent Developer.