Ooops, that’s only one way - but not the perfect one.
The best place to store the library is:
either (1) /WEB-INF/lib (there are already some)
or (2) //appclasses/lib
Try (1) first, if you encounter classloader problems (ClassNotFOundException) the try (2).
By (1) or (2) you make sure that the jar file is part of the web application. A web application is some kind of self containing thing (.war file) which can be moved across application servers. With “setClasspath” extensions, you bypass the concept of web applications.
Hi, put it in (1) ie …/webapps/cis/WEB-INF/lib and all works fine
I guess you use (1) for jar/classes which are ‘global’ ie span many web projects
and (2) if it is project specific …
…scenario (1) is “of general use” (and of course: if you have WEB-INF/classes that refer to, there is no way round).
The problem with (1) may be: if you have libraries which are not used as server only (“server” in software means: they do something for a client program) but which themselves actively call back into the calles’s environment.
Example: Hibernate as persistence framework creates objects for table rows. I.e. somewhere Hiberbate calls something like Class.forName(“xyzClassName”).newInstance() - the class name being part of its parametrization.
This means that the hibernate.jar file (providing the persistence framework) must be able to see the applications classes (the ones, it creates instances for).
If you application classes are in the CAI-projects (//appclasses/classes then the hibernate.jar must be located on the same level.
Sorry, I did not find easier words… - in your case it seems that your jar is a “server”-type jar file. So everything is fine…