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-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 > -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
