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
