Hello all,
There has been a long standing limitation in the JDK w.r.t. the handling of
URLStreamHandlerFactory. Beyond Java 17 this API becomes even more locked
down making dynamic use cases or coordination among frameworks next to
impossible. It appears unlikely to ever be resolved in the JDK.
The OSGi community shares a desire [1] (with others in the wider Java
community) to address this. We were thinking this might happen in a way
that Tomcat may benefit from, since it appears to also have the same issue
[2].
Here is the idea.
We thought that a library could become the de facto implementation which,
by acting as the primordial URLStreamHandlerFactory (which directly
integrates with the JVM), provides the dynamism necessary for any number of
downstream consumers are able to orchestrate a set of protocol handlers
without clobbering everyone else or worse failing outright in those
scenarios where someone else beat you to the punch.
How might this be accomplished? Tom Watson from IBM suggested that by
providing a protocol of it's own which one could obtain by doing something
like `new URL("ushfm:").openConnection()` returning an instance which is
castable (or used reflectively) to a management-like interface.
We imagined that such a library could potentially replace the current
implementation in tomcat, or at least help it to accomplish its goals. This
would enable scenarios where OSGi is embedded in a WAR (my company for
instance), or where tomcat is embedded (and that env already has said
library deployed) or any combination of those. Of course there is room here
for all fallbacks to kick in. If the "lookup" fails, then obviously there
is no such implementation present and you keep doing what you were doing.
Ideally such a library would live in an open source project where there is
credibility for a wide audience, such as Apache.
Thoughts?
Ray
[1] https://github.com/osgi/osgi/issues/226
[2]
https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/catalina/webresources/TomcatURLStreamHandlerFactory.java
