Using Wildfly 8.2.0.Final, Windows 7, JBoss Developer Studio 8.0.2.GA.
We're trying to split our war into modules. Seems like the most natural way to do this is by relying on web fragments + JSF/Facelet ability to find resources in war/WEB-INF/lib jars.
The problem is that changes to xhtml facelet templates and static resources don't apply on the fly, as it happens if the same things are located in the war itself.
As I understand it's because:
- fragment jars are getting deployed by IDE packaged, not exploded;
- VFS creates a copies of jars in the tmp dir, which it then unpacks;
VFS3 User Guide says "Whenever possible the JavaZipFileSystem attempts to use the JarEntry to support file system operations. When this is not possible it will write a copy of the JarEntry to the temporary directory". I don't understand what this "when not possible" means, and stepping through org.wildfly.extension.undertow.deployment.WarStructureDeploymentProcessor code it seems that a jar copy is always made.
- org.jboss.vfs.spi.JavaZipFileSystem seems to try to watch the jar's last modified time, but it looks at the copy, not the original;
- JBoss Developer Studio doesn't change the original jar's last modified time anyway, e.g. when updating a xhtml.
The questions.
- Are there bugs somewhere? VFS? Undertow? I'm not sure if the described behavior is intended.
- Should hotdeploying resources in war libs even supposed to be supported by Wildfly? I.e. is it reasonable?
- How do I achieve this functionality with Wildfly 8.2.0.Final?
- Substitute Undertow's war deployment ResourceManager, modify getResource somehow?
- Do something to VFS.mounts? What?
- Ditch this approach. Instead make these war submodules into EJBs at the ear level, so they will be deployed exploded. Add these "EJBs" as war deployment resource roots like WarStructureDeploymentProcessor does it.
