Hi Scott,
Thank you for looking into this. It made me realize what is going on.
I think we have found a special DI case where the provider and the receiver of the service both don't know its class.
With E4, the following construct is possible:
class MyView {
@Inject @Optional
IRunControllerService service
}
If an instance of the specific service is found by the DI framework, it is placed in the "context" (DI goodybag hashmap,) From this context the requesting classes are visited and the service is injected into MyView.
In the above annotation you tell the Eclipse DI framework to inject the instance of the service into instances of MyView if the service changes in the context.
So this is what happens.
1. The above MyView instance is created by the DI framework (it is a view or an editor or something).
2. The DI fw sees that MyView is looking for the IRCS service and starts tracking for this service
3. At some point ECF creates a proxy for this service
4. ECF sees that the service is to be deliverd to the DI fw and uses its classloader to instantiate the object.
5. The IRCS is not in the dependencies of the DI framework so the class cannot be found
It is an interesting problem and I wonder how it could be solved. The problem is the way ECF is trying to load the class as you explained. If it failes to load the class at this point it should fall back to some alternative methods of loading the class.
There are two solutions that spring to mind:
1. When the class cannot be loaded, ECF looks inside OSGi to fiind who is _importing_ the package of this class and use that bundle to load the class.
2. Let the consumer register a special factory that can provide instances of this class
Workaround
In order to solve this they have found the following workaround.
Make a new interface ILocalRemoteControllerService extends IControllerService
1. Let MyView use ILRCS for its DI
2. Track IRCS yourself
3. Wrap it in an ILRCS instance
4. Put ILRCS in the context
5. Let DI give it to MyView
Cheers,
Wim