You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
How could a code change look like? Would the classloader be passed down to the ServiceLoader.load() to be passed as a second parameter (currently only one parameter is passed, so the threads default classloader is used)?
The text was updated successfully, but these errors were encountered:
The class loader that you are passing to AsciidoctorJRuby.Factory.create() is currently only used to load the Asciidoctor implementation from that location.
But I agree that it would make sense to also use it for loading extensions, converters, etc.
Thank you for looking into this. No hurry necessary as there is a workaround.
I'm happy to test it in my environments once you give me a "ping".
BTW: The AsciiDoc plugin for IntelliJ is about to offer support for user-supplied AsciidoctorJ based extensions in the preview. There might still be some caveats, but the current pre-release offers initial support: asciidoctor/asciidoctor-intellij-plugin#532
For the AsciiDoc plugin for IntelliJ I create a custom class loader and then call
to create an instance. I do this as the list of JARs is determined at runtime.
The expected behavior to me was that all extensions in META-INF should be registered automatically.
But this was not the case.
I found that JRubyAsciidoctor#processRegistrations() doesn't receive the classloader parameter, and neither do its decendants.
A workaround for this: set the thread's classloader like this:
Please advise if this behavior should be changed.
How could a code change look like? Would the classloader be passed down to the ServiceLoader.load() to be passed as a second parameter (currently only one parameter is passed, so the threads default classloader is used)?
The text was updated successfully, but these errors were encountered: