JNDI lookup for blueprint components

If a bundle contains blueprint XML that declares a number of components each with a given ID, those components can be looked up using the JNDI.

The code that we use has the following form:

Object component = new InitialContext().lookup("blueprint:comp/componentId");

This mechanism is useful in two different contexts:

• We can declare and configure any number of components of a web application bundle (WAB), which can then be looked up from servlets that are not themselves blueprint-managed.

• We can declare and configure data sources in blueprint XML, then reference them in a persistence.xml file.

Declaring and configuring components of a WAB

A WAB can contain blueprint XML. This can be used to declare and configure any number of components, which can then be looked up from servlets that are not themselves blueprint-managed. One particular use of this is shown in the OSGi blog sample application, in which the web bundle contains the following blueprint code:

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <reference id="blogService"
             interface="com.ibm.samples.websphere.osgi.blog.api.BloggingService"/>
</blueprint>

The JNDIHelper.getBloggingService() method call includes this code fragment:

  try {
    InitialContext ic = new InitialContext();
    return (BloggingService) ic.lookup("blueprint:comp/blogService");
  } catch (NamingException e) {

This code looks up a blueprint-managed reference to an OSGi service. This is useful because blueprint-managed services are damped as described in section 121.10.1 of the OSGi Service Platform Release 4 Version 4.2 Enterprise Specification. If the BloggingService object is not available when the application code tries to use the reference, the application code waits until the service becomes available again.

Previous versions of the getBloggingService method used a lookup of the following form:

ic.lookup("osgi:service/com.ibm.samples.websphere.osgi.blog.api.BloggingService");

This is not so useful, because the application code can receive a ServiceUnavailableException exception if the service is not available when the application code tries to use the BloggingService object. For example: If the BloggingService object is temporarily unavailable because an in-place update is in progress, the user of the Blog web application can get an HTTP 500 (Internal Error) message in their web browser. With the new form of lookup, web requests wait for a short time (a second or two) until the update completes. Therefore it is easier to write a web application that remains continuously available, from a user perspective, even while the application is being updated in place.

Declaring and configuring data sources

Data sources can be declared and configured in blueprint XML, then referenced in a persistence.xml file. For example, in Apache Aries the org.apache.aries.jpa.container.itest.bundle/src/main/resources/OSGI-INF/blueprint/config.xml file includes the following code:

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">

  <bean id="nonjta" class="org.apache.derby.jdbc.EmbeddedDataSource">
    <property name="databaseName" value="memory:testDB"/> 
    <property name="createDatabase" value="create"/>
  </bean>

  <service interface="javax.sql.XADataSource">
    <service-properties>
      <entry key="transactional" value="true"/>
    </service-properties>
    <bean class="org.apache.derby.jdbc.EmbeddedXADataSource">
      <property name="databaseName" value="memory:testDB"/>
      <property name="createDatabase" value="create"/> 
    </bean>
  </service>

  <reference id="jta" availability="optional" interface="javax.sql.DataSource"
             filter="(transactional=true)"/>

</blueprint>

The org.apache.aries.jpa.container.itest.bundle/src/main/resources/META-INF/persistence.xml file includes the following corresponding code:

... 
  <persistence-unit name="bp-test-unit" transaction-type="JTA">
    <description>Test persistence unit for the JPA Container and Context iTests</description>
    <jta-data-source>blueprint:comp/jta</jta-data-source>
    <non-jta-data-source>blueprint:comp/nonjta</non-jta-data-source>
    <class>org.apache.aries.jpa.container.itest.entities.Car</class>
    <exclude-unlisted-classes>true</exclude-unlisted-classes>
    <properties>
      <!-- These properties are creating the database on the fly. -->
      <!-- We are using them to avoid the tests having to create a database  -->
      <property name=''eclipselink.ddl-generation'' value=''create-tables/>
    </properties>
  </persistence-unit>
</persistence>

In this code fragment, the jta-data-source and non-jta-datasource elements are configured through blueprint:comp/ namespace references.

Related:

Blueprint bundles

Blueprint XML

Beans and the Blueprint Container

Services and the Blueprint Container

References and the Blueprint Container

Scopes and the Blueprint Container

Object values and the Blueprint Container

Object life cycles and the Blueprint Container

Resource references and the Blueprint Container

Dynamism and the Blueprint Container

Type converters and the Blueprint Container

OSGi Service Platform Release 4 Version 4.2 Enterprise Specification

File name: was312.html

prettyPrint();