avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: BlockThread
Date Sat, 03 Jan 2004 06:39:55 GMT
On Saturday 03 January 2004 13:49, Niclas Hedhman wrote:
> Argument in favour of doing 2.
> ==============================
> So far I have only heard "people normally does;"

It seems that a fair number of avalon-excalibur and avalon-components 
components are using the Thread.currentThread().getContextClassLoader(), and 
I think in many instances this usage is outright incorrect, for instance;

in org.apache.avalon.cornerstone.blocks.datasources.DefaultDataSourceSelector 
we find the following snippet in initialize();

            final Configuration dataSourceConf = dataSourceConfs[ i ];
            final String name = dataSourceConf.getAttribute( "name" );
            final String clazz = dataSourceConf.getAttribute( "class" );
            final String driver = dataSourceConf.getChild( "driver", true 
).getValue( "" );

            final ClassLoader classLoader =

            DataSourceComponent component = null;
            if( null == classLoader )
                if( !"".equals( driver ) )
                    Class.forName( driver, true, 
Thread.currentThread().getContextClassLoader() );

                component = (DataSourceComponent)Class.forName( clazz 
                if( !"".equals( driver ) )
                    classLoader.loadClass( driver );

                component = (DataSourceComponent)classLoader.loadClass( clazz 

To me it is apparent that the Author have no clue what he/she is doing in 
respect to Classloaders, or actually more likely that there was a change at 
some point;

If this returns null;
    final ClassLoader classLoader =

why would I not pass "null" directly in the CL argument in;
    Class.forName( driver, true, 
        Thread.currentThread().getContextClassLoader() );

Also, isn't it reasonable that the Classloader for JDBC driver to either be 
loaded by the same classloader as the DataSourceSelector or one of its 
ancestors, for instance the Extension Classloader?

I think so. In Merlin this is very much the case.

HOWEVER, Is the above some kind of MEGA FIX for problems in ECM, Phoenix 
and/or Fortress, or is it just "cruft" that should be made right once and for 
How about all the other components that has a similar setup (heaps of them in 
our repository and I guess a lot "out there")??
Is Legacy support THAT important?
IMHO, we should tighten the contract and add strong semantics to the thread 
context classloader, and incorrect use is a BUG which then needs fixing.
Better to do it now, when Merlin is not that widespread.

Any "historian" care to shed some light?


To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message