tested on lastest build, seems ok

Add methods for registering resources that return a path that considers the web-application context as root.

After clarifying the issue, we've decided to modify the interface and implementation to include the ability for the ResourceRegistry to provide resource URIs that do not include the application context.

The typical use case for the ResourceRegistry was to provide resource URIs for inclusion things like CSS files where it was necessary to add the context dynamically. However, if the developer wanted to use the ResourceRegistry from a backing bean and get the URI for a resource having the context pre-pended is problematic. Because a component that used the URI from the bean would then send that URI to the ViewHandler to be resolved, it would result in the app context being pre-pended again.

I don't think that an application developer has any good reason for having webapp context name hardcoded in the JSPX files. I am marking this invalid.

The reason why all URI are supposed to be transformed by ViewHandler.getResourceURL method is to allow the change of webapp's name or move the pages within the application under a different folder without having to change anything in the page files.

The provided test case does not exercise at all the ResourceRegistry functionality. ice:comandButton (in ICEfacesPage1.jspx) does not use ResourceRegistry for referencing the image of the button. Dynamic resources have their URL generated, there is no input from the application developer nor the component on how the URL should look like. This rules out any API changes we would need to make in the ResourceRegistry.

Also, ice:commandButton uses directly ViewHandler.getResourceURL method to generate an absolute path to where the image can be found. In fact all JSF and ICEfaces components are expected to receive paths that will be transformed according to the Javadoc of ViewHandler.getResourceURL: http://java.sun.com/javaee/javaserverfaces/1.2/docs/api/javax/faces/application/ViewHandler.html#getResourceURL(javax.faces.context.FacesContext,%20java.lang.String)

suggested fix:

Index: C:/work/workspace/icefaces-trunk-ossrepo/core/src/com/icesoft/faces/context/ResourceRegistry.java
===================================================================
— C:/work/workspace/icefaces-trunk-ossrepo/core/src/com/icesoft/faces/context/ResourceRegistry.java (revision 19267)
+++ C:/work/workspace/icefaces-trunk-ossrepo/core/src/com/icesoft/faces/context/ResourceRegistry.java (working copy)
@@ -67,6 +67,8 @@

• @return the URI of the resource
  */
  URI registerResource(Resource resource);
  +
  + URI registerResourceWithRelativePath(Resource resource);

/**

• Register resource to be served. The URI is encoded using

Index: C:/work/workspace/icefaces-trunk-ossrepo/core/src/com/icesoft/faces/context/BridgeFacesContext.java
===================================================================
— C:/work/workspace/icefaces-trunk-ossrepo/core/src/com/icesoft/faces/context/BridgeFacesContext.java (revision 19267)
+++ C:/work/workspace/icefaces-trunk-ossrepo/core/src/com/icesoft/faces/context/BridgeFacesContext.java (working copy)
@@ -941,4 +941,8 @@
}
return false;
}
+
+ public URI registerResourceWithRelativePath(Resource resource)

}

Something along these lines seems reasonable. Assigning to Mircea.

Another option is simply to provide another method in ResourceRegistry that does not call the private BridgeFacesContext.resolve() method, which is prepending the request context path.

ResourceRegistry:

URI registerResourceWithRelativePath(Resource resource);

BridgeFacesContext:

public URI registerResourceWithRelativePath(Resource resource)

Simple test case with commandButton having an image attribute whose value includes the request context path