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