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
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com