On Thu, 2004-12-30 at 08:27 -0600, Heath Borders wrote: > The problem is that JSF needs access to the jars in a uniform spot to > configure the runtime. The spec says that it should act this way.
I've read and understood the documents Martin Cooper in another mail pointed me at (thanks), anyway, this is what I read on the JSF specs, paragraph 10.2.5 and 10.2.6: "These classes and resources comprise the implementation of the JSF APIs that is provided by a JSF implementor. Typically, such classes will be provided in the form of one or more JAR files, which can be either installed with the container s shared class facility, or included in the /WEB-INF/lib directory of a web application archive." So, if I'm not mistaken, the specs explicitly says that those jar can be shared among all applications. That is of course also a golden rule of software distribution: imagine if I have N web applications using JSF and a security issue comes out: in a shared context I just replace the updated jars while in the other case I must manually check all the webapps using them and substitute them one by one. Slow and error prone. > Probably the best way around this is to see if your servlet container > supports aliasing the jars. I'm running websphere, and i think > there's a way that I could keep my jars in a common directory, but > have my apps all reference them as though they were in their > WEB-INF/lilb directories. That's a nice feature from websphere but I'm stuck with tomcat 5.0.28 right now: maybe it has something equivalent? I did a quick search but without any success. Best regards, Alex
