We have a problem when trying to use a custom transport provider inside an application that makes use of ModuleLayer. The exception is ..

No transport provider found for bustype SSH
    at org.freedesktop.dbus/org.freedesktop.dbus.connections.transports.TransportBuilder.build(TransportBuilder.java:177)
    at org.freedesktop.dbus/org.freedesktop.dbus.connections.base.AbstractConnectionBase.<init>(AbstractConnectionBase.java:114)
    at org.freedesktop.dbus/org.freedesktop.dbus.connections.base.ConnectionMethodInvocation.<init>(ConnectionMethodInvocation.java:33)
    at org.freedesktop.dbus/org.freedesktop.dbus.connections.base.ConnectionMessageHandler.<init>(ConnectionMessageHandler.java:42)
    at org.freedesktop.dbus/org.freedesktop.dbus.connections.AbstractConnection.<init>(AbstractConnection.java:41)

The issue is in TransportGuilder.getTransportProvider(). This uses ServiceLoader.load(ITransportProvider.class, TransportBuilder.class.getClassLoader()) to locate the services.

This will only find ITransportProvider implementations that exist in the same layer, or in a parent layer that is associated with TransportBuilder.class.getClassLoader(). My provider is in a child layer, so will never be found.

So there is a need to be able to use the alternative methods provided by ServiceLoader that take a ModuleLayer as the first argument. Also, I would imagine it would be useful to pass alternative ClassLoader instead for applications that don't make use of module layers, but do have different class loader arrangements (e..g pf4j based applications or other plugin frameworks).

That static nature of TransportBuilder.getTransportProvider() and when it is called looks like this might be a moderately challenging fix, so I am not going to dive in and make a PR without discussion.

Initial thoughts are that it looks like this configuration could possibly be passed down in TransportConfig, but there would need to be some rearranging of how the constant PROVIDERS is dealt with.