ServiceMix cannot find OSGI datasource

I dived into ServiceMix 5.4.0 and OSGi and ran into some rather strange behavior with OpenJPA.

I have a data source defined like this:


    <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
        <property name="driverClassName" value="org.postgresql.Driver"/>
        <property name="url" value="jdbc:postgresql://localhost:5432/test"/>
        <property name="username" value="test"/>
        <property name="password" value="test"/>

    <service interface="javax.sql.DataSource" ref="dataSource">
        <entry key="" value="jdbc/test"/>


Using the jndi: names command, I can check that the datasource is visible:

karaf@root> jndi:names
JNDI Name            Class Name                                                  
osgi:service/jndi    org.apache.karaf.jndi.internal.JndiServiceImpl              
osgi:service/jdbc/test org.apache.commons.dbcp.BasicDataSource                     


My persistence.xml:

<persistence version="2.0" xmlns=""

    <persistence-unit name="test" transaction-type="JTA">               



            <property name="openjpa.jdbc.DBDictionary" value="postgres"/>                       
            <property name="openjpa.Log" value="slf4j"/>


Then I add a persistence block to the DAO class via Blueprint:

<?xml version="1.0" encoding="UTF-8"?>

<blueprint  default-activation="eager" 

    <bean id="securityDAO" class="" init-method="init">
        <tx:transaction method="*" value="Required" />
        <jpa:context property="entityManager" unitname="test" />

    <service ref="securityDAO" interface="">



The persistence block is injected successfully, which I check in the init DAO method:

public void init() {
    if (em==null) {
        log.error("Entity manager not found. Check JPA configuration.");
        throw new RuntimeException("No EntityManager found");
    }"Started SecurityDAO");


After all my hard work, ServiceMix rewards me with the following crypto exception when I call my DAO method from another bean:

public void setSecurityDAO (SecurityDAO dao) {
    this.dao = dao;

protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
    String userName = req.getParameter("userName");
    String password = req.getParameter("password");

    // Invocation of injected DAO results in exception
    User u = dao.authenticateUser(userName, password);          


The result is the following:

Caused by: java.lang.RuntimeException: The DataSource osgi:service/javax.sql.DataSource/( required by bundle persistence/0.0.1.SNAPSHOT could not be found.
    at org.apache.aries.jpa.container.unit.impl.JndiDataSource.getDs(
    at org.apache.aries.jpa.container.unit.impl.DelayedLookupDataSource.getConnection(
    at org.apache.openjpa.lib.jdbc.DelegatingDataSource.getConnection(
    at org.apache.openjpa.lib.jdbc.DecoratingDataSource.getConnection(
    at org.apache.openjpa.jdbc.schema.DataSourceFactory.installDBDictionary(
    ... 54 more
Caused by: javax.naming.NoInitialContextException: Unable to find the InitialContextFactory org.eclipse.jetty.jndi.InitialContextFactory.
    at org.apache.aries.jndi.ContextHelper.getInitialContext(
    at org.apache.aries.jndi.OSGiInitialContextFactoryBuilder.getInitialContext(
    at javax.naming.spi.NamingManager.getInitialContext(
    at javax.naming.InitialContext.getDefaultInitCtx(
    at javax.naming.InitialContext.init(
    at javax.naming.InitialContext.<init>(
    at org.apache.aries.jpa.container.unit.impl.JndiDataSource.getDs(
    ... 58 more


Somehow the exported OSGi datasource doesn't find its way in the persistence set. The weird part is that when I added the following code to the init method to see if I can execute a test request, not only does OpenJPA not throw an exception in the init method, but the DAO call that fires the exception now also works:

public void init() {
    if (em==null) {
        log.error("Entity manager not found. Check JPA configuration.");
        throw new RuntimeException("No EntityManager found");

    try {
        Query q = em.createNativeQuery("SELECT 1=1");           
    } catch (Exception ex) {
        log.error("Unable to execute test query against database", ex);
        throw new RuntimeException(ex);
    }"Started SecurityDAO");


So, to summarize, if I call a method from a package other than my DAO, OpenJPA throws an exception indicating that it cannot find InitialNamingContext and shows no sign in the log it started. If I execute a request inside my DAO before the external component arrives, somehow OpenJPA can find the InitialNamingContext, OpenJPA shows up in the log, and subsequent calls from outside the DAO package start working.

Obviously, I missed something basic. Any help or thoughtful explanation of what is breaking or what I am doing wrong would be greatly appreciated.


I didn't notice last night, but when I added to the test query, the following lines appear in the log. They are missing when I comment out this request:

... | Runtime | 220 - org.apache.openjpa - 2.3.0 | Starting OpenJPA 2.3.0
... | JDBC    | 220 - org.apache.openjpa - 2.3.0 | Using dictionary class "org.apache.openjpa.jdbc.sql.PostgresDictionary".
... | JDBC    | 220 - org.apache.openjpa - 2.3.0 | Connected to PostgreSQL version 9.9 using JDBC driver PostgreSQL Native Driver version PostgreSQL 9.3 JDBC4.1 (build 1102).



Tried this on plain vanilla Karaf 3.0.3 and got the same error. As a workaround, I created a separate bean in the bundle that runs the above test request. Apparently, as long as the only bean in the package makes a call to OpenJPA before a bean outside of the package tries to make the call, OpenJPA will be properly initialized.

Since this is mentioned nowhere, I don't see it in the OpenJPA / ServiceMix docs, I can only assume that I am doing something wrong elsewhere in my configuration.


Per John Forth, here's MANIFEST.MF

Manifest-Version: 1.0
Bnd-LastModified: 1430533396366
Build-Jdk: 1.8.0_45
Built-By: somedude
Bundle-Blueprint: OSGI-INF/blueprint/blueprint.xml
Bundle-Description: Database access layer for Peer Review product
Bundle-ManifestVersion: 2
Bundle-Name: Example :: Persistence
Bundle-SymbolicName: persistence-jpa
Bundle-Version: 0.0.1.SNAPSHOT
Created-By: Apache Maven Bundle Plugin
Import-Package: javax.persistence;version="[1.1,2)",org.osgi.service.blu
Meta-Persistence: META-INF/persistence.xml
Tool: Bnd-


And, as it might be related, the pom.xml of the JPA package is:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="" xmlns:xsi="" xsi:schemaLocation="">



    <name>Example :: Persistence</name>







source to share

1 answer

If you are using OSGI, class visibility is defined in the MANIFEST.MF files.

This way the persistence package can see and load the classes that are imported into its MANIFEST.MF.

The correct way to extend an existing package is to define a chunk that is attached to an existing package. This way you can provide classes (like DAO) and files (like persistence.xml) and make it visible to the fragment node.

Now MANIFEST.MF looks like

Bundle-ManifestVersion: 2
Bundle-Version: 0.0.1.SNAPSHOT
Bundle-Vendor: foo bar
Fragment-Host: org.apache.openjpa-bundle
Bundle-ClassPath: .


Please note that this is just an example.

OSGI stands for Proper Visibility.

You can add more than one snippet to an existing package eg. to keep the configuration in a separate kit, making it easy to set up the configuration.



All Articles