Hi Werner,
No, I don't think so. In case of JAX-RS only @Priority on class level is
required. So the current @Priority annotation should be sufficient.
Christian
2016-07-27 11:35 GMT+02:00 Werner Keil <werner.keil_at_gmail.com>:
> 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
>>
>>
>
--
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal