Hi Carsten Ziegeler schrieb: > Felix Meschberger wrote: >> Thanks for pointing this out. >> >> According to the current (and previous) implementation and expectations, >> this JavaDoc is wrong and the JavaDoc of the other resolve methods is >> incomplete and does not reflect intentions. >> >> The intentions are, that the resolve methods never return null but >> instead return a NonExistingResource if the path cannot resolve to a >> resource. >> >> This contrasts with the getResource methods, which in fact will return >> null if a resource cannot be found (and hence never return a >> NonExistingResource). >> >> So the solution to this problem would be update the JavaDoc to something >> like: "@return The resource addressed by the path or NonExistingResource >> if no resource can be resolved". >> > Hmm, so far the resolve(String) method returned null if the resource > could not be found. So I fear we can't change this behaviour as this > would introduce incompatibilities :(
Yikes ! I did not read the code thoroughly enough ! It is the resolve(HttpServletRequest) method which never returns null. > > I'm all for a consistent behaviour so your suggestions make sense. > > People are always confused what the difference between resolve(String) > and getResource(String) is - if the only difference is that the latter > returns null in the case of a non existing resource we might also forget > about this method completly :) One difference is (the intended) return of null or not. Another difference is the resolution approach: resolve() tries hard finding a resource applying a lot of mapping logic. getResource() just simply tries to get the resource with the exact path and goes with the result. But I agree, that for the sake of backwards compatibility, the resolve(String) method should probably really return null. My Bad. Regards Felix > > Carsten
