users@jax-rs-spec.java.net

[jax-rs-spec users] Re: Digest for list users_at_jax-rs-spec.java.net

From: Werner Keil <werner.keil_at_gmail.com>
Date: Mon, 25 Jul 2016 11:36:30 +0200

Partly because most of the MVC committers not only Spec Leads were drawn
fom JAX-RS I suspect.

About microprofile.io it remains to be seen what Oracle really does about
Java EE 8 as announced recently. If Java EE 8 gets more than the 2 profiles
it has right now, then I'd say it would have reached its primary goal :-)
There are certainly things to do there, proof of concept or real life demo
cases we already see, but unless Oracle was to give up Java EE I don't see
any actual profile to be defined or specified there.

Since java.net and kenai.com are going away, maybe Adam Bien might also
rescue his Java EE patterns https://kenai.com/projects/javaee-patterns from
Kenai to e.g. microprofile.io, so backed by the obvious GitHub it's
certainly a good replacement for things done on java.net or kenai.com
earlier.

Of course you're right, and we saw that in other JSRs like the soon
withdrawn 351 (Identity Management) or seemingly more important 375
(Security) that although IBM, Red Hat or Tomitribe (who did start in a
rather helpful way) are involved there as well, it's only up to a few
"small" members like Arjan, Ivar or myself to keep JSR 375 alive.

And e.g. one of the companies that pushed microservice.io Paraya does not
even seem to be in the JCP at the moment. So it seems to be taking out of
Glassfish without contributing back to the underlying standards as of now;-|
Correct me if I'm wrong but after JSR 364 went live I assume the member
directory should be rather up to date now.

Werner


On Mon, Jul 25, 2016 at 11:15 AM, <users-request_at_jax-rs-spec.java.net>
wrote:

> Table of contents:
>
> 1. [jax-rs-spec users] Re: Exception mapper ambiguity - Christian
> Kaltepoth <christian_at_kaltepoth.de>
>
>
>
> ---------- Forwarded message ----------
> From: Christian Kaltepoth <christian_at_kaltepoth.de>
> To: users_at_jax-rs-spec.java.net
> Cc:
> Date: Mon, 25 Jul 2016 08:08:57 +0200
> Subject: [jax-rs-spec users] Re: Exception mapper ambiguity
> I'm very disappointed that it doesn't seem to be possible to start any
> discussions on this mailing list. It is very frustrating for the community
> that most feedback is simply ignored.
>
> I know that most people blame Oracle for the lack of progress. But I also
> don't see reactions from IBM, Red Hat or any other EG member. I don't
> understand this. JAX-RS is so important for the Java EE ecosystem. It will
> even be a core part of microprofile.io. So why the hell is any feedback
> simply ignored?
>
> Christian
>
> 2016-07-18 9:06 GMT+02:00 Christian Kaltepoth <christian_at_kaltepoth.de>:
>
>> 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 - Mon, 25 Jul 2016
>
>