On Wed, May 15, 2013 at 10:37:26AM +0100, João Melo wrote: > I'm also in favor of going 100% Spring, however i'm not confortable with > the hard coded load sequence (it makes code maintenance harder due to > Spring version upgrades).
Would you please point me toward this "hard coded load sequence". The problem there is not immediately obvious to me. > If you could help me here, I would like to clarify. I think the key here is > to centralize the configuration (that's why we need to override the default > load sequence) because, by default, Spring will turn configuration values > like a legos game. Am i correct? Spring has to work out bean dependencies so that it can instantiate (and perhaps configure) beans in a correct sequence. That sequence might not be the one we would have worked out, though it will be correct in that dependencies are instantiated before their dependents. I don't think we should necessarily use Spring to handle all configuration. Most of the code should be unaware of Spring, and yet we have scads of settings that are used in many places around the code. So I think that for much of the configuration we'll still want a central reference point like ConfigurationService or ConfigurationManager. I think that Spring is best used for assembling a modular application from its components; it's not really the method I would choose for end-user configuration of assembled instances. > If I'm reasoning it well, i might introduce a new discussion point, that > is, instead of "ConfigurationServices" we could have an Unified Property > Management like Chris Beams posted here ( > http://blog.springsource.org/2011/02/15/spring-3-1-m1-unified-property-management/ > ). I'll take a look at that, but I want to point out that there are several things going on here which mostly don't affect one another. o Two independent sources of configuration, which behave differently and do not see each other's updates. I want to express one entirely in terms of the other (and eventually remove the dependent one) so that there is a single configuration viewed consistently throughout the code. o There is a desire to reconsider the way that configuration is stored and edited. o There is unused complexity in the Services framework when it sets up for dependency injection. We have a hierarchy of service managers which can start various DI frameworks, but in practice it all boils down to one using Spring. Additionally this is a somewhat unnatural way to use Spring, and introduces sequencing issues. This thread was spawned by issues raised while I was working on merging ConfigurationManager with ConfigurationService, but this thread is really about removing the unused service framework complexity so that all of our configuration work becomes easier to understand. It had been stated that there were cases in which it was necessary to use ConfigurationManager because ConfigurationService hadn't started yet. That suggests to me that we have either something happening out of its proper sequence, or perhaps even some hidden circular dependency. I'd like to remove the unused complexity from the services framework startup so that we can more easily dig out these problems (and also because it makes testing easier). The way I see it right now, instead of having the services framework start up Spring, we should start Spring first and let it start up the (somewhat simpler) services framework. I'd like to suggest that we consider the DI framework question settled -- de facto, we have picked Spring -- and strip down the service framework startup to reflect that decision, independently of any work on remolding storage and access to configuration. I further suggest that merging the guts of ConfigurationManager and ConfigurationService would simplify any effort to change the way that we persist and edit configuration data, because after that we'll only have to work on one subsystem instead of two and won't have to coordinate duplicate changes. -- Mark H. Wood, Lead System Programmer [email protected] Machines should not be friendly. Machines should be obedient.
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ 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
