Tool to resolve unconstrained violations?

[mv...@comcast.net]

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. 



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? 



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? 





v/r, 



Mike Van 

Re: Tool to resolve unconstrained violations?

["Richard S. Hall" <he...@ungoverned.org>]

  On 9/13/10 13:46, mvangeertruy@comcast.net 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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org