This class is currently a melting pot of
- 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)
- 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.