On Sep 7, 2007, at 4:37 PM, Ryan McDonough wrote:
>
> I can certainly see the point whereby injecting container resources
> can be a
> problem for cases where you may not be using a servlet container. I
> think
> there is still value in being able to inject container specific
> interface
> into resources for the instances where you may want that
> functionality. In
> this case however, I think that adding some principal and role
> information
> to the UriInfo interface maybe a better approach as it will provide
> some
> consistency. So we could have:
>
> class PeopleResource {
>
> @HttpContext UriInfo uriInfo;
>
> @UriTemplate("{id}")
> PersonResource getPerson(@UriParam("id) String id) {
> if (uriInfo.isUserInRole("paidSubscriber")) {
> return PaidPersonResource(id);
> } else {
> return CheapSkatePersonResource(id);
> }
> }
> }
>
> This at least provides some level of consistency regardless of
> whether or
> not you are running a servlet container.
Having thought about it some more I think I agree with you. I'm not
sure that adding those methods (isUserInRole, etc) to UriInfo is the
best approach though since that interface is pretty tightly focussed
on providing information about the request URI.
Currently we've defined three injectable resources: UriInfo,
HttpHeaders and PreconditionEvaluator. I think we have a couple of
choices if we add security context to the mix:
(i) Define a new SecurityContext (I'd be open to other names)
interface that can be injected just like the others listed above.
(ii) Provide some kind of unified injectable that provides access to
UriInfo, HttpHeaders etc and includes the additional methods.
Option (i) is the path of least disruption since its purely additive
and it follows the current pattern of having discreet interfaces for
logically separate data. Option (ii) offers the possibility of
unifying request information into a single access point and provides
a place to put additional methods that either don't fit anywhere else
or don't deserve their own dedicated interface.
Opinions ?
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.