Uploaded image for project: 'Magnolia'
  1. Magnolia
  2. MAGNOLIA-5209

Split, deprecate, refactor info.magnolia.cms.core.Path



    • Type: Improvement
    • Status: Closed
    • Priority: Neutral
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.5.3
    • Component/s: core
    • Labels:
    • Sprint:
      Kromeriz 85
    • Story Points:
    • Magnolia Release:


      This class is currently a melting pot of

      Generic path-related methods - which can be useful both in a filesystem- and jcr- context:

      • isAbsolute()
      • getAbsolutePath()

      Filesystem-related, Magnolia-specific methods

      • Unused methods (or methods that should not be used) - getCacheDirectoryPath()
        • These should just go
      • Methods that provide a java.io.File for some of the default properties (getTempDirectory(), getCacheDirectory(), and getHistoryFile().
        • of these 3, only the first is relevant to all modules. The other 2 are actually module specific.
        • none of these actually makes sure the directory is actually created. They attempt to create the directory structure on every call, but never check for results.
      • getRepositoriesConfigFile() which is also not used. (the corresponding property is used directly)
      • getAppRootDir() which is used 3 times, in 3 different ways:
        • once to generate an "appName" in MBeanUtil (which is a very flawed way of uniquely identifying a Magnolia instance)
        • once to get to the web.xml file - which will way if the app is deployed as an unexpanded .war file
        • once to load config files (will probably also fail if the app is deployed as an unexpanded .war file, but info.magnolia.cms.util.ConfigUtil#getConfigFile already works around that, I think)
      • getAbsoluteFileSystemPath, which is used in the combination with the above - but not always (ConfigUtil.getConfigFile for example replicates this logic to find configuration files)

      JCR, generic utility methods:

      • getUniqueLabel()
        • should be named getUniqueNodeName()
      • getValidatedLabel() which transforms an arbitrary String into a valid jcr name.
        • should be named validateNodeName()
        • isCharValid(), which should be private


      • For all filesystem-only methods - move whatever is module-specific to the module in question. Keep the minimum in core, make magnolia.home a first-class citizen property and provide:
        • a clear way of making sure the required paths are valid, exist and can be read from/written to.
        • MagnoliaDirectories could provide "home" (where all files reside) "app root dir" (renamed to webappDir), although usages of the latter should be kept to a minimum and one should probably prefer using javax.servlet.ServletContext#getResource
        • I would consider using a Virtual FS - if all client code is moved to using this new interface, it'd become possible to remove all FS usage, should that be desired. (Jackrabbit has one, and I was hoping to find it in jcr-commons, but that doesn't seem to be the case. Apache commons has a VFS library too, but it seems a little outdated.) - would also help with tests. It looks like Java 7 has something along these lines, so perhaps we could wait until we switch to Java 7 (unless there is a way to get this in a non-intrusive way)
      • For all JCR-related methods - move to NodeUtil ?
      • For the 3 methods that aren't specific to fs or JCR, meh. They're simple enough, I wouldn't mind the duplication - but they probably don't need to be public either.


          Issue Links



              mdivilek Milan Divilek
              gjoseph Magnolia International
              0 Vote for this issue
              4 Start watching this issue


                Date of First Response: