You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/08/02 14:48:02 UTC
Potential Classloader bug
Cocoon has a potential classloader issue. The Excalibur that comes with
Cocoon has support for the <driver/> entry in the JdbcDataSource--and uses
the Context ClassLoader to load the driver's class. The only problem is
that even though the class is properly loaded, it is not loaded in the
same classloader that created the JdbcDataSource.
Now, the question becomes: Should JdbcDataSource use the context classloader,
or should Cocoon fix the classloader issue? If JdbcDataSource does it, that
means the class will be loaded by the same classloader that created JdbcDataSource.
This may or may not be a bad thing. If JdbcDataSource is loaded by the
Boot ClassLoader, then the driver will be loaded for the Boot ClassLoader.
The thing is that the JdbcDataSource works fine when the ClassLoader in the
Context ClassLoader (Thread.currentThread().getContextClassLoader()) is the
same one or a parent of the classloader that loaded the JdbcDataSource.
There is some wierdness with the DriverManager.getConnection() so it may be
that the Driver class should be loaded with the the same classloader as
JdbcDataSource.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Potential Classloader bug
Posted by Berin Loritsch <bl...@apache.org>.
Sylvain Wallez wrote:
>
> Shouldn't there be a mean in Avalon to store this "application root
> ClassLoader" and use it in selected places, like JDBC driver loading ?
> This will allow the JdbcDataSource <driver> to be loaded in the same
> ClassLoader as with the "force-load" parameter.
Cocoon stores the Application Root Classloader in each threads Context
Classloader so that we can execute the following snippet to get it:
Thread.currentThread().getContextClassLoader();
The issue with the JDBC driver was the the loadClass(name) function does
not resolve the class--which is essential to dynamically installing the
driver in the JDBC DriverManager.
I solved the problem by using the JDK1.2 (or is it 1.3 specific) method:
Class.forName(name, true, classLoader);
What this does is load a class with the specified classloader, and the
"true" parameter tells the ClassLoader to resolve the class.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Potential Classloader bug
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Berin Loritsch wrote:
>
> Cocoon has a potential classloader issue. The Excalibur that comes with
> Cocoon has support for the <driver/> entry in the JdbcDataSource--and uses
> the Context ClassLoader to load the driver's class. The only problem is
> that even though the class is properly loaded, it is not loaded in the
> same classloader that created the JdbcDataSource.
>
> Now, the question becomes: Should JdbcDataSource use the context classloader,
> or should Cocoon fix the classloader issue? If JdbcDataSource does it, that
> means the class will be loaded by the same classloader that created JdbcDataSource.
> This may or may not be a bad thing. If JdbcDataSource is loaded by the
> Boot ClassLoader, then the driver will be loaded for the Boot ClassLoader.
>
> The thing is that the JdbcDataSource works fine when the ClassLoader in the
> Context ClassLoader (Thread.currentThread().getContextClassLoader()) is the
> same one or a parent of the classloader that loaded the JdbcDataSource.
> There is some wierdness with the DriverManager.getConnection() so it may be
> that the Driver class should be loaded with the the same classloader as
> JdbcDataSource.
>
Not a specialist about classloader problems, but here are my thoughts.
Tell me if I'm wrong.
The force-load servlet parameter in Cocoon calls ClassUtils.loadClass(),
which uses the ClassLoader used to load itself, i.e. the
ServletContext's ClassLoader. This ClassLoader is also the parent of the
RepositoryClassLoader which is set with Thread.setContextClassLoader.
So what we have here is a ClassLoader which is the root of the
application ClassLoader hierarchy (whatever "application" means, here a
servlet context) and a final ClassLoader which the application should
use to benefit of dynamic compilation.
Shouldn't there be a mean in Avalon to store this "application root
ClassLoader" and use it in selected places, like JDBC driver loading ?
This will allow the JdbcDataSource <driver> to be loaded in the same
ClassLoader as with the "force-load" parameter.
Hope I was clear in explaining my thoughts :)
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Potential Classloader bug
Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
>
> Cocoon has a potential classloader issue. The Excalibur that comes with
> Cocoon has support for the <driver/> entry in the JdbcDataSource--and uses
> the Context ClassLoader to load the driver's class. The only problem is
> that even though the class is properly loaded, it is not loaded in the
> same classloader that created the JdbcDataSource.
>
> Now, the question becomes: Should JdbcDataSource use the context classloader,
> or should Cocoon fix the classloader issue? If JdbcDataSource does it, that
> means the class will be loaded by the same classloader that created JdbcDataSource.
> This may or may not be a bad thing. If JdbcDataSource is loaded by the
> Boot ClassLoader, then the driver will be loaded for the Boot ClassLoader.
>
> The thing is that the JdbcDataSource works fine when the ClassLoader in the
> Context ClassLoader (Thread.currentThread().getContextClassLoader()) is the
> same one or a parent of the classloader that loaded the JdbcDataSource.
> There is some wierdness with the DriverManager.getConnection() so it may be
> that the Driver class should be loaded with the the same classloader as
> JdbcDataSource.
I tried the approach of using JdbcDataSource's ClassLoader to load the class,
but that didn't work. Hmmm.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org