hypfvieh
commented
6 months ago I've looked at this case and I agree that something is missing here.
I first investigated what you mentioned about PropRefRemoteHandler.
When the method handleDBusBoundProperty is used it is assumed that Properties is supported by the given remote object.
That is wrong. The remote object the method receives is an arbitrary object which is not necessarily related to Properties.
In most cases the object behind the remote path is supporting Properties but not necessarily the object passed to this method.
So your fix to create another remote object using Properties will work because the calls are delegated to the object behind the path, not to the given object itself.
For me this seems to be a valid fix. Some tests would be great, but how to test a thing which did work before?
The second thing you mentioned is Marshalling class.
I have to admit I don't see why there is a need to change anything. Also I'm not sure what your change should do. When debugging this the parameter is not Variant it is String so the code will never be executed.
The right fix for this is again in PropRefRemoteHandler.
When handleDBusBoundProperty has executed the remote method call, it must take care of the result.
What is happening here?
The remote call will (hopefully) resolve the requested property and as the javadoc on that method already says, all properties on DBus are always Variant.
Variant may not be the type of object we want to return here. This depends on how the @DBusBoundProperty was used (e.g. the return of the method is Variant).
So we may have to unwrap the Variant here to get the correct object type:
Object result = null;
if (access == Access.READ) {
result = RemoteInvocationHandler.executeRemoteMethod(propertiesRemoteObj, PROP_GET_METHOD,
new Type[] {_method.getGenericReturnType()}, _conn, RemoteInvocationHandler.CALL_TYPE_SYNC, null, DBusNamingUtil.getInterfaceName(_method.getDeclaringClass()), name);
} else {
result = RemoteInvocationHandler.executeRemoteMethod(propertiesRemoteObj, PROP_SET_METHOD, variantType,
new Type[] {_method.getGenericReturnType()}, _conn, RemoteInvocationHandler.CALL_TYPE_SYNC, null, DBusNamingUtil.getInterfaceName(_method.getDeclaringClass()), name, _args[0]);
}
// requested return type is not Variant but the result is -> unwrap Variant
if (_method.getReturnType() != Variant.class && typeClass != Variant.class && result instanceof Variant<?> v) {
return v.getValue();
}
return result;I've already updated master branch to include this patch and your patch as well.
brett-smith
There appears to be something fundamentally wrong with
@DBusBoundProperty. I can't quite put my finger on it yet, but am getting closer.All seems well if I am importing an object using these annotations into dbus-java from a service that is also using dbus-java to export it (both ends are using the same interface classes but this doesn't matter).
However, if I try to import interfaces into dbus-java from a service exported by something other than dbus-java, it fails.
The following example fails.
Results in the exception ...
Now I'm sure this used to work during the initial development, but I cannot find any changes since that may have broken it, so maybe it never actually worked and I only ever tested with dbus-java on both ends.
I wondered if part of the problem was what was addressed by this PR. https://github.com/hypfvieh/dbus-java/pull/252. However, fixing that made no difference.
Digging deeper, I found the following two changes seem to fix it. I've not made a PR for this yet, as this was just me stabbing randomly at the keyboard until it worked, and it probably breaks other stuff.
This is in
PropRefRemoteHandler. It basically changes theinterfacethat is held byRemoteObjecttoProperties. I am fairly happy this is a correct change, and safe, as it only applies when the annotation is in use.The second change was in
Marshalling. The was necessary because the return value was always coming back as aVariantin this case. This one was a bit brute force, and looks likely to break something else. But it should hopefully be a clue as to what is actually going on.The fact that it works with dbus-java exporting the service is a bit odd. What is it doing differently I wonder? It seems like it might not be following the specification of
Propertiesproperly, and the importing side was incorrectly designed to match that.