Typiskt när det gäller JMS så vill man kunna:

• Publicera meddelanden
• Ta emot meddelanden asynkront

Om man inte använder Spring så brukar man lösa detta genom att:

• Publicera meddelanden via JMS-API:et
• Ta emot meddelanden via MDB (Message Driven Beans)

Publicering av meddelanden

Problemet med att använda JMS-API:et för att publicera meddelanden är att det blir mycket onödig kod som måste skrivas. Checkade exceptions måste hanteras, en rad objekt såsom connection factory, session, destinations etc. måste sparas undan, om JMS-kopplingen går ner så måste hantering för "re-connect" byggas etc.

Klassen JmsTemplate är den centrala klassen för publicering av meddelanden. Denna klass baserar på designmönstret template method som tidigare beskrivits i inlägget om Spring JDBC.

Följande exempel visar hur publicering av meddelanden ser ut om man inte använder JmsTemplate utan går direkt mot JMS API:et

public class RawJmsMessageSender {
    private boolean isTopic;
    private ConnectionFactory connectionFactory;

    public void sendMessage(String destinationName, String messageText) {
        try {
            Connection connection = connectionFactory.createConnection();
            Session session = connection.createSession(
                    true, Session.AUTO_ACKNOWLEDGE);
            Destination destination = createDestination(
                    session, destinationName);
            MessageProducer producer =
                session.createProducer(destination);
            TextMessage message = session.createTextMessage();
            message.setText(messageText);
            producer.send(destination, message);
        } catch (JMSException e) {
            // Do error handling here...
            throw new IllegalStateException("Unable to send message", e);
        }
    }

    private Destination createDestination(
            Session session,
            String destinationName) throws JMSException {

        if (isTopic()) {
            return session.createTopic(destinationName);
        } else {
            return session.createQueue(destinationName);
        }
    }

    public boolean isTopic() {
        return isTopic;
    }

    public void setTopic(boolean isTopic) {
        this.isTopic = isTopic;
    }

    public void setConnectionFactory(
            ConnectionFactory connectionFactory) {

        this.connectionFactory = connectionFactory;
    }
}

<bean
  id="rawJmsMessageSender"
  class="se.cygni.sample.spring.jms.RawJmsMessageSender">

    <property name="connectionFactory" ref="connectionFactory"/>
</bean>

I exemplet antas att en ConnectionFactory finns tillgänglig. Klassen RawJmsMessageSender kan alltså skicka JMS-meddelanden på en kö eller topic. Exemplet ovan fungerar inte så bra i verkligheten eftersom en ny connection, session och destination skapas varje gång. Ett runtime exception som är helt otypat (IllegalStateException) skapas när ett fel uppstår.

Ovanstående exempel kan förenklas genom att använda JmsTemplate. På köpet får man dessutom möjlighet att använda en bättre felhantering via Springs JMS-exception hierarki och betydligt mindre kod. Kolla in följande för att se hur JmsTemplate kan användas.

public class JmsTemplateMessageSender {
    private JmsTemplate jmsTemplate;

    public void sendMessage(
            String destinationName, final String messageText) {

        jmsTemplate.send(destinationName, new MessageCreator() {
            public Message createMessage(
                    Session session) throws JMSException {

                return session.createTextMessage(messageText);
            }
        });
    }

    public void setJmsTemplate(JmsTemplate jmsTemplate) {
        this.jmsTemplate = jmsTemplate;
    }
}

<bean
  id="jmsTemplateMessageSender"
  class="se.cygni.sample.spring.jms.JmsTemplateMessageSender">

    <property name="jmsTemplate" ref="jmsTemplate"/>
</bean>

<bean
  id="jmsTemplate"
  class="org.springframework.jms.core.JmsTemplate">

    <property name="connectionFactory" ref="connectionFactory"/>
</bean>

JmsTemplate tillhandahåller en rad template-metoder och i exemplet ovan används send(String, MessageCreator). De eventuella exceptions som kan slängas hanteras av JmsTemplate. JmsTemplate kan konfigureras för att använda både köer och topics och många av de attribut som kan konfigureras på sessionen kan konfigureras direkt på template-objektet. Förutom send-metoden finns andra template-metoder, kolla exempelvis in dokumentationen för convertAndSend som kan konvertera en POJO till ett Message via en MessageConverter.

Mottag av meddelanden

Vid asynkront mottag av JMS-meddelanden måste interfacet javax.jms.MessageListener implementeras. Message Driven Beans (MDB) implementerar detta interface och när MDB:er används hanterar applikationsservern trådning och transaktionshantering av MDB:n. Om man inte har någon applikationsserver kan Springs Message Driven POJOs (MDP) vara till hjälp för att ta emot meddelanden.

MDP:s implementeras med hjälp av en så kallad ListenerContainer som hanterar trådning och pollar kön/topicen efter meddelanden. De tre varianter som finns är:

• SimpleMessageListenerContainer
  Den enklaste av de tre containrarna. Denna container startar ett förutbestämt antal JMS-sessioner vid uppstart av containern.
• DefaultMessageListenerContainer
  Ett mellanting mellan SimpleMessageListenerContainer och ServerSessionMessageListenerContainer som erbjuder vissa konfigurationsmöjligheter. Framför allt så kan denna container ingå i transaktioner som hanteras externt via ex. en TransactionManager.
• ServerSessionMessageListenerContainer
  Denna container kan konfigureras med extern transaktionshantering och användning av ServerSessionPool SPI för hantering av JMS-sessioner.

Nedanstående exempel visar hur man enkelt kan sätta upp en MDP som lyssnar på en kö som finns tillgänglig i JNDI-trädet.

public class JmsMessageReceiver implements MessageListener {
    public void onMessage(Message message) {
        TextMessage textMessage = (TextMessage) message;
        System.out.println("Received message: " + textMessage);
    }
}

<bean
  id="jndiTemplate"
  class="org.springframework.jndi.JndiTemplate">

    <property name="environment">
        <props>
            <prop key="java.naming.factory.initial>vendor stuff</prop>
        </props>
    </property>
</bean>

<bean
  id="jmsMessageReceiver"
  class="se.cygni.sample.spring.jms.JmsMessageReceiver" />

<bean
  id="jmsContainer"
  class="org.springframework.jms.listener.DefaultMessageListenerContainer">

    <property name="connectionFactory" ref="connectionFactory"/>
    <property name="destination" ref="destination"/>
    <property name="messageListener" ref="jmsMessageReceiver" />
    <property name="concurrentConsumers" value="5" />
</bean>

<bean
  id="destination"
  class="org.springframework.jndi.JndiObjectFactoryBean"
  depends-on="connectionFactory">

    <property name="jndiName" value="myQueue" />
    <property name="jndiTemplate" ref="jndiTemplate" >
</bean>

I exemplet ovan används fem trådar som specificeras via attributet concurrentConsumers. Dessa trådar kommer kontinuerligt att polla JMS-kön som är specificerad via bönan destination. När ett meddelande hittas kommer det att vidarebefordras till jmsMessageReceiver-instansen som då måste vara trådsäker.

För mer information om Spring JMS kolla in den officiella dokumentationen.

Templating

Ett designmönster som används flitigt i Spring är "template method". En template-metod definierar ett skelett för en algoritm. Algoritmen är abstrakt och det är upp till subklasser att definiera det konkreta beteendet för algoritmen. Nedanstående exempel som är kraftigt influerat från wikipedia visar hur mönstret fungerar:

/** A game that can be played... */
public interface Game {
    void initializeGame();
    void makePlay(int player);
    boolean endOfGame();
    void printWinner();
} 

/** Concrete implementation of the chess game... */
public class Chess implements Game {
    public void initializeGame() {
        // do chess stuff...
    } 

    public void makePlay(int player) {
        // do chess stuff...
    } 

    public boolean endOfGame() {
        // do chess stuff...
        return false;
    } 

    public void printWinner() {
        // do chess stuff...
    }
} 

/** Concrete implementation of the monopoly game... */
public class Monopoly implements Game {
    public void initializeGame() {
        // do monopoly stuff...
    } 

    public void makePlay(int player) {
        // do monopoly stuff...
    } 

    public boolean endOfGame() {
        // do monopoly stuff...
        return false;
    } 

    public void printWinner() {
        // do monopoly stuff...
    }
} 

/** The class containing the template method. */
public class GameTemplate {
    /**
     * This is a template method that plays the provided
     * game using a specified algorithm (initialize,
     * play, end, print winner)
     *
     * The template method is common to several games in
     * which players play against the others, but only one
     * player is playing at a given time.
     */
    public void play(int playersCount, Game game) {
        game.initializeGame(); 

        int j = 0;
        while (!game.endOfGame()){
            game.makePlay(j);
            j = (j + 1) % playersCount;
        } 

        game.printWinner();
    }
}

Exemplet ovan visar hur en algoritm appliceras på ett Game-objekt i metoden play. Exemplet är en aning förändrat jämfört med originalet så till vida att klassen GameTemplate inte är ett Game utan endast innehåller själva algoritmen för att få en lösare koppling mellan algoritmen och de faktiska Game-objekten.

Nu när vi känner till designmönstret "template method" kan vi kika vidare på templaten som tillhandahålls av Spring för JDBC-relaterade operationer, nämligen JdbcTemplate.

JdbcTemplate

Klassen JdbcTemplate är kärnan i den modul som kallas spring-jdbc. Klasserna i denna modul används när access till databasen sker via JDBC snarare än via ett O/R-mappningsramverk såsom Hibernate.

Att använda rå JDBC kan medföra en hel del problem för utvecklaren där Connections, Statements, ResultSets måste stängas, exceptions måste fångas osv. Kod som är skriven för rå JDBC-användning är ofta väldigt utförlig (verbose) och leder lätt till fel (såsom att glömma att stänga ett statement). Springs JdbcTemplate hjälper utvecklaren med många delar av de uppgifter som krävs för att använda JDBC.

Tabellen ovan visar de delar som JdbcTemplate hjälper dig med jämfört med att använda rå JDBC.

Nedanstående exempel visar vanlig användning av rå JDBC med en enkel parameteriserad SELECT och en mappning mellan ett Person-objekt och ett ResultSet.

private static final String PERSON_QUERY =
        "select first_name, last_name, phone_number "
        + "from person where last_name = ?"; 

public List getPersonList1() {
    List list = new ArrayList();
    Connection connection = null;
    PreparedStatement statement = null;
    try {
        connection = getConnection();
        statement = connection.prepareStatement(PERSON_QUERY);
        statement.setString(1, "Svensson");
        ResultSet rs = statement.executeQuery();
        while (rs.next()) {
            Person person = new Person(
                rs.getString("first_name"),
                rs.getString("last_name"),
                rs.getString("phone_number"));
                list.add(person);
        }
        rs.close();
    } catch (SQLException e) {
        // handle exception somehow...
    } finally {
        if (connection != null) {
            try {
                connection.close();
            } catch (SQLException e) {
                // handle exception somehow...
            }
        }

        if (statement != null) {
            try {
                statement.close();
            } catch (SQLException e) {
                // handle exception somehow...
            }
        }
    }

    return list;
}

Exemplet kan förenklas avsevärt genom användning av JdbcTemplate vilket metoden getPersonList2 i nedanstående exempel visar.

public List getPersonList2 () {
    RowMapper personMapper = new RowMapper() {
        // Maps a row to a Person
        public Object mapRow(
                ResultSet rs,
                int rowNum) throws SQLException {

            return new Person(
                rs.getString("first_name"),
                rs.getString("last_name"),
                rs.getString("phone_number"));
        }
    };

    return getJdbcTemplate().query(
        PERSON_QUERY, new Object[] {"Svensson"}, personMapper);
}

Vi antar i exemplet ovan att man kan få tag på en JdbcTemplate via metoden getJdbcTemplate().

Några saker värda att notera:

• Kod för att hantera connections, statements etc. saknas helt. Detta hanteras av JdbcTemplate som öppnar och stänger alla resurser.
• Mappning mellan SQL-resultatet och affärsobjektet sker i en RowMapper. Detta är ett tydligt mönster och RowMapper-objektet kan återanvändas om det deklareras utanför metoden. Förutom RowMapper finns även andra sätt att mappa data och dessa kan återfinnas i Springdokumentationen.
• Ingen felhantering krävs. Alla eventuella exceptions fångas av JdbcTemplate och konverteras sedan till Springs egna unchecked exceptions mha. SQLExceptionTranslator. Istället för att kasta ett checked exception med en kryptisk databasunik felkod kan tydliga exceptions såsom BadSqlGrammarException eller OptimisticLockingFailureException kastas. De databaser som supportas out-of-the-box är DB2, Derby, H2, HSQL, Informix, MS-SQL, MySQL, Oracle, PostgreSQL och Sybase. Naturligtvis går det även att plugga in egna SQLExceptionTranslators.

Det finns även några inbyggda RowMappers. Metoden queryForInt som exemplifieras nedan skapar en intern RowMapper där ett SQL-resultat mappas mot ett heltal.

public int countPeople() {
    return getJdbcTemplate().queryForInt(
            "select count(*) from person ");
}

I exemplen ovan har endast SELECT-frågor mot databasen ställts. Det finns även metoder för att utföra uppdateringar, se exemplet nedan för en enkel parameteriserad uppdatering:

private static final String UPDATE_PERSON =
    "update person set phone_number = ?"
    + "where first_name = ? and last_name = ?";

public void updatePhoneNumber(
        String firstName, String lastName, String phoneNumber) {

    getJdbcTemplate().update(
            UPDATE_PERSON,
            new Object[] {phoneNumber, firstName, lastName});
}

JdbcTemplate behöver endast konfigureras upp med en datakälla. Det finns några bekväma klasser att ärva från för att enkelt få tag på JdbcTemplate-objektet. Klassen JdbcDaoSupport kan användas för DAO-objekt medan klassen AbstractTransactionalDataSourceSpringContextTests fungerar bra för JUnit-tester. Nedanstående exempel visar detta.

Så här kan en DAO-klass se ut:

public class MyDao extends JdbcDaoSupport {
    private static final String UPDATE_PERSON =
        "update person set phone_number = ? "
        + "where first_name = ? and last_name = ?";

    public void updatePhoneNumber (
            String firstName, String lastName, String phoneNumber) {

        getJdbcTemplate().update(
                UPDATE_PERSON,
                new Object[] {phoneNumber, firstName, lastName});
    }
}

När en DAO konfigureras så måste en DataSource injectas, detta kan exempelvis ske via en JNDI-uppslagning:

<bean
  id="myDataSource"
  class="org.springframework.jndi.JndiObjectFactoryBean">

    <property name="lookupOnStartup" value="false" />
    <property name="proxyInterface" value="javax.sql.DataSource" />
    <property name="resourceRef" value="true" />
    <property name="jndiName" value="jdbc/myds" />
</bean>

Själva DAO-objekten kan exempelvis deklareras i en egen fil som kan användas både för produktion och för test.

<bean id="myDao" class="se.cygni.sample.spring.template.jdbc.MyDao">
    <property name="dataSource" ref="dataSource" />
</bean>

När applikationen ska konfigureras för test så kan en DataSource konfigureras utan JNDI-uppslagning:

<bean
  id="myDataSource"
  class="org.springframework.jdbc.datasource.DriverManagerDataSource" >

    <property name="driverClassName"
        value="oracle.jdbc.driver.OracleDriver" />
    <property name="url" value="jdbc:oracle:thin:@host:port:schema" />
    <property name="username" value="scott" />
    <property name="password" value="tiger" />
</bean>

Ett JUnit-test kan se ut enligt följande:

public class MyDaoTest
        extends AbstractTransactionalDataSourceSpringContextTests {

    private MyDao dao;

    protected String[] getConfigLocations() {
        return new String[] {
                "testDataSourceContext.xml",
                "daoContext.xml"
        };
    }

    public void testDao() {
        dao.updatePhoneNumber("Johnny", "Puma", "555-555 5555");

        int count = getJdbcTemplate().queryForInt(
            "select count(*) from person "
            + "where first_name = 'Johnny' "
            + "and last_name = 'Puma' "
            + "and phone_number = '555-555 5555'");

        assertTrue(count == 1);
    }

    public void setMyDao(MyDao dao) {
        this.dao = dao;
    }
}

I testet ovan visas hur dels MyDao injectas i testklassen eftersom filen daoContext.xml anges som en config-location. Även filen testDataSourceContext.xml inkluderas vilket leder till att en DataSource finns tillgänglig och då injectas denna DataSource i basklassen AbstractTransactionalDataSourceSpringContextTests vilket leder till att metoden getJdbcTemplate blir tillgänglig i testfallet.

Det finns även stöd för Java 5 i Springs JDBC modul. Genom att ärva klassen SimpleJdbcDaoSupport istället för JdbcDaoSupport i din DAO kan Java 5 metoder användas via klassen SimpleJdbcTemplate. Se exemplet nedan.

public List<Person> getPeople() {
    ParameterizedRowMapper<Person> rowMapper =
        new ParameterizedRowMapper<Person>() {
            public Person mapRow(ResultSet rs, int rowNum)
                    throws SQLException {

                return new Person(
                        rs.getString("first_name"),
                        rs.getString("last_name"),
                        rs.getString("phone_number"));
            }
    };

    return getSimpleJdbcTemplate().query(
            "select first_name, last_name, phone_number from person",
            rowMapper);
}

För mer information om Spring och JDBC rekommenderas Springdokumentationen och JavaDoc för JdbcTemplate.

public class Person {
    private Long id;
    private String firstName;
    private String lastName;

    public Person(String firstName, String lastName) {
        this.firstName = firstName;
        this.lastName = lastName;
    }

    public Long getId() {
        return id;
    }

    private void setId(Long id) {
        this.id = id;
    }

    public String getFirstName() {
        return firstName;
    }

    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }

    public String getLastName() {
        return lastName;
    }

    public void setLastName(String lastName) {
        this.lastName = lastName;
    }
}

And a service interface allowing basic CRUD operations for a person :

public interface PersonService {
    public List read(Person p);
    public void save(Person p);
    public void delete(Person p);
}

We want a web interface that allow the user to save a new Person or to modify an existing person. For this I'll use a SimpleFormController. It will be responsible for presenting the form, calling the person's service save(Person), and forwarding the user to a success page (when the person has correctly been saved).

This controller will be configured in a context file like this :

<beans xmlns="http://www.springframework.org/schema/beans"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.springframework.org/schema/beans
                            http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">

    <bean name="/editPerson" class="myProject.web.EditPersonController">
        <property name="commandClass" value="myProject.Person"/>
        <property name="formView" value="personForm"/>
        <property name="successView" value="personSaved"/>
    </bean>

</beans>

To have our test being able to load a context, we'll use the jUnit's @RunWith annotation, and to make our test load our specific context we'll use the Spring's @ContextConfiguration annotation. For more details on Spring's test API, see the chapter 13 of the Spring framework documentation.

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations={"/myProject/EditPersonControllerTest-context.xml"})
public class EditPersonControllerTest {
    @Autowired
    EditPersonController controller;

    /**
     * Tests the creation of a new Person.
     **/
    @Test
    public void testCreate() {

    }
}

The @Autowired annotation will do "by-type" bean injection. This means that since our context contains a single bean of type myProject.web.EditPersonController, that bean (the one we named "/editPerson") will be injected in field "controller" at runtime, before the test methods are called. But for now, the test just doesn't compile because we haven't created the EditPersonController class. Let's create this controller :

import org.springframework.web.servlet.mvc.SimpleFormController;

public class EditPersonController extends SimpleFormController {
}

It does nothing for the moment, except allowing the test to compile.
To test this newly created controller, we need a HttpServletRequest and a HttpServletResponse object. These objects will be passed to the controller's handleRequest method. Our test is, of course, not using a servlet engine that is able to create these objects for us, so we have to mock them. Here comes the use of the Spring's MockHttpServletRequest and MockHttpServletResponse classes. With these objects, we can easily simulate a HTTP request that will be forwarded to our controller. We can then verify if a "GET" HTTP call will make our controller send the person form :

/**
 * Tests the creation of a new Person.
 **/
@Test
public void testCreate() {
    MockHttpServletRequest request = new MockHttpServletRequest();
    request.setMethod("GET");
    ModelAndView mv = controller.handleRequest(request, new MockHttpServletResponse());
    assertEquals(controller.getFormView(), mv.getViewName());
}

The ModelAndView object is used to determine which view the controller chose to send to the user.
Instead of doing :
assertEquals(controller.getFormView(), mv.getViewName());
We could have done :
import static org.springframework.test.web.ModelAndViewAssert.*;
[...]
assertViewName(mv, controller.getFormView());
[...]

Now the user is provided a form with two input fields. One for the "firstname" and one for the "lastname". He fills those fields and submit the form. The controller is then called with the "fistname" and "lastname" posted by the user. It must normally save the person and return the "successView" which we named "personSaved" (see the XML context defined previously). Let's now add this behavior to our test :

import static org.springframework.test.web.ModelAndViewAssert.*;

...

/**
 * Tests the creation of a new Person.
 **/
@Test
public void testCreate() {
    MockHttpServletRequest request = new MockHttpServletRequest();
    request.setMethod("GET");
    ModelAndView mv = controller.handleRequest(request, new MockHttpServletResponse());
    assertEquals(controller.getFormView(), mv.getViewName());

    request = new MockHttpServletRequest();
    request.setMethod("POST");
    request.setParameter("firstName", "Richard");
    request.setParameter("lastname", "Barabé");
    mv = controller.handleRequest(request, new MockHttpServletResponse());
    assertViewName(mv, controller.getSuccessView());
}

So far we've tested that while creating a new Person, the user first asks the Person form (with an HTTP GET call), then submits that form (with an HTTP POST call that details person's information) and is redirected to a success page when finished. We can say we tested the navigation part of the "create new Person" use case.

But, did the controller really saved the Person ? In other words : Did the controller called the PersonService's save(Person p) method ? To test this, I will use EasyMock to mock a PersonService, tell EasyMock I want this PersonService's save(Person p) method to be called once with the correct person, and then I will pass that PersonService mock to the controller. Once done, my test will know if the controller really called the PersonService adequately. Here is the code of the test :

import static org.easymock.EasyMock.*;

...

/**
 * Tests the creation of a new Person.
 **/
@Test
public void testCreate() {
    MockHttpServletRequest request = new MockHttpServletRequest();
    request.setMethod("GET");
    ModelAndView mv = controller.handleRequest(request, new MockHttpServletResponse());
    assertEquals("personForm", mv.getViewName());

    request = new MockHttpServletRequest();
    request.setMethod("POST");
    request.setParameter("firstName", "Richard");
    request.setParameter("lastname", "Barabé");
    
    // Create the service's imitation
    PersonService serviceMock = createMock(PersonService.class);
    controller.setPersonService(serviceMock);
    // The save method should be called with "Richard Barabé"
    serviceMock.save(new Person("Richard", "Barabé"));
    // The save method should be called only once
    expectLastCall().once();
    // Finished telling easymock how my service should be used.
    replay(serviceMock);
    

    mv = controller.handleRequest(request, new MockHttpServletResponse());
    assertViewName(mv, "personSaved");
    
    // Verify that the service have been used as we expect
    // (method save called once with "Richard Barabé")
    verify(serviceMock);
    
}

For this to compile, I need to add a PersonService field and its getter/setter in the controller :

import org.springframework.web.servlet.mvc.SimpleFormController;
import myProject.PersonService;
public class EditPersonController extends SimpleFormController {
    private PersonService service;

    public void setPersonService(PersonService service) {
        this.service = service
    }

    public PersonService getPersonService() {
        return this.service;
    }
}

Now the test asserts the service has been called correctly. As we run it, we can see it fails with the following message :

java.lang.AssertionError:
  Expectation failure on verify:
    save(myProject.Person@1f2cea2): expected: 1, actual: 0
	at org.easymock.internal.MocksControl.verify(MocksControl.java:82)
	at org.easymock.EasyMock.verify(EasyMock.java:1410)
        ...

This just means our controller didn't call the service's save method as expected. Let's make our controller do it's job by adding the expected call :

import org.springframework.web.servlet.mvc.SimpleFormController;
import myProject.PersonService;
public class EditPersonController extends SimpleFormController {
    private PersonService service;

    protected doSubmitAction(Object o) {
        this.service.save((Person) o)
    }

    public void setPersonService(PersonService service) {
        this.service = service
    }

    public PersonService getPersonService() {
        return this.service;
    }
}

Running the test now should succeed. But, unfortunately, the bar is red again. For time consideration, I'll leave aside the investigation and go right to the solution : we did not override the equals and hashcode methods of the Person class. Our controller that received the form submission did create a new Person, setting its first and last name. It then passed this new object to the doFormSubmitAction(Object) that called our mock passing the new person. But we told EasyMock we expected our service to be called with another Person object. Default implementation of the equals method in object makes the following statement false :
(new Person("Richard","Barabé")).equals(new Person("Richard","Barabé"))
So let's implement those hashCode and equals methods (I use Eclipse to generate this "boiler plate" code) :

public class Person {
    private Long id;
    private String firstName;
    private String lastName;

    public Person(String firstName, String lastName) {
        this.firstName = firstName;
        this.lastName = lastName;
    }

    public Long getId() {
        return id;
    }

    private void setId(Long id) {
        this.id = id;
    }

    public String getFirstName() {
        return firstName;
    }

    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }

    public String getLastName() {
        return lastName;
    }

    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

    @Override
    public int hashCode() {
    	final int prime = 31;
    	int result = 1;
    	result = prime * result
    	        + ((firstName == null) ? 0 : firstName.hashCode());
    	result = prime * result
    	        + ((lastName == null) ? 0 : lastName.hashCode());
    	return result;
    }

    @Override
    public boolean equals(Object obj) {
    	if (this == obj)
    	    return true;
    	if (obj == null)
    	    return false;
    	if (getClass() != obj.getClass())
    	    return false;
    	final Person other = (Person) obj;
    	if (firstName == null) {
    	    if (other.firstName != null)
    	        return false;
    	} else if (!firstName.equals(other.firstName))
    	    return false;
    	if (lastName == null) {
    	    if (other.lastName != null)
    	        return false;
    	} else if (!lastName.equals(other.lastName))
    	    return false;
        return true;
    }
}

Now the code behaves correctly when we have two persons with the same fistName and lastName. And that green bar is back again.

There we are, we have successfully developped and tested our controller. This article is to be continued, and next time we'll go over the Validator and View implementation.

There are three things that needs to be done: first we need to start up S2AP with Terracotta enabled, then we need to make Terracotta classes visible to OSGi bundles and finally we have to baptize the class loader in your bundle so that Terracotta can properly identify your clustered objects.

I assume that both Terracotta 2.6.2 and SpringSource Application Platform RC-1 is installed.

Wrap the Startup Script

In order to enable Terracotta in the platform we need to start the JVM with some additional arguments. The easiest way is to wrap the start up script with another script that set the JAVA_OPTS variable. I created a script called startup-dso.bat in %PLATFORM_HOME%/bin:

setlocal
set TC_INSTALL_DIR=<path_to_local_Terracotta_home>
set TC_CONFIG_PATH=<path\to\tc-config.xml>
call %TC_INSTALL_DIR%\bin\dso-env.bat -q
set JAVA_OPTS=%TC_JAVA_OPTS%
call startup.bat
endlocal

Remember to generate a Terracotta boot jar for you environment.

If you run the script it will look promising until you see java.lang.ClassNotFoundException: com.tc.object.bytecode.Manageable in the console. This is because the OSGi bundle class loader cannot see the Terracotta classes that are loaded by the boot class loader.

Delegate Loading of Terracotta Classes

We need to tell the OSGi container in S2AP to delegate the loading of Terracotta classes to the boot class loader. This is achieved by modifying the java5-platform.profile or java6-platform.profile (as appropriate for the level of Java which you're using) found in the platform's lib directory and adding Terracotta's packages (com.tc.*) to the list under the org.osgi.framework.bootdelegation key.

Naming class loaders

Now only one more thing remains to do: the class loader for the bundle that contains the objects you want to cluster needs to be named and registered:


static {
NamedClassLoader ncl = (NamedClassLoader) myClass.getClassLoader();
ncl.__tc_setClassLoaderName("bundle_name");
ClassProcessorHelper.registerGlobalLoader(ncl);
}


The code above have to be run when your bundle is loaded, I just added it to the Spring managed bean that i wanted to cluster. This is a hack as you introduce compile time dependencies to Terracotta and you can only cluster objects from bundles that you can modify. But we will have to do with this until Terracotta get better support for OSGi.

Add the terracotta boot jar to you build path to satisfy the compile time dependency. Make sure that your ordinary runtime classpath doesn't contain the boot jar.

Thats it!

Spring HTTP Invokerの実験をhttp://marxsoftware.blogspot.com/2008/07/simple-spring-http-remoting-example.htmlでしていたとき、Springのドキュメントも見ていました。SimpleUrlHandlerMappingというものが例の中でつかわれておりそれに疑問をもちましたが、SpringのドキュメントにはHTTP Invokerのところでは、何もかかれていません。（MVC Controllerでかかれていた。）ためしに、その定義をなくして、例を動かすと、（もちろん）エラーとなる。もし、例がなく、Springのドキュメントだけだったら、自分ひとりで、HTTP　Invokerを動かすことはできなかったに違いない。

Springはすばらしいフレームワークだけれど、きらいなところがひとつ。ドキュメントに書かれてあることを使ってみようとすることが難しい。ひとつの理由は、全く完全に書かれた例がない。（すこしはあるかも？）たくさんのコードの例がでてくるけど、たいていは完全ではないか、何かが、書かれていない。読者がすでに基本的なことを知っている場合はいいけれど。しかしこの前提は間違っている。完全な例を常につけておくべきだと思う。

Considering how long Spring has been in use, and its popularity, how could such vulnerabilities remain hidden so long? After all, isn't one of the hallmarks of open source the strong community vetting? Could it be that the shift towards single vendor-driven open source is making open source riskier?

What the Spring vulnerabilities are

Kudos to Ryan Berg, chief scientist and co-founder of Ounce Labs, and Ounce team for uncovering the issues and working with SpringSource to raise awareness.

According to Ounce Labs:

The specific vulnerabilities are "ModelView Injection" and "Data Submission to Non-Editable Fields." These vulnerabilities allow attackers to subvert the expected application logic and behavior, gaining control of the application itself, and access to any data, credentials or keys held in the application.

If your applications use the Spring Framework, be sure to read FAQs from the SpringSource advisory and the Ounce Security Advisory.

The deeper question on open source vetting

Now, the reason this story caught my eye:

"As we put more and more trust into the frameworks that are the foundation of our applications, we need to make sure we understand the security decisions made so we can make the right implementation choices."

Two key benefits of OSS are the ability to read and understand the code we use and that "many eyes scouring the code" makes the product more secure.

Considering the millions of downloads of the Spring Framework, should we have expected someone to discover these security holes earlier? Or do developers use what the next guy/gal is using, trusting that "someone" has done the due diligence?

How should we interpret the news versus the long-held belief of increased security as a result of "more eyes scouring the code"? Could that be a trait of merit-based OSS projects that isn't likely to show up in OSS projects where a single vendor writes the code?

If developers outside the company can't contribute code, what is the likelihood that a developer will look at a piece of code within the project and ask, "How can I make this better?" -- and in the process uncover a potential security issue?

I'm really asking a fundamental question: Are merit-based OSS projects more secure than single-vendor-driven OSS projects?

Thoughts?

PS: I should state: "The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions."

There are three types of dependency injection:

• Constructor Injection (e.g. Pico container, Spring etc): Dependencies are provided as constructor parameters.
• Setter Injection (e.g. Spring): Dependencies are assigned through JavaBeans properties (ex: setter methods).
• Interface Injection (e.g. Avalon): Injection is done through an interface. Note: Spring supports only Constructor and Setter Injection

3. What are the benefits of IOC (Dependency Injection)?

Benefits of IOC (Dependency Injection) are as follows:

• Minimizes the amount of code in your application. With IOC containers you do not care about how services are created and how you get references to the ones you need. You can also easily add additional services by adding a new constructor or a setter method with little or no extra configuration.

• Make your application more testable by not requiring any singletons or JNDI lookup mechanisms in your unit test cases. IOC containers make unit testing and switching implementations very easy by manually allowing you to inject your own objects into the object under test.

• Loose coupling is promoted with minimal effort and least intrusive mechanism. The factory design pattern is more intrusive because components or services need to be requested explicitly whereas in IOC the dependency is injected into requesting piece of code. Also some containers promote the design to interfaces not to implementations design concept by encouraging managed objects to implement a well-defined service interface of your own.

• IOC containers support eager instantiation and lazy loading of services. Containers also provide support for instantiation of managed objects, cyclical dependencies, life cycles management, and dependency resolution between managed objects etc.

4.  What is Spring ?

Spring is an open source framework created to address the complexity of enterprise application development. One of the chief advantages of the Spring framework is its layered architecture, which allows you to be selective about which of its components you use while also providing a cohesive framework for J2EE application development.

5. What are the advantages of Spring framework?

The advantages of Spring are as follows:

• Spring has layered architecture. Use what you need and leave you don't need now.
• Spring Enables POJO Programming. There is no behind the scene magic here. POJO programming enables continuous integration and testability.
• Dependency Injection and Inversion of Control Simplifies JDBC
• Open source and no vendor lock-in.

6. What are features of Spring ?

• Lightweight:

  spring is lightweight when it comes to size and transparency. The basic version of spring framework is around 1MB. And the processing overhead is also very negligible.

• Inversion of control (IOC):

  Loose coupling is achieved in spring using the technique Inversion of Control. The objects give their dependencies instead of creating or looking for dependent objects.

• Aspect oriented (AOP):

  Spring supports Aspect oriented programming and enables cohesive development by separating application business logic from system services.

• Container:

  Spring contains and manages the life cycle and configuration of application objects.

• MVC Framework:

  Spring comes with MVC web application framework, built on core Spring functionality. This framework is highly configurable via strategy interfaces, and accommodates multiple view technologies like JSP, Velocity, Tiles, iText, and POI. But other frameworks can be easily used instead of Spring MVC Framework.

• Transaction Management:

  Spring framework provides a generic abstraction layer for transaction management. This allowing the developer to add the pluggable transaction managers, and making it easy to demarcate transactions without dealing with low-level issues. Spring's transaction support is not tied to J2EE environments and it can be also used in container less environments.

• JDBC Exception Handling:

  The JDBC abstraction layer of the Spring offers a meaningful exception hierarchy, which simplifies the error handling strategy. Integration with Hibernate, JDO, and iBATIS: Spring provides best Integration services with Hibernate, JDO and iBATIS

7. How many modules are there in Spring? What are they?

      Spring comprises of seven modules. They are..

• The core container:

  The core container provides the essential functionality of the Spring framework. A primary component of the core container is the BeanFactory, an implementation of the Factory pattern. The BeanFactory applies the Inversion of Control (IOC) pattern to separate an application's configuration and dependency specification from the actual application code. 

• Spring context:

  The Spring context is a configuration file that provides context information to the Spring framework. The Spring context includes enterprise services such as JNDI, EJB, e-mail, internalization, validation, and scheduling functionality. 

• Spring AOP:

  The Spring AOP module integrates aspect-oriented programming functionality directly into the Spring framework, through its configuration management feature. As a result you can easily AOP-enable any object managed by the Spring framework. The Spring AOP module provides transaction management services for objects in any Spring-based application. With Spring AOP you can incorporate declarative transaction management into your applications without relying on EJB components. 

• Spring DAO:

  The Spring JDBC DAO abstraction layer offers a meaningful exception hierarchy for managing the exception handling and error messages thrown by different database vendors. The exception hierarchy simplifies error handling and greatly reduces the amount of exception code you need to write, such as opening and closing connections. Spring DAO's JDBC-oriented exceptions comply to its generic DAO exception hierarchy. 

• Spring ORM:

  The Spring framework plugs into several ORM frameworks to provide its Object Relational tool, including JDO, Hibernate, and iBatis SQL Maps. All of these comply to Spring's generic transaction and DAO exception hierarchies. 

• Spring Web module:

  The Web context module builds on top of the application context module, providing contexts for Web-based applications. As a result, the Spring framework supports integration with Jakarta Struts. The Web module also eases the tasks of handling multi-part requests and binding request parameters to domain objects. 

• Spring MVC framework:

  The Model-View-Controller (MVC) framework is a full-featured MVC implementation for building Web applications. The MVC framework is highly configurable via strategy interfaces and accommodates numerous view technologies including JSP, Velocity, Tiles, iText, and POI. 

8. What are the types of Dependency Injection Spring supports ?

• Setter Injection:

  Setter-based DI is realized by calling setter methods on your beans after invoking a no-argument constructor or no-argument static factory method to instantiate your bean.

• Constructor Injection:

  Constructor-based DI is realized by invoking a constructor with a number of arguments, each representing a collaborato

9. What is Bean Factory ?

A BeanFactory is like a factory class that contains a collection of beans. The BeanFactory holds Bean Definitions of multiple beans within itself and then instantiates the bean whenever asked for by clients.

• BeanFactory is able to create associations between collaborating objects as they are instantiated. This removes the burden of configuration from bean itself and the beans client.
• BeanFactory also takes part in the life cycle of a bean, making calls to custom initialization and destruction methods.

10. What is Application Context?

A bean factory is fine to simple applications, but to take advantage of the full power of the Spring framework, you may want to move up to Springs more advanced container, the application context. On the surface, an application context is same as a bean factory.Both load bean definitions, wire beans together, and dispense beans upon request. But it also provides:

• A means for resolving text messages, including support for internationalization.
• A generic way to load file resources.
• Events to beans that are registered as listeners.

11. What is the difference between Bean Factory and Application Context ?  

On the surface, an application context is same as a bean factory. But application context offers much more..

• Application contexts provide a means for resolving text messages, including support for i18n of those messages. 
• Application contexts provide a generic way to load file resources, such as images. 
• Application contexts can publish events to beans that are registered as listeners. 
• Certain operations on the container or beans in the container, which have to be handled in a programmatic fashion with a bean factory, can be handled declaratively in an application context. 
• ResourceLoader support: Spring’s Resource interface us a flexible generic abstraction for handling low-level resources. An application context itself is a ResourceLoader, Hence provides an application with access to deployment-specific Resource instances. 
• MessageSource support: The application context implements MessageSource, an interface used to obtain localized messages, with the actual implementation being pluggable 

Konfiguration av en springapplikation brukar oftast ske mha XML-context som visats i ett antal exempel tidigare i denna serie, bland annat i artikeln om Spring som DI-ramverk. Det finns dock andra möjligheter att konfigurera upp din Spring-applikation. Ett sätt är att använda annotations.

Det finns en serie annotations som kan användas när en applikation ska sättas ihop via annotations. Den annotation som enkelt hanterar Dependency Injection (DI) kallas @Autowired.

@Autowired
public void setPersonDao(PersonDao personDao) {
    this.personDao = personDao;
}

Ovanstående exempel visar hur ett objekt av typen PersonDao kommer att injectas till metoden setPersonDao. Objektet av typen PersonDao måste vara känt av Spring och måste alltså vara skapat i ett spring-context (via ex XML eller annotations).

För att hitta de komponenter som ska skapas och injectas som i exemplet ovan kan man antingen använda vanliga XML-context eller använda "classpath scanning". Classpath scanning startas via en springkomponent som scannar av classpathen efter lämpliga klasser att instansiera. De komponenter som eftersöks är markerade via annotations med en stereotyp. De stereotyper som finns från och med Spring 2.5 är @Component, @Repository, @Service och @Controller. @Component är en generell stereotyp som kan sättas på vilken springhanterad komponent som helst. De övriga stereotyperna är specialiseringar av komponenter. Om du vet vilken typ av komponent det är du annoterar (dvs en tjänst, data access, MVC controller) bör du använda den specialiserade annotationen, detta är dock bara en markering och medför i dagsläget ingen ytterligare programmatisk signifikans. För att starta scanningen av classpathen måste en komponent deklareras i ex ett XML-kontext enligt exemplet nedan.

<?xml version="1.0" encoding="UTF-8"?>
<beans
  xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:context="http://www.springframework.org/schema/context"
  xsi:schemaLocation="http://www.springframework.org/schema/beans
    http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
    http://www.springframework.org/schema/context
    http://www.springframework.org/schema/context/spring-context-2.5.xsd">

  <context:component-scan
    base-package="se.cygni.sample.spring.annotation"/>
</beans>

Om ovanstående komponent deklareras och kommer alla klasser i paketet se.cygni.sample.spring.annotation att scannas efter stereotypannoteringar, skapas och kopplas ihop. Detta innebär alltså att alla klasser som har annotationerna @Component, @Service, @Repository eller @Controller kommer att bli skapade i springcontainern.

Nedanstående exempel visar hur en tjänst (PersonService) kopplas ihop med en DAO (DAO = Data Access Object) via annoteringar.

Antag nedanstående tjänstegränssnitt och DAO-gränssnitt. DAO-gränssnittet erbjuder klassiska CRUD-metoder och persontjänsten är lite intelligentare.

public interface PersonService {
    Person save(Person person);
    Person get(int id);
    List getAll();
    void delete(int id);
}

public interface PersonDao {
    Person create(Person person);
    Person retrieve(int id);
    List retrieveAll();
    Person update(Person person);
    boolean delete(int id);
    boolean exists(int id);
}

De objekt som kan hanteras av persontjänsten är av typen Person och ser ut så här:

public class Person {
    private int id;
    private String name;

    public int getId() {
        return id;
    }

    public void setId(int id) {
        this.id = id;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }
}

Ok, när gränssnitten är färdigdefinierade kan vi tillhandahålla implementationer av dessa. Implementationerna innehåller de stereotypannotationer som krävs för att Spring ska kunna skapa upp dessa och koppla ihop objekten via @Autowired.

@Service("myPersonService")
public class PersonServiceImpl implements PersonService {
    private PersonDao personDao;

    public void delete(int id) {
        personDao.delete(id);
    }

    public Person get(int id) {
        if (personDao.exists(id)) {
            return personDao.retrieve(id);
        } else {
            return null;
        }
    }

    public List getAll() {
        return personDao.retrieveAll();
    }

    public Person save(Person person) {
        if (personDao.exists(person.getId())) {
            return personDao.update(person);
        } else {
            return personDao.create(person);
        }
    }

    @Autowired
    public void setPersonDao(PersonDao personDao) {
        this.personDao = personDao;
    }
}

@Repository("myPersonDao")
public class InMemoryPersonDao implements PersonDao {
    private int idCounter;
    private Map repository = new HashMap();

    public Person create(Person person) {
        idCounter++;
        person.setId(idCounter);
        repository.put(Integer.valueOf(idCounter), person);
        return person;
    }

    public Person retrieve(int id) {
        Person person = repository.get(Integer.valueOf(id));
        if (person == null) {
            throw new IllegalStateException("Person " + id + " does not exist");
        }
        return person;
    }

    public List retrieveAll() {
        return new ArrayList(repository.values());
    }

    public Person update(Person personToUpdate) {
        Integer id = Integer.valueOf(personToUpdate.getId());
        Person person = repository.get(id);
        if (person == null) {
            throw new IllegalStateException("Person " + id + " does not exist");
        }
        repository.put(id, personToUpdate);
        return personToUpdate;
    }

    public boolean delete(int id) {
        Person deleted = repository.remove(Integer.valueOf(id));
        return deleted != null;
    }

    public boolean exists(int id) {
        return repository.containsKey(Integer.valueOf(id));
    }
}

Ovanstående skapar alltså två objekt. Notera att klasserna är annoterade med @Service respektive @Repository. Det ena objektet är av typen PersonServiceImpl och är namngivet till myPersonService. Man måste inte namnge de komponenter som skapas utan kan endast skriva ex @Service istället för @Service("namn"). Defaultnamnet på en komponent följer Springs namnstandard på beans så objektet ovan skulle alltså heta personServiceImpl. Metoden setPersonDao använder @Autowired och kommer alltså att kopplas ihop med en instans av typen PersonDao och den enda instansen heter i ovanstående exempel myPersonDao. Bindning av komponenter sker alltså "by type" och inte "by name". Namnen kan dock användas om man programmatiskt använder en bean factory för att hämta beans eller om man vill injecta och referera någon namngiven bean ifrån ett XML-context. Dock kan man specificera tydligare vilka objekt som ska kopplas ihop via användning av Qualifiers men det kommer jag inte att behandla i detta inlägg.

Övriga annoteringar

Spring tillhandahåller ytterligare annoteringar för att konfigurera springapplikationer.

• @Required
  Används på metoder som måste injectas. Detta hanteras via en post processor som helt enkelt avbryter exekvering ifall metoden inte blivit anropad. Läs mer här
• @Resource, @PostConstruct och @PreDestroy
  Spring erbjuder stöd för JSR-250 annoteringar. @PostConstruct och @PreDestroy kan användas för lifecyclehantering såsom interfacen InitializingBean och DisposableBean. @Resource används för dependency injection och kan även exekveras exempelvis i en J2EE-container med stöd för JEE 5.
• @Transactional
  Används med Spring-TX för att markera transaktionsattribut direkt i en javaklass istället för i en separat XML-fil. Läs mer om @Transactional och Spring-TX.

Fördelar och nackdelar

Fördelarna med att använda annotations för springkonfigurationen är uppenbara:

• Det blir knappt någon XML.
• Stereotypning av komponenter ger en tydlig bild av komponentens syfte.
• Det går snabbt att skapa en applikation som hanteras av spring utan bökig konfiguration.

Nackdelarna:

• Det kan bli svårt att få överblick över applikationen och hur komponenterna kopplas ihop eftersom det hela blir lite "magiskt".
• Det kan bli knöligt när komplexare ramverksklasser och liknande ska kopplas och då använder man typiskt en XML-fil i alla fall.

Läs mer om konfiguration via annotations här

Spring som DI-ramverk

Spring är ett Dependency Injection-ramverk (se tidigare artikel gällande Dependency Injection). Det är också så många andra saker, men i sin enklaste form är Spring ändå i första hand ett DI-ramverk.

Om du designar din applikation med hjälp av Dependency Injection kan du konfigurera Spring att hantera hur varje enskild komponent ska skapas, konfigureras och bindas ihop med övriga komponenter. En "komponent" i Spring är en vanlig POJO, komponenter som hanteras av Spring kallas för "Spring Beans" (eller på svenska "bönor") även om de inte nödvändigtvis måste uppfylla JavaBeans-specifikationen.

Det centrala objektet i Springs DI-hantering är en BeanFactory. En BeanFactory ansvarar bland annat för att skapa bönor, livscykelhantering och att binda ihop bönorna enligt den konfiguration du tillhandahåller. Det vanligaste sättet att konfigurera dina bönor är att använda XML-konfiguration men det finns även andra konfigurationssätt exempelvis via property-filer eller via annotations. En BeanFactory kan skapas manuellt, det vanligaste är dock att man skapar en BeanFactory via någon av det hjälpklasser som tillhandahålls av Spring exempelvis genom användning av ContextServletListener för webbapplikationer. En specialiserad form av BeanFactory är ett ApplicationContext som är det man typiskt använder, förklaringen till detta hittar du här.

Låt oss se på ett enkelt exempel. Anta att vi ska skriva en applikation som hämtar reklamtexter (strängar) från någon typ av datakälla, för att sedan publicera dem på en ljusskylt. Vi bortser från allt det riktigt komplicerade, som att kommunicera med hårdvaran och sånt, och tittar på det förenklade fallet. Först har vi en datakälla med vissa egenskaper, den fungerar ungefär som en Iterator<String>, så vi modellerar gränssnittet på liknande sätt:

public interface AdTextDataSource {
    boolean hasNext();
    String next();
}

Vi vet inte så mycket mer om datakällan för närvarande än att den kommer att klara av att uppfylla gränssnittet ovan. Dags att titta på konsumenten, dvs den komponent som ska hämta textsträngarna och visa upp dem på enklaste sätt:

public class AdTextConsumer {
    private AdTextDataSource dataSource;

    public void setDataSource(AdTextDataSource ds) {
         this.dataSource = ds;
    }

    public AdTextDataSource getDataSource() {
        return this.dataSource;
    }

    public void loopUntilDone() {
        while (getDataSource().hasNext()) {
            System.out.println(getDataSource().next());
        }
    }
}

Så, var kommer textsträngarna ifrån? Ja det vet vi ju inte riktigt ännu -- det kan vara från en textfil på det lokala filsystemet, en SQL-databas, en extern webbsida, ett pollande webservice-anrop eller nåt helt annat. Men för att testa vår kod bygger vi en liten test-datakälla som lagrar strängarna i en vanlig lista i minnet.

public class InMemoryAdTextDataSource implements AdTextDataSource {
    private List<String> texts = new ArrayList<String>();
    private int index;
    public List<String> getTexts() {
        return this.texts;
    }

    public void setTexts(List<String> texts) {
        this.texts = texts;
    }

    public String next() {
        return getTexts().get(index++);
    }

    public boolean hasNext() {
        return index < getTexts().size();
    }
}

Ovan ser vi att AdTextConsumer inte har något beroende till InMemoryAdTextDataSource utan bara till dess interface. Vi ser också att AdTextConsumer inte instansierar eller slår upp InMemoryAdTextDataSource, det ska vi låta Spring göra. Nedan följer ett ett exempel på hur dessa klasser kan bindas ihop med Spring. Vi skapar en fil som vi kallar för applicationContext.xml med följande innehåll.

<?xml version="1.0" encoding="UTF-8"?>
<beans
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns="http://www.springframework.org/schema/beans"
  xmlns:util="http://www.springframework.org/schema/util"
  xsi:schemaLocation="http://www.springframework.org/schema/beans
    http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
    http://www.springframework.org/schema/util
    http://www.springframework.org/schema/util/spring-util-2.5.xsd">

    <bean id="dataSource" class="AdTextDataSource">
	<property name="texts" ref="texts"/>
    </bean>

    <bean id="consumer"
            class="AdTextConsumer"
            init-method="loopUntilDone">

        <property name="dataSource" ref="dataSource"/>
    </bean>

    <util:list id="texts">
	<value>text1</value>
	<value>text2</value>
	<value>text3</value>
    </util:list>
</beans>

Vi har nu en färdig XML-konfiguration för Spring. Den första bönan vi definierar är dataSource, när vi anger class berättar vi för Spring vilken klass som ska instansieras.

Genom att ange en property (med namnet texts) låter vi Spring köra setTexts-metoden på bönan dataSource, vi har här vårt första exempel på DI.

Bönan texts utgör här initialiseringsdata till dataSource. Hade vi haft vår initialiseringsdata i en propertyfil hade vi exempel kunnat använda Springs PropertiesFactoryBean eller liknande. Bönan texts är lite speciell, Spring skapar ett vanligt List-objekt med värdena vi anger. Vi skulle kunna göra det på annat sätt men Spring har ett util-paket som låter oss skapa bönan på detta kortare sätt.

Nästa böna är consumer som ska kopplas ihop med bönan dataSource. Med init-method har vi infört livscykelshantering. Spring kommer automatiskt att köra metoden loopUntilDone så snart bönan är skapad och alla properties är satta. Motsatsen till init-method kan anges med destroy-method. Livscykelhantering kan man även uppnå genom att implementera interfacen InitializingBean och DisposableBean.

För att få igång ett program behöver vi en main-metod som sparkar igång Spring, det kan göras som följande

public static void main(String[] args) {
    ApplicationContext ctx =
        new ClassPathXmlApplicationContext("applicationContext.xml");
    ctx.refresh();
}

Vi har nu designat våra klasser för DI, inga förekomster av new eller fabriker. Vi har låtit Spring ta hand om skapande av objekt, livscykelhantering och initialiseringsdata. I och med att vi inte har några beroenden till Spring, någon speciell fabrik eller implementationsklass för AdTextDataSource är det enkelt att skapa ett unit-test för att testa vår consumer.

public void testSimple() {
    String[] texts = {"text1", "text2", "text3"};
    AdTextDataSource dataSource = new InMemoryAdTextDataSource();
    dataSource.setTexts(Arrays.asList(texts)); //DI

    AdTextConsumer consumer = new AdTextConsumer();
    consumer.setDataSource(dataSource); // DI
    consumer.loopUntilDone(); // Egentligen hanterat via "init-method"
    assertValidOutput(); // assert på output (inte relevant)...
}

(Ok, jag fuskade lite på slutet och antog att det fanns en assertValidOutput() som kollade att det som skrevs ut stämde -- det är inte relevant för artikeln!)

Här kan man säga att vi manuellt binder ihop dataSource och consumer genom metoden setDataSource. Om man vill testa genom att använda Spring istället så kan man starta ett context via ett JUnit-test genom att ärva någon av subklasserna till AbstractSpringContextTests där metoden getConfigLocations kan överlagras och ex returnera en referens till ovan nämnda contextfil (applicationContext.xml).

Av: Robert Burén, Johan Risén, Tommy Wassgren

Inversion of Control

Inversion of Control (IoC) är egentligen ett samlingsnamn på en mängd mönster. Dessa mönster uppträder ofta i ramverk. Huvudpoängen är att det inte är den egna applikationskoden som styr programflödet utan att detta sköts av ramverket. IoC är också lite informellt känt som "Hollywood Principle" – "don't call us, We'll call you."

Traditionellt i imperativa programmeringsspråk så har applikationskoden explicit styrt programflödet. Programflödet defineras av att applikationskoden styr hela flödet som antingen är egen kod eller anrop till bibliotekskod. Bibliotekskoden kan anropa annan bibliotekskod, men typiskt aldrig den egna koden. Inversion of Control uppstår alltså när bibliotekskoden anropar den egna koden.

Exempel på IoC

1. Händelsestyrd programmering (event-driven programming). En main-loop definerar ett tydligt flöde i vilket den egna applikationskoden kan kopplas in. (exempelvis Swing)
2. JUnit. När du skriver ett testfall enligt JUnit 3.8+ så skapar du en testklass som ärver ramverksklassen TestCase. Du utvecklar en eller flera testmetoder testSomething och testSomethingElse. Ramverket tillhandahåller setUp- och tearDown-metoder där du kan lägga in initiering och uppstädningskod. Men det är inte du som kör testet utan detta gör ramverket.

IoC och beroenden

Definitionen på IoC ovan är betydligt bredare än vad man nu för tiden menar när man använder begreppet IoC. Vanligtvis talar man om att externt, via en container, hantera skapandet av komponenter och dess beroenden.

IoC kan grovt delas in i två kategorier nämligen Dependency Lookup och Dependency Injection (DI) vilka båda beskrivs nedan.

Traditionellt sett har skapande av komponenter och dess beroenden skett i de faktiska komponenterna såsom i detta exempel där klassen Foo skapar en instans av typen Bar och dessutom exekverar det logiska programflödet via metoden executeSomething.

01: public class Foo {
02:     public void doSomething() {
03:         Bar bar = new BarImpl();
04:         bar.executeSomething();
05:     }
06: }

I Figur 1 visas hur en instans av typ BarImpl skapas och därigenom så har klassen Foo ett hårt beroende till en viss typ av implementation av Bar-objekt.

Syftet med att använda IoC för att hantera skapandet av komponenter är att:

• Minimera "glue code" dvs kod som endast finns för att "limma ihop" applikationen.
• Skapa komponenter på ett enhetligt och kontrollerat sätt.
• Hantera beroenden externt så att de inte behöver vara kända av den faktiska javakoden.
• Förbättra testbarhet. Genom att skapandet av objekt hanteras externt så kan implementationer av olika objekt enkelt bytas ut vid testning med hjälp av mock objects.
• Tvinga fram en bra applikationsdesign.

Dependency Lookup

Dependency lookup är en form av IoC som har funnits länge och använts på många olika sätt. En fabrik eller ett register (factory/registry) erbjuder en applikation att koppla ihop en mängd objekt/komponenter utan att exponera för mycket om hur dessa objekt sitter ihop eller vilka beroenden de ingående objekten har. I stället för att sprida denna "create kod" i hela applikationen så kan skapandet modulariseras. Klienten anropar helt enkelt en metod på en fabrik för att få ett färdigihopkopplat och konfigurerat objekt. Klientkoden har endast beroende till fabriken och det objekt som skapas.

Det finns nackdelar med att använda fabriker varav en är att man måste skriva sin fabrikskod. Det kan tyckas trivialt men det blir många klasser som skrivs i onödan och det finns alltid risk för fel. Om vi tittar på ett typiskt användande av en fabrik.

Bar ins = (Bar) MyObjectFactory.getInstance("myBar");

Värt att notera är att vi har en hård referens till fabriken vilket är lite tråkigt. Att mocka fabriken är svårt då vi använder en statisk metod. Att byta implementerande klass i sina testfall kan vara olika svårt beroende på hur man implementerat fabriken. Har vi gjort fabriken lite smart så att den tex väljer vilken klass den ska instansiera utifrån en XML-fil kan man byta implementation utan en egen fabriksimplementation för test.

I detta fall måste vi aktivt välja i koden vilken instans ("myBar") vi vill ha (och stava rätt), kanske kontrollera att den inte är null och att akta oss för eventuella ClassCastExceptions. Även komplexiteten i detta inte är så stor vore det mycket bättre om vi slapp den för att undvika ev fel och boiler plate kod. Den som har gjort JNDI-uppslag kan notera att mönstret är detsamma, båda är exempel på Dependency Pull, en variant av Dependency Lookup.

Ett annat typfall på hur man gjort innan DI är användande av fabriksmetoder som i Singleton pattern (även känt under synonymet Evil singleton pattern). Ett av huvudproblemen i användningen av detta mönster är den dåliga testbarheten pga att statiska metoder används som är svåra att byta ut under test.

Dependency Injection

Dependency injection (DI) är den andra formen av IoC gällande att skapa och hantera komponenter. Med DI är det ramverket som styr algoritmen för hur beroenden mellan ingående delar löses upp.

Med DI skriver man mindre kod och det finns nästan inga hårda beroenden till ramverket. När det gäller Spring kan man förenklat säga att ramverket redan tillhandahåller all den fabriks- och lookup-kod du behöver.

DI-containern (exempelvis Spring) kommer att vilja injicera instanser antingen i en konstruktor eller med getter/setter metoder till din klass vilket betyder att den lilla kod man skriver är mycket enkel och kan automatgenereras av en bra IDE. Med en DI-container kan man till skillnad från i Dependency Lookup fallen ovan utveckla/testa utan beroenden till en extern container. Nedanstående exempel visar hur klassen Foo exponerar en setter-metod som kommer att anropas av DI-containern där Bar-objektet sätts. Observera att klassen Foo nu inte har någon kunskap om hur man skapar Bar-objekt och den hårda kopplingen till BarImpl är borta. Detta hanteras nu istället av DI-containern.

01: public class Foo {
02:     private Bar bar;
03:
04:     // setter method invoked by the DI-container
05:     public void setBar(Bar bar) {
06:         this.bar = bar;
07:     }
08:
09:     public void doSomething() {
10:         bar.executeSomething();
11:     }
12: }

Nästa del i denna artikelserie visar exempel på hur man kan använda Spring som DI-container.

Nedanstående exempel visar hur enkelt det är att testa klassen Foo med en enkel testvariant av Bar-interfacet. På rad 5 används en form a DI direkt i koden. Om ett fabriksmönster eller direkt instansiering hade använts av klassen Foo hade det blivit betydligt mer komplicerat att mocka objektet Bar.

01: public class FooTest extends TestCase {
02:     public void testSomething() {
03:         Foo foo = new Foo();
04:         TestBar testBar = new TestBar();
05:         foo.setBar(testBar);
06:         foo.doSomething();
07:         assertTrue(testBar.count > 0);
08:     }
09:
10:     public static class TestBar implements Bar {
11:         int count = 0;
12:
13:         public void executeSomething() {
14:             count++;
15:         }
16:     }
17: }

Dependency Lookup eller Dependency Injection

Så vad ska man då välja, Dependency Lookup eller DI? Om man använder Dependency Lookup så finns det hårda beroenden till det ramverk som man använder eller de fabriker som måste skapas. Det blir större mängd "glue code" och koden blir inte lika enkel att testa. Därför bör DI användas om möjligt.

Typiska exempel på vad en DI-container hanterar åt dig är:

• Hur vi får tag i referenser till andra objekt eller komponenter
• Åtkomst till systemresurser som exempelvis filsystem
• Hur ett objekt får sin konfiguration eller sina initieringsparametrar
• Livscykelhantering, dvs när och vem som "startar" och "stoppar" ett objekt
• Eftersom DI-containern skapar objekt kan proxies, aspekter, fasader och dylikt konfigureras dynamiskt. I denna serie kommer vi senare att blogga om aspekter i artikeln Introduktion till Spring AOP.

Allt detta är saker du inte vill och inte behöver hantera i din applikationskod!

Källor

• Martin Fowler om Inversion of Control - http://martinfowler.com/articles/injection.html

Av: Per Rasmussen, Johan Risén och Tommy Wassgren.

Artikelserien vänder sig i första hand till nybörjare och relativt oerfarna Spring-utvecklare, men alltefter som vi går in på djupet i olika teknikområden hoppas och tror vi att  det ska finnas intressant information även för de mer erfarna.

Vi kommer att uppdatera den här texten med en aktuell innehållsförteckning varje gång ett nytt avsnitt finns tillgängligt, så sätt gärna ett bokmärke här!

Innehållsförteckning

• Spring från början, introduktion (den här texten)
• Dependency Injection (DI)
• Spring som DI-ramverk
• Konfigurera med annotations
• Spring JDBC
• Spring JMS
• Aspektorientering med Spring (kommer snart)
• Hibernatestödet i Spring (planerad)
• Spring Security (planerad)
• Spring för webbappar (planerad)
• Spring Dynamic Modules (OSGi) (planerad)
• Service Exporters i Spring (planerad)

Para quem tiver interesse de saber mais sobre o evento, visite o link:
http://www.javafree.org/news/view.jf?idNew=3744

This is when hierarchical context feature comes to the rescue. A very good write up about this feature is at this blog.

Man kan låta proxies automatgenereras utifrån cache/flush annotations eller så kan man explicit skapa proxies per böna.

Ett varningens finger dock, även om det var mycket bekvämt kändes det inte helt moget. Ett ex är att det ännu (v0.9) inte går att flusha cachen på lägre nivå än cache/grupp nivå. Ännu allvarligare är att jag upplevde en minnesläcka i ramverkets interna metadata cachning, dvs cachningen av annotations. Att sluta använda annotations och istället använda proxy-konfiguration i xml går runt problemet. Ytterligare en frustration som tyder på att lösningen inte är helt genomarbetat beskrivs här
Sammanfattningsvis, bra tänkt men vänta gärna några versioner.

Skills Required : Java, J2EE, Spring Framework , struts , hibernate, & Oracle Database

Experience Required : 3 - 6 Year(s)
Job Location : NOIDA
Walk-in Date : 26 April 2008
Walk-in Time : 10:00 a.m - 05:00 p.m
Job Description :

Candidates for this position should have the following skills:

1. The candidate should have a BE/BTech /MTech from IIT/RECBITS or any premiere institute in Computer Science/Electronics with 3 - 6+ yrs experience.
2. Expertise in writing server side Java code. Must have expertise in Core Java - multi- threading, RMI, transaction handling, data structures, distributed architecture & Servlets.
3. Good understanding or familiarity with standard data structures such as maps, collections, trees.
4. Experience writing Oracle database code for persistent Java objects. This includes a strong understanding of JDBC and SQL.
5. Experience using a framework such as Struts, Spring, Hibernate is a plus.

For more Information