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-6aaf055d932f602b0 >> 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-perfo >> 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-perfo >> 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-5edc34da45232dc12 >> a96cae52e620adcR22 >>>>>>>>>>>>>>> [3] >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>> >>> >> https://github.com/apache/karaf/pull/993/files#diff-412d137df581cff19 >> 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-perfo >> 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
