Boris Unckel wrote:
Hello,
Von: Fran Varin <[EMAIL PROTECTED]>
Yes, quite correct on your statement regarding using "Application" as the
definition. The essence of what we are looking for is a similar behavior
with Tomcat. Our over arching goal is to minimize or eliminate the need
to have jars that are to be shared by more than one applicaiton (WAR) be
copied into each applicaiton.
You are following the wrong approach in my oppinion. The goal of the
Classloaders is to have every application as independent as possible and to
offer an isolated context where possible.
The pro side of the shared classloader is to have the chance to have a
single point of change for the JARs for all applications. I understand the
approach but I (and I think others at the list too) think it is the wrong
approach because it has disadvantages for static variables, logging etc.
We would like to have them in one place
where they can be accessed by all applicaitons. We've achieved this
somewhat by placing the jar in the shared jars folder. However, the
delegation model prohibits instantiating classes that belong to an
application from any entity in the shared jars folder.
If Tomcat does not have a similar facility as mentioned regarding
WebSphere, what is considered to be the "best practices" approach as far
as Tomcat is concerned?
Best practise (not only for Tomcat) is elimante the need for shareds jars.
To the mailing-list: If you have an library which has not the explicit
recommendation to put it in common/shared lib path (i.E. a special JDBC
driver where the vendor recommends one to put it into shared) what do you
prefer - the single point of change in shared or the isolated point of view
with WEB-INF/lib?
Regards
Boris
IMHO, the better approach is to manage common classes and jars in the
build or source repository system rather than the servlet container.
Versioning gets easier as refactoring is no longer an all or nothing
project. Plus the individual webapps no longer need to even be on the
same server and can be moved with a minimum of dependency issues.
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
