We can use a fancy name too ;) Karaf Secateur ? ;)
Regards JB On 14/11/2019 13:05, Christian Schneider wrote: > 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-6aaf055d932f602b06135e6446ee6c2eR15 >>>>>>>> >>>>>>>> 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. 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-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 >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> -- >>>>>>> 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
