Description of the different projects

Detailed dependencies between the projects can be found in the maven POM File (pom.xml) of each project.

Role of Spring

The Implementation of SPCP7 Projects should use contemporary frameworks and middleware to also act as an example for current programming techniques. This and the fact that Spring can be extremely useful in bigger projects to conserve clarity and flexibility predestine Spring for this multi-tier image gallery.
The Spring Framework and its Spring container offer the possibility to easily follow the dependency injection pattern. But what does this mean? This guide will only give a short overview of the Spring dependency injection methods used in the image gallery projects. The Spring Framework itself has a lot more features which will not be discussed at this place. The interested reader can get detailed information of the version of Spring used in this project within the well built Spring documentation at http://static.springframework.org/spring/docs/2.0.x/reference/index.html .
Dependency injection is also known as inversion of control or the Hollywood principle (Do not call us we will call you). But what does this mean in code? Consider a class which needs a class wide instance of another class be it a singleton instance or a fresh one. Normally you would do something like

   ti = new ImplementationOfInterface(); // ti is of type TestInterface and defined as a field.

within our Class with name TestClass .

But what to do if you want to change the implementation? Either you have to use the factory pattern or you have to change the code which uses ImplementationOfInterface every time you change this implementation. If you are using factories you also have to instantiate the factory somewhere or use static methods which both boils down to the usage of an explicit implementation somewhere.
If you use dependency injection (setter injection in our case) you only have to provide a setter for the ti variable and Spring will make sure that the ti variable has a valid instance when TestClass is instantiated.
But how does this work? All classes from which instances should be injected into another class and all classes which should get classes injected have to be defined within one ore more central XML-Files. One or a few central files are a big advantage for large projects because if you change an implementation of a class you only have to change this few files. The image gallery uses three XML definition files. One within the Alfresco content provider (spcp7.imagegallery.cp.impl.alfresco project) and two within the spcp7.imagegallery.abstraction.impl project. They are divided as follows:

spcp7.imagegallery.abstraction.impl/            // project name
        src/main/resources/
    spcp7_image_gallery_applicationContext.xml  // Content Provider Registry specific classes
    spcp7_cp_alfresco_applicationContext.xml    // Alfresco Content Provider specific classes
                                                // Same as the file below. This means if you
                                                // make changes to one of them you have to copy
                                                // the changes to the other version.
                
spcp7.imagegallery.cp.impl.alfresco/            // project name
        src/test/resources/
  spcp7_cp_alfresco_applicationContext.xml      // Initialisation of classes only for testing

A corresponding pair of classes which will be injected and a class with the setters for the injection may look like this within the XML configuration file:

<!-- Only body of xml file. For the big example look at the files described above -->
<bean id="AlfrescoContentRetrieval"
    class="spcp7.imagegallery.impl.alfresco.AlfrescoContentRetrievalImpl">
    <property name="contentComparator" ref="ContentComparator"/>
    <property name="imageFilter" ref="ImageFilter"/>
    <property name="alfrescoValidation" ref="AlfrescoValidation"/>
    <property name="generalValidation" ref="GeneralValidation"/>
    <property name="alfrescoUtils" ref="AlfrescoUtils"/>
</bean>
<bean id="GeneralValidation" 
 class="spcp7.imagegallery.abstractionlayer.util.GeneralValidation" />
<bean id="ContentComparator"
 class="spcp7.imagegallery.abstractionlayer.util.ContentComparatorImpl" 
 scope="prototype"/>
<bean id="ImageFilter"
 class="spcp7.imagegallery.abstractionlayer.util.ImageFilterImpl" 
 scope="prototype"/>
<bean id="AlfrescoValidation"
 class="spcp7.imagegallery.impl.alfresco.utils.AlfrescoValidation"/>
<bean id="AlfrescoUtils"
 class="spcp7.imagegallery.impl.alfresco.utils.AlfrescoUtils"/>

Within this example the bean with id AlfrescoContentRetrieval class must have setters with e.g. name setContentComparator for contentComparator , imageFilter , alfrescoValidation , generalValidation and alfrescoUtils properties, which are defined with their absolute class name as beans below the AlfrescoContentRetrieval -Bean.

A great benefit of Spring's dependency injection is the fact that it is even possible to insert instances of classes into a list which is used within spcp7_image_gallery_applicationContext.xml to create instances of the available Content Providers. (If you want to know how to implement a new Content Provider read the appropriate HOWTO). This possibility and the fact that you can also inject a Spring instantiated Java Persistence API entityManagerFactory (http://static.springframework.org/spring/docs/2.0.x/reference/orm.html#orm-jpa-setup-lemfb ) make Spring the ideal enhancement for this project.

So far so good. You might be curious after all about how classes from a Spring container can be received and how the container itself gets instantiated as against a normal factory. In this project we use a static method within spcp7.imagegallery.abstractionlayer.impl.internal.ContentProviderRegistrySingleton.java to instantiate or receive an instance of the applicationContext or an instance of the central ContentProviderRegistry class. There are several possibilities. Spring actually provides nice ways to instantiate the applicationContext within web applications. At this point you get to know on how this can be done. The method is not used for this project because it did not work with the project versions of Spring, ICEFaces etc (probably because of the already defined web.xml listeners of ICEFaces) and it is also not needed because the static singleton method provides a more convenient way especially when testing comes into play.

Furthermore Spring can handle the instantiation of Java Server Faces backing beans (look here ). This was also not done because it also did not work with ICEFaces and the other frameworks within the portlet context. This is not remarkable because the portlet session context is quite complex itself and so Spring's context might be destroyed.
The image gallery only has very few backing beans and so it is alright if the instantiation is handled by ICEFaces itself.