Not sure, if we can reply to this mailing list, but I'll try.
For JAX-RS 2.x and JavaEE 8 stay tuned, there should certainly be a new JSR
for Identity Management touching authentication and SSO also with other
JSRs like this one.
So there will be more generic Auth-Header support in JavaEE very soon.
--
Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead, Babel
Language Champion | Java Godfather
Twitter @wernerkeil | @JSR354 | #Java_Social | #EclipseUOMo | #OpenDDR
Skype werner.keil | Google+ gplus.to/wernerkeil
* Eclipse Stammtisch: May 15 2013, Zurich, Switzerland. Werner Keil, UOMo
Lead, JSR 360 EG Member will present "M4M 2 the Rescue of M2M"
* GeeCON: May 16-17 2013, Krakow, Poland. Werner Keil, JCP Executive
Committee Member, JSR 360 EG Member will present "Standards for the Future
of Java Embedded"
* GR8Conf Hackergarten: May 22 2013, Copenhagen, Denmark. Werner Keil, JCP
EC Member, JSR 354 EG Member will present "Groovy/Grails - Best way
for Money using JSR 354"
On Thu, May 2, 2013 at 11:15 AM, <users-request_at_jax-rs-spec.java.net> wrote:
> Table of contents:
>
> 1. [jax-rs-spec users] [jsr339-experts] Re: The origin of
> MessageBodyWriter - when to check - Sergey Beryozkin <
> sberyozkin_at_talend.com>
> 2. [jax-rs-spec users] [jsr339-experts] Why is there no generic
> Auth-Header support in JAX-RS? - Jan Algermissen <
> jan.algermissen_at_nordsc.com>
> 3. [jax-rs-spec users] Re: [jsr339-experts] Why is there no generic
> Auth-Header support in JAX-RS? - Reto Bachmann-Gmür <reto_at_gmuer.ch>
>
>
>
> ---------- Forwarded message ----------
> From: Sergey Beryozkin <sberyozkin_at_talend.com>
> To: <jsr339-experts_at_jax-rs-spec.java.net>
> Cc:
> Date: Wed, 1 May 2013 10:47:12 +0100
> Subject: [jax-rs-spec users] [jsr339-experts] Re: The origin of
> MessageBodyWriter - when to check
> Hi Santiago
> On 26/04/13 13:55, Santiago Pericas-Geertsen wrote:
>
>> Hi Sergey,
>>
>> It's a bit difficult to comment on this without looking at the test. Is
>> this a TCK test that you're referring to? If so, which one?
>>
>> Sorry for a delay. It's indeed a TCK test but I did not want to use the
> list to discuss the specific TCK tests (I'd follow a proper procedure for
> challenging the individual tests) but rather keep the question more in
> 'scope' for this list, and besides I guess I can not even do that as I've
> signed NDA :-)
>
> However we've talked about this issue before, so here is my question in
> some other words:
>
> - custom Application registers a custom provider, typed like this:
>
> public class MyProvider implements MessageBodyReader<Object>,
> MessageBodyWriter<Object> {
> public boolean isReadable(Class c, ...) {
> return InputStream.class.**isAssignableFrom(c);
> }
> public boolean isWriteable(Class c, ...) {
> return InputStream.class.**isAssignableFrom(c);
> }
> }
>
>
>
> I honestly do not see how the 2.0 spec text can make a
> standard/pre-packaged InputStream provider preferred to MyProvider above
> when a resource method expects InputStream.
>
> The spec needs to specific about the order of the 'origin' key (custom vs
> pre-packaged) and furthermore, IMHO, it has to do an explicit text about
> the pre-packaged provider taking a precedence in some cases, because the
>
> "primary key of generic type where providers
> whose generic type is the nearest superclass of the object class are
> sorted first and a secondary key of
> media type" condition does not work because there's no spec requirement
> that pre-packaged providers have to be typed on InputStream, etc, as
> opposed to just 'Object'
>
> What do you think ?
> Sergey
>
> -- Santiago
>>
>> On Apr 25, 2013, at 11:01 AM, Sergey Beryozkin<sberyozkin_at_talend.**com<sberyozkin_at_talend.com>>
>> wrote:
>>
>> Hi Santiago, All,
>>>
>>> The specification says:
>>>
>>> "An implementation MUST support application-provided entity providers
>>> and MUST use those in prefer-
>>> ence to its own pre-packaged providers when either could handle the same
>>> request.
>>> "
>>>
>>> We have a failing test. An application provider, typed on Object, is
>>> written to support some specific types like Boolean, InputStream, etc, and
>>> its isWritebale& isReadable checks that a given Object is of the supported
>>> type and returns true if yes, false if not.
>>>
>>> The test still expects that the shipped/pre-packaged provider
>>> (presumably typed for example on Boolean or InputStream) is chosen.
>>>
>>> The question boils down to what is the order of the 'origin' key. Does
>>> the specification mean that it is a tertiary key ? If yes then I'm
>>> accepting the test is valid, if not - concluding it is not.
>>>
>>> Thanks, Sergey
>>>
>>
>>
>
>
>
> ---------- Forwarded message ----------
> From: Jan Algermissen <jan.algermissen_at_nordsc.com>
> To: "jsr339-experts_at_jax-rs-spec.java.net" <
> jsr339-experts_at_jax-rs-spec.java.net>
> Cc:
> Date: Wed, 1 May 2013 13:55:18 +0200
> Subject: [jax-rs-spec users] [jsr339-experts] Why is there no generic
> Auth-Header support in JAX-RS?
> Hi experts,
>
> given that HTTP Authorization and WWW-Authenticate header syntaxes are
> defined in a generic way, independent of any specific Auth-Scheme, I wonder
> what the reason is that there is no support in the API for these headers.
> (E.g. there is for Cookie and Cache-Control and Link for example)
>
> Can anyone remember the reason?
>
> It's quite painful to implement and everybody seems to roll their own.
> Most of what I see out there is wrong and/or relies on a zillion of regexes
> - quite a bad situation.
>
> In addition, it would really help code clarity if Auth 'objects' would be
> integrated into the API, e.g. via injection of an AuthInfo or similar.
>
> Is this something for 2.1, maybe?
>
>
> Jan
>
> ---------- Forwarded message ----------
> From: "Reto Bachmann-Gmür" <reto_at_gmuer.ch>
> To: jsr339-experts_at_jax-rs-spec.java.net, users_at_jax-rs-spec.java.net
> Cc:
> Date: Thu, 2 May 2013 07:43:23 +0200
> Subject: [jax-rs-spec users] Re: [jsr339-experts] Why is there no generic
> Auth-Header support in JAX-RS?
> Hi Jan
>
> From the comment on issue 43 it seems that the experts want to keep
> everything out of the spec for now that is somehow related to
> authentication.
>
> While for the header you're mentioning this is a nuisance this is a
> blocker for the X509 certificates (issue 43) as support for these cannot be
> implemented at all in a JAX-RS application unless using some implementation
> specific method (such as by relying on the fact that the implementation is
> servlet based).
>
> My plea would be to add all the needed low-level authentication support
> before and independently on whatever high level security API future version
> might bring. (Which I'm not sure if it's needed anyway as the standard
> Java-AccessController mechanism can well be used in Jax-RS implementations).
>
> Cheers,
> Reto
>
>
> On Wed, May 1, 2013 at 1:55 PM, Jan Algermissen <
> jan.algermissen_at_nordsc.com> wrote:
>
>> Hi experts,
>>
>> given that HTTP Authorization and WWW-Authenticate header syntaxes are
>> defined in a generic way, independent of any specific Auth-Scheme, I wonder
>> what the reason is that there is no support in the API for these headers.
>> (E.g. there is for Cookie and Cache-Control and Link for example)
>>
>> Can anyone remember the reason?
>>
>> It's quite painful to implement and everybody seems to roll their own.
>> Most of what I see out there is wrong and/or relies on a zillion of regexes
>> - quite a bad situation.
>>
>> In addition, it would really help code clarity if Auth 'objects' would be
>> integrated into the API, e.g. via injection of an AuthInfo or similar.
>>
>> Is this something for 2.1, maybe?
>>
>>
>> Jan
>
>
>
> End of digest for list users_at_jax-rs-spec.java.net - Thu, 02 May 2013
>
>