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 > > > > >
