Uploaded image for project: 'DSpace'
  1. DSpace
  2. DS-1390

DSpace has too many configurations



    • Attachments:
    • Comments:
    • Documentation Status:


      DSpace has two separate places to go for configuration: ConfigurationManager and ConfigurationService. While very similar, they do work differently, and they generate extra work to keep them similar. I recently wanted to answer a question on dspace-tech concerning configuration of uninstalled webapp.s run from the IDE during development, and realized that the situation was too complex to describe. I'd like to simplify things quite a bit.

      I suggest several phases:

      1. ConfigurationManager contains a number of methods that have nothing to do with simple configuration properties, but rather deal with license texts and news items and the like. These should be moved to classes directly concerned with representing them. In particular, XMLUI has its own way of handling news, so JSPUI should house the one currently in dspace-api, which is only used by JSPUI.

      Removing methods not dealing with serialized Properties will align the signatures of ConfigurationManager and ConfigurationService much more closely.

      2. Review the overall design of access to configuration data. Each configuration source has grown a number of handy features over the years, but I think it's time to do another design pass over the whole issue of how we find bits of DSpace that the JVM doesn't inherently know about, and then implement a single model which well serves both development and production.

      3. Gut ConfigurationManager, replacing the existing code with wrappers for the most closely corresponding ConfigurationService methods. Deprecate all ConfigurationManager methods.

      4. See whether there are useful things only in ConfigurationManager which should be ported to ConfigurationService.

      5. As time permits, replace ConfigurationManager uses.

      I recall that there are proposals to change the way that configuration data are stored and manipulated. I think that this simplification and refactoring should at the very least not impede such efforts, and may complement them nicely. The current (near) duplication of function OTOH does somewhat impede those efforts.


          Issue Links



              mwood Mark H. Wood
              mwood Mark H. Wood
              0 Vote for this issue
              5 Start watching this issue