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