Community
Participate
Working Groups
Images that are provided at an extension point get an internal url like this: bundleentry://3.fwk27682895/icons/ttt.gif The problem is that the part in the middle is based on the default hash-code implementation. See org.eclipse.osgi.baseadaptor.BaseData#getEntry0() The JFace URLImageDescriptor uses this path to register the image at the RAP resource manager. As the hash-code differs between different application servers, images cannot be found in a session-based load balancer scenario where the sessionId is not stored in a cookie but comes with the URL.
Created attachment 173169 [details] Patch proposal In URLImageDescriptor an url pointing to an image that is located in a bundle is registered at the http-Service (indirectly) The incoming URL looks like this bundleentry://9.fwk27682895/icons/full/eview16/view_menu.gif What is registered is this 9.fwk27682895/icons/full/eview16/view_menu.gif Would we need is this org.eclipse.rap.ui/icons/full/eview16/view_menu.gif Idea of the applied patch is to replace the cryptic id with the origin bundle symbolic name.
Btw, the proposed patch improves performance after server restarts or redeployments as images can be loaded from the browser cache because of a deterministic url.
Stefan, your patch would not work with RWT standalone, since the FileLocator cannot be used without OSGi running - in fact, it throws NPEs without. However, we can probably fix this issue by generating image paths from a hash code, as we already do for theming images. As a workaround, you could also create your own ImageDescriptor, that uses FileLocator to create consistent URLs. Or you could file a bug against Equinox to request reproducible bundle IDs/URLs.
(In reply to comment #3) > However, we can probably fix this issue by generating image paths from a hash > code, as we already do for theming images. I don't see how a hash code based image path can help. In fact, the hash code is the problem, because it differs for each app server. > As a workaround, you could also create your own ImageDescriptor, that uses > FileLocator to create consistent URLs. As the ImageDescriptor is used by workbench code, clients have no chance to change this. > Or you could file a bug against Equinox to request reproducible bundle > IDs/URLs. This would be an option. However, indeterministic bundle paths aren't evil in general. They only cause problems when they are used as resource paths at an http webserver. So the platform team could argue it's rather a problem of RAP than of the platform.
(In reply to comment #4) > I don't see how a hash code based image path can help. In fact, the hash code is > the problem, because it differs for each app server. I should have been more clear here, the image path would be based on an hash code of the image data and would thus be deterministic. > > Or you could file a bug against Equinox to request reproducible bundle > > IDs/URLs. > This would be an option. However, indeterministic bundle paths aren't evil in > general. They only cause problems when they are used as resource paths at an > http webserver. So the platform team could argue it's rather a problem of RAP > than of the platform. I think it's worthwhile. If there is no good reason for indeterministic bundle URLs (maybe there is one?), why not avoiding such problems from the beginning? Isn't it an issue with server-side Equinox in general?
Images are now registered under deterministic paths that are generated from hash codes over the image data. Stefan, could you please verify that this solution works for you? Changes are in CVS HEAD.
