fmeschbe's blog

In a previous post I explained how to extend an OSGi framework such that more classes are visible inside the framework from the outside world. This posting provided a very simple example to generate Framework Extension Bundle using a single file and calling the JAR tool from the command line. Here I will expand on this example by creating a Maven 2 project, which may be used in environments where Maven 2 is used for project builds. As a first step, we need a Maven 2 project descriptor. To create this beast, we have to decide, how we build the project. I generally use the Apache Felix Maven Bundle Plugin to build my projects as OSGi bundles. This great plugin comes with support for Maven 2 packaging but also provides goals to call if the packaging functionality should not be used. Before talking too much, let me just present a project descriptor, which I know works. After that I will explain why I did it, like I did it. <project xmlns="http://maven.apache.org/POM/4.0.0"

Imagine your great application running inside an OSGi framework such as Apache Felix or Eclipse Equinox and requiring a class, which you know is provided by the Java Platform but not provided inside the framework. For example, you provide functionality for the general user on the Internet to submit comments or register themselves but you want to protect this functionality from robots. To do this, you include a Captcha and decided to use the simple java captcha library from SourceForge. This library requires classes from the com.sun.image.codec.jpeg package. This package is generally not made visible inside the framework. So, what can you do ? Of course you could configure your OSGi framework to just make the package visible by configuring either the org.osgi.framework.system.packages or the org.osgi.framework.bootdelegation property accordingly. But what if you can't do that ? Here come the so-called Extension Bundles. Extension Bundles are actually Fragment Bundles, which a

Recently I discovered two very nice features of the java.util.LinkedHashMap : accessOrder and removeEldestEntry(Entry) . These features combined let you implement simple LRU caches in under two minutes. accessOrder The accessOrder flag is set when creating the LinkedHashMap instance using the LinkedHashMap(int initialCapacity, float loadFactor, boolean accessOrder) constructor. This boolean flag specifies how the entries in the map are ordered: accessOrder=true The elements are ordered according to their access: When iterating over the map the most recently accessed entry is returned first and the least recently accessed element is returned last. Only the get , put , and putAll methods influence this ordering. accessOrder=false The elements are ordered according to their insertion. This is the default if any of the other LinkedHashMap constructors is used. In this ordering read access to the map has no influence on element ordering. removeEdlestEntry(Entry) The second feature of