2008/7/7 Carsten Ziegeler <[EMAIL PROTECTED]>: > Hi, > > I came across a problem related to class loading in SCR and before trying > to fix this I would get some feedback if this is really a bug (see > FELX-624). > > Now, the problem is as follows - we have three bundles. > Bundle C : Provides a service for SERVICE_X which is registered through > SCR. > > Bundle A : Provides an abstract class AbstractClass that has a bind and > unbind method for SERVICE_X. Therefore bundle A imports this service. > > Bundle B : Provides a component COMPONENT_Y through SCR which inherits from > AbstractClass from Bundle A. The class for COMPONENT_Y does nothing by > itself with SERVICE_X, so there is no import and no import statement > required for bundle B for SERVICE_X. > > All bundles can be deployed and resolved, but when starting bundle B, there > is a ClassNotFoundException as the SCR implementation searches for a bind > method with SERVICE_X as the parameter. The SCR implementation > (DependencyManager#734) uses the classloader from bundle B to load the > parameter class. In this case this is SERVICE_X which is not visible for the > classloader of bundle B. > > So the question is, should there be a more clever search algorithm to > resolve the parameter class? Or is this such an obscure use case that rather > the "workaround" of adding an import statement to SERVICE_X in bundle B > should be used? >
imho SCR should be using the classloader of the class that declared the bind/unbind method, ie: method.getDeclaringClass().getClassLoader() when loading parameter classes - always using B's classloader doesn't sound right to me Please note that we ran into this problem several times in the past, but > never had the time to follow up on it and always used the workaround. We > work with several abstract classes providing basic service functionality > comming from a "common" bundle. > > Carsten > -- > Carsten Ziegeler > [EMAIL PROTECTED] > -- Cheers, Stuart
