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