Hi Steven, If I understand correctly, you want to use the same logging facility for your Felix-contained bundles as well as the rest of the application outside the framework ?
In this case, I suggest to have the org.osgi.services.log package containing the interfaces in some outer classloader and add the packeg to the system packages of felix. This way, the application and Felix are using the same interface class instances. Then I would define a BundleActivator to be added to the Felix.startactivator list which listens for the LogService to be registered and make it available through some bridging to the rest of the application. The bridging functionality could even contain some fallback mechanism in case the LogService would not be available. The Felix Log bundle should wire to the log API packages provided as a system package in this case. And you would need the log bundle jar only once: as a proper bundle. Would this help ? Regards Felix On 12/7/06, Steven E. Harris <[EMAIL PROTECTED]> wrote:
I'm trying to understand what happens when non-bundle parts of a program depend on bundles-as-JARs, and these same bundles are used by other bundles as well. Let me try to make sense of this with an example. I have few bundles that use the org.apache.felix.log bundle. They post log messages to the LogService. My application itself (the part with a main() method that starts up Felix) also uses the org.apache.felix.log /JAR/, as it tracks the LogReaderService and listens with a LogListener implementation. In order to start up my main program, I must either include the org.apache.felix.log JAR in the main JAR or at least point to it on the class path. In order for the other bundles that depend on the logging facility to work right, I was also installing and starting the org.apache.felix.log bundle. It occurred to me that if my main program is already loading up this log-related JAR, it should add the packages already exported by the org.apache.felix.log bundle to the org.osgi.framework.system.packages property supplied to Felix.start(). If I understand this property correctly, adding exported packages to it makes things as though these packages are built into Felix itself (or, rather, the system bundle). Going one step further, I should add the org.apache.felix.log.impl.Activator to the BundleActivator list supplied to Felix.start(). I only realized I had to modify the org.osgi.framework.system.packages property after I tried loading the org.apache.felix.log bundle, then noticed that my program encountered ClassCastExceptions when casting from, say, org.apache.felix.log.impl.LogReaderServiceImpl to org.osgi.service.log.LogReaderService. That must mean that the log-related classes were pulled in by two different class loaders -- one for the main program, and another seen by the bundles using the log bundle. Trying to figure out how to transfer a bundle's Export-Package header to the org.osgi.framework.system.packages property just feels wrong -- invasive and brittle. On the other hand, I don't see how Felix could figure these exports out on its own. The question comes down to this: Is it a poor design to try using a bundle from a normal, "non-bundle" portion of a program, even when there are other bundles in the system that will use this same bundle? If I use the bundle code from my "non-bundle" program, should I not load the actual bundle within Felix? Or should I factor this "non-bundle" program into a bundle itself, and have it use the log bundle like all the other bundles? My language is muddled, but I hope the problem in question is clear enough to provoke a response. -- Steven E. Harris
