On Jun 19, 2008, at 11:00 AM, Stephan Koops wrote:
> Hi,
>
> we discussed this before, and Paul argued for this: For
> implementation reasons I propose to put the methods
> getAncestorResource*() to an own interface, e.g. Ancestors. Last
> times I argued against this, because I don't had in mind, that you
> now need a new Object creation for every UriInfo injection. Until
> now I put the same object for Request, HttpHeaders, SecurityContext
> and UriInfo if one of this is requested in every resource object.
> Jersey also uses (or only used?) a class which implements these
> four interfaces.
Jersey always created a 'request' and a 'context' object. I just
shifted over the Uriinfo implementation from the request to the
context. I grumbled a bit when i had to do it :-) for work reasons
rather than for performance. From a performance perspective i don't
think it is big deal, i think there is a better reason as explained
below, but i can live with the current situation.
> For speed reasons it seems useful to me to move the the methods to
> an interface like Ancestors with the methods getResources() and
> getResourceURIs().
>
A clarification, i argued for a split based on contextual and non-
contextual URI information related to matching and not specifically
just for ancestors. If a split was proposed for just ancestors then i
would prefer UriInfo not to be split.
The main reason was i thought, in the future, that some aspects of
UriInfo could be used in other potential areas. I may end up creating
a Jersey specific RequestUriInfo that is the subset of UriInfo and
has non-contextual methods related to URI matching.
Paul.