Hi Thought to James proposal as well but the idea being more at interceptor level. You write a custom interceptor mapping your config to impls. If CXF does anything it will need user code anyway so not sure it does make sense to provide this abstraction hard to test properly in cxf code itself. Hiwever can be interesting to make it rely on CompletionStage if your config is read remotely and move interceptorchain to a reactive approach if not too costly.
Hope it makes sense Le sam. 6 avr. 2019 à 00:14, Andrei Shakirin <[email protected]> a écrit : > Hi James, > > There are some reasons: > - it will be possible to reuse a bunch of standard CXF filters like Jose > JwsSignatureProvider, JwsSignatureVerifier, KeyEncryptionProvider, > KeyDecryptionProvider, etc > - filters will be sorted by priority in correct order > - necessary context injection will be fulfilled > - service pre-match and post-match filters will be executed in right moment > > Regards, > Andrei. > > > -----Original Message----- > > From: James Carman [mailto:[email protected]] > > Sent: Freitag, 5. April 2019 18:51 > > To: [email protected] > > Subject: Re: Dynamic JAX-RS filters (per request/response) > > > > Why not just have one ContainerRequestFilter that determines what to do > > dynamically and just does it? This way, you don't have to do the > interceptor > > chain gymnastics. > > > > On Fri, Apr 5, 2019 at 12:02 PM Andrei Shakirin <[email protected]> > > wrote: > > > > > > Hi Andriy, > > > > > > DynamicFeature is still too static for these requirement: I would like > to have > > an option to configure interceptors per request/response basis. > > > Regarding the risk: my intention is only to open the option for the > user to > > configure such dynamic filters (for example through message property). > > > Instantiation, configuration, communication with external repo will be > > customer specific code and stays outside the CXF. > > > > > > In other words, filter controlling interceptors (JAXRSInInterceptor, > > JAXRSOutInterceptor, ClientRequestFilterInterceptor, > > ClientResponseFilterInterceptor) will just check if any dynamic filters > are > > configured in the message and, if yes: add, resort and execute them > together > > with static once from ClientProviderFactory and ServerProviderFactory. > > > > > > I do not see any impacts on performance / memory or traceability in > this > > case: we just provide one more option for the user. > > > > > > Regards, > > > Andrei. > > > > > > > -----Original Message----- > > > > From: Andriy Redko [mailto:[email protected]] > > > > Sent: Freitag, 5. April 2019 02:02 > > > > To: Andrei Shakirin; [email protected] > > > > Subject: Re: Dynamic JAX-RS filters (per request/response) > > > > > > > > Hi Andrei, > > > > > > > > Understood, thank you for explanation. I am wondering if JAX-RS's > > > > DynamicFeature may cover some of these use cases? (although it is > > > > not per request but per resource). In general, I personally see the > > > > following risks / > > > > issues: > > > > - performance degradation: the need to recreate the filter chains > > > > for each request (potentially, worst case scenario)may significantly > > > > impact the response times (especially if the external central > > > > repository has to be contacted) > > > > - memory pressure: recreating the filter chains for each request > > > > (again, just worst case scenario) would fill up the heap quickly, > > > > particularly under high server load > > > > - traceability: the presence of the dynamic filter chains means > > > > each message would get special treatment, even two identical calls > > > > may have different outcomes, potentially, how one would understand > why > > and nail the cause? > > > > - what about async flows? should the decision regarding the dynamic > > > > response filter chain be taken at request time or at response time? > > > > more contextual details should be passed along? > > > > > > > > To be fair, I am not sure if such a flexibility is worth the risks. > > > > But in any case, I believe the flow which is used by 99% of the > > > > users should not be impacted anyhow. Hope it makes sense, what do you > > think? > > > > > > > > Thanks! > > > > > > > > Best Regards, > > > > Andriy Redko > > > > > > > > AS> Hi Andriy, > > > > > > > > AS> Yes, kind of. The service must proceed parallel requests from > > > > AS> different > > > > clients having own security requirements: > > > > AS> - activated/deactivated JWT authentication > > > > AS> - JWS > > > > AS> - JWE > > > > AS> - authorization > > > > > > > > AS> The security requirements are controlled dynamically through the > > > > AS> central > > > > repository and are obtained on runtime by client and services. > > > > AS> It will be useful for such use case to control filters chain > > > > AS> dynamically per > > > > request base, in the same way as SOAP interceptors. > > > > > > > > AS> Regards, > > > > AS> Andrei. > > > > > > > > >> -----Original Message----- > > > > >> From: Andriy Redko [mailto:[email protected]] > > > > >> Sent: Mittwoch, 3. April 2019 23:28 > > > > >> To: Andrei Shakirin; [email protected] > > > > >> Subject: Re: Dynamic JAX-RS filters (per request/response) > > > > > > > > >> Hi Andrei, > > > > > > > > >> I would be curious to understand a bit regarding the use case(s). > > > > >> Is it going to be driven by presence of some headers fe? Or > > > > >> something else? Like f.e. each message is inspected, and > > > > >> depending on some criteria, the different filter chains are being > > > > >> constructed? Could you share a > > > > couple of examples? > > > > > > > > >> Thank you. > > > > > > > > >> Best Regards, > > > > >> Andriy Redko > > > > > > > > >> AS> Hi, > > > > > > > > >> AS> Currently JAX-RS filters are bound to exchange endpoint in > > > > >> AS> ClientProviderFactory and ServerProviderFactory and filter > > > > >> AS> chain is always > > > > >> the same for all processing messages. > > > > >> AS> In some use cases (security) it would be useful to activate > > > > >> AS> filters > > > > >> dynamically on message level, that different requests could have > > > > >> own filter chains. > > > > > > > > >> AS> I am going to extend JAXRSInInterceptor, JAXRSOutInterceptor, > > > > >> AS> ClientRequestFilterInterceptor and > > > > >> AS> ClientResponseFilterInterceptor with > > > > >> option to add and execute filters dynamically, additionally to > > > > >> ClientProviderFactory and ServerProviderFactory. > > > > > > > > >> AS> Any objections, thoughts regarding that? > > > > > > > > >> AS> Regards, > > > > >> AS> Andrei. > > > > >> AS> As a recipient of an email from Talend, your contact personal > > > > >> AS> data will be on our systems. Please see our contacts privacy > > > > >> AS> notice at Talend, Inc. > > > > >> AS> <https://www.talend.com/contacts-privacy-policy/> > > > > > > > > > > > > > > > >
