osgi

I tried implementing my own class loader based on some examples. However, I think it is not working as expected ( unable to reload Jar file etc. I see few references of recommending using OSGI or Apache Felix for handling Jar file loading. Is there any examples of loading Jar, instancing a class from the Jar? More details on what I am trying to accomplish..I have a Java command line application that essentially continuously runs. I want it to be able to reference JAR files dynamically at runtime and at run-time instance a class in these jars. These jars may contain 1 or more supporting classes

The "OSGi way" is to develop separate bundles containing discrete, coherent pieces of functionality. Sometimes these bundles contain utility classes, sometimes they depend on utility classes and set up their own OSGi Services. Users, on the other hand, are unlikely to be exposed to bundles. They care more about the application , a piece of software that performs a task or solves their problem. Normally an application will use multiple bundles (say, imported via Import-Package) to perform its tasks. What is the best way to formalise this relationship in the OSGi world? One example requirement

We have lot of components out of which we want to modularize only a few to start with. Wondering what is the best way (in the context of my build environment) to create bundles out of all these components? My environment: Java 6, Maven 2.2.1, Hudson Technologies: Spring 3.0.5, WebSphere 7, Hibernate 3.2.x and most of apache commons. Requirements Modularize only few components. Rest of the components can export all of the packages. When imported into eclipse, I should be able to see the bundles of imported-packages as dependencies in build path (mvn eclipse:eclipse doesn't seem to do this)

I have searched the Internet but failed to find a satisfactory answer. What is the threading model present in an OSGi container? Does it simply spawn a new thread to each registered bundle e.g.? Any reference regarding the threading model would be great. You have not found anything because there is no such thing as an "OSGi threading model". Bundles simply exist and don't "have threads" unless they start them. The OSGi framework follows a synchronous model, ie. everything happens in a strict order. Bundles are not executed in threads (but they have their own classloader instances). There are

OSGi 4.2 has just been released which updates the 4.1 specification with a few new RFCs. So, what's particularly new with OSGi 4.2, which frameworks support 4.2 already (or are close to) and why should you target new developments against a 4.2 framework instead of a 4.1? In most cases, a point release of OSGi (such as 4.1->4.2) doesn't really change much existing behaviour, so it's safe to say that if you have an app that depends on 4.1, it'll run on 4.2 without problem. What is new is that a few items have been standardised which should enable for better interoperability between different