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