tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <knst.koli...@gmail.com>
Subject Re: Classloaders
Date Tue, 26 May 2009 21:35:14 GMT
2009/5/27 Jon Pearson <Jon.Pearson@sixnet.com>:
>> -----Original Message-----
>> From: Konstantin Kolinko [mailto:knst.kolinko@gmail.com]
>> Sent: Tuesday, May 26, 2009 4:44 PM
>> To: Tomcat Users List
>> Subject: Re: Classloaders
>>
>> 1. What tomcat version?
>
> Tomcat v. 6.0.18, JVM 1.6.0_13, Ubuntu 9.04 on kernel 2.6.28-11
>

OK

>> 2. The documentation on classloaders is here:
>> http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html
>
> Thanks, but I've read through that a few times. It describes the
> existing classloader layout but does not describe how to avoid problems
> when using your own within Tomcat.
>

Well, at least you should cooperate with this layout. ;)


Some notes:

The class loader of a web application can be retrieved as
Thread#getContextClassLoader()

Also, if you run in development mode (see Jasper configuration), each JSP
is executed with its own class loader, so that they can be reloaded.
http://tomcat.apache.org/tomcat-6.0-doc/jasper-howto.html

>> 3. Some JDBC drivers use native code. Those cannot be loaded from
>> different class loaders in the same time. Thus, they cannot be loaded
>> from /WEB-INF/lib, as there will be conflicts between applications,
>> or between several instances of the same application if it is
>> restarted.
>
> This one does not include any native code, it is self-contained in a
> single JAR file.
>
>> 4. Put the jar file into WEB-INF/lib, and then restart your
>> web application.
>>  (E.g., using Tomcat Manager).  Your jar library will be loaded.
>> http://tomcat.apache.org/tomcat-6.0-doc/html-manager-howto.html
>> http://tomcat.apache.org/tomcat-6.0-doc/manager-howto.html
>
> It is more of a plugin than a library. The location is user-specified, a
> directory to watch for plugin JARs. Each JAR contains metadata in the
> manifest describing the main class of the plugin. That main class is
> loaded using Class.forName(), causing a static{} block in the class to
> run, performing any registrations necessary to integrate with the
> application.
>
> When the class is needed (i.e. when I try to connect to a database), a
> new instance is created. That involves calling Class.forName()

Do you pass a ClassLoader reference to that forName() call?
What is classloader hierarchy for the ClassLoader used by that call?

See
http://java.sun.com/javase/6/docs/api/java/lang/Class.html#forName(java.lang.String)
http://java.sun.com/javase/6/docs/api/java/lang/Class.html#forName(java.lang.String,%20boolean,%20java.lang.ClassLoader)

> to load
> the PostgreSQL database driver (a class called 'org.postgresql.Driver'),
> contained in postgresql-8.3-604.jdbc4.jar (present in WEB-INF/lib). But
> that call to Class.forName() to load org.postgresql.Driver fails because
> the class cannot be found.
>
> This is confounding because an ancestor classloader of my URLClassLoader
> that made the classes in my plugin JAR available should have access to
> org.postgresql.Driver. In fact, one of them *must* because when the
> classes in my plugin JAR are placed into WEB-INF/classes in their raw
> .class state (not packaged into a jar), everything works.
>

It might be. What happens, step-by-step, in this case?  Additional
classes will be picked up by web-app classloader instantly. Additional
JARs - only upon restart of the web application, because it requires
reconfiguration of the class loader (adds additional URLs to scan for
classes).

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message