Hi,
Does that rely on the existing form of @Priority or changes (also driven by
CDI 2) recently made in JSR 250 (MR ballot just closed) ?
Cheers,
Werner
On Wed, Jul 27, 2016 at 11:15 AM, <users-request_at_jax-rs-spec.java.net>
wrote:
> Table of contents:
>
> 1. [jax-rs-spec users] Early draft 2.1 API for Central - Sergey Beryozkin <
> sberyozkin_at_talend.com>
> 2. [jax-rs-spec users] Re: Exception mapper ambiguity - Sebastian Daschner
> <java_at_sebastian-daschner.de>
> 3. [jax-rs-spec users] Re: Exception mapper ambiguity - Christian
> Kaltepoth <christian_at_kaltepoth.de>
>
>
>
> ---------- Forwarded message ----------
> From: Sergey Beryozkin <sberyozkin_at_talend.com>
> To: Marek Potociar <marek.potociar_at_oracle.com>, Santiago Pericasgeertsen <
> santiago.pericasgeertsen_at_oracle.com>, <jsr370-experts_at_jax-rs-spec.java.net
> >
> Cc:
> Date: Tue, 26 Jul 2016 15:33:26 +0300
> Subject: [jax-rs-spec users] Early draft 2.1 API for Central
> Hi Marek, Santiago
>
> Hope you are doing well.
>
> We'd like in CXF to start merging our JAX-RS 2.1 branch to the main CXF
> 3.2.0-SNAPSHOT.
>
> My colleague had implemented SSE (server only so far) but it is a start
> and interesting, today, we've had a user
> asking for this SSE code.
>
> For us to merge the branch code to the CXF master an early draft
> non-SNAPSHOT 2.1 API would need to be available
> in Central. This is so that we can release CXF 3.2.0 eventually, knowing
> that we do not have SNAPSHOT deps.
> It will also help us to go ahead and implement the NIO experiment and
> CompletableFuture client code directly on the master.
>
> Marek, can you please support it and do the very first API release ? (add
> some qualifier like early_draft, etc, to make it obvious that
> it is far from being complete) ?
>
> a demand for JAX-RS is still very strong. If CXF manages to ship an early
> draft implementation, alongside with RI, it would be easier for
> the community at large to continue working toward 2.1 being eventually
> completed. Depending on how things go I might consider submitting
> a talk to JaveOne to raise the awareness of JAX-RS being implemented in
> ASF.
>
> Many thanks, Sergey
>
>
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Sebastian Daschner <java_at_sebastian-daschner.de>
> To: users_at_jax-rs-spec.java.net
> Cc:
> Date: Tue, 26 Jul 2016 18:06:33 +0200
> Subject: [jax-rs-spec users] Re: Exception mapper ambiguity
>
> Hi Christian,
>
> Sorry for the late response.
>
> +1 for being able to specify the exception mappers via @Priority. But if
> we add this feature I think we should at least think of other potential
> candidates for ordering / selecting as well such as
> Reader/WriterInterceptors or MessageBodyReaders/Writers. WDYT?
>
> Cheers,
> Sebastian
> On 07/18/2016 09:06 AM, Christian Kaltepoth wrote:
>
> Hey all,
>
> I just stumbled upon a minor inaccuracy in the specification. The matching
> algorithm of an exception to an exception mapper is defined like this:
>
> When choosing an exception mapping provider to map an exception, an
>> implementation MUST use the provider whose generic type is the nearest
>> superclass of the exception.
>
>
> That's all. So the spec currently does not define which mapper is selected
> if there are multiple ones for the same exception type. This is problematic
> if there are multiple ones provided by the JAX-RS implementation, 3rd party
> libraries or by the application itself.
>
> This could be fixed if the JAX-RS specifies that in these cases the
> @Priority annotation can be used to order the mappers. I think this
> pattern is widely adopted in Java EE. We also use @Priority for ordering
> SPIs in MVC 1.0.
>
> Thoughts?
>
> Christian
>
>
> --
> Christian Kaltepoth
> Blog: http://blog.kaltepoth.de/
> Twitter: http://twitter.com/chkal
> GitHub: https://github.com/chkal
>
>
>
>
> ---------- Forwarded message ----------
> From: Christian Kaltepoth <christian_at_kaltepoth.de>
> To: users_at_jax-rs-spec.java.net
> Cc:
> Date: Wed, 27 Jul 2016 06:39:22 +0200
> Subject: [jax-rs-spec users] Re: Exception mapper ambiguity
> Hi Sebastian,
>
> thanks for your response. I agree that there are other candidates which
> need support for ordering. I ran into such ambiguity issues with
> ExceptionMapper and ParamConverterProvider. The fact that ambiguity is
> not handled at all for these extension points is currently blocking
> progress for some features in JSR 371. So it would be great if JAX-RS
> could improve the selection algorithm for these to support some kind of
> ordering. And I think @Priority would be a perfect fit.
>
> As far as I know Reader/WriterInterceptors already support ordering via
> @Priority. See section 6.6 of the spec. Not sure about MessageBodyReaders/Writers
> to be honest.
>
> Christian
>
>
>
> 2016-07-26 18:06 GMT+02:00 Sebastian Daschner <java_at_sebastian-daschner.de>
> :
>
>> Hi Christian,
>>
>> Sorry for the late response.
>>
>> +1 for being able to specify the exception mappers via @Priority. But if
>> we add this feature I think we should at least think of other potential
>> candidates for ordering / selecting as well such as
>> Reader/WriterInterceptors or MessageBodyReaders/Writers. WDYT?
>>
>> Cheers,
>> Sebastian
>> On 07/18/2016 09:06 AM, Christian Kaltepoth wrote:
>>
>> Hey all,
>>
>> I just stumbled upon a minor inaccuracy in the specification. The
>> matching algorithm of an exception to an exception mapper is defined like
>> this:
>>
>> When choosing an exception mapping provider to map an exception, an
>>> implementation MUST use the provider whose generic type is the nearest
>>> superclass of the exception.
>>
>>
>> That's all. So the spec currently does not define which mapper is
>> selected if there are multiple ones for the same exception type. This is
>> problematic if there are multiple ones provided by the JAX-RS
>> implementation, 3rd party libraries or by the application itself.
>>
>> This could be fixed if the JAX-RS specifies that in these cases the
>> @Priority annotation can be used to order the mappers. I think this
>> pattern is widely adopted in Java EE. We also use @Priority for ordering
>> SPIs in MVC 1.0.
>>
>> Thoughts?
>>
>> Christian
>>
>>
>> --
>> Christian Kaltepoth
>> Blog: http://blog.kaltepoth.de/
>> Twitter: http://twitter.com/chkal
>> GitHub: https://github.com/chkal
>>
>>
>>
>
>
> --
> Christian Kaltepoth
> Blog: http://blog.kaltepoth.de/
> Twitter: http://twitter.com/chkal
> GitHub: https://github.com/chkal
>
>
> End of digest for list users_at_jax-rs-spec.java.net - Wed, 27 Jul 2016
>
>