Uploaded image for project: 'JBoss VFS'
  1. JBoss VFS
  2. JBVFS-166

Deployment archives that are symlinks do not get cached properly when jboss.vfs.forceCanonical is set to 'true'

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • 2.2.0.GA
    • None
    • None
    • Workaround Exists
    • Hide

      There are two possible work-arounds. One can simply not use a symbolic link for the deployment archive. In addition, one can not set jboss.vfs.forceCanonical. However, in this case, the realCache will be used for deployments where the deploy directory itself is a symbolic link leading to a possible degradation in performance.

      Show
      There are two possible work-arounds. One can simply not use a symbolic link for the deployment archive. In addition, one can not set jboss.vfs.forceCanonical. However, in this case, the realCache will be used for deployments where the deploy directory itself is a symbolic link leading to a possible degradation in performance.

      When a deployment, such as an .ear file, is a symlink and the jboss.vfs.forceCanonical property is set to "true" to address JBVFS-137, the deployment fails to be properly cached leading to an ever increasing vfs-nested.tmp directory.

      JBVFS-137 addresses the problem that permanentRoots in the VFSCache get set according to their canonical path by the URL PropertyEditor. Without the fix, if the deployment directory is a symlink, it will be stored in the cache using a different path than lookups will use. To correct this, when checking for items in the cache, the canonical path must be used, or else there will not be a match. Setting the jboss.vfs.forceCanonical property enables conversion of the deployment's path to a canonical path for this purpose.

      However, in the case of a deployment that is a symbolic link within the deploy directory (i.e., someApp.ear is itself a symbolic link), there is no initial modification of the path to a canonical path. (Because the URL is not being set via a PropertyEditor.) So, it is stored based on the non-canonical path. But, with jboss.vfs.forceCanonical set to true, the lookup is based on the canonical path, which doesn't match.

            ajustin@redhat.com Ales Justin
            rhn-support-miclark Mike Clark
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: