A couple very brief thoughts inline... On 6/4/2010 9:42 AM, Mark H. Wood wrote: > I see several distinct clumps of configuration data: > > o Build configuration. Maven currently handles this for us. What > code do we use, and what transformations are required to produce a > runnable form of that code? > > o Install-time configuration. Where does stuff come from and where > does it go? We're using Ant to do this job. > > o Architectural configuration. This used to be done with link editor > scripts, then we got dynamic linking, then Java made all linkage > dynamic, then we got DI frameworks to formalize dynamic binding. > Anyway, this is how separate hunks of code are knit together to use > each other's services. We seem to be moving to greater use of > Spring for this. > > o Startup configuration. How does an instance of the product find > what it needs to stand up and run? We use context parameters or > assumptions about directory layout to work this out. Includes > answering the question of where is: > > o Operational configuration. This adjusts the product's behavior > toward users of a given instance. Do we offer LDAP authentication, > and from where? do we display thumbnails in certain contexts? what > file formats and metadata schemae do we support? > > I think that we currently have some install, startup, and operational > configuration data all tangled together, and I'd like to try to > disentangle them.
Bravo! I think this is a great explanation of a growing problem. I agree completely with Mark W that we seem to be tangling up several layers of configs -- and some layers have started to get tangled in an ever-growing 'dspace.cfg' file. Minimally, it seems like we have both Startup & Operational configs in that file (you could also argue we have Architectural configs there since it now also holds locations of Spring configs -- more on that below). I'd also like to see us make an effort to disentangle these -- and I know it's not 100% related to this Services discussion, but it seems like we should be keeping this all in mind as we think about the ConfigurationService. (Unrelated Sidetopic: we really need to simplify those first two -- build & install-time -- as well. Be nice to finally determine whether we still need people to have both Maven & Ant as prerequisites to installing DSpace) >> I also think your making the ServiceManager out to be a bit more >> complex than it is. The basic implementation is just the Spring >> Framework with a few designated locations to look for configuration >> xml files in the classpath. The most significant thing that is >> happening is that we lookup the dspace.cfg config locations and create >> the DSpaceConfigurationService before the Spring Application Context >> is initialized. This is pretty much done because of a chicken and egg >> issue where the locations to look for spring configs is a property of >> that configuration file. Maybe if we did not do that, we could just >> instantiate the ConfigurationService directly within Spring as well. >> I'm not against that either. > > That *is* backwards. I think it arises out of the confusion of > distinct configuration groups that I mentioned above. The blob of > code that receives control from outside the product (a main program, a > context listener, whatever) should be told where to find a bootstrap > configuration for Spring, and then Spring can inject further > configuration pointers into DSpace, such as telling the > ConfigurationService where to look. dspace.cfg shouldn't contain > anything that Spring has to know, because it's not for Spring; it's > for DSpace. As it is we have a layering violation, leading to > confusion. +1 again to what Mark W says. This seems "backwards" to me as well. We need to disentangle these configuration groups better. The more we disentangle these config groups, the more likely we could also start to move towards some configs (operational configs as Mark W calls them) being editable via the Admin UI. That's it from me for now -- still digging around a bit in the current Services code & getting my mind around it. Liking the discussion so far! - Tim ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
