felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bram de Kruijff <bdekrui...@gmail.com>
Subject Re: Unable to resolve cause wired to two revisions of same bundle?
Date Mon, 12 Dec 2011 14:59:00 GMT
Ok, so as discussed there is a cyclic dependency in the JAX-RS
packages that may have something to do with it. Still the resolver
should probably see the "uses" clause  as the package being in use (at
that revision) and/or backtrack if it comes up with a conflict and
still fall back to the lower version.

Created an issues for further investigation
https://issues.apache.org/jira/browse/FELIX-3267

grz
Bram

On Mon, Dec 12, 2011 at 12:39 PM, Bram de Kruijff <bdekruijff@gmail.com> wrote:
> On Mon, Dec 12, 2011 at 12:37 PM, Karl Pauls <karlpauls@gmail.com> wrote:
>> On Mon, Dec 12, 2011 at 12:26 PM, Karl Pauls <karlpauls@gmail.com> wrote:
>>> On Mon, Dec 12, 2011 at 12:21 PM, Bram de Kruijff <bdekruijff@gmail.com>
wrote:
>>>> Hi Karl,
>>>>
>>>> On Mon, Dec 12, 2011 at 11:40 AM, Karl Pauls <karlpauls@gmail.com>
wrote:
>>>>> yes, it can:
>>>>>> http://felix.apache.org/site/apache-felix-osgi-faq.html#ApacheFelixOSGiFAQ-WhenIupdatemybundle%252Cwhyaremybundle%2527soldclassesstillbeingused%253F
>>>>
>>>> Erm.. ok so what is happening is:
>>>>
>>>> -> while resolving org.amdatu.web.rest.wink imports
>>>> 1) it links import javax.ws.rs.ext from 18.0 because some other
>>>> bundles is using this package from this revision
>>>> 1.1) thus dragging in javax.ws.rs from 18.0 due to uses clause
>>>> 2) it links import =javax.ws.rs from 18.1 because no other bundle is
>>>> directly using this package from revision 18.0
>>>> 3) *conflict*
>>>>
>>>> Correct? Confused.. Now, why the conflict? If the resolver is smart
>>>> enough to decide to use the 18.0 javax.ws.rs in step 1.1 why not do
>>>> the same in step 2?
>>>
>>> Good question, i was missing that it did get that for the same bundle.
>>> Hm, are you using felix 4.0.1 or 4.0.2?
>>
>> I guess the only thing i can think of (other than a bug) is that if
>> the wink bundle also imports something from another bundle which also
>> links back to this revision of javax.ws.rs...
>
> I'll dig into that some more.
>
> Thanks!
> Bram
>
>>> regards,
>>>
>>> Karl
>>>
>>>> thanks,
>>>> Bram
>>>>
>>>>>
>>>>> On Mon, Dec 12, 2011 at 11:13 AM, Bram de Kruijff <bdekruijff@gmail.com>
wrote:
>>>>>> Hi list,
>>>>>>
>>>>>> having a hard time understanding the problem below. Can a bundle
be
>>>>>> wired to multiple revision of another? I'd think it would refresh
all
>>>>>> wires. Bug or feature? Probably the latter, but I'd like to understand
>>>>>> :)
>>>>>>
>>>>>> When stop/starting a local install I get in this situation. Bundles
>>>>>> are touched/updated from build in between, but nothing really changes
>>>>>> in terms of imports/exports. Bundles are updated from fileinstall,
not
>>>>>> directly by the framework. I recently switched to 4.0.2 so that is
>>>>>> probably related. After the refresh all is fine.
>>>>>>
>>>>>> {quote}
>>>>>> org.osgi.framework.BundleException: Uses constraint violation. Unable
>>>>>> to resolve bundle revision org.amdatu.web.rest.wink [21.1] because
it
>>>>>> is exposed to package 'javax.ws.rs' from bundle revisions
>>>>>> org.amdatu.web.rest.jaxrs [18.1] and org.amdatu.web.rest.jaxrs [18.0]
>>>>>> via two dependency chains.
>>>>>>
>>>>>> Chain 1:
>>>>>>  org.amdatu.web.rest.wink [21.1]
>>>>>>    import: (&(osgi.wiring.package=javax.ws.rs)(version>=1.1.0)(!(version>=2.0.0)))
>>>>>>     |
>>>>>>    export: osgi.wiring.package=javax.ws.rs
>>>>>>  org.amdatu.web.rest.jaxrs [18.1]
>>>>>>
>>>>>> Chain 2:
>>>>>>  org.amdatu.web.rest.wink [21.1]
>>>>>>    import: (&(osgi.wiring.package=javax.ws.rs.ext)(version>=1.1.0)(!(version>=2.0.0)))
>>>>>>     |
>>>>>>    export: osgi.wiring.package=javax.ws.rs.ext; uses:=javax.ws.rs
>>>>>>    export: osgi.wiring.package=javax.ws.rs
>>>>>>  org.amdatu.web.rest.jaxrs [18.0]
>>>>>> -> refresh
>>>>>> {quote}
>>>>>>
>>>>>> Thanks,
>>>>>> Bram
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Karl Pauls
>>>>> karlpauls@gmail.com
>>>>> http://twitter.com/karlpauls
>>>>> http://www.linkedin.com/in/karlpauls
>>>>> https://profiles.google.com/karlpauls
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Karl Pauls
>>> karlpauls@gmail.com
>>> http://twitter.com/karlpauls
>>> http://www.linkedin.com/in/karlpauls
>>> https://profiles.google.com/karlpauls
>>
>>
>>
>> --
>> Karl Pauls
>> karlpauls@gmail.com
>> http://twitter.com/karlpauls
>> http://www.linkedin.com/in/karlpauls
>> https://profiles.google.com/karlpauls
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message