Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] NullpointerException in RemoteServiceAdmin

Hi Scott,

thanks (again) for fixing the issue with the serialization. I finally could upgrade to ECF 3.14.1 with the additional bundles from the snapshot build with the 3 bug fixes. I haven't observed any additional issues - nor the test suite.

Just one more thing: when building the product i stumbled across the following error: 2.5.0.v20180409-2248 depends on: org.eclipse.ecf.remoteservice.asyncproxy [2.1.0.v20180409-2248]

Maybe it would be possible to define that dependency as optional as addition to bug .

Otherwise i have to fiddle around with producing my own features which does not include that bundle (because of non resolveable package org.osgi.util.promise)


Bye Peter

BTW: I'm now on vacation for 1 week - so more on that later ;)

Am 27.09.2018 um 13:39 schrieb Peter Hermsdorf:

Hi Scott,

thanks for the fix! That resolved the issue.

We now face a deserialization issue which probably comes from new code in the 3.14 ECF release.

See for more information.

Bye Peter

Am 26.09.2018 um 17:59 schrieb Scott Lewis:
IOn 9/26/2018 3:54 AM, Peter Hermsdorf wrote:

Hi Scott,

the bug is

Please note that we can not just use the version 2 bundle of org.eclipse.ecf.remoteservice.asyncproxy, because that introduces a dependency to the package org.osgi.util.promise which requires eclipse oxygen as stated here:

updating is currently no option for us.

Ok.   I've fixed/resolved bug 539469.   I think we can wait until next simultaneous release (June 2019) for deprecating this bundle...but it may be difficult not to after that.   It depends mostly upon what happens with framework and rsa standardization.


Thanks, bye Peter

PS: the links to the messages are bringing up a 404 error:

i filed a bug here and added you as CC


Am 25.09.2018 um 16:46 schrieb Scott Lewis:
Hi Peter,

Please go ahead and file a bug.   However, I'm thinking of deprecating the 1.1.0 version of o.e.e.remoteservice.asyncproxy completely (and requiring 2.x), since it's only for support of java 1.7 and below.


On 9/25/2018 1:09 AM, Peter Hermsdorf wrote:


while trying to integrate the fix for the bug below i stumbled upon a new issue:

Caused by: java.lang.NoSuchMethodError: org.eclipse.ecf.remoteservice.AbstractRemoteService.isReturnAsync(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;)Z
    at org.eclipse.ecf.remoteservice.AbstractRemoteService.invoke(
    ... 5 common frames omitted

I updated the ECF implementation to the latest stable version 3.14.1. The above problem happens in bundle org.eclipse.ecf.remoteservice. The class AbstractRemoteService extends AbstractAsyncProxyRemoteService which is imported via package import :


I decided to use the bundle org.eclipse.ecf.remoteservice.asyncproxy version 1.1.0.v20180311-0310 (and not version 2.1. 0 because of other dependencies) which perfectly fits into that version range.

The problem is that in that bundle the class AbstractAsyncProxyRemoteService does not have a method isReturnAsync which leads to the above error.

Should i file a bug or is that a known problem?

Thanks, bye Peter

Am 19.09.2018 um 10:28 schrieb Peter Hermsdorf:


Thanks for looking at the issue!

Bye Peter

Am 18.09.2018 um 19:19 schrieb Scott Lewis:
Hi Peter,

I believe this is due to the (incorrect) line in ImportRegistration.close():

        public void close() {
            boolean publish = false;
            ID containerID = null;
            Throwable exception = null;
            EndpointDescription endpointDescription = null;
            ImportReference imRef = null;
            synchronized (this) {
                // only do this once
                if (!closed) {
                    containerID = getContainerID();
                    exception = getException();
                    endpointDescription = getEndpointDescription();
                    imRef = this.importReference;
                    publish = importReference.close(this);
                    this.importReference = null;                             <-- this line should be deleted
                    closed = true;
...more code

I believe the importReference should never be set to null in the ImportRegistration and that it is incorrect that it did so.   Also synchronization needs to be added to ImportRegistration accessors so that the synchronized block above prevents access to importReference before closed = true (which is resulting in NPE I think).

Peter if you would please open a bug, and put your info in comments I will address in latest version as soon as I can.


On 9/18/2018 7:33 AM, Peter Hermsdorf wrote:

we sometimes faces the following error:


The corresponding code in the class ImportRegistration is

public Throwable getException() {
            return (closed)?updateException:importReference.getException();

So obviously importReference is null but closed is false.

Any ideas what could cause this state? I've seen that there are changes on this class but wasn't able to determine if these have something to do with this handling.

We are still on ECF version 3.13.8 and we are using the ecf-genric provider.

The above code and the call to getImportedEndpoints is used to update the connection state in an RCP application and is asynchronously executed and triggered by a new event to an RemoteServiceAdminListener .... so more ore less on service state change.

Any hints are welcome!

Thanks, bye Peter

Back to the top