NullpointerException in RemoteServiceAdmin

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

NullpointerException in RemoteServiceAdmin

Peter Hermsdorf-2
Hi,

we sometimes faces the following error:

java.lang.NullPointerException
     at
org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$ImportRegistration.getException(RemoteServiceAdmin.java:1139)
     at
org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$ImportRegistration.getImportReference(RemoteServiceAdmin.java:1104)
     at
org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.getImportedEndpoints(RemoteServiceAdmin.java:519)

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


_______________________________________________
ecf-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
Reply | Threaded
Open this post in threaded view
|

Re: NullpointerException in RemoteServiceAdmin

Scott Lewis-2
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.

Scott





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

> Hi,
>
> we sometimes faces the following error:
>
> java.lang.NullPointerException
>     at
> org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$ImportRegistration.getException(RemoteServiceAdmin.java:1139)
>     at
> org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$ImportRegistration.getImportReference(RemoteServiceAdmin.java:1104)
>     at
> org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.getImportedEndpoints(RemoteServiceAdmin.java:519)
>
> 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
>
>
> _______________________________________________
> ecf-dev mailing list
> [hidden email]
> 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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
Reply | Threaded
Open this post in threaded view
|

Re: NullpointerException in RemoteServiceAdmin

Peter Hermsdorf-2

Done: https://bugs.eclipse.org/bugs/show_bug.cgi?id=539218

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.

Scott





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

we sometimes faces the following error:

java.lang.NullPointerException
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$ImportRegistration.getException(RemoteServiceAdmin.java:1139)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$ImportRegistration.getImportReference(RemoteServiceAdmin.java:1104)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.getImportedEndpoints(RemoteServiceAdmin.java:519)

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

_______________________________________________
ecf-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
Reply | Threaded
Open this post in threaded view
|

Re: NullpointerException in RemoteServiceAdmin

Peter Hermsdorf-2

Hi,

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(AbstractRemoteService.java:503)
    ... 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 :

org.eclipse.ecf.remoteservice.asyncproxy;version="[1.0.0,3.0.0)"

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:

Done: https://bugs.eclipse.org/bugs/show_bug.cgi?id=539218

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.

Scott





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

we sometimes faces the following error:

java.lang.NullPointerException
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$ImportRegistration.getException(RemoteServiceAdmin.java:1139)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$ImportRegistration.getImportReference(RemoteServiceAdmin.java:1104)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.getImportedEndpoints(RemoteServiceAdmin.java:519)

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


_______________________________________________
ecf-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
Reply | Threaded
Open this post in threaded view
|

Re: NullpointerException in RemoteServiceAdmin

Scott Lewis-2
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.

Scott


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

Hi,

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(AbstractRemoteService.java:503)
    ... 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 :

org.eclipse.ecf.remoteservice.asyncproxy;version="[1.0.0,3.0.0)"

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:

Done: https://bugs.eclipse.org/bugs/show_bug.cgi?id=539218

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.

Scott





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

we sometimes faces the following error:

java.lang.NullPointerException
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$ImportRegistration.getException(RemoteServiceAdmin.java:1139)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$ImportRegistration.getImportReference(RemoteServiceAdmin.java:1104)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.getImportedEndpoints(RemoteServiceAdmin.java:519)

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



_______________________________________________
ecf-dev mailing list
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
Reply | Threaded
Open this post in threaded view
|

Re: NullpointerException in RemoteServiceAdmin

Peter Hermsdorf-2

Hi Scott,

the bug is https://bugs.eclipse.org/bugs/show_bug.cgi?id=539469

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:

http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg08831.html

updating is currently no option for us.

Thanks, bye Peter

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

http://dev.eclipse.org/mhonarc/lists/ecf-dev/

i filed a bug here https://bugs.eclipse.org/bugs/show_bug.cgi?id=539471 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.

Scott


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

Hi,

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(AbstractRemoteService.java:503)
    ... 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 :

org.eclipse.ecf.remoteservice.asyncproxy;version="[1.0.0,3.0.0)"

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:

Done: https://bugs.eclipse.org/bugs/show_bug.cgi?id=539218

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.

Scott





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

we sometimes faces the following error:

java.lang.NullPointerException
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$ImportRegistration.getException(RemoteServiceAdmin.java:1139)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$ImportRegistration.getImportReference(RemoteServiceAdmin.java:1104)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.getImportedEndpoints(RemoteServiceAdmin.java:519)

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


_______________________________________________
ecf-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
Reply | Threaded
Open this post in threaded view
|

Re: NullpointerException in RemoteServiceAdmin

Scott Lewis-2
IOn 9/26/2018 3:54 AM, Peter Hermsdorf wrote:

Hi Scott,

the bug is https://bugs.eclipse.org/bugs/show_bug.cgi?id=539469

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:

http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg08831.html

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.

Scott


Thanks, bye Peter

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

http://dev.eclipse.org/mhonarc/lists/ecf-dev/

i filed a bug here https://bugs.eclipse.org/bugs/show_bug.cgi?id=539471 and added you as CC


Thanks.


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.

Scott


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

Hi,

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(AbstractRemoteService.java:503)
    ... 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 :

org.eclipse.ecf.remoteservice.asyncproxy;version="[1.0.0,3.0.0)"

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:

Done: https://bugs.eclipse.org/bugs/show_bug.cgi?id=539218

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.

Scott





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

we sometimes faces the following error:

java.lang.NullPointerException
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$ImportRegistration.getException(RemoteServiceAdmin.java:1139)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$ImportRegistration.getImportReference(RemoteServiceAdmin.java:1104)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.getImportedEndpoints(RemoteServiceAdmin.java:519)

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



_______________________________________________
ecf-dev mailing list
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
Reply | Threaded
Open this post in threaded view
|

Re: NullpointerException in RemoteServiceAdmin

Peter Hermsdorf-2

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 https://bugs.eclipse.org/bugs/show_bug.cgi?id=539556 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 https://bugs.eclipse.org/bugs/show_bug.cgi?id=539469

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:

http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg08831.html

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.

Scott


Thanks, bye Peter

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

http://dev.eclipse.org/mhonarc/lists/ecf-dev/

i filed a bug here https://bugs.eclipse.org/bugs/show_bug.cgi?id=539471 and added you as CC


Thanks.


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.

Scott


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

Hi,

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(AbstractRemoteService.java:503)
    ... 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 :

org.eclipse.ecf.remoteservice.asyncproxy;version="[1.0.0,3.0.0)"

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:

Done: https://bugs.eclipse.org/bugs/show_bug.cgi?id=539218

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.

Scott





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

we sometimes faces the following error:

java.lang.NullPointerException
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$ImportRegistration.getException(RemoteServiceAdmin.java:1139)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$ImportRegistration.getImportReference(RemoteServiceAdmin.java:1104)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.getImportedEndpoints(RemoteServiceAdmin.java:519)

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

_______________________________________________
ecf-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
Reply | Threaded
Open this post in threaded view
|

Re: NullpointerException in RemoteServiceAdmin

Peter Hermsdorf-2

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:

org.eclipse.ecf.remoteservice.feature.feature.group 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 https://bugs.eclipse.org/bugs/show_bug.cgi?id=539469 .

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)

Thanks!

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 https://bugs.eclipse.org/bugs/show_bug.cgi?id=539556 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 https://bugs.eclipse.org/bugs/show_bug.cgi?id=539469

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:

http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg08831.html

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.

Scott


Thanks, bye Peter

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

http://dev.eclipse.org/mhonarc/lists/ecf-dev/

i filed a bug here https://bugs.eclipse.org/bugs/show_bug.cgi?id=539471 and added you as CC


Thanks.


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.

Scott


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

Hi,

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(AbstractRemoteService.java:503)
    ... 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 :

org.eclipse.ecf.remoteservice.asyncproxy;version="[1.0.0,3.0.0)"

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:

Done: https://bugs.eclipse.org/bugs/show_bug.cgi?id=539218

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.

Scott





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

we sometimes faces the following error:

java.lang.NullPointerException
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$ImportRegistration.getException(RemoteServiceAdmin.java:1139)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$ImportRegistration.getImportReference(RemoteServiceAdmin.java:1104)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.getImportedEndpoints(RemoteServiceAdmin.java:519)

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

_______________________________________________
ecf-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
Reply | Threaded
Open this post in threaded view
|

Re: NullpointerException in RemoteServiceAdmin

Scott Lewis-2
On 9/28/2018 4:03 AM, Peter Hermsdorf wrote:

>
> 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:
>
> org.eclipse.ecf.remoteservice.feature.feature.group
> 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 https://bugs.eclipse.org/bugs/show_bug.cgi?id=539469 .
>

I'm not sure.  I don't immediately know how we would have the feature
optionally include the 2.1 and 1.1 bundles.   One or the other are
required, based upon the dependencies as Peter points out.   Mat:  do
you know how to do that?

Feel free to open a releng bug for this...we will try to address it, but
I'm not sure how.

BTW:   I've been contemplating releasing 3.14.3 and with this most
recent bug fix it seems time to do so.  Any comments?

Scott


_______________________________________________
ecf-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
Reply | Threaded
Open this post in threaded view
|

Re: NullpointerException in RemoteServiceAdmin

Peter Hermsdorf-2

Hi Scott,


Am 28.09.2018 um 18:42 schrieb Scott Lewis:
I'm not sure.  I don't immediately know how we would have the feature optionally include the 2.1 and 1.1 bundles.   One or the other are required, based upon the dependencies as Peter points out.   Mat:  do you know how to do that?
AFAICT the only possibility is to declare both bundles as optional. Not perfect of course.

What would happen when none of them is deployed? How is the error handling? (worst case of course, should not happen if the target platform is prepared with on or the other bundle)

Thanks,
bye Peter


_______________________________________________
ecf-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
Reply | Threaded
Open this post in threaded view
|

Re: NullpointerException in RemoteServiceAdmin

Mat Booth
In reply to this post by Scott Lewis-2

On Fri, 28 Sep 2018 at 17:42, Scott Lewis <[hidden email]> wrote:
On 9/28/2018 4:03 AM, Peter Hermsdorf wrote:
>
> 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:
>
> org.eclipse.ecf.remoteservice.feature.feature.group
> 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 https://bugs.eclipse.org/bugs/show_bug.cgi?id=539469 .
>

I'm not sure.  I don't immediately know how we would have the feature
optionally include the 2.1 and 1.1 bundles.   One or the other are
required, based upon the dependencies as Peter points out.   Mat:  do
you know how to do that?

Hmm, I'm not sure you can. Eclipse "features" are kind of a hacky hold-over from the pre-OSGi days...

I think the easiest way to workaround this would be not to include the "o.e.ecf.remoteservice.feature" feature in one's product definition, but rather simply include the "o.e.ecf.remoteservice" bundle and the "o.e.ecf.remoteservice.asyncproxy" version of your choice instead.

Alternatively, since the "o.e.ecf.remoteservice" bundle already expresses a non-optional dep on the "o.e.ecf.remoteservice.asyncproxy" bundle with a sufficiently broad version range that either bundle can satisfy the dep -- is it even necessary specify the asyncproxy bundles in the feature definition? In theory you could remove them from the feature definition and Eclipse should still do the Right Thing™ when you install it.

Alternatively alternatively, there appears to be some p2 black magic that can be employed to workaround the limitations of feature manifests. According to the documentation [1] you could, in theory, have a p2.inf file co-located with the feature.xml containing something like this:

requires.0.namespace = org.eclipse.equinox.p2.iu
requires.0.name = org.eclipse.ecf.remoteservice.asyncproxy
requires.0.version = 1.1.100
requires.0.optional = true
requires.1.namespace = org.eclipse.equinox.p2.iu
requires.1.name = org.eclipse.ecf.remoteservice.asyncproxy
requires.1.version = 2.1.0
requires.1.optional = true

And that should augment the requirements generated for the feature IU, but I haven't tried it yet.


 

Feel free to open a releng bug for this...we will try to address it, but
I'm not sure how.

BTW:   I've been contemplating releasing 3.14.3 and with this most
recent bug fix it seems time to do so.  Any comments?

Scott


_______________________________________________
ecf-dev mailing list
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
Reply | Threaded
Open this post in threaded view
|

Re: NullpointerException in RemoteServiceAdmin

Peter Hermsdorf-2

Hi,

Mat, thanks for your comments.

Am 08.10.2018 um 17:45 schrieb Mat Booth:

On Fri, 28 Sep 2018 at 17:42, Scott Lewis <[hidden email]> wrote:
On 9/28/2018 4:03 AM, Peter Hermsdorf wrote:
>
> 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:
>
> org.eclipse.ecf.remoteservice.feature.feature.group
> 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 https://bugs.eclipse.org/bugs/show_bug.cgi?id=539469 .
>

I'm not sure.  I don't immediately know how we would have the feature
optionally include the 2.1 and 1.1 bundles.   One or the other are
required, based upon the dependencies as Peter points out.   Mat:  do
you know how to do that?

Hmm, I'm not sure you can. Eclipse "features" are kind of a hacky hold-over from the pre-OSGi days...

I think the easiest way to workaround this would be not to include the "o.e.ecf.remoteservice.feature" feature in one's product definition, but rather simply include the "o.e.ecf.remoteservice" bundle and the "o.e.ecf.remoteservice.asyncproxy" version of your choice instead.
My problem here was that i had a dependency to the bundle o.e.ecf.osgi.services.distribution which is in feature o.e.ecf.osgi.services.feature which has a dependency to o.e.ecf.remoteservice.feature which includes both versions of the asyncproxy bundles.

I tried removing the o.e.ecf.osgi.services.feature and adding a dependency to o.e.ecf.osgi.services.distribution and the asyncproxy bundle like this:

<import plugin="org.eclipse.ecf.remoteservice.asyncproxy" version="1.1.100" match="compatible"/>

and it does work for me. The correct version is included in the product.

I could live with that solution. It's not too hacky and can be easily removed when we update target platform and then can use asyncproxy bundle version 2.

Thanks for the hints!

Bye Peter



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