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 =
Thread.currentThread().getContextClassLoader();
DataSourceComponent component = null;
if( null == classLoader )
{
if( !"".equals( driver ) )
{
Class.forName( driver, true,
Thread.currentThread().getContextClassLoader() );
}
component = (DataSourceComponent)Class.forName( clazz
).newInstance();
}
else
{
if( !"".equals( driver ) )
{
classLoader.loadClass( driver );
}
component = (DataSourceComponent)classLoader.loadClass( clazz
).newInstance();
}
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 =
Thread.currentThread().getContextClassLoader();
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
all?
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?
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
