Re: JSR311: Servlet spec changes for security and JSR311

From: Bill Burke <>
Date: Wed, 02 Apr 2008 08:45:49 -0400

Paul Sandoz wrote:
> Marc Hadley wrote:
>> On Apr 1, 2008, at 12:00 PM, Bill Burke wrote:
>>>> To give fine-grained control we anticipate allowing use of
>>>> @RolesAllowed on resource classes, sub-resource methods and
>>>> sub-resource locators
>>> This is the approach that I wanted to avoid....JSR311 creating its
>>> own component model. EE is supposed to have an integrated platform
>>> and each spec seems to want to create their own component model. I
>>> mean, the only thing differentiating JAX-RS from EJB-lite will be
>>> transaction demarcation/handling.
>> I agree, ideally we'll be able to say that a resource class can be a
>> JSR 299 Web Bean and leave it at that. However that may not work out
>> if the various time lines don't align so instead we'll have a section
>> on expectations (rather than requirements) for a resource class in an
>> EE container and then revisit that in a maintenance review once all
>> the other pieces are in place. That's what I meant by "anticipate" above.
> Some more info. The sub-locator stuff is very different to that of
> existing EE stuff. Because of this the URI space is not something that
> can be determined statically and is fully known in advance to the
> runtime (or even potentially to the developer if classes are loaded
> dynamically e.g. there are plug-ins to the web application). The URI
> space is augmented at runtime as each object returned by a sub-locator
> is processed. Such sub-locator class may also have @RolesAllowed. Thus I
> don't think any static declaration and duplication of URI templates at
> the servlet container for fine grained security is the right approach.

Again, this can be solved by the EJB or Web Bean layer. There is no
need for another component model. Or maybe you're thinking of using JPA
as a service layer? Um...well, that's just wrong. Didn't we already do
that exercise from CMP->JPA? One of the value points of REST is that
you can re-use your existing architecture. I don't see any reuse here,
just re-inventing the wheel.

Finally, security is one of those cross cutting concerns that a lot of
users want statically declared in XML. Although a neat feature, dynamic
sublocators are a pretty fringe, esoteric use case that 99% of users
won't want or need.


Bill Burke
JBoss, a division of Red Hat