Hi,
how is the custom URLStreamHandlerProvider used? I have no experience with it, just wondering if this isn't similar to https://developer.jboss.org/thread/272349 (that is, if the code in the JDK uses the correct classloader to lookup the ServiceLoader files).
LT
--
You received this message because you are subscribed to the Google Groups "Thorntail" group.
To unsubscribe from this group and stop receiving emails from it, send an email to thorntail+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/thorntail/399b030f-f40c-4ecf-b739-e76954533ce7%40googlegroups.com.
Hi,
how is the custom URLStreamHandlerProvider used? I have no experience with it, just wondering if this isn't similar to https://developer.jboss.org/thread/272349 (that is, if the code in the JDK uses the correct classloader to lookup the ServiceLoader files).
LT
On 28. 01. 20 16:25, Imrich Scheffer wrote:
Hy!--
I have new developing issue with registering new URL protocol handler to my application.
In short case URL hadler can register via java 9+ feature META-INF/services/java.net.spi.URLStreamHandlerProvider. This feature is working good on thorntail-runner Main class, but after build a package and running in java -jar "META-INF/services/java.net.spi.URLStreamHandlerProvider" file is not recognized.
This issue is very similar with https://issues.redhat.com/browse/THORN-948 issue, but closed by out of date.
Any help with register META-INF/services/java.net.spi.URLStreamHandlerProvider file is very appreciated.
Thanks!
You received this message because you are subscribed to the Google Groups "Thorntail" group.
To unsubscribe from this group and stop receiving emails from it, send an email to thor...@googlegroups.com.
Hmm, that's funny, as Runner should be pretty close to the actual
uberjar. It seems we have an unintended difference there.
Thanks,
LT
To unsubscribe from this group and stop receiving emails from it, send an email to thorntail+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/thorntail/4c1d0380-a0f2-45ee-9f6f-2eee3756da93%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/thorntail/4c1d0380-a0f2-45ee-9f6f-2eee3756da93%40googlegroups.com.
Thanks! I don't see anything obviously wrong just from browsing the code quickly, I'll take a deeper look later today.
LT
To unsubscribe from this group and stop receiving emails from it, send an email to thorntail+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/thorntail/6d738fcc-be4c-40c0-aaa7-50fb0c3c749f%40googlegroups.com.
OK, so it's exactly as I thought -- the code in the JDK looks for the ServiceLoader files in the system classloader: https://github.com/openjdk/jdk11u/blob/master/src/java.base/share/classes/java/net/URL.java#L1279-L1281 That's not where it is, in our case. I believe it would be the same with WildFly. (Just to be sure, I placed a breakpoint there and overwrote the `sl` variable with one looked up from current thread's context classloader, and it worked fine.)
You're right that it works with Runner -- I forgot about that, but what Runner does is that it builds the uberjar in a separate JVM, but then runs it from the same JVM, so it has the ServiceLoader files in the system classloader -- I guess because the IDE just puts them on the classpath when it runs the Runner class.
I'm not sure if we can do anything about this.
LT
To view this discussion on the web visit https://groups.google.com/d/msgid/thorntail/d68ca057-f177-6fba-a5a9-138c447eb187%40redhat.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/thorntail/6d738fcc-be4c-40c0-aaa7-50fb0c3c749f%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Thorntail" group.
To unsubscribe from this group and stop receiving emails from it, send an email to thor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/thorntail/d68ca057-f177-6fba-a5a9-138c447eb187%40redhat.com.