It sounds good to me ;) Regards JB
On 14/11/2019 15:53, Loven, Hans CTR (FAA) wrote: > "Karaf Greffer" to keep with the plant theme? > > H > > -----Original Message----- > From: Jean-Baptiste Onofré <j...@nanthrax.net> > Sent: Thursday, November 14, 2019 8:50 AM > To: dev@karaf.apache.org > Subject: Re: [PR/DISCUSS] Interceptor module? > > Good point ;) And I agree. > > Let's find another name ;) > > Regards > JB > > On 14/11/2019 15:46, Loven, Hans CTR (FAA) wrote: >> Respectfully, >> >> Karaf Secateur _sounds_ like a great name for something, but I think it is >> contrary to what this does. Secateurs are pruning shears. Unless I have >> missed something, this project adds annotation-based interceptor capability. >> That seems the opposite of pruning, imho. >> >> >> Cheers, >> Hans >> >> -----Original Message----- >> From: Jean-Baptiste Onofré <j...@nanthrax.net> >> Sent: Thursday, November 14, 2019 6:38 AM >> To: dev@karaf.apache.org >> Subject: Re: [PR/DISCUSS] Interceptor module? >> >> I think we have two options: >> >> 1. Explicit name: Karaf IoC >> 2. Fancy name: Karaf Secateur >> >> Either way is fine for me ;) >> >> Regards >> JB >> >> On 14/11/2019 13:32, Christian Schneider wrote: >>> In that case I am fine with the ioc name. >>> >>> Christian >>> >>> Am Do., 14. Nov. 2019 um 13:17 Uhr schrieb Romain Manni-Bucau < >>> rmannibu...@gmail.com>: >>> >>>> Im fine whatever works the most. >>>> >>>> Ioc proposal comes from the hope to fill the gap between spring/CDI >>>> and OSGi ecosystem without going directly to osgi-cdi which has some >>>> pitfalls for cdi guys. >>>> Interceptors were just the first step but it can be more after so >>>> having interceptor in the name sounded limited to me. >>>> Hope it clarifies where Im coming from. >>>> >>>> Le jeu. 14 nov. 2019 à 13:05, Christian Schneider >>>> <ch...@die-schneider.net >>>>> >>>> a écrit : >>>> >>>>> Sounds good .. for the name I propose karaf-interceptor. >>>>> The name karaf-ioc ( I guess it should mean inversion of control) >>>>> does >>>> not >>>>> seem to match well what it does. >>>>> >>>>> Christian >>>>> >>>>> Am Do., 14. Nov. 2019 um 12:51 Uhr schrieb Jean-Baptiste Onofré < >>>>> j...@nanthrax.net>: >>>>> >>>>>> Agree, my point is that technically possible. >>>>>> >>>>>> And also agree to create a karaf-ioc repo (it takes me 2 minutes ;)). >>>>>> >>>>>> We can start a formal vote about that. Let's just wait Romain's >>>> feedback. >>>>>> >>>>>> Regards >>>>>> JB >>>>>> >>>>>> On 14/11/2019 12:44, Christian Schneider wrote: >>>>>>> Of course it technically works but it would be the only case in >>>>>>> the >>>>> karaf >>>>>>> main repo. It would confuse people a lot. I think we should not >>>>>>> start >>>>>> this. >>>>>>> Creating a new karaf repo is no big issue. >>>>>>> >>>>>>> Christian >>>>>>> >>>>>>> Am Do., 14. Nov. 2019 um 11:54 Uhr schrieb Jean-Baptiste Onofré < >>>>>>> j...@nanthrax.net>: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> It can be released in its own cycle in the main repo. >>>>>>>> >>>>>>>> For instance, ServiceMix Bundles are on an unique git repo, but >>>>>>>> I do release of each independently from the others. >>>>>>>> >>>>>>>> I think we can start like this. >>>>>>>> >>>>>>>> Regards >>>>>>>> JB >>>>>>>> >>>>>>>> On 14/11/2019 11:09, Christian Schneider wrote: >>>>>>>>> The fact that it evolves a lot at the start is even another >>>> argument >>>>> to >>>>>>>>> keep it out of the karaf main repo as there you can only >>>>>>>>> release >>>>>> together >>>>>>>>> with karaf. >>>>>>>>> >>>>>>>>> I think in the end it is your decision - either a new karaf >>>>>>>>> repo (I >>>>> can >>>>>>>>> create it for you) or a new aries repo (again I can create it) >>>>>>>>> or >>>> the >>>>>>>> aries >>>>>>>>> main repo. So all options should be pretty quick to do. >>>>>>>>> (Of course if you decide for aries we need an approval from the >>>>>>>>> pmc >>>>> of >>>>>>>>> aries but I guess that is rather a formality as most are also >>>>>>>>> in >>>> this >>>>>>>> list >>>>>>>>> and would have objected if they did not want it at aries). >>>>>>>>> >>>>>>>>> Christian >>>>>>>>> >>>>>>>>> Am Mi., 13. Nov. 2019 um 09:39 Uhr schrieb Romain Manni-Bucau < >>>>>>>>> rmannibu...@gmail.com>: >>>>>>>>> >>>>>>>>>> I kind of share the fact code will likely be stable - that >>>>>>>>>> said, >>>>>>>> depending >>>>>>>>>> the adoption it can evolve quite a lot for ~1 year I think >>>>>>>>>> (adding >>>>>>>> method >>>>>>>>>> binding support is the one I have in mind if the module works >>>> great >>>>>>>> without >>>>>>>>>> this feature). >>>>>>>>>> Where I'm a bit less "easy" is cause karaf has jms, jpa, jdbc >>>>>>>>>> etc >>>>>>>> modules >>>>>>>>>> so it sounds it is on the same plan to me, no? >>>>>>>>>> That said, once again any home will be fine for me while it >>>>>>>>>> exists >>>>> ;) >>>>>>>>>> >>>>>>>>>> Le mer. 13 nov. 2019 à 09:29, Christian Schneider < >>>>>>>> ch...@die-schneider.net >>>>>>>>>>> >>>>>>>>>> a écrit : >>>>>>>>>> >>>>>>>>>>> I would not put the new code into an existing Aries subproject. >>>>>> Instead >>>>>>>>>> we >>>>>>>>>>> could add a new one. >>>>>>>>>>> Either in its own git repo or in the shared one (depends on >>>>>>>>>>> how >>>> we >>>>>> want >>>>>>>>>> to >>>>>>>>>>> release). >>>>>>>>>>> >>>>>>>>>>> @Romain .. do you plan to version by bundle or the whole >>>>> interceptor >>>>>>>>>>> subproject? >>>>>>>>>>> If you plan to release by bundle then the aries main git >>>>>>>>>>> would >>>> be a >>>>>>>> great >>>>>>>>>>> fit as the modules there are released in the same fashion. >>>>>>>>>>> If you plan to always release the whole interceptor tree then >>>>>>>>>>> a >>>> new >>>>>> git >>>>>>>>>>> repo in aries or karaf would work great. >>>>>>>>>>> >>>>>>>>>>> The karaf main repo would be a bad choice as I think the >>>>> interceptor >>>>>>>> code >>>>>>>>>>> will be quite stable after some time while karaf will always >>>>>>>>>>> be >>>>>>>> changing. >>>>>>>>>>> >>>>>>>>>>> Christian >>>>>>>>>>> >>>>>>>>>>> Am Di., 12. Nov. 2019 um 11:23 Uhr schrieb Romain Manni-Bucau >>>>>>>>>>> < >>>>>>>>>>> rmannibu...@gmail.com>: >>>>>>>>>>> >>>>>>>>>>>> Updated the code, last changes are mainly: >>>>>>>>>>>> >>>>>>>>>>>> 1. moving the module in the right parent (I put it in >>>>>>>>>>>> service >>>>>> instead >>>>>>>>>> of >>>>>>>>>>>> service*s* originally) >>>>>>>>>>>> 2. added an E2E test using pax-exam 3. make it work :) >>>>>>>>>>>> >>>>>>>>>>>> I added a doc page ([1]) to try to share more what it tries >>>>>>>>>>>> to >>>>>>>> achieve. >>>>>>>>>>>> >>>>>>>>>>>> About aries, the proxy module looks almost 100% bound to >>>> blueprint >>>>>> so >>>>>>>>>>>> didn't see it as an option but I don't have a really strong >>>>> blocker >>>>>>>>>>> there, >>>>>>>>>>>> I'll fully trust the OSGi@apache community on that. >>>>>>>>>>>> >>>>>>>>>>>> [1] >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> https://github.com/apache/karaf/pull/993/files#diff-6aaf055d932f602b >>>> 0 >>>> 6135e6446ee6c2eR15 >>>>>>>>>>>> >>>>>>>>>>>> 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-perf >>>> o >>>> rmance >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Le mar. 12 nov. 2019 à 08:15, Grzegorz Grzybek < >>>>>> gr.grzy...@gmail.com> >>>>>>>>>> a >>>>>>>>>>>> écrit : >>>>>>>>>>>> >>>>>>>>>>>>> Hello >>>>>>>>>>>>> >>>>>>>>>>>>> pon., 11 lis 2019 o 20:45 Christian Schneider < >>>>>>>>>> ch...@die-schneider.net >>>>>>>>>>>> >>>>>>>>>>>>> napisał(a): >>>>>>>>>>>>> >>>>>>>>>>>>>> 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. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, IMO it'd fit more into Apache Aries Proxy. >>>>>>>>>>>>> >>>>>>>>>>>>> regards >>>>>>>>>>>>> Grzegorz Grzybek >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> 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-perf >>>> o >>>> rmance >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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-5edc34da45232dc1 >>>> 2 >>>> a96cae52e620adcR22 >>>>>>>>>>>>>>>>> [3] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> https://github.com/apache/karaf/pull/993/files#diff-412d137df581cff1 >>>> 9 >>>> 38e723692a1ec45R24 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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-perf >>>> o >>>> rmance >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> -- >>>>>>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> -- >>>>> -- >>>>> 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 > -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
