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:ja...@carmanconsulting.com] > Sent: Freitag, 5. April 2019 18:51 > To: dev@cxf.apache.org > 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 <ashaki...@talend.com> > 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:drr...@gmail.com] > > > Sent: Freitag, 5. April 2019 02:02 > > > To: Andrei Shakirin; dev@cxf.apache.org > > > 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:drr...@gmail.com] > > > >> Sent: Mittwoch, 3. April 2019 23:28 > > > >> To: Andrei Shakirin; dev@cxf.apache.org > > > >> 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/> > > > > > > > > > > >
