Mark H. Wood created DS-1390:
--------------------------------
Summary: 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
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
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
