Testing OSGi applications and services has always been a difficult challenge. Despite the development of several frameworks such as OPS4J Pax Exam, or junit4osgi, writing tests requires a non-negligible amount of code to manage the OSGi aspect of the test. Indeed, waiting and getting the service under test or releasing the service requires dealing directly with the OSGi framework and so the OSGi API. The OSGi Helper library is a small collection of classes to let tests focus on the behavior to verify instead of drowning the code in the depths of the OSGi development model.
The OSGi Helper library was developed by the Innovation department of akquinet, and was contributed to the OW2 Chameleon project.
This post explains the benefits brought by the library in comparison to plain OSGi tests.
When building applications for specific domains, we often face a more and more important issue: how do I build the runtime required by the application? For enterprise applications, JEE application servers provide a technical stack containing all required services, but for desktop applications, or communication gateways there are no all-in-one solutions. Indeed, the runtime must fit to the environment and application requirements, making it complex to achieve in a flexible way.
akquinet launched the OW2 Chameleon project in 2009. Chameleon provides a way to build OSGi-based runtimes including the required services and your application. This article explains the motivations behind Chameleon and how Chameleon makes our software development more flexible, robust and efficient.
akquinet will represent the Apache Felix project in a panel session at the OSGi Users Forum Germany on the 27th of October in Ludwigsburg, Germany.
The panel will focus on the major OSGi frameworks and projects. The full agenda for the event is here.
akquinet is a pretty active company in the Felix community. It uses Felix daily in a couple of projects but also participates to the development of the Felix project by actively contributing to several sub-projects like the Felix Framework and iPOJO…
If you’re interested by OSGi and Apache Felix, don’t miss this event.
The last week, akquinet has presented the RCF 138 of OSGi R4.2 – Draft named Multiple Frameworks in one JVM to the OSGi Users Group – France meeting (more info here and here (in French)).
This post is the third post of the dynamokos series. This post focuses on the propagation of OSGi dynamism into web interfaces. This became a critical issue, as new innovative and user-friendly web applications must be able to react to ‘server’ changes.
Inside this post
In this post, we see how to manage the dynamism inside a web interface by adapting the web view dynamically. According to the availability of the dynamokos oracle (a remote OSGi service), the page content is updated.
Three ways are investigated to support the dynamism namely,
- the auto-refresh
- the ajax pull
- the comet push
This post is the second post of the dynamokos series. It improves the application made in the first post by adding dynamic remote service discovery.
In this post
The former post ends with an issue. The application behave strangely when the oracle is stopped. In this post, we start to fix the issue. To achieve that, I describe how to use a discovery protocol in order to avoid to statically import the service. We will see:
- How A discovery service works
- How we can use Zookeeper as a discovery protocol
- How to publish a service on Zookeeper
- How to discover a remote service using Zookeeper
This is the first post of the Dynamokos series. This series explores how to build dynamic distributed web applications with OSGi step by step.
Inside this post
In this post, we will show how to:
- Use Apache CXF DOSGi to expose an OSGi service as a web service
- Use Apache CXF DOSGi to import the remote service in another OSGi framework
- Consume the imported service
The code of the post is available from the Dynamokos Google Project.
This post is very similar to the iPOJO / DOSGi tutorial.
Dynamokos is not a Greek specialty. It’s the name of this post series. Dynamokos aims to illustrate how OSGi can be used for distributed dynamic web applications.
OSGi offers great features such as the modularity, dynamism, hot-deployment… However, it is not simplex to know how to build sophisticated applications on the top of OSGi. Especially when such application needs to be distributed and dynamic at the same time, a lot of issues have to be overcome.
Throughout a simple application, this series explores how to build dynamic distributed web application on the top of OSGi.
Four posts compose this series:
- The first post shows how to expose an OSGi service as a web service with OSGi Distributed Service (Apache CXF DOSGi), and how to use this service. In this version the client knows where is the oracle.
- The second post modifies the first example to use a discovery protocol (to find the remote oracle. The web site is modified in order to basically manage the dynamism
- The third post explores the possibilities to mange the dynamism in the web page. This includes auto-refresh, Ajax and Cometd.
- Finally, the last post illustrates how OW2 Chameleon Rose (Remote OSGi Service Ecosystem) may replace DOSGi and the flexibility brings by this wonderful framework.
This post describes the JOnAS Showcase. This showcase illustrates how the JOnAS application server supports OSGi integration. Thanks to JOnAS, OSGi and Java EE can collaborate together in a very elegant way.