-
-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Custom ITransportProvider cannot be found by ServiceLoader #251
Comments
Sounds like a good improvement. It would be great to support user defined classloaders or the module system properly. I tried some ideas but I'm not really happy with it. I pushed my code to "serviceloader-update" branch. Maybe you take a look and improve it if you have good ideas. |
I don't think you can. It's up to the caller to provide the right layer or classloader in addition to the address. This doesn't matter in my particular use-case at least. We already know we are in a layered application, and have to do some special things (nearly always class loader related!). Over the years, other third party libraries we have dealt with have similar issues locating services and resources. Many of them allow class loader to be specified directly, a few allow a ModuleLayer , but only because its "new". Quite often
Will do! |
Perfect, that's behaving exactly as I'd expect. And the configuration is easily discoverable. I would not bother with any further changes. Anyone working with classloaders is going to expect stuff like this, and the fact it is now possible to do at all is great. I consider this fixed, and look forward to it making it into a snapshot or release. Thanks for the super speed response too. |
Merged branch to master, will be part of next release. |
We have a problem when trying to use a custom transport provider inside an application that makes use of ModuleLayer. The exception is ..
The issue is in
TransportGuilder.getTransportProvider()
. This usesServiceLoader.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 withTransportBuilder.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 aModuleLayer
as the first argument. Also, I would imagine it would be useful to pass alternativeClassLoader
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 constantPROVIDERS
is dealt with.The text was updated successfully, but these errors were encountered: