Separation of concerns (see also spcp7 in general )

Description of the different projects

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

spcp7.imagegallery (pom project)

This project is the entry point for the image-gallery projects. It resides directly below the spcp7 root and is the parent project of all projects in the file hierarchy below. Hence all dependencies which should be used in the child projects go into its pom.xml file.

spcp7.imagegallery-war (war project)

This project is the main project of the image gallery and contains view and view logic components. It directly or indirectly uses all other image gallery projects. If you want to change the view of the gallery dig deeper at this point.

spcp7.imagegallery.abstraction.api (jar project)

This project contains all interfaces of the abstraction layer of the image gallery. The Abstraction layer contains everything which is related to Content Provider Registry or Content Provider. If you want to implement a Content Provider necessary interfaces can be found here.

spcp7.imagegallery.abstraction.impl (jar project)

This project contains the implementation of the Content Provider Registry.

spcp7.imagegallery.abstraction util (jar project)

This project contains all utility classes which might be relevant for more than one image gallery project.

spcp7.imagegallery.cp.impl.alfresco (jar project)

This project contains the implementation of an Alfresco Content Provider. Currently this is the only Content Provider. If you want to implement a new Content provider look at the appropriate HOWTO below the HOWTO-Section of this homepage.

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 .
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
    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
  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"
    <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 id="GeneralValidation" 
 class="spcp7.imagegallery.abstractionlayer.util.GeneralValidation" />
<bean id="ContentComparator"
<bean id="ImageFilter"
<bean id="AlfrescoValidation"
<bean id="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 ( ) 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 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.