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
