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