> That's great they've fixed that in 2.0.3. This is from
> 2.0.2 source, which I implemented against.
>
>
com.sun.faces.application.resource.ResourceHandlerImpl#handleResourceRequest
> ...
> resource = createResource(resourceName, libraryName);
>
Well, great. But there is yet another nifty thing to pay attention to, then.
Browsing at the ResourceHandlerImpl class, one may get the idea that
overriding the
createResource(
String resourceName,
String libraryName,
String contentType
)
method would suffice to handle one's own special resources. Instead, it
doesn't since handleResourceRequest invokes:
createResource(
String resourceName,
String libraryName
)
which the lazy coder didn't override. So long, this method in turn invokes
createResource(resourceName, libraryName, null), but from the very same
instance!
handleResourceRequest was probably better doing:
resource = context
.getApplication()
.getResourceHandler()
.createResource(resourceName, libraryName, null)
;
and the one- and two-parameters versions of the createResource method should
"upgrade" to the next version via:
FacesContext
.getCurrentInstance()
.getApplication()
.getResourceHandler()
.createResource(resourceName, libraryName[, null])
The latter seems an overkill to me AND it seems to me specs this time don't
give any special meaning to any of the createResource() method versions. So,
if you need to override createResource(), do it for all three versions!
Besides, it seems to me that method overloading often messes things with
proxy patterns. Why specs proposed three overloaded versions of the same
method in first place?
Giampaolo
> Joel