OSGi – Comparing service dependency management with Blueprint (part 2)

Posted: July 18, 2013 in Java, maven, OSGi

Previous Posts:

Blueprint Overview:

  • Dependency injection framework for OSGi
  • OSGi R4.2
  • XML based configuration
  • Annotation based configuration in prototype stage (as of Jul 2013)
  • Apache Aries – implementation of Blueprint (on 1.0.0 with some visible support but not heavy)
    • 15th December 2010 Aries graduates from the incubator
    • September 2010 0.2-incubating release available, including the results of compliance tests.
    • May 2010 0.1-incubating release available

Summary of findings:

  • CON: It was much harder to get up and running with Blueprint: large number of bundles and bundle dependency issues to resolve.
  • PRO: OSGi awareness is limited to an XML config file (OSGI-INF/blueprint/config.xml).  No OSGi dependencies were needed by the Date Service API or Date Service Impl.  I added an OSGi dependency to the HelloWorldFilter in order to use the HttpService from felix which was needed to register the servlet and filter.
  • CON: Could not _easily_ get the example to work.  The servlet registered correctly to the HttpService (wired in by Blueprint).  But the DateService gave a proxy exception.  Something is still not quite right with the configuration/wiring of the DateService to the HelloWorldFilter.


  1. Follow common setup steps listed in Part 1. Recommendation is to use a separate installation of Felix for each one of these examples to easily flip between the different wiring mechanisms.
  2. Download the Apache Aries Blueprint bundles from: http://aries.apache.org/downloads/currentrelease.html. Versions listed are the versions used at time of post.  I copied all bundle downloads to my ${FELIX_HOME}/bundle directory.  This step makes me cringe.  There’s gotta be a better way (PAX?  Using maven dependencies to pull down the artifacts and copy to the felix home?)
    • org.apache.aries.util (1.0.0) jar
    • slf4j-simple (1.7.5)
    • slf4j-api (1.7.5)
    • log4j-over-slf4j (1.7.5) jar
    • org.apache.aries.proxy (1.0.0) jar
    • org.osgi.compendium-4.2.0.jar
    • org.apache.aries.blueprint (1.1.0) jar
  3. Install and start the bundles downloaded in step 2 (slf4j-simple will only need an install since it is a bundle fragment).  Order is very important, and I’ve listed these bundles in install and start order (top to bottom)
  4. Your bundle list should look like the following:
    g! lb
       ID|State      |Level|Name
        0|Active     |    0|System Bundle (4.2.1)
        1|Active     |    1|Apache Felix Bundle Repository (1.6.6)
        2|Active     |    1|Apache Felix Gogo Command (0.12.0)
        3|Active     |    1|Apache Felix Gogo Runtime (0.10.0)
        4|Active     |    1|Apache Felix Gogo Shell (0.10.0)
        5|Active     |    1|Apache Felix Http Jetty (2.2.0)
        6|Active     |    1|Apache Aries Blueprint Bundle (1.1.0)
        7|Active     |    1|Apache Aries Proxy Bundle (1.0.0)
        8|Active     |    1|Apache Aries Util (1.0.0)
       13|Resolved   |    1|slf4j-simple (1.7.5)
       14|Active     |    1|log4j-over-slf4j (1.7.5)
       15|Active     |    1|slf4j-api (1.7.5)
       18|Active     |    1|osgi.cmpn (
  5. Install and start the 3 bundles from your osgi-evaluation/examples/wiring/*/target/*jar
  6. Test to verify your servlet (with a response header of WIZARD) and your filter (with a response body of Hello World) and your Date Service (wired into your filter to add a formatted date to your response body) are wired together correctly to service your request.  At the time of this post, my filter was throwing an exception and not calling the DateService formattedDate() function correctly.
[~/felix] : curl localhost:8080 -v
* About to connect() to localhost port 8080 (#0)
*   Trying ::1...
* connected
* Connected to localhost (::1) port 8080 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8x zlib/1.2.5
> Host: localhost:8080
> Accept: */*
< HTTP/1.1 500 object is not an instance of declaring class
< Content-Type: text/html; charset=iso-8859-1
< Cache-Control: must-revalidate,no-cache,no-store
< Content-Length: 3846
< Server: Jetty(6.1.x)
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
<title>Error 500 object is not an instance of declaring class</title>
<body><h2>HTTP ERROR 500</h2>
<p>Problem accessing /. Reason:
<pre>    object is not an instance of declaring class</pre></p><h3>Caused by:</h3><pre>java.lang.IllegalArgumentException: object is not an instance of declaring class
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.apache.aries.proxy.impl.ProxyHandler$1.invoke(ProxyHandler.java:54)
    at org.apache.aries.proxy.impl.ProxyHandler.invoke(ProxyHandler.java:119)
    at com.sun.proxy.$Proxy5.getFormattedDate(Unknown Source)
    at org.osgiexample.filters.helloworld.HelloWorldFilter.doFilter(HelloWorldFilter.java:42)
    at org.apache.felix.http.base.internal.handler.FilterHandler.doHandle(FilterHandler.java:88)
    at org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:76)
    at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:47)
    at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33)
    at org.apache.felix.http.base.internal.dispatch.FilterPipeline.dispatch(FilterPipeline.java:48)
    at org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:39)
    at org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:67)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
    at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
    at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390)
    at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
    at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
    at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
    at org.mortbay.jetty.Server.handle(Server.java:326)
    at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
    at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:926)
    at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
    at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
    at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
    at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
    at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
<hr /><i><small>Powered by Jetty://</small></i><br/>

Next Post:

  • Coming soon: OSGi – Comparing service dependency management with iPojo (part 3)
  1. […] Mountain Lion + Git + Case Insensitive filesystem == headaches OSGi – Comparing service dependency management with BundleActivator, Blueprint, Declarative Se… […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s