Tag Archives: architecture

Fragments vs. Buddy Classloading

Classloading is a serious issue when creating OSGi based applications. As each bundle is bound to it’s own classpath, sometimes the reflection mechanism will not work as expected. So, there are basicly two ways of solving the problem of extending a bundle’s classpath (when using Equinox…), either create a feature or use Buddy Classloading. But which solutions fits best for what problem?


A fragment is an OSGi mechanism to allow a dynamic extension of a bundle at runtime. The fragment itself is not a true component as other bundles may not define a dependency on the fragment. It is used for different purposes such as testing, internationalisation or logging configuration. You can add system dependent code or configuration files to a generic implementation. The good thing is, that the extended code has no dependency on the fragment i.e. does not necessarily require the fragment for running (for example testing fragments).

How to
A fragment is structured as a common bundle. It may be created using a wizard (in Eclipse) or by adding a line to the manifest.mf of a common bundle defining the so called fragment host:
Fragment-Host: bundleSymbolic-Name
This advises the runtime to merge the fragment’s content with it’s host at runtime.

What’s good
Fragments are pure OSGi and provide the flexibility of extending a component dynamicly at runtime without breaking the component architecture. Some third party classpath requirements can be solved this way, for example providing a logging configuration.

What’s bad
Some third party classpath requirements cannot be matched using fragments.

Buddy Classloading

Buddy Cassloading is somewhat a hack (in my opinion), as it adds a bundle’s classpath to another’s – you could call it ‘reverse-dependency’. In OSGi terms, this is explicitly not wanted as a bundle should be treated as a component. But since many Java libraries got used to a single classloader environment, they still expect an exclusive access to any class of the application using reflection. So, in some situations, you can’t really avoid using Buddy Classloading in an Equinox environment.

How to
The manifest.mf of the bundle to be extended receives an additional line to define a Buddy Policy:
Eclipse-BuddyPolicy: registered
This defines the bundle to be aware of registered bundles which entend the classpath.

The manifest.mf of the bundle to extend receives two additional lines:
Eclipse-RegisterBuddy: bundleSymbolic-Name
Require-Bundle: bundleSymbolic-Name

This defines the bundle to extend the classpath of the listed bundles. Additionally, the registered Buddy Policy requires the extending bundle to have a dependency on the extended bundle.

What’s good
Buddy Classloading easily enables using common reliable libraries without any problems. Additionally, the extending bundle can still be treated as a ‘normal’ bundle, other bundles may have a dependency on the bundle and use the exported packages as provided.

What’s bad
Buddy Classloading is not ‘the OSGi way’ as it corrupts the idea of having a component based application with clearly separated bundles defining an interface and dependencies. Buddy Classloading is an answer to a technical problem and should not be used for application design.

Bundles & Libraries

I heard a talk about VIB – Very Important Bundles – today at the W-JAX here in Munich. The speaker pointed out some key features and services (and available solutions) necessary for developing applications in an enterprise context. He also discussed the way bundles should be designed in general. There were two mentioned aspects that made me wonder.

  • Bundles represent a deployment artefact only.
  • Bundles may contain libraries they need, if it is applicable.

For me, a bundle is explicitly not only a deployment artefact. Bundles represent a software component and are therefor an architectual element of the software. They are essential to be able to use public and private API, as Java Packages simply do not serve this need. No need to say that I prefer ‘Required Bundles’ instead of ‘Imported Packages’ :). And turning to libraries, they should be encapsulated in a separate bundle and definetly not included in any bundle containing business code. A big advantage is the reusability of these individual so called ‘library bundles’, for instance logging frameworks or apache commons components. From my point of view, intergrating libraries in a bundle and even exporting them makes their management difficulter than necessary, at least within an enterprise context.

Model View Presenter, Passive View & DI

After three days of interesting conversations I’m off to my November holidays. This is a very calm and silent time which leaves a lot time for interesting thoughts.



I heard a talk about testing RCP Applications on Wednesday shortly before I left Munich which was pretty interesting. Ralf Ebert outlined a way of designing GUIs to ease testing by applying the Model View Presenter pattern in combination with the Passiv View pattern. Basicly it introduces a presenter which mediates between the ‘Model’ and the ‘View’. The model includes all data and logic, e.g. adding two numbers. The view simply displays everything. The presenter connects input and widgets and delegates calls from the UI to the model’s logic. This allows mocking the view’s behaviour and simply test the logic within the model.

The testing aspect sounds interesting, but something else comes a long with that design. In distributed systems, the view usually calls some logic from serverside services. That means, the view has to somehow access a service instance by using some context holding component. Now, what about making the view part of this service structure and provide the service via DI. Usually (in Spring terms ūüėČ ) this means hooking the view into the service container, which is pretty bad (if even possible) as they are controlled by the platform. But using a so called view model (at least I tend to call it like that) solves that. The model (and even the presenter) may be hooked easily to the container, which makes interaction quite easy.

Nice idea, what do you think?

Why Java Web Development basicly sucks

Developing Java web application really is a pain in the butt. Simple things like autocompletion, an editable table or client and server side validation seam to be so damn tricky. Sure, you get all these JSF frameworks from Sun or Apache, Rich Faces, Ajax 4 JSF and so on. All these promise to make things SOOOO easy. But tying these together busts the whole¬†thing as they¬†do¬†not work together properly. You really have to bend everything to the max to get it at least running. Why is everybody so fancy about Web Applications anyway? Actually, the Web initially was made for a specific reason which is to display content. Abusing it to develop applications¬†that more or less look and behave like a ‘real’ application brings me to the question, why we do that anyway. Is distribution that important that we need use a hammer to get in the screw?