What I found was that the file descriptors was being opening (scheduled tasks) and another task trying to delete the file. Differently of *nix systems, the Windows lock a file when it is opened (even just for read). It seems there is one or more scheduled tasks reloading the directory "${java.io.tmpdir}/cas/services". I believe is a good idea to use a explicit lock file (opened for loading) in the temp directory and if the lock file exists do not try to delete because it's being used.
To verify that it was happening, first I executed the server and management using different temp directory
java -jar -Djava.io.tmpdir=c:\temp\cas cas-overlay-server-demo\target\cas.war
java -jar -Djava.io.tmpdir=c:\temp\mgr cas-overlay-management-demo\target\cas-management.war
And the errors was became less frequent (loading almost always with success the cas server).
To prove that has an process scheduled I made a couple changes: Created new classes under cas-overlay-server-demo using System.out.println to show when the file is being loaded.
I believe the version 5.0.4 is still not fully tested on Windows systems. I don't know how CAS works internally, but the approach to register/delete can't be done on this way on Windows Systems. Maybe creating a explicit lock file when the file is being loaded then the delete task should wait until the lock file is not in there anymore.
First of all, I have cleaned manually, restart the windows and the problem still persist.@leleuj gave me a glue with the classname AbstractResourceBasedServiceRegistryDao and then I did a little bit more investigation, made some changes to see what was happening.