Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (athena.apache.org: domain of fmeschbe@gmail.com designates
 209.85.134.184 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=F8ZrV7S0fzPl62CmPoaJIgKZbY7YzsyYSqDs2MsJIpVYYY6zBWueLHdmxe2inDL9u1
         VAuiuTi7oKCiN4ANMO5YLGHDD+NDURodMGv2nU/PD63qFarqV8cpzW8RPWGNy+U7oMqz
         ifQ2VXhWimn6IdSUs13SmiJMBt/tp2eKqUpCc=
Message-ID: <48872031.4070009@gmail.com>
Date: Wed, 23 Jul 2008 14:12:33 +0200
From: Felix Meschberger <fmeschbe@gmail.com>
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: dev@felix.apache.org
Subject: Re: Question about class loading and SCR (see FELIX-624)
References: <487213B7.2040303@apache.org>
	 <81f0d9c0807070609qf1460beledef80369cf703c0@mail.gmail.com>
	 <48721B84.4030404@apache.org>
 <81f0d9c0807070719v18de67d5t7805037a968c3d66@mail.gmail.com>
 <48722DD7.1070304@apache.org>
In-Reply-To: <48722DD7.1070304@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

Carsten Ziegeler schrieb:
> Stuart McCulloch wrote:
>>
>> looking at the current code that trawls the super-classes, I believe the
>> problem could be solved by changing 'DependencyManager.java:734'
>> so a ClassNotFoundException will drop down to the exhaustive search
>> of declared methods (this code would need to be refactored out, so it
>> can be called from multiple catch blocks)

The reason for trawling the super-classes is, that protected methods are 
only accessible through reflection with the Class.getDeclaredMethod 
method. This method in turn only returned methods of the Class itself 
not methods of extended classes.

>>
>> re-writing that whole function might reveal more optimizations though :)
>>
> Yes, I took a much simpler approach which should be alright: I use the 
> bundle which exports the service for loading the class. This classloader 
> has already loaded the class as the bundle is exporting this service. 
> And this class should be the same which should be used for the 
> bind/unbind method as otherwise class cast exceptions would occur.

Right, this should work as the framework should already guarantee that 
the class object used by the service and the class object used by the 
abstract class with the bind methods are the same.

Nevertheless, I would think, that using the class loader from 
Class.getClassLoader() of the class providing the bind (or unbind) 
method to be called is probably better than using the bundle providing 
the service. Its just cleaner IMHO.

That is the assignment of the parameterClass in DependencyManager#734 
would be:

    parameterClass =
        targetClass.getClassLoader().loadClass(parameterClassName)

instead of using serviceBundle.loadClass.

Of course, we would have to catch (and ignore) the 
ClassNotFoundException here, as the loader of the target class might not 
have the parameter class because the target class does not have the bind 
method we are looking for.

WDYT ?

Regards
Felix

> 
> A quick test of our hugh application massivly using SCR did not reveal 
> any problems.
> 
> Carsten
>