Re: [ecf-dev] Problem using multiple services from single server

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

Re: [ecf-dev] Problem using multiple services from single server

From: Timothy Vogel <tvogel@xxxxxxx>
Date: Fri, 13 Mar 2015 06:59:16 -0400
Delivered-to: ecf-dev@xxxxxxxxxxx
Importance: Normal
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>

Peter,

I have an RCP application that uses ECF RSA with karaf. I am using the new support for HTTP/HTTPS through websockets and r_osgi provider. Here are the non default start levels for my application. Note it also uses JPA and Derby so there are some non-ECF bundles listed.

Hope this helps,

Tim

ch.ethz.iks.r_osgi.remote@default:true

ch.ethz.iks.r_osgi.transport.http@default:true

ch.qos.logback.classic@2:true

ch.qos.logback.core@2:true

java_websocket@default:true

javax.persistence@3:true

org.apache.derby@3:true

org.eclipse.core.runtime@default:true

org.eclipse.ecf.console@default:true

org.eclipse.ecf.discovery@default:true

org.eclipse.ecf.identity@default:true

org.eclipse.ecf.osgi.services.distribution@5:true

org.eclipse.ecf.osgi.services.remoteserviceadmin.proxy@default:true

org.eclipse.ecf.provider.r_osgi@default:true

org.eclipse.ecf.provider.remoteservice@default:true

org.eclipse.ecf.provider@default:true

org.eclipse.ecf.remoteservice.asyncproxy*1.0.0.v20140410-1838@default:default

org.eclipse.ecf.remoteservice@default:true

org.eclipse.ecf.sharedobject@default:true

org.eclipse.ecf.ssl@default:false

org.eclipse.ecf@default:true

org.eclipse.equinox.common@2:true

org.eclipse.equinox.ds@1:true

org.eclipse.equinox.event@2:true

org.eclipse.equinox.simpleconfigurator@1:true

org.eclipse.gemini.blueprint.extender@3:true

org.eclipse.gemini.dbaccess.derby@3:true

org.eclipse.gemini.dbaccess.util@3:true

org.eclipse.gemini.jpa@3:true

org.eclipse.osgi.services@default:true

org.eclipse.osgi@-1:true

org.eclipse.update.configurator@3:true

org.objectweb.asm@default:true

Date: Fri, 13 Mar 2015 10:48:08 +0100
From: peter.hermsdorf@xxxxxxxxx
To: ecf-dev@xxxxxxxxxxx
Subject: Re: [ecf-dev] Problem using multiple services from single server

You are right, thanks for the hint. With the suggested runlevel setup the services get imported actually and my testsuite is working again!
But on startup i see the following exception (see below), which is caused by accessing org.eclipse.ecf.internal.osgi.services.remoteserviceadmin.Activator.context before the Activator.start method was called.

But since the access comes from AbstractTopologyManager.getRemoteServiceAdmin I don't really understand why Activator was not yet called by the framework.
Also fiddling around with the start levels of org.eclipse.ecf.osgi.services.remoteserviceadmin does not yield to a result yet ... it's currently as autostart with level 4.

my current setup of startlevel for ecf is:

    target {
        "org.eclipse.ecf.ssl*3.4.0.v20150306-2024"
        "org.eclipse.ecf*3.4.0.v20150306-2024" autostart
        "org.eclipse.ecf.console"
        "org.eclipse.ecf.discovery" autostart
        "org.eclipse.ecf.osgi.services.distribution" autostart startLevel=3
        "org.eclipse.ecf.osgi.services.remoteserviceadmin.proxy" autostart
        "org.eclipse.ecf.osgi.services.remoteserviceadmin" autostart
        "org.eclipse.ecf.provider.remoteservice" autostart
        "org.eclipse.ecf.provider" autostart
        "org.eclipse.ecf.remoteservice" autostart
        "org.eclipse.ecf.remoteservice.asyncproxy*1.0.0.v20140410-1838"
        "org.eclipse.ecf.sharedobject"
        "org.eclipse.ecf.identity.nl_de"
        "org.eclipse.ecf.identity*3.4.0.v20150306-2024" autostart
        "org.eclipse.osgi.services.remoteserviceadmin" autostart
    }

where the default autostart level is at 4.

Thanks for your support!

java.lang.NullPointerException
    at org.osgi.util.tracker.ServiceTracker.<init>(ServiceTracker.java:224)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.AbstractTopologyManager.getRemoteServiceAdmin(AbstractTopologyManager.java:155)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.AbstractTopologyManager.handleServiceModifying(AbstractTopologyManager.java:441)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.AbstractTopologyManager.handleEvent(AbstractTopologyManager.java:397)
    at org.eclipse.ecf.internal.osgi.services.distribution.BasicTopologyManagerImpl.event(BasicTopologyManagerImpl.java:119)
    at org.eclipse.ecf.internal.osgi.services.distribution.BasicTopologyManagerComponent.event(BasicTopologyManagerComponent.java:57)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry$6.call(ServiceRegistry.java:1192)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHookPrivileged(ServiceRegistry.java:1239)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHooksPrivileged(ServiceRegistry.java:1222)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyEventListenerHooksPrivileged(ServiceRegistry.java:1189)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:806)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:771)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.setProperties(ServiceRegistrationImpl.java:171)
    at org.eclipse.equinox.internal.app.EclipseAppDescriptor.refreshProperties(EclipseAppDescriptor.java:124)
    at org.eclipse.equinox.internal.app.EclipseAppContainer.refreshAppDescriptors(EclipseAppContainer.java:470)
    at org.eclipse.equinox.internal.app.EclipseAppContainer.lock(EclipseAppContainer.java:520)
    at org.eclipse.equinox.internal.app.EclipseAppDescriptor.createAppHandle(EclipseAppDescriptor.java:190)
    at org.eclipse.equinox.internal.app.EclipseAppDescriptor.launchSpecific(EclipseAppDescriptor.java:90)
    at org.osgi.service.application.ApplicationDescriptor.launch(ApplicationDescriptor.java:311)
    at org.eclipse.equinox.internal.app.EclipseAppContainer.startDefaultApp(EclipseAppContainer.java:260)
    at org.eclipse.equinox.internal.app.EclipseAppContainer.start(EclipseAppContainer.java:104)
    at org.eclipse.equinox.internal.app.Activator.addingService(Activator.java:134)
    at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:932)
    at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:1)
    at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
    at org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:183)
    at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:317)
    at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:261)
    at org.eclipse.equinox.internal.app.Activator.start(Activator.java:56)
    at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
    at java.security.AccessController.doPrivileged(Native Method)
    at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
    at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683)
    at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
    at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:300)
    at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:440)
    at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:263)
    at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:107)
    at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:469)
    at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
    at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:395)
    at org.eclipse.osgi.internal.loader.SingleSourcePackage.loadClass(SingleSourcePackage.java:35)
    at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:461)
    at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
    at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
    at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
    at org.eclipse.core.internal.runtime.PlatformActivator.startAppContainer(PlatformActivator.java:44)
    at org.eclipse.core.internal.runtime.PlatformActivator.start(PlatformActivator.java:31)
    at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
    at java.security.AccessController.doPrivileged(Native Method)
    at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
    at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683)
    at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
    at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:300)
    at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:440)
    at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:263)
    at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:107)
    at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:469)
    at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
    at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:395)
    at org.eclipse.osgi.internal.loader.SingleSourcePackage.loadClass(SingleSourcePackage.java:35)
    at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:461)
    at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
    at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
    at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
    at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:188)
    at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClassHoldingLock(ClasspathManager.java:632)
    at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:607)
    at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:568)
    at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:492)
    at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:465)
    at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
    at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:395)
    at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:464)
    at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
    at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
    at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
    at org.eclipse.osgi.internal.loader.BundleLoader.loadClass(BundleLoader.java:340)
    at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:229)
    at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(AbstractBundle.java:165)
    at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:679)
    at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
    at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:300)
    at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:440)
    at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:263)
    at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:107)
    at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:469)
    at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
    at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:395)
    at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:464)
    at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
    at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
    at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
    at org.eclipse.osgi.internal.loader.BundleLoader.loadClass(BundleLoader.java:340)
    at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:229)
    at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1212)
    at org.eclipse.equinox.internal.ds.model.ServiceComponent.createInstance(ServiceComponent.java:493)
    at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.createInstance(ServiceComponentProp.java:270)
    at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.build(ServiceComponentProp.java:331)
    at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponent(InstanceProcess.java:620)
    at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponents(InstanceProcess.java:197)
    at org.eclipse.equinox.internal.ds.Resolver.buildNewlySatisfied(Resolver.java:473)
    at org.eclipse.equinox.internal.ds.Resolver.enableComponents(Resolver.java:217)
    at org.eclipse.equinox.internal.ds.SCRManager.performWork(SCRManager.java:816)
    at org.eclipse.equinox.internal.ds.SCRManager$QueuedJob.dispatch(SCRManager.java:783)
    at org.eclipse.equinox.internal.ds.WorkThread.run(WorkThread.java:89)
    at java.lang.Thread.run(Thread.java:744)

Am 13.03.2015 um 09:25 schrieb Wim Jongman:

Unfortunately, this is not a correct assumption. You have to check the run configuration and see the start order of the equinox.ds bundle. If this bundle starts at 2, it will cause your component bundles to also start early. No matter what the sequence number is in ss.

You could try the following: Set the start order of equinox.ds to 4 and the start order of ecf distribution to 3. This is done in the run configuration for development time and in the product file configuration when you build it.

Cheers,

Wim
On Fri, Mar 13, 2015 at 8:42 AM, Peter Hermsdorf <peter.hermsdorf@xxxxxxxxx> wrote:
Thanks for that hint Wim, that solved the ugly Exceptions on server startup.
I checked all client and server bundles to have Lazy Activation and unchecked "activate immediately" in the service descriptors.

regarding the bundle start order i see the following

91    ACTIVE      org.eclipse.ecf.osgi.services.distribution_2.1.0.v20150306-2024
osgi>
osgi> ss edef
"Framework is launched."

id    State       Bundle
194    ACTIVE      com.godyo.service1.api.IService1.edef_1.0.0
195    ACTIVE      com.godyo.service2.api.IService2.edef_1.0.0

so i guess the edef bundles are started far after the distribution bundle....

bye, peter

Am 12.03.2015 um 17:26 schrieb Wim Jongman:
Could there be some mismatch between starting your services and the ECF distribution bundle, e.g. the ECF bundles are started after your bundles? It should not really matter because also the services should be discovered even if ECF distribution is started after your registrations. But this is where I should go an fiddle.

Also uncheck this flag. I don't know the exact details any more but this flag in combination with the "Bundle-ActivationPolicy: lazy" enables you to register the service without starting your bundle. Starting the bundle is in general not the problem but running the activator is.

Cheers,

Wim
On Thu, Mar 12, 2015 at 4:41 PM, Peter Hermsdorf <peter.hermsdorf@xxxxxxxxx> wrote:
Hi Wim,

I'll take a closer look at that - maybe I can somehow relax the service dependencies on startup

I now (again) have the problem that my edef registration/description bundles are not honoured. This time in the integration Testsuite.
When running the testsuite with -console -noExit i see:
> ss edef
194 ACTIVE com.godyo.IService1.edef_1.0.0
195 ACTIVE com.godyo.IService2.edef_1.0.0

but the services do not get bound. When refreshing the bundles the binding is triggered immediately.

Any ideas how to fix that?

What would be another "easy" approach to trigger the import? Is there some code that i can use to configure the EndpointDescriptions programmatically?

Other ideas?

Thanks for all hints!

bye, Peter

Am 12.03.2015 um 15:46 schrieb Wim Jongman:
Hi Peter,

When components are immediately activated AND they have a dependency on another component then this can happen.

Cheers,

Wim
On Thu, Mar 12, 2015 at 12:57 PM, Peter Hermsdorf <peter.hermsdorf@xxxxxxxxx> wrote:
Hi,

my switch to Eclipse 3.8 (Juno) and with that to ECF 3.9.3 was so far successful. That means after fiddling around with dependencies, launch configs and feature configuration i have a running server and a running RCP app with working _multiple_ service discovery - as expected! great!

:) so far so good. I still need to fix the build and test suites but that seems possible till now.

current open points:
1) on client side i still see the following error for every service imported:

!ENTRY org.eclipse.ecf.osgi.services.remoteserviceadmin 4 0 2015-03-12 10:58:40.889
!MESSAGE org.eclipse.core.runtime.Status[plugin=org.eclipse.ecf.osgi.services.remoteserviceadmin;code=4;message=org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin:postEvent:No EventAdmin service available to send eventTopic=org/osgi/service/remoteserviceadmin/IMPORT_REGISTRATION eventProperties={event=RemoteServiceAdminEvent[containerID=StringID[ecftcp://peter-desktop:8889/server], getType()=1, getSource()=org.eclipse.ecf.osgi.services.remoteserviceadmin_4.2.0.v20150306-2024 [91], getException()=null, getImportReference()=org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$ImportReference@1276b35, getExportReference()=null], bundle.id=91, objectClass=[Ljava.lang.String;@ef769a, timestamp=1426154320883, endpoint.id=ecftcp://peter-desktop:8889/server, service.imported.configs=[Ljava.lang.String;@153b262, bundle.symbolicname=org.eclipse.ecf.osgi.services.remoteserviceadmin, import.registration=ECFEndpointDescription[{component.id=3, component.name=com.godyo.service, ecf.endpoint.id.ns=org.eclipse.ecf.core.identity.StringID, ecf.generic.server.port=8889, endpoint.id=ecftcp://peter-desktop:8889/server, endpoint.package.version.com.godyo.service.api=1.0.0, objectClass=[Ljava.lang.String;@137cdb0, remote.configs.supported=[Ljava.lang.String;@a111ba, remote.intents.supported=[Ljava.lang.String;@92e44d, service.imported=org.eclipse.ecf.provider.remoteservice.generic.RemoteServiceImpl@1e47e28, service.imported.configs=[Ljava.lang.String;@16a85a}], bundle=org.eclipse.ecf.osgi.services.remoteserviceadmin_4.2.0.v20150306-2024 [91], bundle.version=4.2.0.v20150306-2024, bundle.signer=[Ljava.lang.String;@186ec5b};severity4;exception=null;children=[]]

but nevertheless the services are discovered and working

2) on server startup i see multiple of these

WARNING 75 Getting a lock required more than 10000 ms. There might be a synchronization problem in this callstack or just the build/dispose process of some components took too long!
java.lang.Exception: Debug stacktrace
    at org.eclipse.equinox.internal.ds.InstanceProcess.getLock(InstanceProcess.java:120)
    at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponent(InstanceProcess.java:560)
    at org.eclipse.equinox.internal.ds.ServiceReg.getService(ServiceReg.java:53)
    at org.eclipse.osgi.internal.serviceregistry.ServiceUse$1.run(ServiceUse.java:141)
    at java.security.AccessController.doPrivileged(Native Method)
    at org.eclipse.osgi.internal.serviceregistry.ServiceUse.getService(ServiceUse.java:139)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:468)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getService(ServiceRegistry.java:467)
    at org.eclipse.osgi.framework.internal.core.BundleContextImpl.getService(BundleContextImpl.java:594)
    at org.osgi.util.tracker.ServiceTracker.addingService(ServiceTracker.java:411)
    at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:932)
    at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:1)
    at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
    at org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:183)
    at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:317)
    at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:261)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$3.run(RemoteServiceAdmin.java:1307)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$3.run(RemoteServiceAdmin.java:1)
    at java.security.AccessController.doPrivileged(Native Method)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.postEvent(RemoteServiceAdmin.java:1301)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.publishEvent(RemoteServiceAdmin.java:1182)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.publishExportEvent(RemoteServiceAdmin.java:1338)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.exportService(RemoteServiceAdmin.java:371)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.AbstractTopologyManager.handleServiceRegistering(AbstractTopologyManager.java:436)
    at org.eclipse.ecf.internal.osgi.services.distribution.BasicTopologyManagerImpl.access$0(BasicTopologyManagerImpl.java:1)
    at org.eclipse.ecf.internal.osgi.services.distribution.BasicTopologyManagerImpl$1.run(BasicTopologyManagerImpl.java:84)
    at java.lang.Thread.run(Thread.java:744)

this needs to be investigated, nevertheless the services are obviously exported without any further notification. they are listed as services on the osgi console and are available on the client.

So it seems like my main problem is fixed and i can stay with this setup. Thanks again Scott!
Any further hints on the error messages are still welcome.

thx, bxe, peter

Am 11.03.2015 um 17:38 schrieb Scott Lewis:
Hi Peter,

After thinking about this a little bit, I believe I have more of an explanation for what's going on with you/your use case. In short, I think it comes down to this:

On 3/11/2015 3:10 AM, Peter Hermsdorf wrote:

<stuff deleted>
Realistically, it might become difficult/impossible to support ECF 3.7 on Indigo for much longer...and I *believe* that ECF 3.9.3 will run on everything back to Kepler (although I admit I haven't tested on Kepler yet...I will do so/help do so, however, if that is necessary. Please let me know). The dependency here is on the use of the OSGI Wiring API (required for compliance with modern versions of OSGi RSA spec), which I *think* only appeared in Kepler version of Equinox (can't remember what number version of Equinox that was right now).

Of course thats a problem. I tried upgrading to the latest version, but as you already statet, there is a dependency to a core equinox.osgi package version 1.7 whereas eclipse indigo only has version 1.6 available.

An upgrade of our RCP app to Eclipse 4 is planned, but currently not in work. I case we would need a fix in ECF 3.7 I would consider patching/building it myself ....

i.e. the version of ECF RSA that you are using (ECF 3.7/Indigo) was done prior to two changes that are affecting you:

1) It was prior to the OSGi RSA 1.1 specification, which required reworking the use of the edef-given properties...for both discovery and distribution/lookup/import on the consumer.   The reason this was necessary was that RSA 1.1 added the notion of a remote service 'update' (i.e. updating the remote service's properties), and so to do this with EDEF meant adding additional properties, and more importantly, changing the semantics/handling of endpointdescription equality. I now believe this is why my initial response of making the endpoint.service.id unique in your generated edef didn't for you, because you are using a version prior to when this property (only) was used to determine ed uniqueness.

2) Some changing (simplification, really) of use of ECF-specific remote service properties. I can't immediately go into technical detail here, as I have to remind myself about the specifics (I've forgotten), but I'm pretty sure that that's this could be affecting you/your use case as well.

IMHO there are two ways to deal with this:

1) Help you transition to ECF 3.9.3 (or something more recent from ECF).   One thing to consider:   I'm pretty sure that ECF 3.9.3 will run properly on Equinox Kepler or later, and I believe that Kepler had/has support for RCP 3.8 (as opposed to requiring that you move to Eclipse 4.x immediately).

2) As you say above, we could look to apply a 'fix' to ECF 3.7 (what you are experiencing may not actually be a bug in 3.7, but rather simply not yet applying the right set of remote service property values...I'm not sure at this point). I will help with this if you so desire, but as you might expect I'm not anxious to do this...i.e. I would prefer 1.   Why? Two reasons: a) Moving forward it's simpler for ECF; b) When you move to something more recent in terms of ECF versions it would be better if you didn't have to rework your edef in addition to adjusting to the UI and other changes.

I'm willing to help with either 1 or 2 based upon what you decide, but I'm limited by resources (my time).

To help me figure out what would be involved with 2, would you let me know what the exact version of ECF you are using is? (i.e. with qualifier)

Thanks,

Scott

_______________________________________________ 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
_______________________________________________
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

Follow-Ups:
- Re: [ecf-dev] Problem using multiple services from single server
  - From: Peter Hermsdorf

References:
- [ecf-dev] Problem using multiple services from single server
  - From: Peter Hermsdorf
- Re: [ecf-dev] Problem using multiple services from single server
  - From: Scott Lewis
- Re: [ecf-dev] Problem using multiple services from single server
  - From: Peter Hermsdorf
- Re: [ecf-dev] Problem using multiple services from single server
  - From: Scott Lewis
- Re: [ecf-dev] Problem using multiple services from single server
  - From: Peter Hermsdorf
- Re: [ecf-dev] Problem using multiple services from single server
  - From: Wim Jongman
- Re: [ecf-dev] Problem using multiple services from single server
  - From: Peter Hermsdorf
- Re: [ecf-dev] Problem using multiple services from single server
  - From: Wim Jongman
- Re: [ecf-dev] Problem using multiple services from single server
  - From: Peter Hermsdorf
- Re: [ecf-dev] Problem using multiple services from single server
  - From: Wim Jongman
- Re: [ecf-dev] Problem using multiple services from single server
  - From: Peter Hermsdorf

Prev by Date: Re: [ecf-dev] Problem using multiple services from single server
Next by Date: Re: [ecf-dev] Problem using multiple services from single server
Previous by thread: Re: [ecf-dev] Problem using multiple services from single server
Next by thread: Re: [ecf-dev] Problem using multiple services from single server
Index(es):
- Date
- Thread

Breadcrumbs