Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

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.

...

Command holds the details about the command we will call. Notice it doesn't parse any XML and most importantly it does not instantiate any Step directly; that is decoupled from the Command and we will show you later how it is assembled. All {{Command}}s do a Command does when getting created is sit there like a good old Java Bean should. It just "IS".

...

Ok, at this point you're saying, "but, wait a second, how did you configure the CommandService, {{Command}}s and {{Step}}s Commands and Steps so they could be available?"  That's the majic of Spring, and there's a couple ways we do this, but I will take the most explicit approach that still will allow you to wire in your own {{Command}}s Commands later.

Step 4: The Spring Configuration

...

We 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 {{Command}}s 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 .

...

One of the luxuries we get from using the autowire byType in our spring configuration within the ServiceManager, is that now we can allow others to toss in their commands regardless of what they are named — we just need to know that they implement our Command interface and provide {{Step}}s Steps we can execute.  For instance, to introduce a command that will allow us to index discovery or operate on the statistics indexes, we can, in our Discovery and Statistics Addons _  add additional src/main/resources/spring/spring-dspace-addon-discovery-services.xml_. Do the following:

Discovery (dspace/trunk/dspace-discovery/dspace-discovery-provider/src/main/resources/spring)

...