Re: Websocket server configurator as @ServiceProvider: a bug?

[Romain Manni-Bucau]

What about the system property container orders (.priority or so)?

Le lun. 26 avr. 2021 à 20:31, Mark Thomas  a écrit :

> 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é  .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, 
> 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é  >>> .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 

Re: Websocket server configurator as @ServiceProvider: a bug?

[Mark Thomas]

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é 
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,  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é 
.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  |  Blog
 | Old Blog
 | Github <
https://github.com/rmannibucau> |
LinkedIn  | 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

Re: Websocket server configurator as @ServiceProvider: a bug?

[Romain Manni-Bucau]

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é 
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,  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é  > .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  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | 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
> >
> >
>

Re: Websocket server configurator as @ServiceProvider: a bug?

[Raymond Augé]

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,  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é  .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  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | 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
>
>

Re: Websocket server configurator as @ServiceProvider: a bug?

[Mark Thomas]

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é 
a écrit :


Are you maybe in JPMS mode?

On Thu., Apr. 22, 2021, 9:51 a.m. Raymond Augé, 
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  |  Blog
 | Old Blog
 | Github <
https://github.com/rmannibucau> |
LinkedIn  | 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

Re: Websocket server configurator as @ServiceProvider: a bug?

[Romain Manni-Bucau]

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?


Le jeu. 22 avr. 2021 à 16:10, Raymond Augé 
a écrit :

> Are you maybe in JPMS mode?
>
> On Thu., Apr. 22, 2021, 9:51 a.m. Raymond Augé, 
> 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  |  Blog
> >>>  | Old Blog
> >>>  | Github <
> >>> https://github.com/rmannibucau> |
> >>> LinkedIn  | Book
> >>> <
> >>>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>> >
> >>>
> >>
>

Re: Websocket server configurator as @ServiceProvider: a bug?

[Romain Manni-Bucau]

Le jeu. 22 avr. 2021 à 16:06, Raymond Augé 
a écrit :

> @ServiceProvider is just a hint no?
>

Hmm, didn't check the tomcat specific setup but thought it was adding
META-INF/services/ entry too which is current issue.
Seems you are right and
https://github.com/apache/tomcat/blob/master/res/META-INF/tomcat-websocket.jar/services/jakarta.websocket.server.ServerEndpointConfig$Configurator
is just "there".


>
> It does not change the implementation behavior... Unless you've found
> otherwise, which would be surprising.
>

If it does not add the file all good and we can drop
https://github.com/apache/tomcat/blob/master/res/META-INF/tomcat-websocket.jar/services/jakarta.websocket.server.ServerEndpointConfig$Configurator
all good for me


>
> 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  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
>

Re: Websocket server configurator as @ServiceProvider: a bug?

[Raymond Augé]

On Thu., Apr. 22, 2021, 9:46 a.m. Raymond Augé, 
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  |  Blog
>>  | Old Blog
>>  | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn  | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>>
>

Re: Websocket server configurator as @ServiceProvider: a bug?

[Raymond Augé]

Are you maybe in JPMS mode?

On Thu., Apr. 22, 2021, 9:51 a.m. Raymond Augé, 
wrote:

>
>
> On Thu., Apr. 22, 2021, 9:46 a.m. Raymond Augé, 
> 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  |  Blog
>>>  | Old Blog
>>>  | Github <
>>> https://github.com/rmannibucau> |
>>> LinkedIn  | Book
>>> <
>>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> >
>>>
>>

Re: Websocket server configurator as @ServiceProvider: a bug?

[Raymond Augé]

@ServiceProvider is just a hint no?

It does not change the implementation behavior... Unless you've found
otherwise, which would be surprising.

Ray

On Thu., Apr. 22, 2021, 9:29 a.m. Romain Manni-Bucau, 
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  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>