Sorry but not understand why both Tomcat and OWB doing the same think with nearly same classes
@Remy Just wonder why did you introduce such a module in tomcat modules? Do you have any specific purpose? On 30 Jun 2020 Tue at 11:24 Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > Hmm, I'm not following, spoke of websockets, not async requests and as an > user I expect a tomcat-owb integration module to make both working together > otherwise it is pointless to have an integration module not integrating > technologies. > Now the spec mentions it is supported in an EE world - we are not there but > I guess we should be consistent with it in such a module: > > https://jakarta.ee/specifications/websocket/1.1/apidocs/javax/websocket/server/ServerEndpointConfig.Configurator.html#getEndpointInstance-java.lang.Class- > > I suspect tomcat could use by itself the instance manager to avoid this > integration need but then it would leak the "release" call - it must be > compensated by another mechanism since the websocket spec does not give it. > > Anyway, we can open a new thread on the impl, didn't intend to hijack this > one. > > Le mar. 30 juin 2020 à 09:59, Mark Struberg <strub...@yahoo.de.invalid> a > écrit : > > > It means we support @RequestScoped and ApplicationScoped beans in Async > > Requests and events as required by the spec. > > > > The rest is afaik not portable. > > > > Happy to be proven wrong ;) > > > > LieGrue, > > strub > > > > > > > Am 30.06.2020 um 09:39 schrieb Romain Manni-Bucau < > rmannibu...@gmail.com > > >: > > > > > > If does support means you can write websocket code, sure. > > > If it means "works with cdi beans" then I think we miss this class: > > > > > > https://github.com/apache/tomee/blob/master/tomee/tomee-catalina/src/main/java/org/apache/tomee/catalina/websocket/JavaEEDefaultServerEnpointConfigurator.java > > > > > > 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 mar. 30 juin 2020 à 09:29, Mark Struberg <strub...@yahoo.de.invalid > > > > a > > > écrit : > > > > > >> our tomcat integration does support websockets afair. > > >> > > >> LieGrue, > > >> strub > > >> > > >>> Am 30.06.2020 um 08:20 schrieb Romain Manni-Bucau < > > rmannibu...@gmail.com > > >>> : > > >>> > > >>> @Gurkan Erdogdu <gurkanerdo...@yahoo.com> the first reason to keep > > >> tomcat > > >>> module is that we release it whereas o.a.tomcat:tomcat-owb does not > > exist > > >>> for end users today ("you can build from source" is not an option > IMHO > > >> and > > >>> justifies to fork in most cases). The main difference in terms of > code > > is > > >>> the fact tomcat integration provides a valve for the principal > whereas > > we > > >>> only use a filter but I guess it is enough since valve will prevent > to > > >>> position the filter - = capture of the principal - in the filter > chain > > >> and > > >>> can therefore break apps even if it is tempting to make it always win > > (we > > >>> shouldn't use a thread local but we don't have much options there). > > Both > > >>> impl miss websocket integration - tomee has it - so it looks like > > >>> tomcat-owb is a fork of our module today, not much so release point > is > > a > > >>> blocker for me. > > >>> > > >>> With jakarta I guess we can maybe ask tomcat+jetty to get an official > > >>> servlet components injections and drop all specific code. > > >>> > > >>> Last point about the consistency for jetty AND tomcat is also key for > > me, > > >>> there is no reason to favor jetty and not tomcat. > > >>> > > >>> +1 to drop the version from the module though, it does not make sense > > >>> anymore - was for 6 -> 7 move IIRC. > > >>> > > >>> 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 mar. 30 juin 2020 à 00:34, Gurkan Erdogdu < > cgurkanerdo...@gmail.com > > > > > >> a > > >>> écrit : > > >>> > > >>>> Hi Remy > > >>>> > > >>>>> I would think you should keep "tomcat7" too, it's not really the > same > > >>>> idea > > >>>>> as modules/owb. > > >>>>> > > >>>> I have looked at both implementations and both are the same purpose, > > >>>> injection into Servlet related classes and get the current > Principal > > >> from > > >>>> the request. In Tomcat/OWB module, its integration is more natural > > than > > >> the > > >>>> Tomcat7 module. > > >>>> What is the benefit of using Tomcat7 in OWB? > > >>>> Regards. > > >>>> Gurkan > > >>>> > > >>>> > > >>>> On Tue, Jun 30, 2020 at 12:33 AM Rémy Maucherat <r...@apache.org> > > >> wrote: > > >>>> > > >>>>> On Mon, Jun 29, 2020 at 1:54 PM Romain Manni-Bucau < > > >>>> rmannibu...@gmail.com> > > >>>>> wrote: > > >>>>> > > >>>>>> +1 to drop jms module, never saw any usage of it > > >>>>>> -0.5 for tomcat7, rational being that if we want to do it, we > should > > >>>> (at > > >>>>>> the same time) 1. ensure tomcat module is at least 1-1 (not the > > case I > > >>>>>> think) + released properly and not just a sandbox and 2. drop > jetty > > >>>>>> integration too (which can be envisioned since we worked to > > integrate > > >>>> OWB > > >>>>>> in jetty itself) but dropping tomcat7 module without these two > > >>>> conditions > > >>>>>> looks like an user regression to me. > > >>>>>> > > >>>>> > > >>>>> I would think you should keep "tomcat7" too, it's not really the > same > > >>>> idea > > >>>>> as modules/owb. The main problem is using a version number in the > > >> module > > >>>>> name, that creates confusion in the long run and gives the > impression > > >> it > > >>>> is > > >>>>> outdated. Tomcat 7 will be eoled "soon", for example. > > >>>>> > > >>>>> Rémy > > >>>>> > > >>>>> > > >>>>>> > > >>>>>> I guess ee modules can move to tomee too - any other consumer - > with > > >>>> the > > >>>>>> relevant adaptations to our codebase? > > >>>>>> > > >>>>>> 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 lun. 29 juin 2020 à 13:38, Gurkan Erdogdu < > > >> cgurkanerdo...@gmail.com > > >>>>> > > >>>>> a > > >>>>>> écrit : > > >>>>>> > > >>>>>>> Hi folks > > >>>>>>> I would like to discuss to remove the following modules from the > > OWB > > >>>>> code > > >>>>>>> base. > > >>>>>>> > > >>>>>>> - webbeans-jms : We introduced this module years ago for JMS but > > >>>>>> frankly > > >>>>>>> never see any usage. Also, it was not completed. > > >>>>>>> - webbeans-tomcat7 : We introduced this modules for Tomcat7 > > >>>>>> integration > > >>>>>>> but now it is useless and Tomcat already includes this > integration > > >>>>>> with > > >>>>>>> more natural way ( > > >>>>>>> https://github.com/apache/tomcat/tree/master/modules/owb) > > >>>>>>> > > >>>>>>> WDYT? Any objection? > > >>>>>>> Regards. > > >>>>>>> Gurkan > > >>>>>>> > > >>>>>> > > >>>>> > > >>>> > > >>>> > > >>>> -- > > >>>> Gurkan Erdogdu > > >>>> http://gurkanerdogdu.blogspot.com > > >>>> > > >> > > >> > > > > > -- Gurkan Erdogdu http://gurkanerdogdu.blogspot.com
