File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Tomcat and the fly likes Shared Vs Packaged jars Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Products » Tomcat
Bookmark "Shared Vs Packaged jars" Watch "Shared Vs Packaged jars" New topic
Author

Shared Vs Packaged jars

murali talluri
Greenhorn

Joined: Apr 15, 2004
Posts: 3
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?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16142
    
  21

Don't even think about it.

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.
murali talluri
Greenhorn

Joined: Apr 15, 2004
Posts: 3
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)?

Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16142
    
  21

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Shared Vs Packaged jars