You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Raymond Augé <ra...@liferay.com.INVALID> on 2022/02/16 23:11:21 UTC
ULRStreamHandlerFactory proposal
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
Re: ULRStreamHandlerFactory proposal
Posted by Raymond Augé <ra...@liferay.com.INVALID>.
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é <ra...@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é <ra...@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 <rm...@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 <re...@apache.org> a écrit
>>> :
>>>
>>> > On Thu, Feb 17, 2022 at 12:11 AM Raymond Augé
>>> > <ra...@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-unsubscribe@tomcat.apache.org
>>> > For additional commands, e-mail: dev-help@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
Re: ULRStreamHandlerFactory proposal
Posted by Raymond Augé <ra...@liferay.com.INVALID>.
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é <ra...@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 <rm...@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 <re...@apache.org> a écrit :
>>
>> > On Thu, Feb 17, 2022 at 12:11 AM Raymond Augé
>> > <ra...@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-unsubscribe@tomcat.apache.org
>> > For additional commands, e-mail: dev-help@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
Re: ULRStreamHandlerFactory proposal
Posted by Raymond Augé <ra...@liferay.com.INVALID>.
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 <rm...@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 <re...@apache.org> a écrit :
>
> > On Thu, Feb 17, 2022 at 12:11 AM Raymond Augé
> > <ra...@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-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
--
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow, Java Champion
Re: ULRStreamHandlerFactory proposal
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <re...@apache.org> a écrit :
> On Thu, Feb 17, 2022 at 12:11 AM Raymond Augé
> <ra...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: ULRStreamHandlerFactory proposal
Posted by Rémy Maucherat <re...@apache.org>.
On Thu, Feb 17, 2022 at 12:11 AM Raymond Augé
<ra...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org