fmeschbe's blog

At times you want (or need) to include third party libraries in your bundles. You basically have two options to do that: Embed the complete library Inline the required classes/packages (or everything) Until recently I was in the camp of embedding the complete libraries and setting the Bundle-ClassPath manifest header accordingly. The Embed-Dependency directive of the Apache Felix Maven Bundle Plugin makes this extremely easy to do. Lately, though, this has been questioned by Karl Paul's pojosr project. This project brings the OSGi Service Registry to regular applications. The nice thing here is, that it really is a stripped down OSGi Framework basically removing the modularity pillar. The drawback is that this causes the Bundle-ClassPath manifest header and embeddeded libraries to not be supported. Thus to run your regular bundle inside pojosr, you will have to inline all third party libraries instead of embedding them. The upside is that this really works. For example the Apac...

After subscribing to the OSGi Planet feed I felt like starting to read some old blog posts and stumbled upon a series of posts by BJ Hargave around the issues of the Eclipse ContextFinder caused by the Class.forName methods. For the full story please go and read Class.forName caches defined class in the initiating class loader (and folow the links !). So, these posts caused me to try and look how we behave in Apache Sling ... and of course hoped we would be clean. Well, hmm, turns out we are not ... I found nine classes using Class.forName . So we probably have to clean this up. Maybe or maybe not, these uses may be the cause for some strange failures we had over time. I cannot really tell. But I cannot exclude this possibility either. BTW, this is what I did to find the classes: $ find . -name "*.java" -exec fgrep -l Class.forName {} \;