[starksm64]

Ok, I see. That is typical behavior for a directory. We'll have to look to the metadata files for root's that are directories to restore the behavior from the 4.x versions.

[alesj]

That is typical behavior for a directory.

Does this go recursively?
e.g. A/B/C/web.xml ... will modification on web.xml show on A as well, or just C?

We'll have to look to the metadata files for root's that are directories to restore the behavior from the 4.x versions.

That's our constant debate, how to diff between archive and directory in vfs? :-)

[starksm64]

"alesj" wrote:

That's our constant debate, how to diff between archive and directory in vfs? :-)

Its not a debate, there is no difference in terms of the VFS api. Further, there is no distinction between a child directory that is simply a container and an exploded deployment. That is information that is only known by the structure deployers. I'm running into this as part of JBAS-5689 where I see that messaging/jms-ds.xml does not show up in the profile deployments. Rather just the parent messaging directory does and it has subdeployments.

Maybe we need an attributed file system extension to VirtualFile so further information like content-type and deployment type could be added. With that you would be able to distinguish between an archive and directory, and not have to rerun the structural deployers to figure out what something is.

[alesj]

Btw: did you see that I solved this issue. ;-)
- http://anonsvn.jboss.org/repos/jbossas/trunk/system/src/main/org/jboss/system/server/profile/basic/MetaDataAwareProfile.java

[starksm64]

Only for the basic profile impl, and only for file: uris.

[alesj]

Only for the basic profile impl, and only for file: uris.

What else do you need?
Or didn't you say this is profile detail. ;-)
If we need more, then like you said, we need extension to VFS.

[starksm64]

hot deployment is an implementation detail, but I'm talking about identifying a directory vs an archive (exploded or not) for other purposes as well. The VFS alone cannot determine this. What I was suggesting was adding an attributes or perhaps simply a properties accessor to the VFS api to allow additional information to be built up from the structure deployer, etc.

The complication with this is keeping it around. This should not be too hard for in memory usage that is built up only for the current runtime. Persisting such info across restarts is a little more involved as its a security issue to need write access to the filesystem.