Re: [ecf-dev] Failed to inject method in E4

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]

Re: [ecf-dev] Failed to inject method in E4

From: J Langley <jlangley@xxxxxxxxxxxxxxxxx>
Date: Tue, 2 Sep 2014 11:00:26 -0500 (CDT)
Delivered-to: ecf-dev@xxxxxxxxxxx
List-archive: <https://dev.eclipse.org/mailman/private/ecf-dev>
List-help: <mailto:ecf-dev-request@eclipse.org?subject=help>
List-subscribe: <https://dev.eclipse.org/mailman/listinfo/ecf-dev>, <mailto:ecf-dev-request@eclipse.org?subject=subscribe>
List-unsubscribe: <https://dev.eclipse.org/mailman/options/ecf-dev>, <mailto:ecf-dev-request@eclipse.org?subject=unsubscribe>
Thread-index: /iO4MnHd4hntj4kPw/W43aP9rqv8N+V4EEYI
Thread-topic: Failed to inject method in E4

Sorry if this comes through twice - I sent if from the wrong account:

I'm currently using a workaround similar to one that Wim suggested below except that I'm using a DS component that is also registered as an Addon in a fragment. That way when this bug is fixed I can just throw away the workaround.

Has anyone tried using the Eclipse-BuddyPolicy? You would have to update the manifest of the e4 workbench bundle to set the policy to "registered" and repackage it. I can't try it in my current deployment, but it may be another workaround that doesn't involve writing code.

-J.

From: "Scott Lewis" <slewis@xxxxxxxxxxxxx>
To: ecf-dev@xxxxxxxxxxx
Sent: Thursday, August 28, 2014 9:43:11 AM
Subject: Re: [ecf-dev] Failed to inject method in E4

On 8/28/2014 12:54 AM, Alex Blewitt wrote:

So it’s worth noting that the way OSGi services get injected into the E4 context layer aren’t actually injected, but resolved on demand from a base class. There’s a set of E4 contexts which are nested, and at the top level there’s a EclipseContextOSGi which does the service lookup. At this point, all of the services are loaded via the bundleContext of the EclipseContextOSGi bundle (org.eclipse.e4.core.contexts).

https://git.eclipse.org/c/platform/eclipse.platform.runtime.git/tree/bundles/org.eclipse.e4.core.contexts/src/org/eclipse/e4/core/internal/contexts/osgi/EclipseContextOSGi.java

The services are also statically cached; when a service is accessed, the value is cached in a map. So they don’t get rebound anyway.

There is the concept of an originating context that gets passed through, but this is ignored at the service lookup layer.

I think this could be considered a bug. If the ServiceTracker used to get the service (from RSA) were to use the originating (end consumer) BundleContext, then everything would work just fine. The problem is that e4 is effectively telling RSA that the injection service is the end consumer of the service when it's really another middle man.

Scott

So although injecting other E4 contexts are aware of the originating requests, in the general case the OSGi ones are not.

It’s possible that the E4 binding works when using service interfaces from standard bundles (and DS will do its own look-it-up-in-the-right-bundle approach) but E4 tends not to.

Alex
On 27 Aug 2014, at 22:49, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
Hi Guys,

Hmm.   I've looked over the output below, and this doesn't immediately appear to me to be some problem with ECF's remote services.   I can't really tell, however, whether it's some issue with the e4 dependency injection system.   That appears the likely explanation, but I really don't know or understand the e4 mechanisms very well.

But let me tell you what appears to be going on with the exception below, and perhaps those that know more about e4 can use this info.

When ECF discovers and then imports a remote service, the first thing it needs to do to create a proxy for that service is to load the service interface class (represented by RemoteServiceAdmin.loadServiceInterfacesViaBundle on stack below).    To load the service interface, it can't use the RSA bundle to do so (i.e. Bundle.loadClass), but rather it has to use the bundle that's requesting access to the OSGi service. In the case of the below the service type is IRunControllerService, and the requesting bundle is org.eclipse.e4.ui.workbench.

The reason this is necessary has to do with OSGi's rules about exports and imports. Obviously the RSA code knows nothing about IRunControllerService, and so typically the only Bundle that does is the one that is asking for the service (because it has to cast it to the service type anyway...just to use it...and so has to import the service type).   This is also related to OSGi's service-level security, as only bundles that declare their imports (and have appropriate service permissions if running with security manager), can load the service type class.   One way to summarize this is that this behavior is not an ECF RSA implementation choice, but rather more a required/specified behavior for proxy classloading since it has to be able to load the service type classes in order to create the proxy.

Anyway, what seems to be happening in this case is that it's the e4.ui.workbench that's requesting access to the proxy, and so RSA is using the e4.ui.workbench bundle to attempt to load the service type class. It makes sense that the e4.ui.workbench bundle wouldn't know about this service, but what I don't understand is why is it trying to request/get the service...without access to the service type? That's where I don't know enough about the e4 di stuff and where I run out of answers.

It certainly must work with ServiceTracker and/or DS. I'm not precisely sure how DS manages this but obviously it does as part of compliance with the DS specification.   My guess is that it's the DS injectee bundle that gets used as the requester/getter of any service, rather than the ds implementation bundle, but I'm not certain of that.

Scott

On 8/27/2014 12:42 PM, J Langley wrote:
Incredible timing!

I ran into the exact same issue yesterday. I have services on a remote machine that I can connect to client services using DS, but if I try to @Inject them into a GUI element I get the error that Wim mentioned. I haven't had enough time to track down the root cause yet, but I reply with anything I find. I considered creating a bug, but I would like to see if it is an issue with ECF or an underlying E4 problem.

In the meantime, I think I will create an Addon that uses a service tracker to find the service and add it to the context.

Thanks,
-J.

From: "Wim Jongman" <wim.jongman@xxxxxxxxx>
To: "Eclipse Communication Framework (ECF) developer mailing list." <ecf-dev@xxxxxxxxxxx>
Sent: Wednesday, August 27, 2014 1:45:49 PM
Subject: [ecf-dev] Failed to inject method in E4

Hi,

I have advised ECF on a project creating an E4 based RCP application and we have found and odd thing. When a service is discovered and published in the local OSGi containter there is an exception when E4 dependency injection wants to instantiate the object.

When the service is obtained with a service tracker and then pushed into the e4 context everything is ok.

We get a CNFE like this:

java.lang.ClassNotFoundException: ln.ont.sdaorj.services.simulation.IRunControllerService cannot be found by osgi.identity; osgi.identity="org.eclipse.e4.ui.workbench"; type="osgi.bundle";

I appreciate your ideas.

Cheers,

Wim

osgi> !SESSION 2014-08-27 14:38:16.217 -----------------------------------------------
eclipse.buildId=unknown
java.version=1.7.0_60
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Framework arguments: -product ln.ont.sdaorj.gui.product -clearPersistedState
Command-line arguments: -product ln.ont.sdaorj.gui.product -data O:\/../runtime-ln.ont.sdaorj.client.product -dev file:O:/.metadata/.plugins/org.eclipse.pde.core/ln.ont.sdaorj.client.product/dev.properties -os win32 -ws win32 -arch x86 -consoleLog -clearPersistedState -console

!ENTRY org.eclipse.e4.ui.workbench 1 0 2014-08-27 14:38:17.122
!MESSAGE LifeCycleManager - Eclipse context registered @lifecyclemanager
INFO - RemoteBroker - Remote Broker constructed
INFO - RemoteBroker - Remote broker: service trackers active
INFO - HostConfigurationManager - Creating host configuration manager
INFO - Class - Service ln.ont.sdaorj.services.IHostConnectionService.proxy@xxxxxxxxxxxxxxx.remoteservice.RemoteServiceID[containerID=StringID[ecftcp://192.168.192.85:3787/server];containerRelativeID=1] from Name arrived at remote broker

!ENTRY org.eclipse.ecf.osgi.services.remoteserviceadmin 4 0 2014-08-27 14:38:39.746
!MESSAGE org.eclipse.core.runtime.Status[plugin=org.eclipse.ecf.osgi.services.remoteserviceadmin;code=4;message=org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin:loadInterfacesViaBundle:interface=ln.ont.sdaorj.services.simulation.IRunControllerService cannot be loaded by clientBundle=org.eclipse.e4.ui.workbench;severity4;exception=java.lang.ClassNotFoundException: ln.ont.sdaorj.services.simulation.IRunControllerService cannot be found by osgi.identity; osgi.identity="org.eclipse.e4.ui.workbench"; type="osgi.bundle"; version:Version="1.1.0.v20140228-1539"; singleton:="true";children=[]]
!STACK 0
java.lang.ClassNotFoundException: ln.ont.sdaorj.services.simulation.IRunControllerService cannot be found by osgi.identity; osgi.identity="org.eclipse.e4.ui.workbench"; type="osgi.bundle"; version:Version="1.1.0.v20140228-1539"; singleton:="true"
    at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:416)
    at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:336)
    at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:328)
    at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at org.eclipse.osgi.internal.framework.EquinoxBundle.loadClass(EquinoxBundle.java:568)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.loadServiceInterfacesViaBundle(RemoteServiceAdmin.java:1635)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.createProxy(RemoteServiceAdmin.java:1694)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.access$5(RemoteServiceAdmin.java:1685)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$ProxyServiceFactory.getService(RemoteServiceAdmin.java:1670)
    at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$1.run(ServiceFactoryUse.java:212)
    at java.security.AccessController.doPrivileged(Native Method)
    at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService(ServiceFactoryUse.java:210)
    at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.getService(ServiceFactoryUse.java:111)
    at org.eclipse.osgi.internal.serviceregistry.ServiceConsumer$2.getService(ServiceConsumer.java:45)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:489)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getService(ServiceRegistry.java:461)
    at org.eclipse.osgi.internal.framework.BundleContextImpl.getService(BundleContextImpl.java:619)
    at org.eclipse.e4.core.internal.contexts.osgi.EclipseContextOSGi.serviceChanged(EclipseContextOSGi.java:120)
    at org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:109)
    at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:914)
    at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
    at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:862)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:801)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:127)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:225)
    at org.eclipse.osgi.internal.framework.BundleContextImpl.registerService(BundleContextImpl.java:464)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$10.run(RemoteServiceAdmin.java:1569)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$10.run(RemoteServiceAdmin.java:1)
    at java.security.AccessController.doPrivileged(Native Method)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.createAndRegisterProxy(RemoteServiceAdmin.java:1567)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.importService(RemoteServiceAdmin.java:2134)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.importService(RemoteServiceAdmin.java:423)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.AbstractTopologyManager.handleECFEndpointAdded(AbstractTopologyManager.java:244)
    at org.eclipse.ecf.internal.osgi.services.distribution.BasicTopologyManagerImpl.endpointAdded(BasicTopologyManagerImpl.java:123)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.EndpointDescriptionLocator$1.dispatchEvent(EndpointDescriptionLocator.java:156)
    at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
    at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
DEBUG - StartScenarioHandler - Run controller service registered @ StartScenarioHandler
DEBUG - AsFastAsPossibleHandler - Run controller service registered @ AsFastAsPossibleHandler
DEBUG - PauseScenarioHandler - Run controller service registered @ PauseScenarioHandler
DEBUG - StopScenarioHandler - Run controller service registered @ StopScenarioHandler
DEBUG - ScenarioTimeVisualizer - Run controller service registered @ ScenarioTimeVisualizer

!ENTRY org.eclipse.ecf.osgi.services.remoteserviceadmin.proxyDEBUG - ScenarioSpeedSlider - Run controller service registered @ ScenarioSpeedSlider
4 0 2014-08-27 14:38:39.752
!MESSAGE FrameworkEvent ERROR
!STACK 0
org.osgi.framework.ServiceException: Exception in org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$ProxyServiceFactory.getService()
    at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService(ServiceFactoryUse.java:222)
    at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.getService(ServiceFactoryUse.java:111)
    at org.eclipse.osgi.internal.serviceregistry.ServiceConsumer$2.getService(ServiceConsumer.java:45)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:489)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getService(ServiceRegistry.java:461)
    at org.eclipse.osgi.internal.framework.BundleContextImpl.getService(BundleContextImpl.java:619)
    at org.eclipse.e4.core.internal.contexts.osgi.EclipseContextOSGi.serviceChanged(EclipseContextOSGi.java:120)
    at org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:109)
    at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:914)
    at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
    at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:862)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:801)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:127)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:225)
    at org.eclipse.osgi.internal.framework.BundleContextImpl.registerService(BundleContextImpl.java:464)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$10.run(RemoteServiceAdmin.java:1569)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$10.run(RemoteServiceAdmin.java:1)
    at java.security.AccessController.doPrivileged(Native Method)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.createAndRegisterProxy(RemoteServiceAdmin.java:1567)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.importService(RemoteServiceAdmin.java:2134)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.importService(RemoteServiceAdmin.java:423)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.AbstractTopologyManager.handleECFEndpointAdded(AbstractTopologyManager.java:244)
    at org.eclipse.ecf.internal.osgi.services.distribution.BasicTopologyManagerImpl.endpointAdded(BasicTopologyManagerImpl.java:123)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.EndpointDescriptionLocator$1.dispatchEvent(EndpointDescriptionLocator.java:156)
    at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
    at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
Caused by: java.lang.RuntimeException: ProxyServiceFactory cannot load any serviceInterfaces=[] for serviceReference={ln.ont.sdaorj.services.simulation.IRunControllerService}={endpoint.service.id=208, HOST_NAME=Name, service.scope=bundle, HOST_PORT=3787, service.bundleid=7, endpoint.id=5f790ac2-681b-4fe6-9fd8-b9359e2b70dd, service.imported=org.eclipse.ecf.provider.remoteservice.generic.RemoteServiceImpl@c7ed08, service.imported.configs=[ecf.generic.client], HOST_IP=192.168.192.85, service.id=211} via clientBundle=org.eclipse.e4.ui.workbench
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.createProxy(RemoteServiceAdmin.java:1700)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.access$5(RemoteServiceAdmin.java:1685)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$ProxyServiceFactory.getService(RemoteServiceAdmin.java:1670)
    at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$1.run(ServiceFactoryUse.java:212)
    at java.security.AccessController.doPrivileged(Native Method)
    at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService(ServiceFactoryUse.java:210)
    ... 26 more
INFO - Class - Service ln.ont.sdaorj.services.simulation.IRunControllerService.proxy@xxxxxxxxxxxxxxx.remoteservice.RemoteServiceID[containerID=StringID[ecftcp://192.168.192.85:3787/server];containerRelativeID=2] from Name arrived at remote broker
INFO - Class - Service ln.ont.sdaorj.services.simulation.IPlatformDataService$IExtendedPlatformDataService.proxy@xxxxxxxxxxxxxxx.remoteservice.RemoteServiceID[containerID=StringID[ecftcp://192.168.192.85:3787/server];containerRelativeID=3] from Name arrived at remote broker
INFO - Class - Service ln.ont.sdaorj.services.simulation.ISystemTrackDataService$IExtendedSystemTrackDataService.proxy@xxxxxxxxxxxxxxx.remoteservice.RemoteServiceID[containerID=StringID[ecftcp://192.168.192.85:3787/server];containerRelativeID=4] from Name arrived at remote broker
INFO - Class - Service ln.ont.sdaorj.services.simulation.IEngagementDataService$IExtendedEngagementDataService.proxy@xxxxxxxxxxxxxxx.remoteservice.RemoteServiceID[containerID=StringID[ecftcp://192.168.192.85:3787/server];containerRelativeID=5] from Name arrived at remote broker

osgi> ss sdaorj
"Framework is launched."

id    State       Bundle
4    ACTIVE      ln.ont.sdaorj.gui_1.0.0.qualifier
12    ACTIVE      ln.ont.sdaorj.scenario.runcontroller_1.0.0.qualifier
30    ACTIVE      ln.ont.sdaorj.remotebroker_3.0.0.qualifier
33    RESOLVED    ln.ont.sdaorj.libraries_1.0.0
46    STARTING    ln.ont.sdaorj.messaging_4.0.0.qualifier
47    RESOLVED    ln.ont.sdaorj.services_1.0.0.qualifier
58    RESOLVED    ln.ont.sdaorj.common_1.0.0.qualifier
76    RESOLVED    ln.ont.sdaorj.data_1.0.0.qualifier
84    ACTIVE      ln.ont.sdaorj.connection.controls_1.0.0.qualifier
osgi>

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev

References:
- [ecf-dev] Failed to inject method in E4
  - From: Wim Jongman
- Re: [ecf-dev] Failed to inject method in E4
  - From: J Langley
- Re: [ecf-dev] Failed to inject method in E4
  - From: Scott Lewis
- Re: [ecf-dev] Failed to inject method in E4
  - From: Alex Blewitt
- Re: [ecf-dev] Failed to inject method in E4
  - From: Scott Lewis

Prev by Date: [ecf-dev] etcd-based discovery provider initial signs of life
Next by Date: Re: [ecf-dev] etcd-based discovery provider initial signs of life
Previous by thread: Re: [ecf-dev] Failed to inject method in E4
Next by thread: Re: [ecf-dev] Failed to inject method in E4
Index(es):
- Date
- Thread

Breadcrumbs