Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Eclipse Communications Framework (ECF) » ECF r-osgi : NPEs in proxies during startup
ECF r-osgi : NPEs in proxies during startup [message #1732833] Fri, 20 May 2016 14:54 Go to next message
Erwin De Ley is currently offline Erwin De LeyFriend
Messages: 52
Registered: August 2013
Member
When using the r_osgi provider (3.5.300.v20160405-1820), we always get NPEs from inside the generated proxies when starting the consumer application.

And then some time later the proxy gets in order.

Does this ring a bell for someone?

thanks!
erwin & yannick

Some detailed info :

We have a service that implements 2 interfaces : an IRestService and an IDataSourceService. In the DS config we try to only export the IDataSourceService interface :

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" immediate="true" name="DataSourceService">
   <implementation class="com.isencia.passerelle.edm.datasource.service.impl.DataSourceService"/>
   <service>
      <provide interface="com.isencia.sherpa.rs.IRestService"/>
      <provide interface="com.isencia.passerelle.edm.datasource.service.IDataSourceService"/>
   </service>
   <property name="service.exported.interfaces" type="String" value="com.isencia.passerelle.edm.datasource.service.IDataSourceService"/>
   <property name="service.exported.configs" type="String" value="ecf.r_osgi.peer"/>
</scr:component>


This seems to be picked up correctly for the r_osgi bundle :

osgi>services (objectClass="com.isencia.passerelle.edm.datasource.service.IDataSourceService")
{com.isencia.sherpa.rs.IRestService, com.isencia.passerelle.edm.datasource.service.IDataSourceService}={component.name=DataSourceService, component.id=58, service.exported.configs=ecf.r_osgi.peer, service.exported.interfaces=com.isencia.passerelle.edm.datasource.service.IDataSourceService, service.id=126}
  "Registered by bundle:" com.isencia.passerelle.edm.datasource.service.impl_3.0.5.qualifier [189]
  "Bundles using service"
    com.isencia.sherpa.rs_6.12.4.qualifier [71]
    org.eclipse.ecf.osgi.services.remoteserviceadmin_4.4.0.v20160405-1820 [123]
    org.eclipse.ecf.provider.r_osgi_3.5.300.v20160405-1820 [74]
{com.isencia.passerelle.edm.datasource.service.IDataSourceService}={component.name=DataSourceService, ecf.rsvc.id=155, ecf.rsvc.ranking=0, service.remote.registration=true, ecf.rsvc.cid=r-osgi://Yannick-PC:9278, ecf.robjectClass=[com.isencia.passerelle.edm.datasource.service.IDataSourceService], component.id=58, service.id=155}
  "Registered by bundle:" com.isencia.passerelle.edm.datasource.service.impl_3.0.5.qualifier [189]
  "Bundles using service"
    ch.ethz.iks.r_osgi.remote_1.0.5.RC1_v20160405-1820 [182]


But during the startup we get NPEs in generated proxies for both interfaces :

!SESSION 2016-05-12 10:24:53.779 -----------------------------------------------
eclipse.buildId=unknown
java.version=1.7.0_79
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_GB
Framework arguments: -product com.isencia.passerelle.edm.datasource.consumer.product
Command-line arguments: -product com.isencia.passerelle.edm.datasource.consumer.product -data C:\Users\visyan\workspace-passerelle-edm/../runtime-datasourceservice.consumer.ecf.local.product -dev file:C:/Users/visyan/workspace-passerelle-edm/.metadata/.plugins/org.eclipse.pde.core/datasourceservice.consumer.ecf.local.product/dev.properties -os win32 -ws win32 -arch x86_64 -consoleLog -console

!ENTRY R-OSGi Proxy Bundle generated for Endpoint r-osgi://169.254.254.194:9278#218 4 0 2016-05-12 10:24:54.437
!MESSAGE FrameworkEvent ERROR
!STACK 0
org.osgi.framework.BundleException: Exception in proxy.bgjocfeocfeobje_jchicbi.com.isencia.sherpa.rs.IRestServiceImpl.start() of bundle R-OSGi Proxy Bundle generated for Endpoint r-osgi://169.254.254.194:9278#218.
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:734)
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.resume(AbstractBundle.java:390)
at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1176)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:559)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:544)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:457)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:438)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:1)
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.NullPointerException: A null service reference is not allowed.
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.getService(BundleContextImpl.java:586)
at proxy.bgjocfeocfeobje_jchicbi.com.isencia.sherpa.rs.IRestServiceImpl.start(Unknown Source)
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)
... 12 more
Root exception:
java.lang.NullPointerException: A null service reference is not allowed.
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.getService(BundleContextImpl.java:586)
at proxy.bgjocfeocfeobje_jchicbi.com.isencia.sherpa.rs.IRestServiceImpl.start(Unknown Source)
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.resume(AbstractBundle.java:390)
at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1176)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:559)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:544)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:457)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:438)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:1)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)

!ENTRY R-OSGi Proxy Bundle generated for Endpoint r-osgi://YANNICK-PC:9278#218 4 0 2016-05-12 10:24:54.440
!MESSAGE FrameworkEvent ERROR
!STACK 0
org.osgi.framework.BundleException: Exception in proxy.YANNICK_PC_jchicbi.com.isencia.passerelle.edm.datasource.service.IDataSourceServiceImpl.start() of bundle R-OSGi Proxy Bundle generated for Endpoint r-osgi://YANNICK-PC:9278#218.
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:734)
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.resume(AbstractBundle.java:390)
at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1176)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:559)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:544)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:457)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:438)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:1)
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.NullPointerException: A null service reference is not allowed.
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.getService(BundleContextImpl.java:586)
at proxy.YANNICK_PC_jchicbi.com.isencia.passerelle.edm.datasource.service.IDataSourceServiceImpl.start(Unknown Source)
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)
... 12 more
Root exception:
java.lang.NullPointerException: A null service reference is not allowed.
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.getService(BundleContextImpl.java:586)
at proxy.YANNICK_PC_jchicbi.com.isencia.passerelle.edm.datasource.service.IDataSourceServiceImpl.start(Unknown Source)
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.resume(AbstractBundle.java:390)
at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1176)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:559)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:544)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:457)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:438)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:1)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
WARNING: Port 9278 already in use. This instance of R-OSGi is running on port 9279

!ENTRY org.eclipse.equinox.ds 4 0 2016-05-12 10:24:55.186
!MESSAGE Could not bind a reference of component com.isencia.passerelle.edm.datasource.consumer. The reference is: Reference[name = IDataSourceService, interface = com.isencia.passerelle.edm.datasource.service.IDataSourceService, policy = dynamic, cardinality = 0..n, target = null, bind = bindDataSourceService, unbind = null]

!ENTRY org.eclipse.equinox.ds 4 0 2016-05-12 10:24:55.188
!MESSAGE Could not bind a reference of component com.isencia.passerelle.edm.datasource.consumer. The reference is: Reference[name = IDataSourceService, interface = com.isencia.passerelle.edm.datasource.service.IDataSourceService, policy = dynamic, cardinality = 0..n, target = null, bind = bindDataSourceService, unbind = null]

And then, after a minute or two, our consumer can start using the proxy after all to start pushing data (which is the thing our service allows) :
osgi> 2016-05-12 10:26:41 INFO  DataSourceServiceComponent:27 - Got proxy IDataSourceService=proxy.Yannick_PC_jchibff.com.isencia.passerelle.edm.datasource.service.IDataSourceServiceImpl@5abcfadd
2016-05-12 10:26:41 INFO  DataSourceServiceComponent:29 - Starting remote call via proxy...
2016-05-12 10:26:41 INFO  DataSourceServiceComponent:44 - Published value1: 72

Re: ECF r-osgi : NPEs in proxies during startup [message #1732840 is a reply to message #1732833] Fri, 20 May 2016 15:57 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1038
Registered: July 2009
Senior Member
Hi Erwin and Yannick,

erwin de ley wrote on Fri, 20 May 2016 10:54
When using the r_osgi provider (3.5.300.v20160405-1820), we always get NPEs from inside the generated proxies when starting the consumer application.

And then some time later the proxy gets in order.

Does this ring a bell for someone?



It might. The r-OSGi provider needs to clean up (remove) the bundles that it creates to hold the proxy impl, and it only gets to do that if the client is shutdown normally (i.e. doesn't crash and doesn't get terminated via Eclipse debugger). I/we have seen cases like this when the previous client session is terminated abnormally, meaning that the previous rosgi proxy bundles are still present, but are irrelevant and nonstartable (NPE on next launch). This doesn't generally prevent the discovery and use of the new proxy (which I think is happening for you after a while).

If you shutdown the consumer normally (i.e. 'shutdown' at osgi console) then these NPEs shouldn't occur. And it has been harmless (except for the ominous log entries) in other cases.

If a normal shutdown does *not* fix this issue, please open a bug and I'll look into it immediately.

If discovery is taking minutes...what discovery provider are you using? If desired, chances are this time delay could be reduced.

Thanks. Scott

[Updated on: Fri, 20 May 2016 09:23]

Report message to a moderator

Re: ECF r-osgi : NPEs in proxies during startup [message #1733303 is a reply to message #1732840] Thu, 26 May 2016 03:02 Go to previous messageGo to next message
Yannick De Visscher is currently offline Yannick De VisscherFriend
Messages: 2
Registered: May 2016
Junior Member
Hi Scott,

Even on the first startup and also after a clean osgi exit, the NPEs are thrown.
We are using org.eclipse.ecf.provider.r_osgi (3.5.300.v20160405-1820).

This is my launcher config

<?xml version="1.0" encoding="UTF-8"?>
<?pde version="3.5"?>

<product name="DataSourceService Consumer" uid="com.isencia.passerelle.edm.datasource.consumer.local" id="com.isencia.passerelle.edm.datasource.consumer.product" application="com.isencia.passerelle.edm.datasource.consumer.app" version="3.0.3.qualifier" useFeatures="false" includeLaunchers="false">

   <configIni use="default">
   </configIni>

   <launcherArgs>
      <programArgs>-console -consoleLog
      </programArgs>
      <vmArgs>-Declipse.ignoreApp=true 
-Dosgi.noShutdown=true 
-DverboseRemoteServiceAdmin=true
-Dservice.exported.configs=ecf.r_osgi.peer
-Dch.ethz.iks.r_osgi.topic.filter=*
      </vmArgs>
   </launcherArgs>

   <launcher>
      <solaris/>
      <win useIco="false">
         <bmp/>
      </win>
   </launcher>

   <vm>
   </vm>

   <plugins>
      <plugin id="ch.ethz.iks.r_osgi.remote"/>
      <plugin id="com.isencia.passerelle.edm.datasource.consumer"/>
      <plugin id="com.isencia.passerelle.edm.datasource.service"/>
      <plugin id="javax.servlet"/>
      <plugin id="javax.xml"/>
      <plugin id="org.apache.felix.gogo.command"/>
      <plugin id="org.apache.felix.gogo.runtime"/>
      <plugin id="org.apache.felix.gogo.shell"/>
      <plugin id="org.apache.log4j"/>
      <plugin id="org.eclipse.core.contenttype"/>
      <plugin id="org.eclipse.core.jobs"/>
      <plugin id="org.eclipse.core.runtime"/>
      <plugin id="org.eclipse.ecf"/>
      <plugin id="org.eclipse.ecf.discovery"/>
      <plugin id="org.eclipse.ecf.identity"/>
      <plugin id="org.eclipse.ecf.osgi.services.distribution"/>
      <plugin id="org.eclipse.ecf.osgi.services.remoteserviceadmin"/>
      <plugin id="org.eclipse.ecf.osgi.services.remoteserviceadmin.proxy"/>
      <plugin id="org.eclipse.ecf.provider"/>
      <plugin id="org.eclipse.ecf.provider.jmdns"/>
      <plugin id="org.eclipse.ecf.provider.r_osgi"/>
      <plugin id="org.eclipse.ecf.remoteservice"/>
      <plugin id="org.eclipse.ecf.remoteservice.asyncproxy"/>
      <plugin id="org.eclipse.ecf.sharedobject"/>
      <plugin id="org.eclipse.equinox.app"/>
      <plugin id="org.eclipse.equinox.common"/>
      <plugin id="org.eclipse.equinox.concurrent"/>
      <plugin id="org.eclipse.equinox.console"/>
      <plugin id="org.eclipse.equinox.ds"/>
      <plugin id="org.eclipse.equinox.event"/>
      <plugin id="org.eclipse.equinox.preferences"/>
      <plugin id="org.eclipse.equinox.registry"/>
      <plugin id="org.eclipse.equinox.util"/>
      <plugin id="org.eclipse.osgi"/>
      <plugin id="org.eclipse.osgi.services"/>
      <plugin id="org.eclipse.osgi.services.remoteserviceadmin"/>
      <plugin id="org.objectweb.asm"/>
      <plugin id="slf4j.api"/>
      <plugin id="slf4j.log4j12" fragment="true"/>
   </plugins>

   <configurations>
      <plugin id="ch.ethz.iks.r_osgi.remote" autoStart="true" startLevel="0" />
      <plugin id="com.isencia.passerelle.edm.datasource.consumer" autoStart="true" startLevel="0" />
      <plugin id="javax.xml" autoStart="true" startLevel="0" />
      <plugin id="org.apache.felix.gogo.command" autoStart="true" startLevel="0" />
      <plugin id="org.apache.felix.gogo.runtime" autoStart="true" startLevel="0" />
      <plugin id="org.apache.felix.gogo.shell" autoStart="true" startLevel="0" />
      <plugin id="org.eclipse.core.contenttype" autoStart="true" startLevel="0" />
      <plugin id="org.eclipse.core.jobs" autoStart="true" startLevel="0" />
      <plugin id="org.eclipse.ecf" autoStart="true" startLevel="0" />
      <plugin id="org.eclipse.ecf.console" autoStart="true" startLevel="0" />
      <plugin id="org.eclipse.ecf.discovery" autoStart="true" startLevel="0" />
      <plugin id="org.eclipse.ecf.identity" autoStart="true" startLevel="0" />
      <plugin id="org.eclipse.ecf.osgi.services.distribution" autoStart="true" startLevel="0" />
      <plugin id="org.eclipse.ecf.osgi.services.remoteserviceadmin" autoStart="true" startLevel="0" />
      <plugin id="org.eclipse.ecf.osgi.services.remoteserviceadmin.proxy" autoStart="true" startLevel="0" />
      <plugin id="org.eclipse.ecf.provider" autoStart="true" startLevel="0" />
      <plugin id="org.eclipse.ecf.provider.jmdns" autoStart="true" startLevel="0" />
      <plugin id="org.eclipse.ecf.provider.r_osgi" autoStart="true" startLevel="0" />
      <plugin id="org.eclipse.ecf.remoteservice" autoStart="true" startLevel="0" />
      <plugin id="org.eclipse.ecf.remoteservice.asyncproxy" autoStart="true" startLevel="0" />
      <plugin id="org.eclipse.ecf.sharedobject" autoStart="true" startLevel="0" />
      <plugin id="org.eclipse.equinox.common" autoStart="true" startLevel="0" />
      <plugin id="org.eclipse.equinox.concurrent" autoStart="true" startLevel="0" />
      <plugin id="org.eclipse.equinox.console" autoStart="true" startLevel="0" />
      <plugin id="org.eclipse.equinox.ds" autoStart="true" startLevel="0" />
      <plugin id="org.eclipse.equinox.event" autoStart="true" startLevel="0" />
      <plugin id="org.eclipse.equinox.preferences" autoStart="true" startLevel="0" />
      <plugin id="org.eclipse.equinox.registry" autoStart="true" startLevel="0" />
      <plugin id="org.eclipse.equinox.util" autoStart="true" startLevel="0" />
      <plugin id="org.eclipse.osgi" autoStart="true" startLevel="0" />
      <plugin id="org.eclipse.osgi.services" autoStart="true" startLevel="0" />
      <plugin id="org.eclipse.osgi.services.remoteserviceadmin" autoStart="true" startLevel="0" />
      <plugin id="org.objectweb.asm" autoStart="true" startLevel="0" />
   </configurations>

</product>


Where can I open a bug?

Kind regards,

Yannick
Re: ECF r-osgi : NPEs in proxies during startup [message #1733461 is a reply to message #1733303] Fri, 27 May 2016 17:08 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1038
Registered: July 2009
Senior Member
Yannick De Visscher wrote on Wed, 25 May 2016 23:02
Hi Scott,

Even on the first startup and also after a clean osgi exit, the NPEs are thrown.
We are using org.eclipse.ecf.provider.r_osgi (3.5.300.v20160405-1820).

This is my launcher config

<code deleted>

Where can I open a bug?



Hi Yannick. Best to open a bug here: https://bugs.eclipse.org/bugs/enter_bug.cgi?product=ECF

Probably best to select ecf.providers as the component, and put '[r-OSGi] <subject>' in the subject line...for example: [r-OSGi] non-fatal NPE in proxy creation

Just so I'm clear on what's happening: The desired proxy is eventually created, injected, and used successfully, right? It just takes longer than you would expect, and is preceeded by the NPEs in log?

If you don't mind it would be diagnostic if you could try to reproduce under two other conditions:

1) Export via another provider...e.g. ecf.generic.server and see if a similar things happens. I'm expecting not, but it would be helpful to eliminate this possibility
2) Try exporting with only one interface (the one you consume)

If you like I can help with this if you are willing to give me temporary access to your code. My direct email is slewis at composent.com

Thanks,

Scott

Re: ECF r-osgi : NPEs in proxies during startup [message #1734228 is a reply to message #1733461] Mon, 06 June 2016 12:39 Go to previous messageGo to next message
Yannick De Visscher is currently offline Yannick De VisscherFriend
Messages: 2
Registered: May 2016
Junior Member
Hi Scott,

Sorry for the delay.

Bug posted at: https://bugs.eclipse.org/bugs/show_bug.cgi?id=495535

The desired proxy is indeed created, injected and used. It takes about 20 seconds before the proxy is available, that's not such a big deal for us.
We were already exporting only one interface (IDataSourceService), the other one isn't even in the classpath of the consumer application.

I've tried using the generic server, but I can't seem to get it to work with this one...

Access to the code won't be possible because it's part of quite a big project.
If I have the time I might try to reproduce this issue with some ecf example classes.

Kind regards,

Yannick

Re: ECF r-osgi : NPEs in proxies during startup [message #1734402 is a reply to message #1734228] Wed, 08 June 2016 02:26 Go to previous message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1038
Registered: July 2009
Senior Member
Yannick De Visscher wrote on Mon, 06 June 2016 08:39
Hi Scott,

Sorry for the delay.

Bug posted at: https://bugs.eclipse.org/bugs/show_bug.cgi?id=495535

The desired proxy is indeed created, injected and used. It takes about 20 seconds before the proxy is available, that's not such a big deal for us.
We were already exporting only one interface (IDataSourceService), the other one isn't even in the classpath of the consumer application.


This is indeed very strange.

Quote:


I've tried using the generic server, but I can't seem to get it to work with this one...



It should be a matter of changing the service.exported.configs service property to

service.exported.configs="ecf.generic.server"

If there is something else going on please do let me know as I've not seen these problems before.

Quote:


Access to the code won't be possible because it's part of quite a big project.
If I have the time I might try to reproduce this issue with some ecf example classes.



Ok...that would be great, as I currently cannot reproduce, and it's going to be next to impossible to fix without being able to first reproduce.

What might work is if you can reproduce with using two interface classes (e.g. IRestService IDataSourceService) with some similar-but-not-same method signatures...with only trivial implementations.

One other thing to check that I just thought of. What are you doing WRT discovery? (e.g. a discovery protocol like jmsdns/zeroconf, jslp, one of the other discovery providers, or edef-etc. Sorry if I already asked this...you should probably answer on the bug you created (thanks for doing that by the way)
Previous Topic:I lose osgi remote service
Next Topic:Register MessageBodyWriter Provider for use with jersey jax-rs
Goto Forum:
  


Current Time: Fri Mar 29 07:13:05 GMT 2024

Powered by FUDForum. Page generated in 0.04388 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top