Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <dev@avalon.apache.org>
From: Niclas Hedhman <niclas@hedhman.org>
Organization: Private
To: "Avalon Developers List" <dev@avalon.apache.org>
Subject: Re: BlockThread
Date: Sat, 3 Jan 2004 14:39:55 +0800
User-Agent: KMail/1.5
References: <NBBBJGEAGJAKLIDBKJOPKEIDGFAB.noel@devtech.com>
 <200401031349.26103.niclas@hedhman.org>
In-Reply-To: <200401031349.26103.niclas@hedhman.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200401031439.55246.niclas@hedhman.org>

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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org