Although JSR APIs are generally simple to use, they introduce a lot of difficulties when used from OSGi Environments. The main two problems they introduce are:
- Lack of OSGi metadata
Many JSR API class libraries lack OSGi headers in their manifests as such they don't export packages of classes they should provide and don't import the needed ones.
- Class/Resource Loading problems
This is mostly noted for JSR specifications whose implementations are provided separately (like StAX) and JSR specifications that need to load user's classes and resources (like JPA and JAXB2). The problem of these specifications that they are oblivious about OSGi so they mostly use thread's context class loader to load needed classes and resources, while this seemed to work fine in non-osgi environments, in OSGi Environments it was not the case since there is no guarantee that thread's context loader will be a one which loads needed resources from the OSGi Environment.
Overcoming the first problem was mostly done in one of two ways: Generating new JAR files with OSGi-headers from the original ones (either using a tool or manually) or keeping OSGi application launchers like DA-Launcher handle the task of bundle generation from OSGi-incompatible JAR files.
Overcoming the second was by setting thread's context class loader to a class loader which loads classes and resources from the OSGi Environment. This was not a very simple solution since developers had to find/develop such class loader and they had to set it each time they wanted to access the API. Another problem is that the mentioned solution is fair only when you have the source code of the bundle which accesses the API, if you don't then you have a very difficult case and there is a probability of the problem being unsolvable.
Tackling similar problems for more than a dozen of OSGi-based applications I reached a conclusion that the most elegant way to solve these problems is to develop OSGi-compatible versions of JSR API class libraries. OSGi-compatible versions of the class libraries differ not only in that they define the needed OSGi headers but also in that they have a Bundle Activator which sets the right class loader for the API to use, project "OSGi-Compatible JSR APIs" is dedicated for this task. Currently, StAX-API is the only supported JSR API, the work for supporting JPA and JAXB2 is in progress. Of course, the role of OSGi-compatible versions of the JSR API class libraries is not limited to define needed headers and set the class loader, but generally making the usage of JSR's API in OSGi Environments as simple as it should be.
All of the provided libraries at "OSGi-Compatible JSR APIs" are licensed under the Apache v2 license and any contributions or ideas to simplify the usage of JSR APIs from OSGi Environments are welcomed.