This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I would like to know pros and cons of packaging jars in each war that's going to be deployed Vs putting them in shared library folder.
We are developing portal which has multiple portlets (each portlet is deployed in Tomcat as war). These portlets are Spring MVC portlets and depend on Spring framework jars.
Is it a better practice to package Spring jars in each war or create a shared library in Tomcat (classloader) in put them in there?
Is it fair to assume that when the jars are packaged with each the war, the classes are loaded into the heap, lots of portlets times lots of jars equals a lot of memory?
If you put something in the tomcat shared libs directory it has to be designed to work in a multi-threaded environment as a shared resource. Otherwise all the apps will corrupt each other and you'll have horrible unpredictable failures. Maybe immediately, if you're lucky. Otherwise it may not happen until the most critical time.
J2EE is not the lightest of platforms, but for what it does, it's not that bad. There's no good purpose served in trying to warp its intents just because you "might" use lots of resources.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Apr 15, 2004
Thanks Tim. We are leaning towards packaging jars in each war. We are not there yet where we can do load testing with our portal but looking ahead will it be an issue with performance when under load (many instances of same jar)?
It's impossible to predict the performance of an app except as an approximation based on what it's trying to do. Every app has its own characteristics, and webapps are no different. While there are certain obvious good and bad things to do, the real bottlenecks are never when they're expected to be, so the ultimate determination has to be made by measuring under load. Just doing tricks with low-level code or library organizations or stuff like that in the expectation of better performance costs more than it's worth - especially when the tricks involve undermining the maintainability or integrity of the app. In fact, code tricks can actually make it HARDER to optimize, because they can cause the code to be much harder to unravel before trying an alternative. And, in point of fact, given a choice between a better algorithm and "optimized" code, go with the algorithm. Just make sure that the algorithm in question is really "better" for that particular task. I had one famous case where a bubble sort would vastly out-perform heap/quicksorts, because the data was coming in in a worst-case sequence for those sorts.
As long as each WAR contains its own copy of a JAR, there's no problem. Only when you start sharing the same file among multiple apps is there risk. However some jars ARE intended to be shared - such as the JDBC driver jars - and they should go into the tomcat common library directory.