In your application, create file:
This file should contains one line:
( For checking - in the deployable packages, the files should be in
WEB-INF/classes/META-INF/services folder )
Drawbacks: the resource postfix will be stored on the server. If server is reloaded, the links to the resources on the page loaded from the previous session will be invalid
Thanks for the reply. The suggested change doesn't seem to make a difference. I cleared my browser cache, double checked the file names were as you said and that the files were in the right location:
Chrisl@DFVGM71J ~ $ cd "C:\bin\seam\jboss-4.2.0.GA\server\default\deploy\dcs.ear\dcs.war\WEB-INF\classes\META-INF\services" Chrisl@DFVGM71J /cygdrive/c/bin/seam/jboss-4.2.0.GA/server/default/deploy/dcs.ear/dcs.war/WEB-INF/classes/META-INF/services $ ls org.ajax4jsf.resource.InternetResourceBuilder Chrisl@DFVGM71J /cygdrive/c/bin/seam/jboss-4.2.0.GA/server/default/deploy/dcs.ear/dcs.war/WEB-INF/classes/META-INF/services $ cat org.ajax4jsf.resource.InternetResourceBuilder org.ajax4jsf.resource.cached.CachedResourceBuilder Chrisl@DFVGM71J /cygdrive/c/bin/seam/jboss-4.2.0.GA/server/default/deploy/dcs.ear/dcs.war/WEB-INF/classes/META-INF/services $
Admittedly, having a META-INF folder under WEB-INF/classes did seem unusual to me (especially since I have other Rich Faces skins config EAR/META-INF), so I also tried
Chrisl@DFVGM71J ~ $ cd "C:\bin\seam\jboss-4.2.0.GA\server\default\deploy\dcs.ear\META-INF\services" Chrisl@DFVGM71J /cygdrive/c/bin/seam/jboss-4.2.0.GA/server/default/deploy/dcs.ear/META-INF/services $ ls org.ajax4jsf.resource.InternetResourceBuilder Chrisl@DFVGM71J /cygdrive/c/bin/seam/jboss-4.2.0.GA/server/default/deploy/dcs.ear/META-INF/services $ cat org.ajax4jsf.resource.InternetResourceBuilder org.ajax4jsf.resource.cached.CachedResourceBuilder Chrisl@DFVGM71J /cygdrive/c/bin/seam/jboss-4.2.0.GA/server/default/deploy/dcs.ear/META-INF/services $
But that also did not work, maybe I've misunderstood your instructions?
My RichFaces version is 3.0.2 (richfaces-3.0.2-20070620.002147-16.jar).
Sorry, in a Richfaces 3.1.0, package names was changed.
For a richfaces 3.0.x , in the file name and class name "org.ajax4jsf.framework.resource" instead of "org.ajax4jsf.resource".
Still I hope that eventually we will replace such ugly URL with better one. For this particular example GradientA depends from only 2 numbers, so instead of all this default serialization it may be something like "ffeedd,aabbcc" and that it.
Thanks Alex/Sergey, that worked.
+1 for ishabalov's suggestion for shorter URLs!
Chris, you cannot imagine for how long I'm faithing for shorter URL's :-) It is not that difficult to solve, but it a small problem that always fall to the "nice to have category". But now it is the last straw! I swear to take a look to the code and try to do something with that later today or Monday. :-)
Why says that force people to drill a security hole in the own framework is easy job ? Just keep trying.... :-)
It'll be great if you manage to get something in, but I fully understand those project pressures that make these sorts of tasks low priority.
If you need me to run some tests on any new code then feel free to give me a shout.
Thanks again for a fast resolution to this issue.
I've fixed long URL's in several image resources that I found (panel header gradient, tab panel header and several images in tree rendering). Now the typical ULL looks like this:
which is much shorter than before. All other functionality remain the same - I've just improve parameters encoding to consume less space.
If you will find any other long resources URL's tell me :-)
Sorry I missed ilya_shaikovsky's response and have only just got around to testing this against RC3. The solution has worked fine and those URLs are much shorter now.
Thank you all for your help, it is very much appreciated.