|
Re: Providers ordering
I agree. Naturally, user-defined providers should take precedence over built-in ones. Clearly, this statement is implicit rather than explicit and should be clarified —at least for some providers.
I agree. Naturally, user-defined providers should take precedence over built-in ones. Clearly, this statement is implicit rather than explicit and should be clarified —at least for some providers.
|
By
Santiago Pericas-Geertsen
·
#43
·
|
|
Re: Returning CompletionStage from the resource method
Hi Sergey,
ad 1) the response processing will be done on the caller (completer) thread (so, completionStage#whenComplete(..), not #whenCompleteAsync(..)), simply because it works in a
Hi Sergey,
ad 1) the response processing will be done on the caller (completer) thread (so, completionStage#whenComplete(..), not #whenCompleteAsync(..)), simply because it works in a
|
By
Pavel Bucek
·
#42
·
|
|
Re: Built-in proxy support in Client API?
Hi Pavel,
I don't want to hijack the topic, I'm just saying that we can handle both cases in a common way.
Regards
Dennis
Hi Pavel,
I don't want to hijack the topic, I'm just saying that we can handle both cases in a common way.
Regards
Dennis
|
By
Dennis Kieselhorst
·
#41
·
|
|
Re: Built-in proxy support in Client API?
Hi Dennis,
thanks for the pull request; please don't hijack the topic - this one is about client proxy support. Feel free to start a new thread.
Regards,
Pavel
Hi Dennis,
thanks for the pull request; please don't hijack the topic - this one is about client proxy support. Feel free to start a new thread.
Regards,
Pavel
|
By
Pavel Bucek
·
#40
·
|
|
Re: Providers ordering
Hi Christian
Thanks too,
I agree using @Priority is a viable option. But as I implied earlier, this approach (apart from solving the issue shown with MVC vs custom CSRF mapper)
Hi Christian
Thanks too,
I agree using @Priority is a viable option. But as I implied earlier, this approach (apart from solving the issue shown with MVC vs custom CSRF mapper)
|
By
Sergey Beryozkin
·
#39
·
|
|
Re: Providers ordering
Continuing with the idea of the special treatment of the providers shipped with the spec implementations.
Rather than pursue a @DefaultProvider idea, how about treating the providers
Continuing with the idea of the special treatment of the providers shipped with the spec implementations.
Rather than pursue a @DefaultProvider idea, how about treating the providers
|
By
Sergey Beryozkin
·
#38
·
|
|
Re: Providers ordering
Hey Sergey,
thanks for your quick reply.
Yes, exactly. In this case JAX-RS currently doesn't specify which one should be used.
Not sure if something like @DefaultProvider is flexible enough. Maybe
Hey Sergey,
thanks for your quick reply.
Yes, exactly. In this case JAX-RS currently doesn't specify which one should be used.
Not sure if something like @DefaultProvider is flexible enough. Maybe
|
By
Christian Kaltepoth
·
#37
·
|
|
Re: Providers ordering
Hi Christian
Right, do you mean that both of these providers are custom as far as the JAX-RS implementation is concerned ?
Sure, I see what you mean now.
I
Hi Christian
Right, do you mean that both of these providers are custom as far as the JAX-RS implementation is concerned ?
Sure, I see what you mean now.
I
|
By
Sergey Beryozkin
·
#36
·
|
|
Re: Providers ordering
Hi Sergey,
Of course nobody will want to create two ExceptionMapper<MyObject> implementations in his application. It is more about the case that some framework provides a "default" exception mapper
Hi Sergey,
Of course nobody will want to create two ExceptionMapper<MyObject> implementations in his application. It is more about the case that some framework provides a "default" exception mapper
|
By
Christian Kaltepoth
·
#35
·
|
|
Re: Returning CompletionStage from the resource method
Hi Pavel
I'd leave it up to the implementation to decide.
The other thing I was thinking about. On the client side we have RxInvoker which supports not only CompletableFuture. Should we have
Hi Pavel
I'd leave it up to the implementation to decide.
The other thing I was thinking about. On the client side we have RxInvoker which supports not only CompletableFuture. Should we have
|
By
Sergey Beryozkin
·
#34
·
|
|
Re: Providers ordering
Hi Pavel
Not sure it is relevant but it is not exactly the case with MessageBodyReader/Writers where the custom providers can still lose to built-in providers.
By
Hi Pavel
Not sure it is relevant but it is not exactly the case with MessageBodyReader/Writers where the custom providers can still lose to built-in providers.
By
|
By
Sergey Beryozkin
·
#33
·
|
|
Re: Providers ordering
Hey Pavel,
thanks a lot for your quick reply.
Thanks a lot for pointing me to section 4.2.4. But as you already wrote the current version of this statement just covers entity providers.
I would be
Hey Pavel,
thanks a lot for your quick reply.
Thanks a lot for pointing me to section 4.2.4. But as you already wrote the current version of this statement just covers entity providers.
I would be
|
By
Christian Kaltepoth
·
#32
·
|
|
Re: Built-in proxy support in Client API?
Hi,
in my view there should be at least standardized constants for the properties in 2.1. I created a PR for the timeout stuff yesterday: https://github.com/jax-rs/api/pull/555
These properties can
Hi,
in my view there should be at least standardized constants for the properties in 2.1. I created a PR for the timeout stuff yesterday: https://github.com/jax-rs/api/pull/555
These properties can
|
By
Dennis Kieselhorst
·
#31
·
|
|
Re: Providers ordering
Hi,
I was writing to propose exactly that. That's be the more flexible approach, and would resolve my open question about what exactly is a built-in provider
Hi,
I was writing to propose exactly that. That's be the more flexible approach, and would resolve my open question about what exactly is a built-in provider
|
By
Guillermo González de Agüero
·
#30
·
|
|
Re: Providers ordering
Hi Christian,
see chapter 4.2.4:
Which i s the base of what I mentioned - there is one issue though - this is only about entity providers, not about ExceptionMappers, which
Hi Christian,
see chapter 4.2.4:
Which i s the base of what I mentioned - there is one issue though - this is only about entity providers, not about ExceptionMappers, which
|
By
Pavel Bucek
·
#29
·
|
|
Re: Providers ordering
Hi everyone,
I'm very happy to see that the issue of provider ordering is addressed in the upcoming JAX-RS release. Thanks a lot for your work on that.
I would like to point the EG to a discussion
Hi everyone,
I'm very happy to see that the issue of provider ordering is addressed in the upcoming JAX-RS release. Thanks a lot for your work on that.
I would like to point the EG to a discussion
|
By
Christian Kaltepoth
·
#28
·
|
|
Built-in proxy support in Client API?
Hi all,
It might be too late to add this (if so, no worries), but I've been running into a few customer situations where customers are using HTTP/HTTPS proxy servers with their JAX-RS client APIs.
Hi all,
It might be too late to add this (if so, no worries), but I've been running into a few customer situations where customers are using HTTP/HTTPS proxy servers with their JAX-RS client APIs.
|
By
Andy McCright
·
#27
·
|
|
Re: Providers ordering
Hi,
Have you considered how this will behave when the provider is a CDI @Alternative or @Stereotype?
I'm unsure how much those could interfere but I think it's something to take into account
Hi,
Have you considered how this will behave when the provider is a CDI @Alternative or @Stereotype?
I'm unsure how much those could interfere but I think it's something to take into account
|
By
Guillermo González de Agüero
·
#26
·
|
|
Returning CompletionStage from the resource method
Dear experts,
as we already stated, we'd like to support returning CompletionStage from the resource mehod, corresponding spec issue is here:
https://github.com/jax-rs/api/issues/551
The only open
Dear experts,
as we already stated, we'd like to support returning CompletionStage from the resource mehod, corresponding spec issue is here:
https://github.com/jax-rs/api/issues/551
The only open
|
By
Pavel Bucek
·
#25
·
|
|
Providers ordering
Dear experts,
there is couple of filed issues related to provider ordering, namely:
https://github.com/jax-rs/api/issues/538
https://github.com/jax-rs/api/issues/537
We
Dear experts,
there is couple of filed issues related to provider ordering, namely:
https://github.com/jax-rs/api/issues/538
https://github.com/jax-rs/api/issues/537
We
|
By
Pavel Bucek
·
#24
·
|