Hi Felix, On Thu, Mar 27, 2008 at 2:39 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > (1) The EmptyRangeIterator.next() method in the patch should throw > a NoSuchElementException instead of returning null...
ok, I'll change that. > (2) special casing issues... I agree with the suggested change in JcrResourceResolver.resolve, and I'll use a new SyntheticStarResource.appliesTo(HttpServletRequest) method so that the SyntheticStarResource can decide by itself it if is limited to GET or applies to all HTTP methods. That'll make the JcrResourceResolver cleaner. > ... In addition, I also suggest to not limit this special casing to the GET > method. This would just create such a SyntheticStarResource for any > request ... We don't want a SyntheticStarResource for POST, do we? That might interfere with the way we handle POST to *, see SLING-343 for example. But I didn't check if removing the GET limitation would actually cause problems - I just assumed it would. > ... Thinking about it, we might even take a further step and drop the > SyntheticStarResource completely and have the > NonExistingResource.adaptTo(Node.class) method return this fake node. > (or have an extension of the NonExistingResource class in the > jcr/resource bundle, which implements this adapter and which is returned > by the resolve method)... Conceptually I think this star resource is more a "synthetic" resource than a "non existing" resource - viewed from the client side the resource does exist, it is just internally that it doesn't have any storage. I'd be open to have SyntheticStarResource extend NonExistingResource instead of SyntheticResource as it does now, but I'm not sure what that would bring. -Bertrand
