I think anything that involves exposing temp locations is wrong -- too much impl details.
Which means we should then allow for direct vfs urls to be used in policy files.
And this leads us back to
For this use case I would simply say "deploy as exploded" and it should work.
(a) you don't wanna expose temp details
(b) whatever URL you return should be useable (e.g. open jar file from it or JarURLConnection)
and this two don't work together.
There are various dimensions to this problem.1) pushing some implementation details into public interface realm (temp files naming and structure)2) potential file locks on windows if exposing jar:file: urls to deploy location (as user code may then bypass vfs and use JarFile directly causing locks - preventing undeploy)3) using specific deployment scenario (expanded vs. packaged) tailored to specific requirements - third party libs working directly with jar:file: urls4) support for policy filesIn principle temp files naming should be an implementation detail. vfs3 for example doesn't use vfs-nested.tmp as far as I know. If this is exposed any future implementation will need to keep supporting the contract.From this point of view exposing jar:file: url to temp location is a no-no. The proper way to address JBAS-7882 issue is to deploy the application in expanded form. Policy file should then contain jar:file url patterns to deploy dir.Caveat is that by giving client jar:file urls to deploy jars, third party libs may lock them, preventing application undeploy via filesystem move/delete on windows.On the other hand, to avoid any possibility of file locking issues on windows, exposing direct jar:file: urls to deploy location is a no-no - all jar:file: should point to temp location, which then has to be predictible and properly structured. Policy files should then contain jar:file urls to temp location. In this case JBAS-7882 is covered by packaged deployment as well.
This package contain policy files and also properly structured to follow