It depends of the scope. I don't mind to start in Karaf and move to Karaf IoC later. Up to you.
Regards JB On 11/11/2019 20:49, Romain Manni-Bucau wrote: > Guess it is true for all project and I assume "submodule" means > "subproject" right? > Not sure what it means in practise (new git?) but it is not shocking. Any > proposal karaf-ioc (we could add more feature later this way)? Is it what > you meant? > > 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:45, Christian Schneider <[email protected]> > a écrit : > >> 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. >> 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 < >> [email protected]>: >> >>> @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é <[email protected]> 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é >>>> [email protected] >>>> http://blog.nanthrax.net >>>> Talend - http://www.talend.com >>>> >>> >> >> >> -- >> -- >> Christian Schneider >> http://www.liquid-reality.de >> >> Computer Scientist >> http://www.adobe.com >> > -- Jean-Baptiste Onofré [email protected] http://blog.nanthrax.net Talend - http://www.talend.com
