What about the system property container orders (<class>.priority or so)?
Le lun. 26 avr. 2021 à 20:31, Mark Thomas <ma...@apache.org> 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é <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 > >
