Open a Web browser and navigate to http://localhost:8080/greenpages. Click the Submit button. Unfortunately the search will not return any results as the Web bundle is still using the stub Directory implementation provided by the greenpages.app module, rather than the JPA-based implementation that is provided by greenpages.jpa. This can be confirmed by using the OSGi telnet console.

Open a command prompt and enter

telnet localhost 2401

At the resulting prompt, enter ‘ss’ (for short status) and press return. This will return a list of all of the bundles currently running in dm Server. Ending something like this:

99	ACTIVE      com.springsource.org.apache.commons.dbcp_1.2.2.osgi
100	ACTIVE      com.springsource.org.h2_1.0.71
101	ACTIVE      greenpages-2-greenpages-synthetic.context_2.0.0
102	ACTIVE      greenpages-2-greenpages_2.0.0
103	ACTIVE      greenpages-2-greenpages.db_2.0.0
104	ACTIVE      greenpages-2-greenpages.jpa_2.0.0
105	ACTIVE      greenpages-2-greenpages.web_2.0.0

The bundle that is of primary interest is the Web bundle (greenpages-2-greenpages.web_2.0.0). In the example above this is bundle 105. Enter a command of “bundle <web-module-bundle-id>”, that is “bundle 105” for the case above. There will be many lines of output.

Towards the top of the generated output will be details of the services which are being used by the Web module, for example:

  Services in use:
    {org.osgi.service.packageadmin.PackageAdmin}={service.ranking=2147483647, 
      service.pid=0.org.eclipse.osgi.framework.internal.core.PackageAdminImpl, service.vendor=Eclipse.org - Equinox, service.id=1}
    {greenpages.Directory}={org.springframework.osgi.bean.name=directory, 
      Bundle-SymbolicName=greenpages-2-greenpages, Bundle-Version=2.0, service.id=124}
    {org.xml.sax.EntityResolver}={spring.osgi.core.bundle.id=49, spring.osgi.core.bundle.timestamp=1247557173528, service.id=53}
    {org.springframework.beans.factory.xml.NamespaceHandlerResolver}={spring.osgi.core.bundle.id=49, 
      spring.osgi.core.bundle.timestamp=1247557173528, service.id=52}
    

As can be seen in this output the greenpages.Directory service is being provided by a bundle with a symbolic name of greenpages-2-greenpages: the service is coming from the greenpages.app bundle, rather than the greenpages.jpa bundle.

The service which is being used by the Web bundle can be changed at runtime without having to restart the application or dm Server. This can be achieved changing greenpages.app so that it no longer publishes its Directory implementation. As a result of this Directory service no longer being available, the Web bundle will automatically switch to using the JPA-based implementation.

Open the osgi-context.xml file in the META-INF/spring folder of the greenpages.app project and comment out the publication of the directory service:

<!-- <osgi:service interface="greenpages.Directory" ref="directory"/> -->

Now save the updated file which will cause the application to be updated and refreshed on the server. Switch back to the Web browser and click Submit again.

This time eight results should be returned. Clicking on any of the View links will display the listing’s details. The application is now working. All that remains is to apply some best practices to the middle tier.

Note: Throughout this last chapter, a warning (a Spring Beans Problem) from the greenpages.jpa project is shown,

Referenced bean 'dataSource' not found
    module-context.xml
    /greenpages.jpa/src/main/resources/META-INF/spring
  

This can be ignored. It is a reflection of the fact that although the two application contexts (for greenpages.db and greenpages.jpa) can see each other’s beans on deployment (they are both part of the Web application), the tool suite does not detect this and therefore gives a warning.