[
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
