2

I am using Apache Felix in a host application to provide the ability to load extensions at runtime. The mechanism works great but I have some very temperamental behaviour regarding the bundles starting if I include certain dependencies. If for example I use the following in my pom.xml:

<packaging>bundle</packaging>

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.felix</groupId>
            <artifactId>maven-bundle-plugin</artifactId>
            <version>2.5.0</version>
            <extensions>true</extensions>
            <configuration>
                <instructions>
                    <Bundle-SymbolicName>${project.groupId}.${project.artifactId}</Bundle-SymbolicName>
                    <Bundle-Name>${project.artifactId}</Bundle-Name>
                    <Bundle-Version>1.0.0</Bundle-Version>
                    <Bundle-Activator>${pom.groupId}.activator.Activator</Bundle-Activator>
                    <Include-Resource>{maven-resources}, {maven-dependencies}</Include-Resource>
                    <Import-Package>*</Import-Package>
                    <Embed-Dependency>jackson-core</Embed-Dependency>
                    <Embed-Transitive>true</Embed-Transitive>
                </instructions>
            </configuration>
        </plugin>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <configuration>
                <source>1.7</source>
                <target>1.7</target>
            </configuration>
        </plugin>
    </plugins>
</build>
<dependencies>
    <dependency>
        <groupId>org.apache.felix</groupId>
        <artifactId>org.osgi.core</artifactId>
        <version>1.4.0</version>
    </dependency>
    <dependency>
        <groupId>org.aspectj</groupId>
        <artifactId>aspectjtools</artifactId>
        <version>1.8.2</version>
    </dependency>
    <dependency>
        <groupId>co.ff36</groupId>
        <artifactId>halo.core</artifactId>
        <version>1.0.0</version>
        <scope>provided</scope>
    </dependency>
</dependencies>

Everything works perfectly and the bundle registers and starts. However if I include async-http-client in the bundle it registers but does not start! I have tried embedding the dependency in the bundle even though the parent exposes it by the parent host application. If I look inside the compiled bundle the jar has been included but it still wont actually start.

I tried adding:

    <dependency>
        <groupId>com.ning</groupId>
        <artifactId>async-http-client</artifactId>
        <version>1.9.31</version>
    </dependency>

and modified:

<Embed-Dependency>jackson-core, async-http-client</Embed-Dependency>

Neither of these options work. I am not getting any error in the host application and I just can't work out why some libraries cause this but not others.

tarka
  • 5,289
  • 10
  • 51
  • 75

2 Answers2

0

The Jackson can be accessed as OSGi bundles you don't need to embed it. If you have felix webconsole or other type of console you can check what import (or capability) is not presented which causes that the bundle cannot came to ACTIVE state. As the POM shows all dependecies included in transitive form. It's not a good idea to use that, because it means no classes loaded from other bundles, instead of everything is embeded, which means you create a monolithic bundle which is not using anything from bundles.

Another possible reason to not start is that the activator calls some method which throws an exception which will invalidate your activator, as the OSGi spec defines. Recommended to check your log, maybe there is some reflection instantiate classes in the code which cannot be resolved, because its not manifested by bundle plugin - only that packages can be imported which are presented in classes import's.

  • Thanks for the feedback. My apologies as it is not clear from my original question that I only embedded to try and resolve the problem and find out if it was a permissions or access problem. The normal pom does not do this as per your suggestion. I have found the cause of the problem and have updated the question. – tarka Dec 04 '15 at 08:30
0

After further investigation it turns out that the problem is related to versioning. The bundle MANIFEST.MF that is created explicitly states the versions for some import packages:

Import-Package: ...,com.fasterxml.jackson.core.type;version="[2.4,3)",com.ning.http.client;version="[1.9,2)",
 org.osgi.framework;version="[1.5,2)"

However, the host application does not specify a version:

Constants.FRAMEWORK_SYSTEMPACKAGES_EXTRA -> ... com.ning.http.client ...

It appears that the version must be explicitly stated in the host and it must match the bundles import otherwise the bundle won't activate.

tarka
  • 5,289
  • 10
  • 51
  • 75