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