Lastly, I do agree that if fixed in Java that would be the best case scenario. However, I am not hopeful.
On Thu, Feb 17, 2022 at 9:08 AM Raymond Augé <raymond.a...@liferay.com> wrote: > 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 > -- *Raymond Augé* (@rotty3000) Senior Software Architect *Liferay, Inc.* (@Liferay) OSGi Fellow, Java Champion
