-
15. Re: StructureModificationChecker and Synch with VFS3
The deploymentName to identify the deployment context and VirtualFile for the original copy of the deployment root. That should hopefully be enough?
Yeah. I think this would be enough. Will take a quick run through to make sure there isn't anything else to consider.
-
16. Re: StructureModificationChecker and Synch with VFS3
With the strategy discussed in this post, does it make sense to have a SynchWrapperModificationChecker? Are there use cases for still having a the deployment root be periodically synchronized with the the original physical location?
-
17. Re: StructureModificationChecker and Synch with VFS3
With the strategy discussed in this post, does it make sense to have a SynchWrapperModificationChecker? Are there use cases for still having a the deployment root be periodically synchronized with the the original physical location?
This workaround was introduced due to how JBossWeb works.
e.g.
If you had to create copy -- which we did due to Winz locking crap & resource loading at undeploy - JBW code worked on a copy.
But users of course don't have a clue about that copy (nor should they),
hence they expect when they changed the (exploded) original, the copy needed to reflect those changes.
Dunno how JBW works these days, and I'm not following this descussion in details, to know if/how this still applys.
-
18. Re: StructureModificationChecker and Synch with VFS3
I have been doing some diggin on JBW to see if it is still doing a copy. I can find no instance of JBW making a copy of directories. I only see a reference to making an exploded copy of web archive files using VFSUtils.unjar(root) in https://svn.jboss.org/repos/jbossas/trunk/server/src/main/java/org/jboss/web/deployers/AbstractWarDeployer.java.
With this is mind, I am not sure the StructureModificationChecker really helps much since the only copies are from unjared web archives, the modification check only makes sense against the original war file, and if it has been modified, the whole works would need to be unjared again. So there wouldn't be any file by file changes to sync.
I did some further digging on the use of ModificationType and ModificationActions. Outside of tests I do not see any usage of custom modification types/actions for any deployers. Is this still in use? Can it be cleaned up?
-
19. Re: StructureModificationChecker and Synch with VFS3
I did some further digging on the use of ModificationType and ModificationActions. Outside of tests I do not see any usage of custom modification types/actions for any deployers. Is this still in use? Can it be cleaned up?
I wouldn't clean it up.
It's a feature that's implemented and tested.
The fact is that it's not widely used, if used at all.
Or why exactly would you remove it?
You can limit some of the types for start, and log warning for the non-supported.