Page History

...

What we see is that the Script Launcher hardwires all Business Logic to XML configuration, and while this is a great prototype, certainly not very extensible.  For instance, what if we may want to initialize other details into the command or step?  What if we are calling something that uses a different method than a static main to execute?  and what if we want to set certain properties on its state beforehand? To do these tasks we would either need to rewrite the class with a main method, or we would either need to extend the launcher to do this, or add those details from the dspace.cfg. So what we will show you in refactoring this code is that you can get a great deal more flexibility out of Spring with a great deal less work on your part. Spring applies the concept of "inversion of control". The Inversion of Control (IoC) and Dependency Injection (DI) patterns are all about removing dependencies from your code.  In our case, we will be removing a dependency on the  hardcoded XML file for configuration and liberating the Command/Step domain model from the ScriptLauncher, allowing for possible reuse in other areas of the application.

Spring Based DSpace Script Launcher

Firstly we recognize that we have few domain objects here that we can work with: Command, Step and Arguments are all ripe to be defined as interfaces or implementation classes that capture the domain of the Launcher that we will execute.  Perhaps by creating these we can disentangle the Business logic of the Launcher from its configuration in XML.  Doing so without Spring, we might still have to bother with parsing the XML file.  So with Spring we get a luxury that we no longer need to think about that.

...

Step 4: The Spring Configuration

Wiki MarkupWe place the Spring Configuration in a special place for the DSpace Service Manager, and the Service Manager is pretty smart about finding these.  It expects us to place these files in a couple different places.  But in our example I will show the current places in DSpace  It expects us to place these files in a couple different places.  But in our example I will show the current places in DSpace 1.7.x. In all cases we want to be placing these files under _\[dspace-module\]/src/main/resources/spring_

spring-dspace-core-services.xml

This location allows us to "augment the existing services without actually overriding them". We generally reserve this for the core DSpace services like RequestService, ConfigurationService, SessionService, etc.

...

spring-dspace-addon-

...

[a

...

unique

...

name

...

]-services.xml

This location allows us to "override" the XML loading a specific service by overwriting its configuration in one of our own.

Now to show you our Launcher Service. The trick here is we will use a feature in Spring called autowire byType. It will collect all the Commands and wire them together for us, no matter the type. I'll save you having to view the whole file — you can see it here if you like .

...