Is true and I have tried. As you know, servlet specification indicates that shared libraries is based on Container Extensions (9.7.1 of Servlet Specification 2.4). I'm using IBM WebSphere and this Application Server has "Server Shared Libraries" and "Application Shared Libraries". Using first one all the jars are shared by all application deployed, using the second one you configure a shared library and you can choices which application use it. The classloader that loads the "Application Shared Libraries" is the classloader of the module/application that has the reference to the shared library (Best Practice for Using Common Application Files http://www-1.ibm.com/support/docview.wss?fdoc=aimwas&rs=180&uid=swg27006 159 )
The problem using shared libraries is that all tld files presents in some jar (shale, myfaces, tomahawk, struts...) need to be copied manually in WEB-INF directory of each application. So, in my opinion, copy a jar or a tld file is the same :-). At the and of my tests, I have decided to put in shared libraries all jar not tipically web oriented (for example Jakarta-commons) and put in WEB-INF/lib jars like shale, myfaces, tomahawk and struts. The reason I'm using shared libraries is that we have developed same web application with the same framework and I want/need to be sure that all application use the libraries I decided. Regards Mario Buonopane ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: 8 marzo 2007 17.00 To: MyFaces Discussion Subject: Re: Sharing myfaces libraries On 3/7/07, [EMAIL PROTECTED] <[EMAIL PROTECTED] > wrote: I have more than one application developed with same version of shale/myfaces/tomahawk. Is it correct install these libraries in "Shared Libraries" not remove them from WEB-INF/lib of each application? It depends on your situation. Installing the libraries as shared inside the server definitely makes your WAR files smaller and therefore likely to deploy a little faster. On the other hand, you will be requiring that all of the co-installed applications use the same versions of these dependencies, rather than potentially being able to upgrade them individually. One thing to watch out for -- some libraries have been known to have quirks when installed in as a shared library, due to the fact that the class loader hierarchy is changed. The fundamental issue is that it's easy to write code that assumes application classes are loaded by the same class loader that loaded your class. That's true if your class was in /WEB-INF/lib but not true if you install your class in a shared library (your class loader will be a parent of the webapp class loader). The simplest way to find out whether this works is to try it. Craig Regards Mario This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
