(feat): Add BusName and ObjectPath annotation support for core

[fingergohappy]

• Add BusName and ObjectPath annotations to mark interface bus names and object paths
• Implement annotation-based remote object retrieval in DBusConnection
• Add validation for annotation presence and uniqueness with improved error messages

then you can use like this:

@DBusInterfaceName("org.ganesha.nfsd.exportmgr")
@BusName("org.ganesha.nfsd")
@ObjectPath("/org/ganesha/nfsd/ExportMgr")
public interface ExportMgr extends DBusInterface, Properties {
  String AddExport(String path, String expr);

  ShowExportResult ShowExports();

  /**
   * 使用配置文件添加导出
   *
   * @param expr 表达式
   * @param conf 配置文件
   * @return
   */
  String AddExportWithConf(String expr, String conf);

  void RemoveExport(UInt16 exportId);
} 

		ExportMgr remoteObject = connection.getRemoteObject( ExportMgr.class);

It's very convenient to use.

[hypfvieh]

Thanks for the PR, nice idea.
I'm afraid, but I highly doubt that I gonna merge it because your idea will only work in some circumstances.

In your example it will work because you are in charge on how the exported interfaces are defined on the bus (name and path).
But when you write an application which will only "use" DBus to retrieve stuff from another application not under your control, most of the time object path will not be static/constant.

Think of querying any hardware service like bluez or NetworkManager.
There are multiple instances for NetworkManager. While the busname is constant, the objectpath will vary. There are paths for every network device and every wifi access point nearby etc.

In that case the new @ObjectPath annotation will never work because it is a constant value.

Something similar may happen when using the DBusName annotation. There are some cases where the name is fixed. But there are even more cases where the same interface is used for different exported objects and just using different names.
In that case the new annotation will only cover one of many possibilities.

To avoid confusion when using this library I don't want to add additional features which only work in a few cases and introduce possible misunderstanding/allow misusing.

If you still want to use annotations for your setup, you may create a utility method which does the steps you implemented inDBusConnection but in your own code.

[fingergohappy]

Thanks for the PR, nice idea. I'm afraid, but I highly doubt that I gonna merge it because your idea will only work in some circumstances.

In your example it will work because you are in charge on how the exported interfaces are defined on the bus (name and path). But when you write an application which will only "use" DBus to retrieve stuff from another application not under your control, most of the time object path will not be static/constant.

Think of querying any hardware service like bluez or NetworkManager. There are multiple instances for NetworkManager. While the busname is constant, the objectpath will vary. There are paths for every network device and every wifi access point nearby etc.

In that case the new @ObjectPath annotation will never work because it is a constant value.

Something similar may happen when using the DBusName annotation. There are some cases where the name is fixed. But there are even more cases where the same interface is used for different exported objects and just using different names. In that case the new annotation will only cover one of many possibilities.

To avoid confusion when using this library I don't want to add additional features which only work in a few cases and introduce possible misunderstanding/allow misusing.

If you still want to use annotations for your setup, you may create a utility method which does the steps you implemented inDBusConnection but in your own code.

Thank you for your reply. You're right, it seems I have some misunderstandings about the concept of dbus.