Everyone seems to think annotations are cool and want to use them now days. A lot has been written about the pros and cons of using annotations and personally I think they should be used with caution. Mixing annotation domains to a point of total confusion, spreading configuration related meta-data across large code bases to a point where refactoring becomes very hard are only some of the risks. Nevertheless, annotations are cool.

I wanted to add annotation functionality to some “aspect” of our code base. An aspect being an interface Foo and multiple implementations of Foo in various artifacts (e.g., FooA from project A, FooB from project B and so on).

public interface Foo{
  void bar();
}

public class FooA implements Foo{
  @Override
  public void bar(){
    System.out.println("I am number 6!");
  }
}

First thing I created a Fooish type-level (class-level) annotation

@Target({ ElementType.TYPE })
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Fooish {
  boolean cool() default true;

  String[] tags() default { "all" };
}

Next I annotated my classes with my new Fooish annotation:

@Fooish(cool=false, tags= {"sixfoo"})
public class FooA implements Foo{
  @Override
  public void bar(){
    System.out.println("I am number 6!");
  }
}

Meanwhile, in another Foo across the galaxy from A:

@Fooish(cool=true, tags= {"freefoo"})
public class FooB implements Foo{
  @Override
  public void bar(){
    System.out.println("I am not a number, I am a free man!");
  }
}

I am now ready to do some classpath scanning for my Foos. At first I went a looked the reflections library which I have to say is quite cool.

I popped the maven repository and dependencies:

<repository>
    <id>reflections-repo</id>
    <name>Reflections Maven2 Repository</name>
    <url>http://reflections.googlecode.com/svn/repo</url>
</repository>

<dependency>
  <groupId>org.reflections</groupId>
  <artifactId>reflections</artifactId>
  <version>0.9.5</version>
</dependency>
<dependency>
  <groupId>com.google.collections</groupId>
  <artifactId>google-collections</artifactId>
  <version>1.0</version>
</dependency>

And now I am ready to start scanning for annotations:

final StopWatch sw = new StopWatch();
sw.start();
final Reflections reflections = new Reflections("org.projectx", new TypeAnnotationsScanner());
Set<Class<?>> theFoos = reflections.getTypesAnnotatedWith(Fooish.class);
sw.stop();
System.out.println("Classpath scanning took: " + sw.getTime() + "ms");
for (final Class<?> theFoo : theFoos) {
final Fooish annotation = theFoo.getAnnotation(Fooish.class);
  if (Arrays.asList(annotation.tags()).contains("freefoo")) {
     System.out.println("This foo "+ theFoo.getClass().getName() + ", is a free foo");
  }
}

The reflections API has much more than is shown here, the output of the scan showed:

Classpath scanning took: 1782ms

Not bad for quite a large code base, but still, incurring a 2 seconds penalty for service load time is severe a production environment where services might be candidate to frequent restarts. Continuous deployment requires it to be snappy. A side note here, you should never try to do this kind of scanning during runtime, only load time. Reflection-based operations are costly in Java.

Next I suddenly remembered that Spring does this kind of work when you do stuff like <mvc:annotation-driven /> and <context:component-scan /> in you bean configuration file. There’s gotta be a way to hook up into that process use it for my own good. Turns out there is.

Spring allows you to load your annotated classes into their container if you also annotate them with the @Component type-level annotation. So my Foos need another annotation:

@Fooish(cool=true, tags= {"freefoo"})
@Component
public class FooB implements Foo{
  @Override
  public void bar(){
    System.out.println("I am not a number, I am a free man!");
  }
}

To load all my Foos into the Spring application context I added the following to my Spring configuration file:

<context:component-scan base-package="org.projectx">
  <context:include-filter type="annotation" expression="com.projectX.annotation.Fooish" />
</context:component-scan>

You can have other component scanners in the Spring configuration but this one is dedicated only to the classes annotated with @Component and @Fooish.

Now I want a Fooish handler which handles all instances of Fooish beans loaded to the context, I can easily do it with by implementing the ApplicationContextAware interface, then calling the getBeansWithAnnotation method of the ApplicationContext.

public class MyFooishHandler implements ApplicationContextAware, InitializingBean {
  private ApplicationContext applicationContext;

  @Override
  public void afterPropertiesSet() throws Exception {

    final Map<String, Object> myFoos = applicationContext.getBeansWithAnnotation(Fooish.class);

    for (final Object myFoo : myFoos.values()) {
      final Class<? extends Object> fooClass = myFoo.getClass();
      final Fooish annotation = fooClass.getAnnotation(Fooish.class);
      System.out.println("Found foo class: " + fooClass + ", with tags: " + annotation.tags());
    }
  }

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

I am sure there’s some overhead here to but the up side is once I annotate my Foos with @Component I can also take advantage of other features of the Spring container and this method doesn’t require additional dependencies on the classpath assuming Spring’s already there.

Elasticsearch is a good abstraction around Lucene Search Engine and an alternative to Solr. ElasticSearch provides out of the box index distribution along with a decent JSON RESTful interface backed by a Java/Groovy API. ElasticSearch also elaborate list of modules for a variety of integrations.

I wanted to integrate ElasticSearch in my Spring-based application and a factory/configuration abstraction came to mind.

A an embedded node within a cluster can be instantiated and used to execute requests against the distributed index. It deserves its own factory bean since it has lifecycle management operations and configuration associated with it. Note that configLocation can be provided along with local map of settings, if neither are provided elasticsearch will looks for its configuration files in the working directory or a “config” subdirectory. The local property can also be set (overridable via system property for unit tests).

    <bean
        class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
        <property name="systemPropertiesModeName" value="SYSTEM_PROPERTIES_MODE_OVERRIDE" />
        <property name="searchSystemEnvironment" value="true" />
        <property name="locations">
            <list>
                <value>classpath*:**/elasticsearch.properties</value>
            </list>
        </property>
        <property name="properties">
            <props>
                <prop key="projectx.index.dir">/var/tmp/index</prop>
                <prop key="projectx.index.dir.create">true</prop>
                <prop key="projectx.index.name">projectx</prop>
            </props>
        </property>
    </bean>

    <bean id="esNode"
        class="org.projectx.elasticsearch.ElasticsearchNodeFactoryBean">
        <property name="configLocation"
            value="classpath:org/projectx/elasticsearch/elasticsearch.properties" />
    </bean>

Once we have an ElasticSearch Node at hand we can start performing operations on the distributed index. However for the majority of the data access a Template style class could be handy:

    <bean id="esNodeTemplate" class="org.projectx.elasticsearch.NodeTemplate">
        <constructor-arg ref="esNode" />
        <constructor-arg value="${projectx.index.name}" />
    </bean>

To display how the template get’s use you can look at the intergration test base class:

public class ElasticsearchTestBase {

  @Resource
  NodeTemplate nodeTemplate;

  @Before
  public void before() {
    if (!nodeTemplate.indexExists()) {

      nodeTemplate.executeGet(new NodeCallback<CreateIndexResponse>() {

        @Override
        public ActionFuture<CreateIndexResponse> execute(final IndicesAdminClient admin) {
          return admin.create(Requests.createIndexRequest(nodeTemplate.getIndexName()));
        }
      });
    }
  }

  @After
  public void after() {
    nodeTemplate.deleteIndex();
  }

  protected void refreshIndex() {
    nodeTemplate.refreshIndex();
  }

  protected void flushIndex() {
    nodeTemplate.flushIndex();
  }

  protected IndexResponse index(final XContentBuilder content) {
    final IndexResponse response = nodeTemplate.executeGet(new ClientCallback<IndexResponse>() {

      @Override
      public ActionFuture<IndexResponse> execute(final Client client) {
        final IndexRequest request = Requests.indexRequest(nodeTemplate.getIndexName())
                                             .source(content).type("log");
        return client.index(request);
      }
    });
    assertNotNull("response is null", response);
    return response;
  }

  protected <Q> List<SearchHit> search(final String field, final Q value, final int maxResults) {
    return nodeTemplate.search(field, value, maxResults);
  }

}

An then the actual test:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = { "classpath:org/projectx/elasticsearch/applicationContext-elasticsearch.xml" })
public class ElasticSearchIntegrationTest extends ElasticsearchTestBase {

  @Test
  public void testIndex() throws Exception {

    final Collection<File> files = Collections.singletonList(new File(
        "src/test/resources/othello1-1.txt"));

    int totalDocs = 0;
    for (final File file : files) {
      @SuppressWarnings("unchecked")
      final List<String> lines = FileUtils.readLines(file, "UTF-8");

      int lineNumber = 1;
      for (final String line : lines) {
        indexLine(file, line, lineNumber);
        lineNumber++;
        totalDocs++;
      }
    }

    refreshIndex();

    final List<SearchHit> hits = search("rownum", 1, 100);

    assertEquals("incorrect number of results", 1, hits.size());
  }

  private void indexLine(final File file, final String line, final int rownum) throws Exception {
    final XContentBuilder jsonBuilder = XContentFactory.jsonBuilder();
    jsonBuilder.startObject();
    jsonBuilder.field("rownum", rownum);
    jsonBuilder.field("path", file.getAbsolutePath());
    jsonBuilder.field("modified", file.lastModified());
    jsonBuilder.field("contents", line);
    jsonBuilder.endObject();

    index(jsonBuilder);
  }

This provides an good application-layer abstraction around dealing with nodes and a good integration to the Spring container.

ElasticSearch Spring integration is on GitHub

Recently I had to implement an active-passive redundancy of a singleton service in our production environment where the general rule is always have “more than one of anything”. The main motivation is to alleviate the need to manually monitor and manage these services, whose presence is crucial to the overall health of the site.

This means that we sometime have a service installed on several machines for redundancy, but only one of the is active at any given moment. If the active services goes down for some reason, another service rises to do its work. Turns out this is actually called leader election. One of the most prominent open source implementation facilitating the process of leader election is Zookeeper.

Originally developed by Yahoo reasearch, Zookeepr is a service providing reliable distributed coordination. It is highly concurrent, very fast and suitable mainly for read-heavy access patterns. Reads can be done against any node of a Zookeeper cluster while writes a quorum-based. To reach a quorum, Zookeeper utilizes an atomic broadcast protocol.

After reading the documentation several times to get a good grasp of both core concepts and operational aspects. My favourite method is to read the documentation once quickly, then go implement something, a tutorial if you’d like, then go back and read it again, quickly. After this start writing the actual code. Finally go back to the documentation and read it again, that last time is always the clearest, everything falls into place. Why? maybe because documentations are written by people with close familiarity to the topic and for people with close familiarity with the topic (or it’s just me making excuses for the fact that I am slow in the head). So how does Zookeeper work?

Connectivity, State and Sessions

Zookeeper maintains an active connection with all its clients using a heartbeat mechanism. Furthermore, Zookeeper maintains a session for each active client that is connected to it. When a client is disconnected from Zookeeper for more than a specified timeout the session expires. This means that Zookeeper keeps a pretty good picture of all the animals in its zoo. The key thing here is that Zookeeper knows about the state of its clients and is able to notify others in a consistent, ordered manner about this state and its changes.

Data Model

The Zookeeper data model consists of a hierarchy of nodes, called ZNodes. ZNodes can hold a relatively small (efficiency is key here) amount of data, they are versioned and timestamped . There are several properties a ZNode can have that make them particularly useful for different use cases. Each node in Zookeeper can have the persistent, ephemeral and sequential flags. These determine the naming of the node and its behavior with respect to the client session.

• The persistent node is basically a managed data bin
• The ephemeral node exists for the lifetime of its client session
• The sequential node, when created, gets a unique number (identity, sequence, counter and like a hundred different names you could call this) suffixed to its name

The latter two provide the means to implementing a variety of distribution tasks such as locks, queues, barriers, transactions, elections and other synchronization related tasks.

Events

Zookeeper allows its clients to watch for different events in its node hierarchy. This way clients can get notified of different changes in the distributed state of affairs and act accordingly. These watches are one timers and should be persisted again by the client after notification. The client is also responsible of handling session expiration which means that ephemeral nodes should be re-persisted after an expiration.

Phew, am I babbling today or what? down to business.

Zookeeper requires a lot of boiler plate code, mostly around connectivity and for the majority of the time you will be doing the same things over and over. Luckily Stefan Groschupf and Patrick Hunt wrote a client abstraction called ZkClient. I published a maven artifact for this on OSS so it’s available to our build system. The library also provides a persistent notification scheme in the form of listeners.

Next I cooked up a factory bean for ZkClient and a template style class to act as an applicative abstraction to Zookeeper operations

    <bean id="zkClient" class="org.projectx.zookeeper.ZkClientFactoryBean">
        <property name="ensemble" value="localhost:2181,localhost:2182,localhost:2183" />
        <property name="connectionTimeout" value="2000" />
        <property name="sessionTimeout" value="10000" />
        <property name="stateListeners">
            <list>
                <ref local="zkStatsCollector" />
            </list>
        </property>
    </bean>

    <bean id="zkStatsCollector" class="org.projectx.zookeeper.ZookeeperClientStatsCollector" />

    <bean id="zkTemplate" class="org.projectx.zookeeper.ZookeeperTemplate">
        <constructor-arg ref="zkClient" />
    </bean>

The ZooKeeperClientStatsCollector is a listener implementation which collects stats about session connects/disconnects, exported to JMX as an MBean.

Now I can happily create nodes to my heart’s content.

Leader Election

The Zookeeper documentation describes in general terms how leader election is to be performed. The general idea is that all participants of the election process create an ephemeral-sequential node on the same election path. The node with the smallest sequence number is the leader. Each “follower” node listens to the node with the next lower sequence number to prevent a herding effect when the leader goes away. In effect this creates a linked list of nodes. When a node’s local leader dies it goes to election either find a smaller node or becoming the leader if it has the lowest sequence number.

The following image describes a scenario with 3 clients participating in the election process:

Each client participating in this process has to:

1. Create an ephemeral-sequential node to participate under the election path
2. Find its leader and follow (watch) it
3. Upon leader removal go to election and find a new leader, or become the leader if no leader is to be found
4. Upon session expiration check the election state and go to election if needed

One thing to consider here is the nature of the work being done by the leader. Make sure it’s state can be preserved if its leadership is revoked. Leader loss could be caused by any number of reasons including initiated restarts due to maintenance and releases. It could also be brought about by network partitioning.

Designing services for graceful recovery is a requirement for distributed systems not leader election.

Spring helps here because interception can be used to suppress method invocations of various services based on leadership status. Below is an example of an interception based leadership control:

    <bean id="leaderElectionProxyTemplate" class="org.springframework.aop.framework.ProxyFactoryBean"
        abstract="true">
        <property name="interceptorNames">
            <list>
                <value>leaderElectionTarget</value>
            </list>
        </property>
    </bean>

    <bean id="leaderElectionTarget"  class="org.projectx.zookeeper.election.LeaderElectionTargetInterceptor" />

    <bean id="myService" parent="leaderElectionProxyTemplate">
        <property name="target">
            <bean class="org.projetx.service.MyService">
        </property>
    </bean>

The service myService is the one controlled by leader election, all it’s method are going to be suppressed or invoked based on leadership status.

Another implementation uses a quartz scheduler instance as its target target:

    <bean id="leaderElectionTarget"
        class="org.projectx.zookeeper.election.quartz.SchedulerElectionTarget">
        <constructor-arg ref="myScheduler" />
    </bean>

This implementation puts a quartz scheduler on standby mode when leadership is revoked and resumes it when it’s granted (notice it will not actually stop running tasks, this will be allowed their natural completion, so in effect you may have a scheduled task running on two services due to partitioning scenarios. This means that whatever is scheduled has to be aware of another service possibly doing the same work. This problem can be easily solved with a Zookeeper barrier implementation, more on that in another post.

But Zookeeper’s capabilities extend far beyond Leader Election.

Presence

Another very good use for Zookeeper is maintaining a clear image of who’s alive in the data center. Every service creates an ephemeral node on some presence path. This can then be viewed by the human eye in the Zookeeper Hue Browser, the Rest Server or the Solr Cloud console. You could also use the various client APIs to point your monitoring tools at Zookeeper to know who’s where.

Here’s an example of defining a presence manager with Spring:

    <bean id="presenceNodeFactory" class="org.projectx.zookeeper.presence.PresenceNodeFactory">
        <constructor-arg ref="zookeeperTemplate" />
        <constructor-arg value="${org.projectx.zookeeper.services.root}/${org.projectx.environment}" />
        <constructor-arg value="${zookeeper.entity.name}" />
        <constructor-arg ref="serviceMetaDataProvider" />
    </bean>

    <bean id="presenceManager" class="org.projectx.zookeeper.presence.PresenceManager">
        <constructor-arg ref="presenceNodeFactory" />
    </bean>

    <bean id="serviceMetaDataProvider"
        class="org.projectx.zookeeper.presence.ServiceMetaDataProvider">
        <constructor-arg value="${zookeeper.entity.name}" />
    </bean>

The serviceMetaDataProvider decorates the node with whatever data you’d like to see on the presence node (ip, revision, release numbers, various timestamps and what not).

Configuration

Some applications use Zookeeper to keep configuration stored (considering it’s within the size limits recommended by Zookeeper). This is much better than managing your configuration in property files, xmls or even a database (remember Zookeeper is Fast for reads). Zookeeper also offers access control with ACLs on it’s node structure and this comes in handy when managing configurations. Solr Cloud and Glu use Zookeeper in this way.

If you wish to run your data center the democratic way, where important decisions are made in coordination with other stakeholders, Zookeeper certainly helps.

Leader Election with Spring is on GitHub, Source shown in this post can be found on Gist.

Happy Zookeeping!

This post is not going to dwell on the details of creating an App Engine account or a Facebook application. Those are described very well by their providers and across the web.

The example is an application called “famousity”. It authenticates a Facebook user then looks through his friends and determines how famous they are by executing a Google search on their exact name and comparing the hit count. Not very clever but will do in order to get a first feel of these tools.

After creating a Facebook application you should be see the following screen:

As you can see the Canvas URL is http://fbfamousity.appspot.com is where our Google App Engine application resides. We’re going to need our application id, API Key and App Secret values moving forward so we keep them handy by creating a class to encapsulate them (of course in a real world scenario we should have externalized these):

public class FacebookUtil {
    private static final String API_KEY = "API_KEY"; // replace with real values from Facebook app configuration
    private static final String SECRET = "SECRET"; // replace with real values from Facebook app configuration
    private static final String APPLICATION_ID = "APPLICATION_ID "; // replace with real values from Facebook app configuration

    private static final String FB_GRAPH_URL = "https://graph.facebook.com/";
    private static final String FB_OAUTH_URL = FB_GRAPH_URL + "oauth/";
    private static final String FB_FRIENDS_URL = FB_GRAPH_URL + "me/friends?";

    // private static final String REDIRECT_URL =
    // "http://apps.facebook.com/famousity/";

    // localhost is for testing
    private static final String REDIRECT_URL = "http://localhost:8888/";

    public static String getApplicationId() {
        return APPLICATION_ID;
    }

    public static String getAPIKey() {
        return API_KEY;
    }

    public static String getSecret() {
        return SECRET;
    }

    public static String getAuthorizeUrl() {
        final StringBuilder sb = new StringBuilder(FB_OAUTH_URL);
        sb.append("authorize?client_id=").append(APPLICATION_ID);
        sb.append("&display=page&redirect_uri=").append(REDIRECT_URL);
        sb.append("&scope=user_status,publish_stream,offline_access,email");
        return sb.toString();
    }

    public static String getAccessTokenUrl(final String authCode) {
        final StringBuilder sb = new StringBuilder(FB_OAUTH_URL);
        sb.append("access_token?canvas=1&fbconnect=0&type=user_agent&client_id=").append(
                APPLICATION_ID);
        sb.append("&redirect_uri=").append(REDIRECT_URL);
        sb.append("&client_secret=").append(SECRET);
        sb.append("&code=").append(authCode);
        return sb.toString();
    }

    public static String getFriendsUrl(final String authToken) {
        return FB_FRIENDS_URL + authToken;
    }
}

One thing to note here about this class is that the REDIRECT_URI field has a value of either http://localhost:8888/ or http://apps.facebook.com/famousity/ depending on weather we are working in our local development environment or the App Engine “production” environment. Remember to change this before deploying your application to App Engine (the change needs to take place in the Facebook application settings as well).

For my development environment I used STS with Google Integration. However, if you use Eclipse you can simply install the Google Eclipse Plugin which provides App Engine and GWT support within the IDE.

After installing the IDE plugin you get a new Google toolbar for creating a new web application, compiling GWT, profiling to speed tracer and deploying your app to App Engine. It seems that even tighter Eclipse integration is planned for the next version of the plugin.

Facebook’s authentication is composed of several steps:

The user initially goes to http://apps.facebook.com/famousity the canvas page is invoked. After that ourapplication needs to send an authorization request with the appropriate permissions. Something along the lines of:

https://graph.facebook.com/oauth/authorize?client_id=APP_CLIENT_ID&display=page&redirect_uri=http://localhost:8888/&scope=user_status,publish_stream,offline_access,email

Once the user authorizes our app it will redirect back to the parameter specified under “redirect_uri” with the access token.

This covers the initial authorization flow, but you must also account for the scenario where the user denies access to your app in which case face will provide you with an error message parameter in the form of:

http://YOUR_CANVAS_PAGE?error_reason=user_denied&error=access_denied&error_description=The+user+denied+your+request

The next time the user arrives at the application it has already been authorized but you still need to retrieve the access token. The application needs to execute access token request. It looks like:

https://graph.facebook.com/oauth/access_token?canvas=1&fbconnect=0&type=user_agent&client_id=APP_CLIENT_ID&redirect_uri=http://localhost:8888/&client_secret=APP_SECRET

After that the application can proceed to execute authorized graph API calls using the provided token:

https://graph.facebook.com/me/friends?access_token=FB_PROVIDED_ACCESS_TOKEN

To create a new GWT-App Engine-Facebook project open Eclipse and click the New Web Application Project, type the name and a package and click Finish. This will create a new GWT application. It will also generate some sample code, notice it has created a “client”, “server” and “shared” packages The client package should contain two interfaces the RemoteService specification interface and it’s Async correspondent. In our case we will create a Facebook service to handle facebook operations:

@RemoteServiceRelativePath("facebook")
public interface FacebookService extends RemoteService {
    public String login(String authToken);
    public List<FbFriend> findFriends(String authToken);
}

And it’s Async twin, an identical interface with another parameter, a typed AsyncCallback:

public interface FacebookServiceAsync {
    public void login(String authToken, AsyncCallback<String> asyncCallback);
    public void findFriends(String authToken, AsyncCallback<List<FbFriend>> asyncCallback);
}

Our Facebook service contains two methods, one is for the initial authentication of the user and accepts an existing authentication token used to pass back to the client. This lets the client know that the user was previously authenticated and can proceed into the app. For more information on the Facebook authentication flow check their documentation. The login method returns the authentication token which is later used in subsequent calls to the Facebook API.

The findFriends method accepts the authentication token and retrieves a list of FbFriend instances. Note that in GWT classes used to communicate between the client and the remote service must implement the IsSerializable interface.

public class FbFriend implements IsSerializable {

    private Long id;
    private String name;

    public Long getId() {
        return id;
    }

    public String getName() {
        return name;
    }

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

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

The FacebookService implementation is shown below

public class FacebookServiceImpl extends RemoteServiceServlet implements FacebookService {
    private static final long serialVersionUID = 1L;

    public String login(final String authToken) {
        final String url = FacebookUtil.getAccessTokenUrl(Util.encode(authToken));
        return Util.fetchURL(url);
    }

    public List<FbFriend> findFriends(final String authToken) {
        final String friendsUrl = FacebookUtil.getFriendsUrl(encodeUrl(authToken));
        final String json = Util.fetchURL(friendsUrl);
        final FBFriends fbFriends = new Gson().fromJson(json, FBFriends.class);
        return fbFriends.getData();
    }

    private static String encodeUrl(final String unencodedToken) {
        final String[] parts = unencodedToken.split("=");
        if (parts.length < 2) {
            return "";
        }
        return "access_token=" + Util.encode(parts[1]);
    }
}

Our FacebookService will handle the login and the friend retrieval but what about the Google name search hit counts? For this we devise another service with an async counterpart:

@RemoteServiceRelativePath("google")
public interface GoogleService extends RemoteService {
    public Long findFriendRanking(FbFriend friend);
}

public interface GoogleServiceAsync {
    public void findFriendRanking(FbFriend friend, final AsyncCallback<Long> asyncCallback);
}

And here is the implementation for this service:

public class GoogleServiceImpl extends RemoteServiceServlet implements GoogleService {
    private static final long serialVersionUID = 1L;

    private static final Logger logger = LoggerFactory.getLogger(Util.class);
    private static final String GOOGLE_API_URL = "http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=";

    private final DatastoreService datastore = DatastoreServiceFactory.getDatastoreService();

    public Long findFriendRanking(final FbFriend friend) {
        final Key key = KeyFactory.createKey("profile", friend.getId());
        try {
            final Entity profile = datastore.get(key);
            final Object result = profile.getProperty("estimatedResultCount");
            return (Long) result;
        } catch (final EntityNotFoundException e) {
            logger.debug("Could not find an entry for {} in the datastore.", friend.getId());
            final Long resultCount = findResultCount(friend.getName());
            final Entity newProfile = new Entity(key);
            newProfile.setProperty("profileName", friend.getName());
            newProfile.setProperty("estimatedResultCount", resultCount);
            datastore.put(newProfile);
            return resultCount;
        }
    }

    public Long findResultCount(final String name) {
        final String queryUrl = GOOGLE_API_URL + Util.encode("\"" + name + "\"");
        logger.debug("Executing google query {}", queryUrl);
        final String resultJson = Util.fetchURL(queryUrl);

        final ResponseDataContainer container = new Gson().fromJson(resultJson,
                ResponseDataContainer.class);

        if (null != container && null != container.getResponseData()
                && null != container.getResponseData().getCursor()) {
            final Long resultCount = container.getResponseData().getCursor()
                    .getEstimatedResultCount();
            return resultCount;
        } else {
            return -1L;
        }
    }
}

We create a key based on the friend’s Facebook id and then use that key to search the AppEngine datastore. If the key doesn’t exist we handle the EntityNotFoundException by executing a new search and placing the result values in the datastore for future use.

When working in the local development environment, notice that the AppEngine library has created a local datastore for you. This can be found under “war/WEB-INF/appengine-generated/local_db.bin” in our workspace.

In case you’re wondering about the validity of the results here it is a complete spoof. The Google Ajax Search API has been deprecated for quite some time now and the correctness of the results is dubious at best. It will do for this example but not for any real world apps.

Now to the GWT client code, here we need to perform a few basic steps:

We use the returned “code” parameter returned to us by Facebook to see if the user has an access token. If he doesn’t we redirect him to the authorization Url this will cause Facebook to display the following authorization dialog:

Next we check for the “user_denied” parameter place by the caller (Facebook) and display an appropriate error message to the user (if we want to force him to authorize all permissions, depending on what our app requires to function). If the user has denied our authorization request we better notify him that he needs to authorize us:

After we’re done with the authorization checks we can now safely proceed with our access token to retrieve the user’s friend list, using our FacebookService remote interface. For each friend returned we draw a widget then execute a name search using our GoogleService remote interface.

public class Famousity implements EntryPoint {

    private final FacebookServiceAsync facebookService = GWT.create(FacebookService.class);
    private final GoogleServiceAsync googleService = GWT.create(GoogleService.class);

    private MessageBox messageBox;

    public void onModuleLoad() {
        final String authToken = Location.getParameter("code");
        final String error = Location.getParameter("error_reason");

        if (null != error && error.equals("user_denied")) {
            userDenied();
        } else if (authToken == null || "".equals(authToken)) {
            redirect(FacebookUtil.getAuthorizeUrl());
        } else {
            messageBox = MessageBox.wait("Famousity", "", "Analyzing friend rankings...");

            facebookService.login(authToken, new AsyncCallback<String>() {
                public void onFailure(final Throwable caught) {
                    handleError(caught);
                }

                public void onSuccess(final String authToken) {
                    rankFriends(authToken);
                }
            });
        }
    }

    private void userDenied() {
        MessageBox.confirm("Error authrizing famousity",
                "You have deined famousity from installing correctly, click 'Yes' to try again",
                new Listener<MessageBoxEvent>() {

                    public void handleEvent(final MessageBoxEvent be) {
                        if (be.getButtonClicked().getText().equals("Yes")) {
                            redirect(FacebookUtil.getAuthorizeUrl());
                        } else {
                            be.getMessageBox().close();
                        }
                    }
                });
    }

    private void rankFriends(final String authToken) {

        final RootPanel rootPanel = RootPanel.get();
        facebookService.findFriends(authToken, new AsyncCallback<List<FbFriend>>() {
            public void onFailure(final Throwable caught) {
                Window.alert(caught.getMessage());
            }

            public void onSuccess(final List<FbFriend> friends) {
                closeMessageBox();
                final Header header = new Header();
                header.setText("How famous are your friends");
                rootPanel.add(header);

                for (final FbFriend friend : friends) {
                    final Panel friendPanel = new HorizontalPanel();

                    friendPanel.setStyleName("panel");
                    final Image profilePic = new Image(getProfilePictureUrl(friend));
                    profilePic.setStyleName("profilePic");
                    friendPanel.add(profilePic);
                    friendPanel.add(new Hidden(friend.getId().toString()));
                    friendPanel.add(new Text(friend.getName()));
                    final Text countText = new Text("");
                    friendPanel.add(countText);
                    rootPanel.add(friendPanel);

                    googleService.findFriendRanking(friend, new AsyncCallback<Long>() {

                        public void onFailure(final Throwable caught) {
                            handleError(caught);
                        }

                        public void onSuccess(final Long result) {
                            if (result > 0) {
                                countText.setText(result.toString());
                            } else {
                                countText.getParent().setVisible(false);
                            }
                        }
                    });
                }
            }

        });

    }

    private void handleError(final Throwable caught) {
        Window.alert(caught.getMessage());
    }

    private String getProfilePictureUrl(final FbFriend friend) {
        return "http://graph.facebook.com/" + friend.getId() + "/picture";
    }

    private void closeMessageBox() {
        if (messageBox != null) {
            messageBox.close();
            messageBox = null;
        }
    }

    // redirect the browser to the given url
    public static native void redirect(String url)/*-{
		$wnd.location = url;
    }-*/;
}

While the user is waiting a neat progress bar is displayed using the aid of GWT-EXT:

This is what the (censored) output looks like:

A few words about the GWT code here. GWT relies heavily on asynchronous calls. There is some suspicion that rises from nesting these calls although Google has a good explanation for why this is the way it is. Some discussion of this issue can be found here and here. It seems some recommend moving logic to the server while other try to devise more neat solutions for the code. In AppEngine more logic running on the server may pose a problem due to the 30 second limitation. We must take these matters under consideration when combining these two technologies. The need to explicitly implement the RemoteService and it’s Async twin seem a bit off as well, they smell a little like the old EJB stuff. Other MVC implementations save you this kind of boilerplate code by using annotations or configuration files.

After testing the application in Eclipse, click the “Deploy App Engine Project” button in Eclipse then provide the Google credentials and our application get’s compiled and deployed automatically. A pretty cool combination, for my next social project I think I am going to take a closer look at Spring Social.

Source code is available here.

One thing is the Spring documentation and most examples I’ve found in my travels have pointed toward the scenario where all your JobDetails and Triggers are defined “statically” in the Spring configuration files, not at runtime. My use case is slightly different, I need to create these Triggers at runtime. Some posts like this one suggests using a dependency-injected factory which will both create and wire the Triggers at runtime with dependencies, this is a valid solution but violates the IoC principle.

In a previous post I showed how to use Spring prototype scoped beans with dependency injection. In this post I’d like to show how the same notion can be applied to create prototype-scoped Quartz Triggers and JobDetails with Spring.

Let’s start by defining the scheduler using a SchedulerFactoryBean to create an instance of the scheduler:

<bean id="quartzScheduler"
	class="org.springframework.scheduling.quartz.SchedulerFactoryBean">
	<property name="jobFactory">
		<bean class="org.springframework.scheduling.quartz.SpringBeanJobFactory" />
	</property>
	<property name="configLocation" value="classpath:quartz.properties" />
	<property name="waitForJobsToCompleteOnShutdown" value="true" />
	<property name="triggerListeners">
		<list>
			<ref bean="myTriggerListener" />
		</list>
	</property>
	<property name="schedulerContextAsMap">
		<map>
			<entry key="myServiceBean" value-ref="myServiceBean" />
		</map>
	</property>
	<property name="dataSource" ref="datasource" />
</bean>

Notice how myServiceBean is wired into the schedulerContextAsMap property. In its documentation Spring suggests that for persistent jobs you wire your beans this way and not via the JobDataMap, the “state context” mechanism for jobs.

So now I can get to work and define my Trigger and JobDetail prototype factories:

<bean id="jobTriggerFactory"
	class="org.springframework.beans.factory.config.ObjectFactoryCreatingFactoryBean">
	<property name="targetBeanName">
		<idref local="jobTrigger" />
	</property>
</bean>
<bean id="jobTrigger" class="org.springframework.scheduling.quartz.SimpleTriggerBean"
	scope="prototype">
      <property name="group" value="myJobs" />
      <property name="description" value="myDescription" />
      <property name="repeatInterval" value="${myproperties.repeatinterval}" />
</bean>

<bean id="jobDetailFactory"
	class="org.springframework.beans.factory.config.ObjectFactoryCreatingFactoryBean">
	<property name="targetBeanName">
		<idref local="jobDetail" />
	</property>
</bean>

<bean id="jobDetail" class="org.springframework.scheduling.quartz.JobDetailBean"
	scope="prototype">
	<property name="jobClass" value="org.echotech.scheduler.MyJob" />
	<property name="volatility" value="false" />
	<property name="durability" value="false" />
	<property name="requestsRecovery" value="true" />
</bean>

<bean id="schedulerManager" class="org.echotech.scheduler.MySchedulerManagerImpl">
	<constructor-arg ref="quartzScheduler" />
	<constructor-arg ref="jobDetailFactory" />
	<constructor-arg ref="jobTriggerFactory" />
</bean>

The code for MySchedulerManagerImpl shows how to register a new Job with the scheduler using the provided factories.

public class MySchedulerManagerImpl {
   private final Scheduler scheduler;
   private final ObjectFactory<SimpleTrigger> jobTriggerFactory;
   private final ObjectFactory<JobDetail> jobDetailFactory;

   public MySchedulerManagerImpl(final Scheduler scheduler,
         final ObjectFactory<JobDetail> jobDetailFactory,
         final ObjectFactory<SimpleTrigger> jobTriggerFactory) {
      Assert.notNull(scheduler, "scheduler cannot be null");
      Assert.notNull(jobDetailFactory, "jobDetailFactory cannot be null");
      Assert.notNull(jobTriggerFactory, "jobTriggerFactory cannot be null");
      this.scheduler = scheduler;
      this.jobDetailFactory = jobDetailFactory;
      this.jobTriggerFactory = jobTriggerFactory;
   }

   public void scheduleNewJob(final Map<String, String> parameters,
         final String name) {
      // create a trigger
      SimpleTrigger trigger = jobTriggerFactory.getObject();
      trigger.setRepeatCount(SimpleTrigger.REPEAT_INDEFINITELY);
      trigger.setStartTime(new Date());
      trigger.setName(name);

      // create job details
      JobDetail jobDetail = jobDetailFactory.getObject();

      jobDetail.setName(name);
      jobDetail.setGroup(trigger.getGroup());
      jobDetail.getJobDataMap().putAll(parameters);

      try {
         scheduler.scheduleJob(jobDetail, trigger);
      } catch (SchedulerException e) {
         // handle this, either wrap and re-throw with runtime variant or do
         // something meaningful
      }
   }
}

This way you can decide what JobDetail and Trigger parameters you want to be defined in the Spring container (values can be externalized to property files, JNDI or other sources using the common Spring abstractions) and what is determined at runtime.

Hope this helps, happy scheduling

Cobertura is one of the key static analysis tool every developer should work with. I’ve seen numerous project increase their code coverage using this tool and which in turn can and will reduce QA cycles and overall bug counts any given system.

I recently had to integrate Cobertura code coverage with TestNG into the build system and CI server and found very little on the net on how to do it. EclEmma has a great coverage plugin for eclipse which is a must for every developer writing tests (a small nit that I had with TestNG and this plugin is that you have to run the tests first using the TestNG plugin and only then I was successful in running them again in coverage mode). But the plugin is not enough, it is also important to run coverage reports on a nightly build and continuously monitor the coverage percentage of your application as the project evolves.

In order to run the Cobertura coverage you need to:

1. instrument your classes
2. execute your tests with the instrumented classes
3. use the cobertura generated execution file created at step 2 to generate an html report.

For keeping things DRY, you’re better off not copying your test ant targets but reuse the existing ones. In order to do this let’s make the classpathref attribute of the TestNG task parametric (I used a var so I can override it from other builds, you need antcontrib to use var).

   <property name="cb.file" location="${basedir}/cobertura.bin" />
   <var name="cb.arg" value="none" />

   <!-- normally this would contain your standard test classpath -->
   <var name="test.cp" value="test.cp" />
   <target name="test">
      <testng classpathref="${test.cp}"
              haltOnFailure="true">
         <xmlfileset dir="${basedir}/src/test" includes="tests.xml" />
         <sysproperty key="${cb.arg}" value="${cb.file}" />
      </testng>
   </target>

The remainder of the build file looks roughly something like this:

   <!-- define the cobertura jars classpath -->
   <path id="cb.cp">
      <!--
		Includes the following jars:
		asm-all 3.2
		cobertura 1.9.4.1
		log4j 1.2.14
		oro 2.0.8
		-->
   </path>

   <target name="cb.init">
      <!-- output directory -->
      <property name="cb.report.dir" value="${basedir}/cobertura" />
      <!-- instrumentation directory -->
      <property name="cb.instrument.dir"
                value="${cb.report.dir}/.cobertura-instrumented-classes" />

      <!-- your main java source files -->
      <property name="cb.src.dir" value="${basedir}/src/main" />
      <!-- your main class files files -->
      <property name="cb.classes.dir" value="${basedir}/bin/main" />
      <!-- your test class files -->
      <property name="cb.test.classes.dir" value="${basedir}/bin/test" />

      <taskdef classpathref="cb.cp" resource="tasks.properties" />
   </target>

   <target name="cb" depends="cb.gen, cb.xml, cb.html">
      <delete file="${cb.file}" />
      <delete dir="${cb.instrument.dir}" />
   </target>

   <target name="cb.instrument">
      <mkdir dir="${cb.report.dir}" />
      <cobertura-instrument todir="${cb.instrument.dir}/"
                            maxmemory="512M"
                            datafile="${cb.file}">
         <fileset dir="${cb.classes.dir}">
            <include name="**/*.class" />
         </fileset>
      </cobertura-instrument>
   </target>

   <target name="init.cb.path">
      <var name="test.cp" value="cb.test.cp" />
      <var name="cb.sysarg" value="net.sourceforge.cobertura.datafile" />
      <path id="cb.test.cp">
         <pathelement path="${cb.instrument.dir}" />
         <pathelement path="${cb.classes.dir}" />
         <pathelement path="${cb.test.classes.dir}" />
         <path refid="test.cp" />
         <path refid="cb.cp" />
      </path>
   </target>
   <target name="cb.run" depends="init.cb.path, test" />
   <target name="cb.gen" depends="cb.init, cb.instrument, cb.run" />
   <target name="cb.html">
      <cobertura-report format="html"
                        destdir="${cb.report.dir}"
                        maxmemory="512M"
                        datafile="${cb.file}">
         <fileset dir="${cb.src.dir}">
            <include name="**/*.java" />
         </fileset>
      </cobertura-report>
   </target>

   <target name="cb.xml">
      <cobertura-report format="xml"
                        destdir="${cb.report.dir}"
                        maxmemory="512M"
                        datafile="${cb.file}">
         <fileset dir="${cb.src.dir}">
            <include name="**/*.java" />
         </fileset>
      </cobertura-report>
   </target>

Make sure you remember to initialize your test classpath properly as part of the Cobertura flow.

Once you get this working (had to overcome a couple of obstacles with Cobertura report not finding the datafile and tweak the classpath a bit to get it to work) it is really easy to connect this to your CI build. If you’re using Hudson then download the Cobertura Plugin and point it to all of your projects output cobertura.xml files. These CI servers are great in aggregating these reports and providing a time-lapse view of your code coverage:

In this example I have a SearchBusinessDelegate which depends on MyService to execute the search.

MyService‘s interface:

public interface MyService {
	List<Long> executeSerch(final int maxResults, final SearchCriteria criteria);
}

and here is SearchBusinessDelegate‘s implementation:

public class SearchBusinessDelegate {

	private final MyService myService;

	private SearchCriteria statefulCriteria;
	private int maxResults;

	public SearchBusinessDelegate(final MyService myService) {
		this.myService = myService;
	}

	public void initCriteria(final SearchCriteria searchCriteria, final int maxResults) {
		this.statefulCriteria = searchCriteria;
		this.maxResults = maxResults;
	}

	public List<Long> executeSearch() {
		Assert.isTrue(maxResults > 0, "maxResult cannot be less than 1");
		Assert.notNull(statefulCriteria, "search criteria cannot be null");
		return myService.executeSerch(maxResults, statefulCriteria);
	}
}

Notice the delegate’s mix of load time dependencies and run time parameters. IMO you should be extremely cautious about using these kind of stateful delegates, one noticeable drawback of this implementation is the need to assert that initCriteria was invoked prior to invoking executeSearch, which is a foxhole. For the sake of implementing the pattern correctly this is now kept as is.

The traditional way of doing this is to implement a BusinessDelegateFactory which gets injected the BusinessDelegate‘s dependencies and does the dependency injection on the business delegate upon creation. For example:

public class SearchBusinessDelegateFactory {
	private final MyService myService;

	public SearchBusinessDelegateFactory(final MyService myService) {
		this.myService = myService;
	}

	public SearchBusinessDelegate create(final SearchCriteria searchCriteria, final int maxResults) {
		final SearchBusinessDelegate delegate = new SearchBusinessDelegate(myService);
		delegate.initCriteria(searchCriteria, maxResults);
		return delegate;
	}
}

And the Spring configuration would be:

<bean id="myService" class="org.echotech.service.MyServiceImpl" />

<bean id="searchBusinessDelegateFactory" class="org.echotech.service.SearchBusinessDelegateFactory">
	<constructor-arg ref="myService" />
</bean>

Using this factory however causes us to lose IoC principle en-route. We are creating the delegate in code which kind of defeats the purpose (for example, think about how you’d wrap the SearchBusinessDelegate‘s with AOP interception this way), bummer. We could have our factory implement the ApplicationContextAware and retrieve the prototype instance from the context each time. But this factory code, is it really necessary? isn’t that the purpose of using Spring in the first place?

The answer is yes, we can take advantage of Spring’s ObjectFactory implementations, namely ObjectFactoryCreatingFactoryBean.

First we define the factory in Spring:

<bean id="myService" class="org.echotech.service.MyServiceImpl" />

<bean id="searchBusinessDelegate" class="org.echotech.service.SearchBusinessDelegate"
	scope="prototype">
	<constructor-arg ref="myService" />
</bean>

<bean id="searchBusinessDelegateFactory"
	class="org.springframework.beans.factory.config.ObjectFactoryCreatingFactoryBean">
	<property name="targetBeanName">
		<idref local="searchBusinessDelegate" />
	</property>
</bean>

Now we can wire the factory in our client (in this case, a controller) which ensures a fresh instance of the delegate (prototype scope in Spring) is used for every invocation of executeSomething method:

@Controller
public class MyController {

	private final ObjectFactory<SearchBusinessDelegate> delegateFactory;

	public MyController(final ObjectFactory<SearchBusinessDelegate> delegateFactory) {
		this.delegateFactory = delegateFactory;
	}

	@RequestMapping(method = RequestMethod.GET)
	public List<Long> executeSomething(@RequestParam(value = "keyword") final String keyword) {
		final SearchBusinessDelegate delegate = delegateFactory.getObject();
		delegate.initCriteria(new SearchCriteria(keyword, true), 100);
		return delegate.executeSearch();
	}
}

This way we can get a prototype instance of our delegate for each invocation while taking advantage of Spring dependency injection and other Spring features (e.g., AOP, post processing, etc.) for our prototype.

For each application there is typically a single top node (the web or desktop application layer). From this node the dependencies spread out to the various components which the application requires. Further down the stack these dependencies join where low level components are shared by higher level components for re-usability.

When you decide to go full stack Spring, modularity can get tricky, the Spring documentation typically tells you to bootstrap the application context in code or via the deployment descriptor (web.xml for j2ee web applications using ContextLoaderListener).

In code this is done by instantiating one of the ApplicationContext variants:

ApplicationContext context = new ClassPathXmlApplicationContext(new String[] {"a1-file.xml", "a2-file.xml"});

In the web.xml the configuration is quite similar:

<context-param>
  <param-name>contextConfigLocation</param-name>
  <param-value>/WEB-INF/a1-file.xml /WEB-INF/a2-file.xml</param-value>
</context-param>

<listener>
  <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

But now what happens when you want to inject dependencies from lower level components into higher level components? The most straightforward solution is to add an import into A‘ s context file:

<beans>
    <import resource="classpath*:b1-file.xml"/>
    <import resource="classpath*:b2-file.xml"/>
    <import resource="classpath*:c1-file.xml"/>
    <import resource="classpath*:c2-file.xml"/>   

    <!-- from here on A's beans can be injected with b's and c's beans -->
</beans>

This seems easy but has some obvious pitfalls. For starters we just stated that A has to manage the bean definition for the entire stack which reeks of a maintenance hurdle. A more natural approach would be to have each component manage its own bean definition and define a single dependency between each component in the graph.

To solve this we can create a single file in each component, a descriptor file if you wish, and import only that component’s file-set in the descriptor file.

So B‘s and C‘s descriptors would look like

SpringDescriptor.xml in component B:

<beans>
    <import resource="classpath*:b1-file.xml"/>
    <import resource="classpath*:b2-file.xml"/>
</beans>

SpringDescriptor.xml in component C:

<beans>
    <import resource="classpath*:c1-file.xml"/>
    <import resource="classpath*:c2-file.xml"/>
</beans>

This way we can define a single import for all the components in our stack in A‘s context:

<beans>
    <import resource="classpath*:**/**SpringDescriptor*.xml"/>   

    <!-- from here on A's beans can be injected with any component that contains the SpringDescriptor*.xml files -->
</beans>

So is this good enough? IMO no, it still has some drawbacks. When you load your beans this way, everything gets piled loaded into a single ApplicationContext which is created at the application’s entry point and contains beans from the entire stack. For small applications with few dependencies this might work but when this scales up things might get tangled. For example defining BeanPostProcessor or PropertyPlaceholderConfigurer for a single-component-scope is not possible in this design and is often desirable.

Another evil scenario I’ve come across is one where due to improper initialization of the application context (using a static singleton for bootstrapping application context) the application context actually gets initialized twice. Spring references this scenario in Glue code and the evil singleton.

To the rescue comes ContextSingletonBeanFactoryLocator which brings a bombastrous name and a handy solution for the task at hand.

The idea here is that every component contains a descriptor XML file (similar to our SpringDescriptor.xml, the default convention is beanRefContext.xml which can be customized by defining a different selector). This descriptor is keyed and defines the application context for that component.
Here is an example of the beanRefContext.xml from our B component.

 <beans>
   <bean id="bContext"
         class="org.springframework.context.support.ClassPathXmlApplicationContext">
     <constructor-arg>
       <list>
         <value>b1-file.xml</value>
         <value>b2-file.xml</value>
       </list>
     </constructor-arg>
     <constructor-arg ref="cContext">
   </bean>

 </beans>

As you can see this is nothing short of instantiating an ApplicationContext for each component in our graph, taking advantage of the second constructor argument of ClassPathXmlApplicationContext which defines a parent context. Yes, ApplicationContexts can be chained in a hierarchy (unidirectional, beans can “see” other beans in parent contexts only and not vice-versa).

Bootstrapping the context in code is the carried out this way:

BeanFactoryLocator beanFactoryLocator = ContextSingletonBeanFactoryLocator.getInstance();
BeanFactoryReference beanFactoryReference = beanFactoryLocator.useBeanFactory("aContext");
BeanFactory beanFactory = beanFactoryReference.getFactory();

Note that the getInstance method of the ContextSingletonBeanFactoryLocator class has an overload which accepts a selector argument designating the convention for descriptor files.

In a web deployment the ContextSingletonBeanFactoryLocator is utilized using the LOCATOR_FACTORY_KEY_PARAM and the LOCATOR_FACTORY_SELECTOR_PARAM of the ContextLoader class. These can be specified in web.xml

<context-param>
  <param-name>parentContextKey</param-name>
  <param-value>aContext</param-value>
</context-param>
<!-- Specfies the parent context of the root WebApplicationContext -->

<context-param>
  <param-name>locatorFactorySelector</param-name>
  <param-value>SpringDescriptor.xml</param-value>
</context-param>
<!-- Specifies a different convention. the default being beanRefContext.xml -->

The only problem which remains is how to define components with more than one parent contexts. This cannot be done with the standard ApplicationContext as it only accepts a single context for the parent, which forces a liner hierarchy between contexts. You could still arrange the context so that all beans have the desired visibility scope for example the dependency graph shown above could be organized the following way:

Finally, with the introduction of Spring OSGi the approach towards initialization and life-cycle of ApplicationContexts has changed but more on that in another post.

However, eclipse truely reveals its power when you add healthy dosage of plugins to the mix. Everyone has their list, here are my favorites:

Name	Web Page	Update Site	Comments
SpringSTS	Plugin Web Page	http://dist.springsource.com/snapshot/STS/nightly/e3.4	A must for anyone who uses spring for eclipse 3.5 see the spring blog
FindBugs	Plugin Web Page	http://findbugs.cs.umd.edu/eclipse	Find bugs is a must for any developer, you can learn about avoiding common coding mistakes, and become a better programmer
PMD	Plugin Web Page	http://pmd.sourceforge.net/eclipse	PMD complements and enhances FindBugs
EclEmma	Plugin Web Page	http://update.eclemma.org/	Get instant coverage information on your unit and integration tests
Spell Checker	Plugin Web Page	http://www.bdaum.de/eclipse/eSpell3	For some reason I was never quite happy with the eclipse spell chekcer.
JbossTools	Plugin Web Page	http://download.jboss.org/jbosstools/updates/stable/	A must for hibernate users
Subclipse SVN	Plugin Web Page	http://subclipse.tigris.org/update_1.6.x	SVN source control plugin
AccuBridge for Accurev	Plugin Web Page	http://www.accurev.com/download/eclipseupdate/34	Source control plugin for Accurev (the plugin is free, the software is not)
JsEclipse	Plugin Web Page	http://download.macromedia.com/pub/labs/jseclipse/autoinstall/	Javascript plugin
Atlassian IDE Connector	Plugin Web Page	http://update.atlassian.com/atlassian-eclipse-plugin/e3.4	Great for Jira and other Atlassian products, update site works for eclipse 3.5 as well>
Structure 101	Plugin Web Page	http://www.headwaysoftware.com/downloads/structure101/ideplugin/eclipse/	Structure 101 Plugin, AgileJ has one too if you use that
IvyDE	Plugin Web Page	http://www.apache.org/dist/ant/ivyde/updatesite	Plugin for working with Apache Ivy
JDepend4Eclipse	Plugin Web Page	http://andrei.gmxhome.de/eclipse/	A java dependency analysis tool (a free albeit feature-less version of structure 101)
Perforce P4WSAD	Plugin Web Page	http://www.perforce.com/downloads/http/p4-wsad/install/3.5	A plugin for working with the Perforce SCM system
Google Eclipse Plugin	Plugin Web Page	http://dl.google.com/eclipse/plugin/3.6	A plugin for working with Google Web Toolkit and Google App Engine

<bean id="myApplicationContext" lazy-init="false"
	class="org.springframework.context.support.ClassPathXmlApplicationContext">
	<constructor-arg>
		<list>
			<value>classpath*:myJar-applicationContext.xml</value>
			<value>localXml-applicationContext.xml</value>
		</list>
	</constructor-arg>
</bean>

And then again in LocalSessionFactoryBean when defining hibernate mapping locations:

<bean id="hibernateSessionFactory"
	class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
	<property name="mappingLocations">
		<list>
			<value>classpath*:org/echotech/**/*.hbm.xml</value>
			...
		</list>
	</property>
	...
</bean>

And on to several more places in the Spring framework where resource locations need to be defined. At the heart of this mechanism lies the PathMatchingResourcePatternResolver class. This class is not exposed much in the Spring documentation, I guess framework developers treat it as an internal utility class.

Why is this useful to me? I the enterprise application domain resources can be quite difficult to manage, they are usually numerous and they reside in many artifacts (jars). Good componentization is useful, almost a must, for defining resource-ownership, but sometimes cross-cutting concerns require you to scan and retrieve everything. Assuming naming conventions are well-enforced, pattern-based resolution can prove to be quite powerful.

In my example I want to use pattern matching for classes rather than resources. Here is the proposed bean definition:

<bean id="classResourcePatternResolver" class="org.echotech.util.ClassResourcePatternResolver">
	<constructor-arg>
		<list>
			<value>classpath*:org/echotech/**/**Service.class</value>
		</list>
	</constructor-arg>
</bean>

As you can see I am trying to capture of all of my service classes, regardless of package location (or physical jar/compiled class location). Here is the implementation of ClassResourcePatternResolver:

public class ClassResourcePatternResolver {

	private static final String CLASS_SUFFIX = ".class";
	private static final String CLASSES_LOCATION = "classes";

	private final List<Class<?>> classes = new LinkedList<Class<?>>();
	private final ResourcePatternResolver resourcePatternResolver = new PathMatchingResourcePatternResolver();

	public ClassResourcePatternResolver(final List<String> resourceLocations) throws IOException,
			ClassNotFoundException {
		for (final String resourceLocation : resourceLocations) {
			classes.addAll(resolveClassesFromPattern(resourceLocation));
		}
	}

	private Collection<Class<?>> resolveClassesFromPattern(final String pattern)
			throws IOException, ClassNotFoundException {
		final Collection<Class<?>> classes = new LinkedList<Class<?>>();
		if (ResourcePatternUtils.isUrl(pattern)) {
			final Resource[] resources = resourcePatternResolver.getResources(pattern);
			for (final Resource resource : resources) {
				final String className;
				final URL url = resource.getURL();
				if (ResourceUtils.isJarURL(url)) {
					className = resolveClassFromjar(url.toString());
				} else {
					className = resolveClassFromPath(url.toString());
				}

				if (StringUtils.hasText(className)) {
					classes.add(Class.forName(className));
				}
			}
		} else {
			classes.add(Class.forName(pattern));
		}

		return classes;
	}

	private static String resolveClassFromPath(final String url) {
		final String classUrl = url.substring(url.indexOf(CLASSES_LOCATION)
				+ CLASSES_LOCATION.length() + 1, url.indexOf(CLASS_SUFFIX));
		return ClassUtils.convertResourcePathToClassName(classUrl);
	}

	private static String resolveClassFromjar(final String url) {
		final String classUrl = url.substring(url.indexOf(ResourceUtils.JAR_URL_SEPARATOR) + 2, url
				.indexOf(CLASS_SUFFIX));
		return ClassUtils.convertResourcePathToClassName(classUrl);
	}

	public List<Class<?>> getClasses() {
		return classes;
	}
}

Notice that I have to handle both the jar resource url and the local filesystem resource url (assuming in any scenario the compile classes will either reside in a jar or in an exploded classes directory, be it /WEB-INF/classes or build/classes). Notice I’ve used several utility classes from the Spring toolbox such as ClassUtils, ResourcePatternUtils and more, all complement each other in this implementation.

Finally a simple unit test:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = { "/spring/util-context.xml" })
public class ClassResourcePatternResolverTest extends AbstractJUnit38SpringContextTests {
	@Autowired
	private ClassResourcePatternResolver classResourcePatternResolver;

	@Test
	public void test() throws Exception {

		List<Class<?>> classes = classResourcePatternResolver.getClasses();

		for (Class<?> clazz : classes) {
			System.out.println("Resolved class: " + clazz.getName());
		}
	}
}

Will produce the following output:

...
Resolved class: org.echotech.service.AnotherService
Resolved class: org.echotech.service.MyService

I can easily use this to detect classes from the entire classpath, changing the pattern to classpath*:org/**/**Url*.class will detect all classes containing Url in my classpath

...
Resolved class: org.apache.jasper.tagplugins.jstl.core.Url
Resolved class: org.springframework.remoting.support.UrlBasedRemoteAccessor
Resolved class: org.springframework.core.io.UrlResource
Resolved class: org.springframework.web.util.UrlPathHelper
Resolved class: org.springframework.web.servlet.handler.AbstractDetectingUrlHandlerMapping
Resolved class: org.springframework.web.servlet.handler.AbstractUrlHandlerMapping$PathExposingHandlerInterceptor
Resolved class: org.springframework.web.servlet.handler.AbstractUrlHandlerMapping$UriTemplateVariablesHandlerInterceptor
Resolved class: org.springframework.web.servlet.handler.AbstractUrlHandlerMapping
Resolved class: org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping
Resolved class: org.springframework.web.servlet.handler.SimpleUrlHandlerMapping
Resolved class: org.springframework.web.servlet.mvc.AbstractUrlViewController
Resolved class: org.springframework.web.servlet.mvc.UrlFilenameViewController
Resolved class: org.springframework.web.servlet.mvc.multiaction.AbstractUrlMethodNameResolver
Resolved class: org.springframework.web.servlet.mvc.support.AbstractControllerUrlHandlerMapping
Resolved class: org.springframework.web.servlet.tags.UrlTag$UrlType
Resolved class: org.springframework.web.servlet.tags.UrlTag
Resolved class: org.springframework.web.servlet.view.AbstractUrlBasedView
Resolved class: org.springframework.web.servlet.view.UrlBasedViewResolver
Resolved class: org.apache.taglibs.standard.tag.common.core.UrlSupport
Resolved class: org.apache.taglibs.standard.tag.el.core.UrlTag
Resolved class: org.apache.taglibs.standard.tag.rt.core.UrlTag
Resolved class: org.apache.tiles.definition.dao.BaseLocaleUrlDefinitionDAO
Resolved class: org.apache.tiles.definition.dao.CachingLocaleUrlDefinitionDAO$WildcardMapping
Resolved class: org.apache.tiles.definition.dao.CachingLocaleUrlDefinitionDAO
Resolved class: org.apache.tiles.definition.dao.LocaleUrlDefinitionDAO
Resolved class: org.apache.tiles.definition.dao.ResolvingLocaleUrlDefinitionDAO
Resolved class: org.apache.tiles.definition.UrlDefinitionsFactory$CompatibilityDefinitionsImpl
Resolved class: org.apache.tiles.definition.UrlDefinitionsFactory