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