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:[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 chain is
>> always
>> the same for all processing messages.
>> AS> In some use cases (security) it would be useful to activate filters
>> dynamically on message level, that different requests could have own filter
>> chains.
>> AS> I am going to extend JAXRSInInterceptor, JAXRSOutInterceptor,
>> AS> ClientRequestFilterInterceptor and 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 data
>> AS> will be on our systems. Please see our contacts privacy notice at
>> AS> Talend, Inc. <https://www.talend.com/contacts-privacy-policy/>
