[MAGNOLIA-5209] Split, deprecate, refactor info.magnolia.cms.core.Path Created: 29/Jul/13  Updated: 30/Aug/17  Resolved: 28/Feb/17

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: None
Fix Version/s: 5.5.3

Type: Improvement Priority: Neutral
Reporter: Magnolia International Assignee: Milan Divilek
Resolution: Fixed Votes: 0
Labels: support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to MGNLUI-1860 Upload Failed. The directory does not... Closed
relates to MGNLDAM-286 Get temporary directory from the Path... Closed
relation
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:
Sprint: Kromeriz 85
Story Points: 13

 Description   

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

Proposals:

  • 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.

Generated at Mon Feb 12 04:03:00 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.