Graham, 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.
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. 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 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. 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. Mark On Thu, May 27, 2010 at 9:07 AM, Graham Triggs <[email protected]> wrote: > I'll add an extra note to all of this. > > It's important to not just look at the specifics of one option, but to > consider what the alternatives could be. > > The obvious starting point there would be to look at what it would mean to > let Spring (and [possibly] SpringDM) simply be Spring, and only wire the > 'service' beans through IoC, without pushing it under another layer. > > G > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Dspace-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspace-devel > > -- Mark R. Diggory Head of U.S. Operations - @mire http://www.atmire.com - Institutional Repository Solutions http://www.togather.eu - Before getting together, get t...@ther ------------------------------------------------------------------------------ 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
