On Fri, 5 Apr 2002, Mark Shaw wrote:
> Date: Fri, 5 Apr 2002 15:29:04 -0800
> From: Mark Shaw <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> Subject: Design question: common/lib --> WEB-INF/lib
>
> I have a design question I'm guessing someone has already tackled:
>
> Description:
> I'm developing an application that runs within Tomcat. All the JARs for
> that application are in it's webapp/WEB-INF/lib, except for a few classes
> that implement a Realm which referenced in server.xml. Because these
> classes are referenced in server.xml, they need to be in
> {catalina_home}/common/lib. The problem I have is that my Realm need to use
> my database code, but my database JARs are defined in my webapp lib. I
> could put everything in common/lib except that I'd like to be able to
> control (start/stop/re-load) my application using the Tomcat manager.
>
> Question:
> How can my code in common/lib reference objects in webapp/lib? Do I have to
> do this using JNDI by defining common interfaces in common/lib and returning
> webapp/lib objects from my factories? Any guidances is appreciated.
>
Using JNDI is one way, but it can be cumbersome.
Another way is to rely on a requirement in J2EE 1.3 (and therefore in
Servlet 2.3) that requires containers to expose the web application's
class loader:
ClassLoader webappLoader =
Thread.currentThread().getContextClassLoader();
Class webappClass = webappLoader.loadClass("com.mycompany.MyClass");
This works because the container (Tomcat in this case) always sets the
thread context class loader to the one for the webapp being executed on
the current request thread -- therefore, the classes in /WEB-INF/classes
and /WEB-INF/lib are visible via this class loader, even though the class
containing the above code is loaded from somewhere else.
WARNING - This only works for request processing threads managed by the
container. If you start your own threads, you are on your own for saving
a reference to the webapp class loader you need.
> Thanks,
> -Mark
>
Craig
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
