You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Matt Madhavan <ma...@gmail.com> on 2011/10/07 22:44:53 UTC
Urgent - Strange uses constraints violation issues
Hello,
I'm running into some strange uses constraint issues! I'm involved in a
rather large Enterprise application for my client. There are multiple
developers both in the States and India involved in this! This could be one
of the largest Enterprise OSGi project ever!
As Niel Bartlett put it here
http://njbartlett.name/2011/02/09/uses-constraints.html
this may make or break my client's adaptation of OSGi technology for their
enterprise development. Any help will be appreciate as I would like to solve
this and keep a tight lid on the OSGi development.
The following is the output from KARAF:
Error executing command: Unable to resolve module
com.hcsc.ccsp.common.om.claim [214.6] because it is exposed to package
'com.hcsc.ccsp.common.om.common.babjo.occurs' from com.hcsc
.ccsp.common.om.common [215.5] and com.hcsc.ccsp.common.om.common [215.0]
via two dependency chains.
Chain 1:
com.hcsc.ccsp.common.om.claim [214.6]
import:
(&(package=com.hcsc.ccsp.common.om.common.babjo.occurs)(version>=1.0.0)(!(version>=2.0.0)))
|
export: package=com.hcsc.ccsp.common.om.common.babjo.occurs
com.hcsc.ccsp.common.om.common [215.5]
Chain 2:
com.hcsc.ccsp.common.om.claim [214.6]
import:
(&(package=com.hcsc.ccsp.common.om.common.babjo)(version>=1.0.0)(!(version>=2.0.0)))
|
export: package=com.hcsc.ccsp.common.om.common.babjo;
uses:=com.hcsc.ccsp.common.om.common.babjo.occurs
export: package=com.hcsc.ccsp.common.om.common.babjo.occurs
com.hcsc.ccsp.common.om.common [215.0]
Both babjo and babjo.occurs are in the same bundle. Their version is
1.0.0.M1-SNAPSHOT. Both the chains resolve to the same version of the
package any way so as Neil Bartlet puts it in
the com.hcsc.ccsp.common.om.claim class space there should be only version
of *.babjo.occurs! Any ideas?
The following are my questions:
1. Why are even two chains here?
2. When the uses constraint is generated does it have a version or its just
0.0.0?
3. [215.5] - 215 I understand is the bundle id! what is .5 and .0 imply?
4. Can some one point me to some good document on this?
Any help will be greatly appreciated! If I get any help I may come in this
w,e and fix the issues. There are multiple issues like this!
Thanks in advance!
Thanks
Matt
Re: Urgent - Strange uses constraints violation issues
Posted by Matt Madhavan <ma...@gmail.com>.
Hi Neil,
Sorry I absolutely did not try to create spam situation. The guys in the
list are the folks I have been following and respect them as well.
At my client there are multiple companies involved in the same project -
with their interests as well. So it was kind of easy to blame on OSGi for
everything. No project is not on the verge of canned. Its been humming
along- just wanted to stop the whispers and other things becoming major
issues.
I appreciate your help. yes the Refresh worked great.Sorry am still kind of
new to Karaf.
Thanks again and will read the spec you sent below!
Matt
On Fri, Oct 7, 2011 at 4:10 PM, Neil Bartlett <nj...@gmail.com> wrote:
> Hello Matt,
>
> First could I say that I do wish you luck and success with your project…
> but you might find things go more smoothly if you had talked to somebody
> earlier on when you began to have problems! Emailing this list of people,
> late on a Friday evening just before your enormously important project gets
> canned… well, it feels a bit spammy.
>
> Nevertheless, I think I can help. The numbers following the dots in the
> bundle IDs are the bundle *revision* numbers. For background on this, read
> chapter 7 of the new OSGi R4.3 Core specification… but to put it simply, the
> revision number goes up each time you update a bundle. So when you see this:
>
> com.hcsc.ccsp.common.om.common [215.0]
> com.hcsc.ccsp.common.om.common [215.5]
>
> … those are actually different bundles, so far as the resolution algorithm
> is concerned. That's why there are two chains and two exports of the same
> package. It looks like you have updated the bundle at least five times
> without ever performing a refresh, and some importers are still wired to the
> original [215.0] revision.
>
> Remember that OSGi does NOT go around tearing down import/export wirings
> merely because a new version of a bundle has been installed! In order to
> trigger a re-wiring operation you MUST do a refresh… this is necessary
> because you may be doing a batch of multiple updates/installs, and the
> framework doesn't know when you are finished.
>
> Hopefully the problem should be solved simply by typing "refresh". Please
> let us know how it goes.
>
> Regards
> Neil
>
> On Friday, 7 October 2011 at 21:44, Matt Madhavan wrote:
>
> Hello,
> I'm running into some strange uses constraint issues! I'm involved in a
> rather large Enterprise application for my client. There are multiple
> developers both in the States and India involved in this! This could be one
> of the largest Enterprise OSGi project ever!
>
> As Niel Bartlett put it here
> http://njbartlett.name/2011/02/09/uses-constraints.html
> this may make or break my client's adaptation of OSGi technology for their
> enterprise development. Any help will be appreciate as I would like to solve
> this and keep a tight lid on the OSGi development.
>
> The following is the output from KARAF:
>
> Error executing command: Unable to resolve module
> com.hcsc.ccsp.common.om.claim [214.6] because it is exposed to package
> 'com.hcsc.ccsp.common.om.common.babjo.occurs' from com.hcsc
> .ccsp.common.om.common [215.5] and com.hcsc.ccsp.common.om.common [215.0]
> via two dependency chains.
>
> Chain 1:
> com.hcsc.ccsp.common.om.claim [214.6]
> import:
> (&(package=com.hcsc.ccsp.common.om.common.babjo.occurs)(version>=1.0.0)(!(version>=2.0.0)))
> |
> export: package=com.hcsc.ccsp.common.om.common.babjo.occurs
> com.hcsc.ccsp.common.om.common [215.5]
>
> Chain 2:
> com.hcsc.ccsp.common.om.claim [214.6]
> import:
> (&(package=com.hcsc.ccsp.common.om.common.babjo)(version>=1.0.0)(!(version>=2.0.0)))
> |
> export: package=com.hcsc.ccsp.common.om.common.babjo;
> uses:=com.hcsc.ccsp.common.om.common.babjo.occurs
> export: package=com.hcsc.ccsp.common.om.common.babjo.occurs
> com.hcsc.ccsp.common.om.common [215.0]
>
>
> Both babjo and babjo.occurs are in the same bundle. Their version is
> 1.0.0.M1-SNAPSHOT. Both the chains resolve to the same version of the
> package any way so as Neil Bartlet puts it in
> the com.hcsc.ccsp.common.om.claim class space there should be only version
> of *.babjo.occurs! Any ideas?
>
> The following are my questions:
> 1. Why are even two chains here?
> 2. When the uses constraint is generated does it have a version or its just
> 0.0.0?
> 3. [215.5] - 215 I understand is the bundle id! what is .5 and .0 imply?
> 4. Can some one point me to some good document on this?
>
> Any help will be greatly appreciated! If I get any help I may come in this
> w,e and fix the issues. There are multiple issues like this!
>
> Thanks in advance!
>
> Thanks
> Matt
>
>
>
>
Re: Urgent - Strange uses constraints violation issues
Posted by Neil Bartlett <nj...@gmail.com>.
Hello Matt,
First could I say that I do wish you luck and success with your project… but you might find things go more smoothly if you had talked to somebody earlier on when you began to have problems! Emailing this list of people, late on a Friday evening just before your enormously important project gets canned… well, it feels a bit spammy.
Nevertheless, I think I can help. The numbers following the dots in the bundle IDs are the bundle *revision* numbers. For background on this, read chapter 7 of the new OSGi R4.3 Core specification… but to put it simply, the revision number goes up each time you update a bundle. So when you see this:
com.hcsc.ccsp.common.om.common [215.0]
com.hcsc.ccsp.common.om.common [215.5]
… those are actually different bundles, so far as the resolution algorithm is concerned. That's why there are two chains and two exports of the same package. It looks like you have updated the bundle at least five times without ever performing a refresh, and some importers are still wired to the original [215.0] revision.
Remember that OSGi does NOT go around tearing down import/export wirings merely because a new version of a bundle has been installed! In order to trigger a re-wiring operation you MUST do a refresh… this is necessary because you may be doing a batch of multiple updates/installs, and the framework doesn't know when you are finished.
Hopefully the problem should be solved simply by typing "refresh". Please let us know how it goes.
Regards
Neil
On Friday, 7 October 2011 at 21:44, Matt Madhavan wrote:
> Hello,
> I'm running into some strange uses constraint issues! I'm involved in a rather large Enterprise application for my client. There are multiple developers both in the States and India involved in this! This could be one of the largest Enterprise OSGi project ever!
>
> As Niel Bartlett put it here
> http://njbartlett.name/2011/02/09/uses-constraints.html
> this may make or break my client's adaptation of OSGi technology for their enterprise development. Any help will be appreciate as I would like to solve this and keep a tight lid on the OSGi development.
>
> The following is the output from KARAF:
>
> Error executing command: Unable to resolve module com.hcsc.ccsp.common.om.claim [214.6] because it is exposed to package 'com.hcsc.ccsp.common.om.common.babjo.occurs' from com.hcsc
> .ccsp.common.om.common [215.5] and com.hcsc.ccsp.common.om.common [215.0] via two dependency chains.
>
> Chain 1:
> com.hcsc.ccsp.common.om.claim [214.6]
> import: (&(package=com.hcsc.ccsp.common.om.common.babjo.occurs)(version>=1.0.0)(!(version>=2.0.0)))
> |
> export: package=com.hcsc.ccsp.common.om.common.babjo.occurs
> com.hcsc.ccsp.common.om.common [215.5]
>
> Chain 2:
> com.hcsc.ccsp.common.om.claim [214.6]
> import: (&(package=com.hcsc.ccsp.common.om.common.babjo)(version>=1.0.0)(!(version>=2.0.0)))
> |
> export: package=com.hcsc.ccsp.common.om.common.babjo; uses:=com.hcsc.ccsp.common.om.common.babjo.occurs
> export: package=com.hcsc.ccsp.common.om.common.babjo.occurs
> com.hcsc.ccsp.common.om.common [215.0]
>
>
>
> Both babjo and babjo.occurs are in the same bundle. Their version is 1.0.0.M1-SNAPSHOT. Both the chains resolve to the same version of the package any way so as Neil Bartlet puts it in the com.hcsc.ccsp.common.om.claim class space there should be only version of *.babjo.occurs! Any ideas?
>
> The following are my questions:
> 1. Why are even two chains here?
> 2. When the uses constraint is generated does it have a version or its just 0.0.0?
> 3. [215.5] - 215 I understand is the bundle id! what is .5 and .0 imply?
> 4. Can some one point me to some good document on this?
>
> Any help will be greatly appreciated! If I get any help I may come in this w,e and fix the issues. There are multiple issues like this!
>
> Thanks in advance!
>
> Thanks
> Matt
>
>