It's not really a proposal, it's just something user can do, and can do
today. It's just like when you use JPA in a JAX-RS resource. People do that
all the time, yet JAX-RS doesn't need be bundled with an implementation of
the JPA spec on Java SE.
And there's more. There's BeanValidation, really great to use with JAX-RS,
but also not needed to bundle with JAX-RS. And EJB, with pooled and
transactional beans, work great from JAX-RS, but no need to bundle it, etc.
Of course individual vendors may bundle all that, but then you have
essentially Java EE, or actually Java EE. It's more or less what TomEE
does. It runs on Java SE, bundles all the Java EE specs, and then it
actually IS Java EE ;)
But I'd like to stress that Interceptors here are not necessarily the way
to make the *common annotations* @RolesAllowed work in JAX-RS. Interceptors
are an alternative way, by which *the user* can do pretty much what a
common annotations @RolesAllowed backed by the JAX-RS spec would do, but
*without any involvement from JAX-RS*. It's completely transparant to
JAX-RS. Just like a user can use a Servlet Filter today without the spec
needing to have any knowledge of what the user does in that filter.
In order to give meaning to the *common annotations* @RolesAllowed, the
JAX-RS spec should indeed say something about it, and JAX-RS
implementations have to provide some code for that, but it's relatively
simple if you just use existing Servlet APIs.
In that regard, a common annotations @RolesAllowed and a potential
Intercepter based @RolesAllowed are completely opposites. In the first case
you just have the annotation, and each spec must interpret it individually
and act on it. While in the latter case the Interceptor comes with code
that can be applied to everything that's a CDI bean or other managed bean
to which Interceptors can be applied. The spec that uses that bean does not
have to be aware of what those Interceptors do.
Kind regards,
Arjan Tijms
On Thu, Mar 3, 2016 at 11:24 PM, <markus_at_headcrashing.eu> wrote:
> That would impose that JAX-RS comes bundled with an implementation of the
> Interceptors spec on Java SE, which is actually intended for Java EE:
>
> "Interceptors are used ... on instances of Java EE components and other
> managed classes"
>
> As that will not be the case, your proposal won't work.
>
> -Markus
>
>
>
> Zitat von arjan tijms <arjan.tijms_at_gmail.com>:
>
> Interceptor spec Interceptor ;) Using java.interceptor.Interceptor
>>
>> Assumes of course that the JAX-RS resource is also a CDI bean, which is
>> why
>> I mentioned "especially if JAX-RS also further aligns with CDI."
>>
>> On Thu, Mar 3, 2016 at 6:31 PM, <markus_at_headcrashing.eu> wrote:
>>
>> So with "interceptor" you actually mean "JAX-RS Interceptor"?
>>>
>>>
>>> Zitat von arjan tijms <arjan.tijms_at_gmail.com>:
>>>
>>> Depends, one can keep adding things to Java SE until it's essentially
>>> Java
>>>
>>>> EE anyway, but regardless how is that a problem?
>>>>
>>>> If I have a JAX-RS application, and I apply my very own
>>>> FooBarInterceptor,
>>>> and I run it on Java SE where I don't also add CDI, then it won't get
>>>> called. That's pretty much the entire idea. Nothing for the JAX-RS spec
>>>> to
>>>> worry or care about is it?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Mar 2, 2016 at 7:55 PM, <markus_at_headcrashing.eu> wrote:
>>>>
>>>> You miss the point that JAX-RS does not mandate that CDI must be used on
>>>>
>>>>> Java SE. So the interceptor will never get called.
>>>>>
>>>>>
>>>>> Zitat von arjan tijms <arjan.tijms_at_gmail.com>:
>>>>>
>>>>> On Tue, Mar 1, 2016 at 11:12 PM, <markus_at_headcrashing.eu> wrote:
>>>>>
>>>>>
>>>>>> The JAX-RS specification says that JAX-RS can be used not only within
>>>>>> Java
>>>>>>
>>>>>> EE but also as a standalone technology ontop of Java SE. To make a
>>>>>>> JAX-RS
>>>>>>> application work correctly in both environments (hence: without JSR
>>>>>>> 375
>>>>>>> beneath) the JAX-RS specification either must declare that JSR 375 is
>>>>>>> to
>>>>>>> be
>>>>>>> bundled with JAX-RS on Java SE, or it must define a different way to
>>>>>>> declare security with in turn enables JSR 375 on Java EE but may use
>>>>>>> any
>>>>>>> other technology on Java SE.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> JAX-RS doesn't have to know about an Interceptor based @RolesAllowed,
>>>>>> does
>>>>>> it?
>>>>>>
>>>>>> Such an interceptor can be applied to every method to which
>>>>>> Interceptors
>>>>>> can be applied and it does what it does then. No need for JAX-RS to be
>>>>>> aware of what it exactly does, so no need for JAX-RS to define a
>>>>>> different
>>>>>> way for when JAX-RS runs on top of Java SE.
>>>>>>
>>>>>> It's not that different from using say the @Transactional interceptor.
>>>>>> Anyone can apply that to a method, and if that method is applicable
>>>>>> for
>>>>>> interception a transaction it will be transactional. But JSF, MVC,
>>>>>> JAX-RS
>>>>>> and what have you do not all need to go duplicate JTA or provide JTA
>>>>>> delegation mechanisms, do they? They only need to use CDI beans, which
>>>>>> automatically provides Interception, and then the actual interceptors
>>>>>> people put on their methods is not the concern of the spec that just
>>>>>> uses
>>>>>> CDI and/or Interceptors.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Zitat von arjan tijms <arjan.tijms_at_gmail.com>:
>>>>>>>
>>>>>>> If it's an Interceptor spec interceptor, will it not run regardless
>>>>>>> of
>>>>>>> what
>>>>>>>
>>>>>>> the JAX-RS spec otherwise says about security?
>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Mar 1, 2016 at 10:31 PM, <markus_at_headcrashing.eu> wrote:
>>>>>>>>
>>>>>>>> To clarify my proposal, I actually don't care about *which*
>>>>>>>> annotation
>>>>>>>> is
>>>>>>>>
>>>>>>>> getting used, as long as JAX-RS 2.1 specifies one common solution
>>>>>>>> for
>>>>>>>>
>>>>>>>>> ALL
>>>>>>>>> implementations. Certainly my vote would be for "enable
>>>>>>>>> @RolesAllowed
>>>>>>>>> by
>>>>>>>>> default" as it is what currently everone simply would expect to
>>>>>>>>> work
>>>>>>>>> out
>>>>>>>>> of
>>>>>>>>> the box.
>>>>>>>>>
>>>>>>>>> Zitat von arjan tijms <arjan.tijms_at_gmail.com>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> What do you think?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> As we're streamlining security for the entire platform via JSR 375,
>>>>>>>>>>
>>>>>>>>>>> I
>>>>>>>>>>>
>>>>>>>>>>> would
>>>>>>>>>> not be a fan of having another JAX-RS (or any spec for that
>>>>>>>>>> matter)
>>>>>>>>>> specific annotation or other artefact to deal with security.
>>>>>>>>>>
>>>>>>>>>> One of the plans for JSR 375 is to have an Interceptor spec/CDI
>>>>>>>>>> based
>>>>>>>>>> @RolesAllowed equivalent, which may be more consistent, especially
>>>>>>>>>> if
>>>>>>>>>> JAX-RS also further aligns with CDI.
>>>>>>>>>>
>>>>>>>>>> For the existing common annotations version of @RolesAllowed I
>>>>>>>>>> would
>>>>>>>>>> definitely go for "Enable it by default.". These things should
>>>>>>>>>> Just
>>>>>>>>>> Work,
>>>>>>>>>> and not require any "activation" really (some EJB containers had
>>>>>>>>>> the
>>>>>>>>>> same
>>>>>>>>>> problem, a need to activate @RolesAllowed, really inconvenient and
>>>>>>>>>> hurting
>>>>>>>>>> portability of apps).
>>>>>>>>>>
>>>>>>>>>> Kind regards,
>>>>>>>>>> Arjan Tijms
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Mar 1, 2016 at 6:28 PM, <markus_at_headcrashing.eu> wrote:
>>>>>>>>>>
>>>>>>>>>> Experts,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I hope you're in the mood for another small spec clarification in
>>>>>>>>>>
>>>>>>>>>>> the
>>>>>>>>>>> hope
>>>>>>>>>>> to further align Jersey, WebSphere, CXF and RestEasy. :-)
>>>>>>>>>>>
>>>>>>>>>>> The current Jersey manual says that it will respect role-based
>>>>>>>>>>> security
>>>>>>>>>>> annotations (@PermitAll, @DenyAll, @RolesAllowd; according to JSR
>>>>>>>>>>> 250
>>>>>>>>>>> "Common Annotations for the Java Platform") as soon as a
>>>>>>>>>>> Jersey-specific
>>>>>>>>>>> filter is EXPLICITLY enabled by means of JAX-RS feature config
>>>>>>>>>>> API.
>>>>>>>>>>> If
>>>>>>>>>>> I
>>>>>>>>>>> understood the WebSphere manual correctly, I respects these
>>>>>>>>>>> annotations
>>>>>>>>>>> BY
>>>>>>>>>>> DEFAULT. According chapter 36 of its manual, it seems as if
>>>>>>>>>>> RESTeasy
>>>>>>>>>>> wants
>>>>>>>>>>> EXPLICIT enabling by Servlet web.xml. CXF on the other hand
>>>>>>>>>>> apparantly
>>>>>>>>>>> wants the deployer to enable an interceptor EXPLICITLY. So all
>>>>>>>>>>> those
>>>>>>>>>>> JAX-RS
>>>>>>>>>>> products process these annotations, but each has a different way
>>>>>>>>>>> to
>>>>>>>>>>> enable
>>>>>>>>>>> it. Looking through the eyes of an ISV, this is real
>>>>>>>>>>> pain-in-the-*
>>>>>>>>>>> since
>>>>>>>>>>> security is a must-have in all non-trivial products and nobody
>>>>>>>>>>> wants
>>>>>>>>>>> to
>>>>>>>>>>> provide four different configs for the same off-the-shelf app.
>>>>>>>>>>>
>>>>>>>>>>> I'd like to suggest that the spec 2.1 defines ONE COMMON way
>>>>>>>>>>> which
>>>>>>>>>>> enables
>>>>>>>>>>> security on ALL JAX-RS products.
>>>>>>>>>>>
>>>>>>>>>>> I have two proposals:
>>>>>>>>>>>
>>>>>>>>>>> (a) Enable it by default. It should not do any real harm
>>>>>>>>>>> regarding
>>>>>>>>>>> backwards compatibility. This way, nobody has to worry about
>>>>>>>>>>> security
>>>>>>>>>>> besides adding above role annotations.
>>>>>>>>>>>
>>>>>>>>>>> (b) Enable it explicitly by adding @Secured on the Application
>>>>>>>>>>> class. I
>>>>>>>>>>> think this is ugly as the existence of above annotations already
>>>>>>>>>>> imply
>>>>>>>>>>> that
>>>>>>>>>>> security is wanted.
>>>>>>>>>>>
>>>>>>>>>>> As all products already support the functionality, we just need
>>>>>>>>>>> to
>>>>>>>>>>> agree
>>>>>>>>>>> upon a SINGLE way to enable it. I think people simply expect this
>>>>>>>>>>> in
>>>>>>>>>>> 2.1.
>>>>>>>>>>>
>>>>>>>>>>> What do you think?
>>>>>>>>>>>
>>>>>>>>>>> -Markus
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>