Ah. That is a general problem with the ServiceLoader mechanism. It is
good for situations where you have one, unknown implementation. If there
are multiple implementations there is no mechanism for the user to
express a preference - short of hacking the class loader to ensure the
"right" one is found first.
Generally, I don't like the idea of hard-coding assumptions regarding
priority. Whether those assumptions put Tomcat's implementation first or
last.
As you point out, with Java 9+ a solution that allows a Comparator to be
provided to the ContainerProvider that would sort the ServiceLoader
results would be possible. But that will need API changes. I created:
https://github.com/eclipse-ee4j/websocket-api/issues/365
Meanwhile what to do for Tomcat 10 and earlier?
What if we added a static method to o.a.t.w.WsContainerProvider that
caused getContainer() to return null rather than an instance. That would
essentially hide the Tomcat implementation from the ServiceLoader
mechanism but not block its use as a default.
Expanding on that slightly, a static getter and setter for
disableGetContainer would - assuming you control when the ServiceLoader
mechanism is invoked- allow disabling/enabling of the Tomcat
implementation on a case by case basis.
Thoughts?
Mark
On 22/04/2021 18:48, Romain Manni-Bucau wrote:
It is not wrong per se but it is not usable to plug a custom impl which is
my issue.
@Mark: what about ignoring the default if there is another impl in
serviceloader iteration? Would fix it even if it would create some useless
stuff but recent serviceloader api solves it if we want to avoid it (with
Provider support). If not, the alternative is to make the spi registration
in another jar usable when not relying on tomcat-ws-api. Both options work
too even if first one would be simpler probably.
Le jeu. 22 avr. 2021 à 18:29, Raymond Augé <raymond.a...@liferay.com.invalid>
a écrit :
Romain are you saying that having a service descriptor in this case is
wrong?
On Thu., Apr. 22, 2021, 11:47 a.m. Mark Thomas, <ma...@apache.org> wrote:
On 22/04/2021 16:18, Romain Manni-Bucau wrote:
I am not in JPMS Ray.
About I think the issue is a "double bug" (well one bug, two step
resolutions) since I can drop the SPI registration but
then @ServiceProvider will recreate it so I propose:
1. to drop the explicit SPI registration and keep the default which is
1-1
(even faster but that's more than minor) since it is not needed at all
and
will enable to use the SPI properly (at least when a single impl is
there,
when multiple are there a system property can help but that's another
topic
and rare enough to be ignored for now probably)
2. to drop ServiceProvider annotation and replace it by the needed OSGi
metadata rather than this particular API
Wdyt?
I don't see what problem you are attempting to solve.
The SPI registration is required in case the Tomcat implementation is
used with an API that doesn't have the Tomcat implementation as the
hard-coded default.
What is the concern with using the @ServiceProvider annotation to enable
Bnd to generate the correct meta data?
Mark
Le jeu. 22 avr. 2021 à 16:10, Raymond Augé <raymond.a...@liferay.com
.invalid>
a écrit :
Are you maybe in JPMS mode?
On Thu., Apr. 22, 2021, 9:51 a.m. Raymond Augé, <
raymond.a...@liferay.com>
wrote:
On Thu., Apr. 22, 2021, 9:46 a.m. Raymond Augé, <
raymond.a...@liferay.com>
wrote:
@ServiceProvider is just a hint no?
It does not change the implementation behavior... Unless you've
found
otherwise, which would be surprising.
To be clear, there is no runtime behavior associated with
@ServiceProvider
_unless_ you are running tomcat in OSGi, which would bring in the
Service
Loader Mediator to handle the SPI call, BUT still would not change to
logic
around using a fallback impl if so coded.
Ray
On Thu., Apr. 22, 2021, 9:29 a.m. Romain Manni-Bucau, <
rmannibu...@gmail.com> wrote:
Hi all,
Websocket server configurator uses the SPI to load the impl and if
not
found fallbacks on the hardcoded tomcat default.
Isn't the SPI intended to override the default and
therefore @ServiceProvider breaks this feature?
If not, how to override it globally without doing it on a per
endpoint
basis?
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
