I need to object. It is pretty valid to use JAX-RS without CDI, EJB,
JTA, etc. Think for example of a Raspberry Pi controlling some
electronics. It just needs a REST frontend and a JNI backend. No
database included at all. But Java SE for Embedded Devices.
Zitat von arjan tijms <arjan.tijms_at_gmail.com>:
> Wasn't a "solution", but as you correctly mentioned an ALTERNATIVE indeed,
> and in fact a complete opposite alternative. But I think we already agree
> about the main proposal as per the followup mail ;)
>
> You solution would enforce that it becomes impossible to run the same
>> JAX-RS application unchanged in Java SE and Java EE environments
>
>
> Someone who wants to run a single JAX-RS application unchanged on both Java
> SE and Java EE already has a difficult time.
>
> How is such an application going to use JPA, BeanValidation, CDI, EJB, JTA
> etc then? How much can a JAX-RS application really do when only using
> JAX-RS APIs and nothing else? Is that even a real-life constraint people
> care about? I mean, you can always bundle these Java EE libs, and then
> you'd essentially have created your own Java EE anyway. Or would you still
> call such a thing Java SE then?
>
>
>
>
> On Fri, Mar 4, 2016 at 12:17 AM, <markus_at_headcrashing.eu> wrote:
>
>> You still miss the point. All JAX-RS implementations already support
>> @RolesAllowed. My proposal targets upon unification of the API to enable
>> it. Not more. Not less. Your solution targets on providion an ALTERNATIVE
>> implementation outside of the JAX-RS container, which is out-of-scope of
>> JSR 370 for good reason: The container MUST forward security tasks to the
>> Java EE server product once bundled withat that, so it MUST know about
>> @RolesAllowed. You solution would enforce that it becomes impossible to run
>> the same JAX-RS application unchanged in Java SE and Java EE environments,
>> which is a clear target of the JAX-RS API and particularly my proposal.
>>
>>
>> Zitat von arjan tijms <arjan.tijms_at_gmail.com>:
>>
>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>>