Thursday, October 29, 2009

Getting Spring POJOs from external Spring unaware systems

There are cases when one wants to instantiate POJOs from classes that are not Spring aware (like old EJBs).
In such circumstances, one needs to get the Spring application context and retrieve beans from the Spring container.

This is how you do it:

1. Create a class that provides the Spring application context from the container
import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;

/**
* This class provides an application-wide access to the
* Spring ApplicationContext!
*
* Use AppContext.getApplicationContext() to get access
* to all Spring Beans.
*
*/
public class ApplicationContextProvider implements ApplicationContextAware
{
private static ApplicationContext ctx;

private ApplicationContextProvider(){}

public static ApplicationContext getApplicationContext()
{
return ctx;
}

@Override
public void setApplicationContext(ApplicationContext ctx) throws BeansException
{
this.ctx = ctx;
}
}

2. Wire it in Spring

<bean id="contextApplicationContextProvider" class="com.yournamespace.ApplicationContextProvider"></bean>

3. Get a bean from any other class

SomeBean bean = (SomeBean)ApplicationContextProvider.getApplicationContext().getBean("someBean");

Thursday, October 22, 2009

Building an Agile Team

I have read this article with interest regarding building an Agile Team
Very good points, summarizing everything in two words: building an Agile Team, its all about communication and resources... good resources!
But from experience I would like to add the following point:
What about one tries to build an Agile team with the existing resources?
This is the common scenario were one tries to introduce Agile in an existing technical department.

I think Agile\Scrum is all about common sense. Definitely as stated in the article, communication is what makes the success of an Agile team but also the continuous improvement, sprint after sprint.
And I think that's what makes sprint retrospectives very important. From experience, sprint retrospectives are not given the necessary attention. Sometimes, retrospectives are done for the sake of doing them.

A retrospective should be a 'mini-revolution'.
Pigs should openly speak of what is hindering their velocity and how can improve it like:
  • Software used for the Agile process
  • External forces interfering the team
  • Lacking of particular resources
  • Problems with the current architecture, framework used...and so on.