Mainly, when a VFSClassLoaderPolicy is created outside the deployerframework (ex. JMXKernel), how do we make sure the archives aremounted and who is responsible for their cleanup? Right now there isa hack that will ensure the archives are mounted, but will leak thereference to the mount. In this case it seems like the creator ofthe policy should really be responsible for the handling of thereferences, and the policy should not be aware. Any thoughts?

Ales:

Currently VFSCLPolicy can be created two ways:(a) from deployers(b) from <classloader> element

For (a) we should already taken care of its archives via structural deployers.With (b) policy is created via bean which is a Module which creates the policy.So, in that case, I would just add create and destroy methods to this Module bean, where we would mount and unmount via bean's lifecycle callbacks.

For any other usage the user should be aware of how to properly use VFS3.

I was able to get the (b) case working by adding the create and destroy methods to the VFSClassLoaderPolicyModule. This works well. Looking into how to accomplish the same thing from VFSDeploymentClassLoaderPolicyModule, which does not appear to support the create and destroy semantics. Is is safe to rely on the Module:release method? It appears to be called during undeploy of the module.

Looking into how to accomplish the same thing from VFSDeploymentClassLoaderPolicyModule, which does not appear to support the create and destroy semantics. Is is safe to rely on the Module:release method? It appears to be called during undeploy of the module.

Why would you need to mount/unmount this module?

The roots in this module can only come from current/underlying deployment,

which you already had to properly mount (and will have to properly unmount).