Observing different efforts in the OSGi space I noticed a camp of developers who believe that the whole OSGi Concept shouldn't conflict much with past or simply not-osgi efforts so it wouldn't require from developers any OSGi-specific efforts to run their application inside the OSGi Environment, with this approach developers could run their OSGi-oblivious applications in the OSGi Environment and still be able to evolve them to benefit from OSGi in the future depending on their needs.

If you followed my previous work on tackling OSGi-incompatible applications you might share me the view that all of the problems that OSGi-incompliant and OSGi-incompatible applications have when running them in the OSGi Environment are either caused by wrong metadata or class/resource loading problems. Not that I'm passionate about the idea above, but having Bundler on one hand (which I consider to be by far the most powerful and advanced solution for dealing with OSGi-incompliant libraries) and ClassLoading-Utils on the other I came to know that it doesn't require much from me to enable this concept, I also decided to go one step further so I would allow absolutely any standalone Java Application run normally in the OSGi Environment, this led me to add a new feature to Bundler that allows users to instruct Bundler to generate a Bundle Activator for JAR archives which contain a Main Class with main method so when the generated bundle is started the Activator will invoke the main method.

The result of my efforts where adding the OSGi-aware Thread Context Class Loader support and Bundler integration features to version 1.1.0 of DA-Launcher.

Like always, to test the concept above I picked the most complex scenario - I always follow this rule because I assume that if the most complex scenario works then the simpler ones will mostly work too. So I picked an OSGi-oblivious JPA application, to understand what's special about the application lets follow how it executes step by step:

• From the main method, the client application consumes the javax.persistence.Persistence class to create an Entity Manager Factory, both of the mentioned classes are not imported by the client application (after all it's a plain JAR archive).
• The javax.persistence.Persistence in its turn will look for implementations of the JPA SPIs by looking for resources in the Thread Context Class Loader which has the "/META-INF/services/javax.persistence.spi.PersistenceProvider" path. JPA providers like Toplink, Hibernate and OpenJPA contain this file to tell JPA that they exist.
• Then the JPA provider (OpenJPA in our case) will look for a persistence unit with the specified name in the files with the "/META-INF/persistence.xml" (our JPA client application has such file). After finding the persistence.xml file the Persistence provider will create an Entity Manager Factory, for that, it will need to consume the entity classes located in our Client Application JAR archive.

So what we have here? A client code which doesn't import needed packages, a framework which looks for classes and resources in the Thread context class loader and same packages re-exported by multiple bundles (a potential for package wiring conflicts). If you know of a scenario which is worse, please let me know. To run the application I configured DA-Launcher to make the Thread Context Class Loader OSGi-aware (by setting an XML attribute in the "/example-application/config/general-settings.xml" file and have two directories for OSGi-incompliant libraries, one for the application archives and the other for its dependencies, I also instructed Bundler to create a Bundle Activator for the Client Application by setting some property in the file "/example-application/bundles/osgi-incompliant-applications/osgi-incompliant-jpa-client-1.0.0.properties". Although the result was pretty predictable, it was very interesting for me to see a plain Java application which is completely oblivious about OSGi work inside the OSGi Environment like a normal OSGi-based Application would.