Another small point is that the issue is with cleanup more than with registration. The Java 17 API has no way to remove factories. This tied to the lack of a coordination model means that you risk classloader pinning. Sure tomcat has a work around. But there is no portable API anywhere to do it. Each product has it's own design an quirks.
On Thu, Feb 17, 2022 at 9:02 AM Raymond Augé <raymond.a...@liferay.com> wrote: > I would like to clarify one small point which may have been missed in my > description. > > The issue is that there is not only tomcat. There are other frameworks in > the Java ecosystem having a desire to manage URLStreamHandlerFactories. The > problem is coordination between them when they are peers, or when they form > any type of hierarchy. The current API simply cannot cope with that. We > have an issue with tomcat as it is to be honest because we are downstream > from it, and if tomcat did it's binding we are screwed in our downstream > use case. The same if a framework were to do it and tomcat were downstream > of it (embedded). > > Anyhow, thank you for your consideration. > > Ray > > > > On Thu, Feb 17, 2022 at 6:10 AM Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > >> Hi all >> >> It is a very valid point, since tomcat started to use this API it got >> worked around in all integrations (bypassed to disable war: url handling >> basically). >> I never fully got why tomcat integrated at that level since in standalone >> mode it owns the deployment so it does not need at all AFAIK so anything >> making it optional would be a +1 from me. >> That said I would avoid a shared lib which will create new issues and >> conflicts quite easily so I would probably encourage to implement the war: >> support different (likely testing the protocol only? should be sufficient >> in tomcat land). >> >> >> Anyway +1 to encourage Oracle to make the JVM support nicer and plural but >> I'm not sure it will happen tomorrow so there are still rooms to enhance >> tomcat "integrability" way before IMHO. >> >> Hope it makes sense. >> >> Romain Manni-Bucau >> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> <https://rmannibucau.metawerx.net/> | Old Blog >> <http://rmannibucau.wordpress.com> | Github < >> https://github.com/rmannibucau> | >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book >> < >> https://www.packtpub.com/application-development/java-ee-8-high-performance >> > >> >> >> Le jeu. 17 févr. 2022 à 10:57, Rémy Maucherat <r...@apache.org> a écrit : >> >> > On Thu, Feb 17, 2022 at 12:11 AM Raymond Augé >> > <raymond.a...@liferay.com.invalid> wrote: >> > > >> > > 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? >> > >> > It should be fixed by the Java platform. How hard is it to add >> > URL.setURLStreamHandlerFactory(String protocol, >> > URLStreamHandlerFactory fac) ? I think the problem is that nobody was >> > really asking, so Oracle did nothing. Given the amount of improvements >> > and additions to the platform since the stagnation of Java 8, why >> > would they still refuse it ? They've even been rewriting NIO ! >> > >> > Also, and more importantly, you can very very easily use >> > TomcatURLStreamHandlerFactory.addUserFactory (doing it through >> > reflection if needed) as all currently supported Tomcat versions have >> > this API. You're already integrating Tomcat using some integration >> > code, so your integration code should be using this. >> > >> > Rémy >> > >> > > 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 >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> > For additional commands, e-mail: dev-h...@tomcat.apache.org >> > >> > >> > > > -- > *Raymond Augé* (@rotty3000) > Senior Software Architect *Liferay, Inc.* (@Liferay) > OSGi Fellow, Java Champion > -- *Raymond Augé* (@rotty3000) Senior Software Architect *Liferay, Inc.* (@Liferay) OSGi Fellow, Java Champion
