[ https://jira.duraspace.org/browse/DS-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark H. Wood updated DS-1390: ----------------------------- Assignee: Mark H. Wood Status: Accepted (was: Volunteer Needed) > DSpace has too many configurations > ---------------------------------- > > Key: DS-1390 > URL: https://jira.duraspace.org/browse/DS-1390 > Project: DSpace > Issue Type: Improvement > Components: DSpace API > Reporter: Mark H. Wood > Assignee: Mark H. Wood > Fix For: 4.0 > > > 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel