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 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 central > repository and are obtained on runtime by client and services. > AS> It will be useful for such use case to control filters chain 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 chain > >> AS> 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/> > > >
