Let me start out by admitting that I'm a Spring newbie. On Thu, Jun 03, 2010 at 03:48:31PM -0700, Mark Diggory wrote: > Its important to note that "somehow" we need to have some model for > accessing the objects created. If we are going to just have > auto-wiring and rampant getter/setter/constructor injection, then > there is no business model for the application developer to rely on.
Clearly it's possible to use Spring (or any other DI framework) in an undisciplined fashion and wind up creating an unintelligible stew of code. There's more going on here than just wiring classes together. 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. Anyway, there are several different groups of people all wanting to exercise different facets of configuration, so we need (a) a clear model of which controls belong to each group, and (b) for each set of controls, a model that makes it comprehensible and usable by the people who use it. DSpace has come a long way in becoming readily extensible, but not far enough I think. It sure would be handy to be able to create a *separable* code tree whose translated form can just be unwrapped over the top of a DSpace instance and taken up automagically. That will take some rules for *how* we have Spring wire stuff up, and what any developer can expect to be wirable. I think this is where the Services framework is aiming. > 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. > I'm not going to suggest that the KernelInit/Manager registration as > an MBean is is entirely necessary as a simple mechanism to retain a > handle on the services for the applications, but it does give a common > means for accessing the services and meets our needs for now. I'm > sure we can find some strategies for simplifying it in the future. I must admit that when I was trying to work out where the starting points are and how everything comes together, this MBean stuff seemed to just be in my way. There's a reason for it to be there but I haven't grasped it yet. Gotta go back and read the code again. > I am promoting the idea that for now DSpace Addon Modules are > jars/wars with spring configuration included in a manner that allows > them to automatically register with the service manager on inclusion > on the classpath. This eases assembly and testing when you do not > have all the application wiring/injection in the central dspace.cfg I > also have enabled the ability to register "Activators" that are > executed after the spring application Context initialization via > spring itself, thus doing away with the need to hardwire them in the > dspace.cfg as well. If we are going to have Spring around, then we definitely should break up its configuration into pieces that belong to various well-delimited subassemblies. User sites have to do too much to weave additional facilities into the base. This is much better than a few years ago, but I think we can and should do still better. > This pretty much makes the dspace-services service manager > implementation just what your asking for... a bunch of Java Beans > instantiated and injected by a Spring Application Context. If you > would rather use injection to wire the services into the application > as well, rather than the application looking up the Kernel as an > MBean. Well that would be an interesting idea to explore the design > of, I would be curious to see if the strategy provides any greater > benefit or simplicity. We can use this in some places, where injection can be done once at startup. Injecting multiple instances that are created and destroyed as needed takes further rewriting so that we ask Spring for them. Instances created by code that is not in our hands, such as an object pooling package, can be handled in Spring but it gets somewhat hairy. At first I was concerned about the amount of wiring we'd need to knit together ~900 classes, and much of it repetitive. Every class that needs configuration, for example, would have to be injected with a reference. But then, with the Services framework, every class that needs configuration has to have its own code to get a reference to the kernel and then ask the ServiceManager for a reference to the ConfigurationService. So maybe it is better to have Spring just poke in the one reference we actually want, N times, since it is there anyway and it supplies all the code we need except for one setter. Hmmm. One can divide the problem of linkage into two sets of cases: o Linking to services which we "just know" are there. E.g. every configurable class assumes (through one convention or another) that configuration is available. If it is absent, the app. breaks horribly, which is okay because configuration is one of those services without which a coherent application doesn't exist. o Linking to optional services opportunistically. Plugins and event listeners make DSpace extensible, but (some) don't have to be present. How do options get found, or even find each other? I think we need to keep these two sets in mind when asking, "how should we link this stuff together?" And for whom are we doing this particular linkage: developers, architects, sysadmin.s, or instance managers? -- Mark H. Wood, Lead System Programmer [email protected] Balance your desire for bells and whistles with the reality that only a little more than 2 percent of world population has broadband. -- Ledford and Tyler, _Google Analytics 2.0_
pgpP8m3R3kHyf.pgp
Description: PGP signature
------------------------------------------------------------------------------ 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
