Details
-
Improvement
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
None
-
None
-
None
Description
The packaging of Felix framework and resolver seems not to be done in an OSGI manner. "Org.apache.felix.framework" and "org.apache.felix.resolver" sources are separate components, but are combined together in the resultant "org.apache.felix.framework" jar file. It's not specified as a dependency but seems to be assembled in a copy and paste manner.
The reason its done this way is probably due to the dependency of "org.apache.felix.resolver" on an earlier version of the Felix framework. "Org.apache.felix.framework" has as a dependency on "org.apache.felix.resolver" and vice-a-versa. This cyclic specification is what makes it problematic and why the assemble was done in this copy and paste manner. Obviously, the packaging of the two sources as one jar makes for a simple and convienient one jar dependence for embedding Felix into an application.
I discovered this issue, when I added the framework source to my application and then discovered that the framework required the Resolver class which was missing, so I added a dependency for the Resolver in my application. This appeared to work, until some magic threshold was hit that cause the class resolution order to change. What I discovered was that I had two different copies of "org.osgi.framework.Version" in my application. For a while, I was getting the newer version of "Version" that contained the "valueOf" method in it. When that magical threshold was hit, it caused me to get the older version of "Version" which didn't have the "valueOf" method in it, which cause the code to crash. A tough problem to track down. The root cause, IMHO, however comes back to an improper specification of the dependency. I think it fair to say the Felix framework and resolver components aren't constructed in a manner congruent with OSGI principals.
Embedding the source into a application rather then adding a jar dependency can be useful to developers who kind-a wants to look-behind-the-curtain if they are running into some non-obvious issues with their OSGI embedded environment. It's often a lot little easier to debug in this configuration.