On 9/13/10 13:46, [email protected] wrote:
All, One major impediment to converting a working application into an OSGi bundle is this thing called an unconstrained violation. From what I've read, if you get an unconstrained violation, and Karaf does not tell you what that violation was, figuring it out is a long and arduous process. This process involves ensuring all of the imports you use on your application do now conflict with imports your imported packages use. First off, is that a correct explanation? I think it is close, but not quite correct.
You must be referring to a "constraint violation". This is, basically what you describe, when a bundle is exposed to different sources for the same package. This generally happens because another it imports from is exposing it (e.g., via a return type or method parameter) to the same package, but from a different provider.
It would seem to me, that writing a tool to figure out a given unconstrained violation should (while not trivial) shouldn't be a completely arduous task. Has there been thought given to creating a tool that would help to resolve unconstrained violations?
Given a proposed dependency graph, it is not difficult to pinpoint the constraint violation. The difficult part is telling you how to resolve the constraint violation.
In previous versions of the Felix framework, the error reporting for a constraint violation was definitely not helpful. However, since framework 3.0 you get much better explanation of what led to the constraint violation. Admittedly, it is probably hard to read, but once you understand what it is saying it gives you a lot of info.
A second question I have can best be presented by an example. My developers prefer Spring 3.0.2-RELEASE to 2.5.6-SNAPSHOP, and the dev's also use Camel. The Camel 2.2.0 features.xml file specifies the use of Spring 2.5.6.SNAPSHOT. My developers are currently using camel, AND Spring 3.0.2-RELEASE. As long as the version numbers of these products are clearly made available in Karaf (they are), this should not create an unconstrained violation, right? Ok, now to the real question, when hunting down unconstrained violations, should I be focusing on those bundle-imports who have no version numbers? The bundle "0" has no version in Karaf 1.6.0, could the use of other versions of say... javax.annotations be what is causing the unconstrained violation?
A typical scenario occurs when you are trying to override a package in the JRE. If importing bundles do not specify a version on this package, then they are often wired to the system bundle since it has priority since it is already resolved. This can cause constraint violations with other bundles that do specify a version and get wired to the same package supplied by a bundle.
If the importing bundles can legitimately use the system bundle's versions of the package, then maybe importing version 0.0.0 is appropriate, but if they cannot (e.g., some JRE packages are incomplete) then they need to specify an actual version otherwise their metadata is incorrect.
Another possibility is to modify the framework configuration so the system bundle doesn't export that package at all, so the conflict cannot exist. But this should only be done if you still have difficulties after fixing the bundle metadata (or if you cannot fix it).
-> richard --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
