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