Details
-
Type:
Bug
-
Status: Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 1.6DR#2
-
Fix Version/s: None
-
Component/s: ICE-Components
-
Labels:None
-
Environment:Any
-
Workaround Exists:Yes
-
Workaround Description:I have suggested that the customer override the path to the image directory with the absolute path. ex) imageDir="http://localhost:8080/APP/xmlhttp/css/xp/css-images/"
Description
ICEfaces resources, such as images and styles, are being retrieved based on a relative url to the context root. If the context root has been changed, such as by a redirect, the application will be unable to find the resources. Solution is to retrieve resources based on an absolute url. Several customers are having issues with this.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Assigning to Tyler to comment on specific cases (perhaps forum references).
Are there some specific cases where absolute URLs are required? We have improved URL resolution for portlets, but this may not be sufficient for other cases.
Show
Ted Goddard
added a comment -
Assigning to Tyler to comment on specific cases (perhaps forum references).
Are there some specific cases where absolute URLs are required? We have improved URL resolution for portlets, but this may not be sufficient for other cases.
We are facing issue because of this bug. We have our resource (image/JS etc) in a seperate webapp with its own context root. We also have existing libraries which constructed the URLs fine. An eg is <mycompany:url type="image" name="abc.jpg"/>. But we cannot embed this in icefaces tags for eg:
<ice:commandButton image="<mycompany:url type="image" name="abc.jpg"/>" ..../>
This would be ideal. As a workaround we are gonna construct the URL explicitly like this:
image="http://#
{facesContext.externalContext.request.serverName}:#
{facesContext.externalContext.request.serverPort}/images/imgage11.jpg"
Not a great one, but at least avoids hardcodings of server name and port!