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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>
>>
>>