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-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 >
