Backed off on the de-registering/re-registering approach, and added a way for the resource registry to detect, when a Resource is being registered, that's already been registered, when the file name has changed, and update all the dispatching to work with the new file name. Then changed OutputResource to always be registering resources, even when they're previously been registered, to allow the update to occur. The reality is that we can't detect all the scenarios of Resource objects changing, so focusing on optimisations to not register old Resource objects is pointless. The cost is just the CPU/time of calculating the digest, which were were incurring anyway.
Tested against ICE-5422, to ensure was not introducing a regression there.
icefaces-ee-1.8.2_P01
Subversion 21130
icefaces\icefaces\component\src\com\icesoft\faces\component\outputresource\OutputResource.java
icefaces\icefaces\core\src\com\icesoft\faces\webapp\http\common\standard\ModifiablePathDispatcherServer.java
icefaces\icefaces\core\src\com\icesoft\faces\webapp\http\core\ResourceDispatcher.java
TRUNK
Subversion 21131
icefaces\icefaces\component\src\com\icesoft\faces\component\outputresource\OutputResource.java
icefaces\icefaces\core\src\com\icesoft\faces\webapp\http\common\standard\ModifiablePathDispatcherServer.java
icefaces\icefaces\core\src\com\icesoft\faces\webapp\http\core\ResourceDispatcher.java
This also does not work with the regular Facelets component-showcase, it just fails differently. With Facelets-enhanced, when you change the name of the file, it fails to register that resource, so the file is not found. With Facelets, when you go to change the name of the file, it simply does not change the resource link, so it can still find and download the old, now incorrect, file name.