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 > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
