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 Java™ Naming and Directory Interface (JNDI).
Object component = new InitialContext().lookup("blueprint:comp/componentId");
This
mechanism is useful in two different contexts:<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.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.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="openjpa.jdbc.SynchronizeMappings" value="buildSchema(ForeignKeys=true)"/>
<property name="openjpa.jdbc.DBDictionary" value="derby"/>
</properties>
</persistence-unit>
</persistence>
In this code fragment, the jta-data-source and non-jta-datasource elements
are configured through blueprint:comp/ namespace
references.