It makes sense. +1 with the plan. Regards JB
On 12/11/2019 06:30, Romain Manni-Bucau wrote: > Ok so let's: > > 1. Finish the PoC > 2. Review the API (and impl but rhis part can evolve faster ;)) > 3. Validate where we put it and move forward with integrations :) > > Le mar. 12 nov. 2019 à 06:14, Jean-Baptiste Onofré <j...@nanthrax.net> a > écrit : > >> It depends of the scope. I don't mind to start in Karaf and move to >> Karaf IoC later. Up to you. >> >> Regards >> JB >> >> On 11/11/2019 20:49, Romain Manni-Bucau wrote: >>> Guess it is true for all project and I assume "submodule" means >>> "subproject" right? >>> Not sure what it means in practise (new git?) but it is not shocking. Any >>> proposal karaf-ioc (we could add more feature later this way)? Is it what >>> you meant? >>> >>> 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. 11 nov. 2019 à 20:45, Christian Schneider < >> ch...@die-schneider.net> >>> a écrit : >>> >>>> Great to hear that you already considered aspecio. >>>> If we want to put this into apache then I rather would suggest Apache >>>> Felix, Apache Aries or a Karaf submodule. >>>> The interceptor support is a small standalone module that should have >> its >>>> own lifecycle. >>>> Putting it in the main karaf tree would mean it is released for every >> karaf >>>> version. >>>> >>>> Christian >>>> >>>> Am Mo., 11. Nov. 2019 um 20:38 Uhr schrieb Romain Manni-Bucau < >>>> rmannibu...@gmail.com>: >>>> >>>>> @Christian yes and no. Ray pointed out aspecio to me but I had a few >>>> issues >>>>> with it: >>>>> >>>>> 1. it brings its own stack - and yes I care about each single dep my >> app >>>>> brings cause, a) network usage the size can implies with modern >>>>> deployments, b) security vulnerabilities the stack can hide. >>>>> 2. it is not at asf or asf influenced (as part of codehaus projects had >>>>> been in early times for exapple) with all it implies in terms of >>>> governance >>>>> and legal quality. >>>>> 3. the API is reinvented compared to the final step of my proposal >> which >>>>> would be aligned on the standard. Current version of code is almost >>>> aligned >>>>> on interceptor API (you just sed the package for the mainstream usage) >>>> but >>>>> the consumer side is a bit different, I must refine it to be closer to >>>> CDI >>>>> but it is just a matter of handling RUNTIME interceptor annotations and >>>>> just using @Interceptors as a component property type of type boolean >> and >>>>> not a value holder which breaks interceptor simplicity. >>>>> 4. it is a one guy github project (even if code quality is not bad) so >>>> not >>>>> something you can reliably use in a professional project (<joke>we >> don't >>>>> code in javascript ;)</joke>) >>>>> 5. no commit since > 1 year? >>>>> >>>>> Hope it clarifies a bit how I ended up on that proposal. >>>>> >>>>> 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. 11 nov. 2019 à 20:22, Jean-Baptiste Onofré <j...@nanthrax.net> a >>>>> écrit : >>>>> >>>>>> Hi Romain, >>>>>> >>>>>> that sounds great to me ! Thanks for that. >>>>>> >>>>>> First, you did well in terms of modules organization: it makes sense >> to >>>>>> have interceptor in service (like staticcm). >>>>>> >>>>>> About the use case, it makes sense as well. I will take a deeper look >>>>> soon. >>>>>> >>>>>> Thanks again ! >>>>>> Regards >>>>>> JB >>>>>> >>>>>> >>>>>> On 11/11/2019 19:37, Romain Manni-Bucau wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I took some time this week-end to draft an interceptor module in >>>> Karaf. >>>>>>> I tried to describe it in the related PR ([1]) - in WIP mode so don't >>>>>> jump >>>>>>> on me yet cause tests are not there please ;). >>>>>>> >>>>>>> High level, I missed a lot interceptors (from javax.) when starting >>>> to >>>>>> use >>>>>>> SCR. >>>>>>> It mainly change the way to add transversal features (metrics, >>>>> security, >>>>>>> tracing, circuit-breaker, asynchronism to cite a few). >>>>>>> >>>>>>> I still have some API refinement to do but high level it would >>>> enable a >>>>>>> service to be marked as intercepted ([2]) and implement interceptors >>>>> "as >>>>>>> usual" ([3]) and link them with a marker (in the PoC it is an >>>>>> annotation). >>>>>>> >>>>>>> It is in very early stages but before investing way more time, I'd >>>> like >>>>>> to >>>>>>> know if it sounds like a module Karaf could host and would benefit >>>> more >>>>>>> than me or if it is an "EE guy" idea ;). >>>>>>> >>>>>>> Wdyt? >>>>>>> >>>>>>> [1] https://github.com/apache/karaf/pull/993 >>>>>>> [2] >>>>>>> >>>>>> >>>>> >>>> >> https://github.com/apache/karaf/pull/993/files#diff-5edc34da45232dc12a96cae52e620adcR22 >>>>>>> [3] >>>>>>> >>>>>> >>>>> >>>> >> https://github.com/apache/karaf/pull/993/files#diff-412d137df581cff1938e723692a1ec45R24 >>>>>>> >>>>>>> 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 >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Jean-Baptiste Onofré >>>>>> jbono...@apache.org >>>>>> http://blog.nanthrax.net >>>>>> Talend - http://www.talend.com >>>>>> >>>>> >>>> >>>> >>>> -- >>>> -- >>>> Christian Schneider >>>> http://www.liquid-reality.de >>>> >>>> Computer Scientist >>>> http://www.adobe.com >>>> >>> >> >> -- >> Jean-Baptiste Onofré >> jbono...@apache.org >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> > -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
