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.