You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Martin Ždila <m....@gmail.com> on 2013/05/20 12:18:21 UTC
strange package wiring
Hello
I am using Apache Felix 4.2.1.
I have two bundles that export package org.osgi.service.cm:
1. bundle 89 (osgi.cmpn) exports package org.osgi.service.cm of version
1.4.0
2. bundle 75 (org.apache.felix.configadmin) exports package
org.osgi.service.cm of version 1.5.0
After I start framework, all imports of org.osgi.service.cm will resolve to
2, but one resolves to 1:
1:
g! inspect cap osgi.wiring.package 89
osgi.cmpn [89] provides:
...
osgi.wiring.package; org.osgi.service.cm 1.4.0 required by:
org.apache.aries.jmx.core [72]
...
2:
g! inspect cap osgi.wiring.package 75
org.apache.felix.configadmin [75] provides:
-------------------------------------------
osgi.wiring.package; org.apache.felix.cm 1.0.0 [UNUSED]
osgi.wiring.package; org.apache.felix.cm.file 1.0.0 [UNUSED]
osgi.wiring.package; org.osgi.service.cm 1.5.0 required by:
gofer-web [300]
gofer-mongodb-connector [205]
gofer-configurationAdmin-commandlineAdapter [136]
gofer-crypto [143]
gofer-web-jetty [296]
gofer-logging-appenders [171]
gofer-configurationAdminManager [141]
org.apache.felix.scr [82]
gofer-cluster-util [135]
org.apache.felix.eventadmin [76]
gofer-configurationAdminManager-api [137]
gofer-database-datasource-c3p0 [144]
gofer-monitor-collector [210]
Bundle 72 (org.apache.aries.jmx.core) requires:
g! inspect req osgi.wiring.package 72
org.apache.aries.jmx.core [72] requires:
...
osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.cm)(version>=1.3.0))
resolved by:
osgi.wiring.package; org.osgi.service.cm 1.4.0 from osgi.cmpn [89]
After I do "refresh 72" (bundle org.apache.aries.jmx.core) then requirement
changes from 1 to 2:
g! inspect req osgi.wiring.package 72
org.apache.aries.jmx.core [72] requires:
osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.cm)(version>=1.3.0))
resolved by:
osgi.wiring.package; org.osgi.service.cm 1.5.0 from
org.apache.felix.configadmin [75]
After framework restart the dependency is reset back to 1.
Is it normal operation? I thought that framework uses automatically highest
usable version of the exported package to satisfy imports without any
manual refresh. Is it a bug? If not, how to make it to use second wiring
without manual refresh?
Thanks in advance
--
Ing. Martin Ždila
tel:+421-908-363-848
mailto:martin@zdila.sk
http://www.zdila.sk/
Re: strange package wiring
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 5/20/13 07:41 , Martin Ždila wrote:
> Hello
>
> I am using Apache Felix 4.2.1.
>
> I have two bundles that export package org.osgi.service.cm:
>
> 1. bundle 89 (osgi.cmpn) exports package org.osgi.service.cm of version
> 1.4.0
> 2. bundle 75 (org.apache.felix.configadmin) exports package
> org.osgi.service.cm of version 1.5.0
>
> After I start framework, all imports of org.osgi.service.cm will resolve to
> 2, but one resolves to 1:
>
> 1:
> g! inspect cap osgi.wiring.package 89
> osgi.cmpn [89] provides:
> ...
> osgi.wiring.package; org.osgi.service.cm 1.4.0 required by:
> org.apache.aries.jmx.core [72]
> ...
>
> 2:
> g! inspect cap osgi.wiring.package 75
> org.apache.felix.configadmin [75] provides:
> -------------------------------------------
> osgi.wiring.package; org.apache.felix.cm 1.0.0 [UNUSED]
> osgi.wiring.package; org.apache.felix.cm.file 1.0.0 [UNUSED]
> osgi.wiring.package; org.osgi.service.cm 1.5.0 required by:
> gofer-web [300]
> gofer-mongodb-connector [205]
> gofer-configurationAdmin-commandlineAdapter [136]
> gofer-crypto [143]
> gofer-web-jetty [296]
> gofer-logging-appenders [171]
> gofer-configurationAdminManager [141]
> org.apache.felix.scr [82]
> gofer-cluster-util [135]
> org.apache.felix.eventadmin [76]
> gofer-configurationAdminManager-api [137]
> gofer-database-datasource-c3p0 [144]
> gofer-monitor-collector [210]
>
> Bundle 72 (org.apache.aries.jmx.core) requires:
>
> g! inspect req osgi.wiring.package 72
> org.apache.aries.jmx.core [72] requires:
> ...
> osgi.wiring.package;
> (&(osgi.wiring.package=org.osgi.service.cm)(version>=1.3.0))
> resolved by:
> osgi.wiring.package; org.osgi.service.cm 1.4.0 from osgi.cmpn [89]
>
>
> After I do "refresh 72" (bundle org.apache.aries.jmx.core) then requirement
> changes from 1 to 2:
>
> g! inspect req osgi.wiring.package 72
> org.apache.aries.jmx.core [72] requires:
> osgi.wiring.package;
> (&(osgi.wiring.package=org.osgi.service.cm)(version>=1.3.0))
> resolved by:
> osgi.wiring.package; org.osgi.service.cm 1.5.0 from
> org.apache.felix.configadmin [75]
>
> After framework restart the dependency is reset back to 1.
>
> Is it normal operation?
Depends on how you want to define normal. The Felix resolver is
incremental, so it makes choices as it goes along and doesn't try to do
any global optimization. In short, it is possible that changing the
resolver order will change the results. When you do the refresh after
the fact, you are effectively changing the resolving order.
> I thought that framework uses automatically highest
> usable version of the exported package to satisfy imports without any
> manual refresh.
No, that is not the case. It tries to use the highest priority, which is
recommended to be already resolve packages sorted by version, then
unresolved packages sorted by version. Even then, they framework is not
required to follow this order.
> Is it a bug?
No. Technically, the only thing that would be a bug is if the resolver
came up with a result that was invalid (i.e., violated class space
consistency). As long as the result is valid, then that is fine by the spec.
> If not, how to make it to use second wiring
> without manual refresh?
Good question.
If bundle 89 is only exporting the package (i.e., it doesn't import it
too) and it gets resolved first, then it will be a resolved version of
the package which will have higher priority than bundle 75, which would
then cause the resolver to favor it. So, try to make sure bundle 89 is
resolved first.
I don't think there is a general solution to this issue...
Although, deploying the OSGi companion code is rarely a good idea. It is
not a cohesive module and in this case it looks like it is giving you an
extra provider of the package in question when you don't really
need/want one.
-> richard
>
> Thanks in advance
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
strange package wiring
Posted by Martin Ždila <m....@mwaysolutions.com>.
Hello
I am using Apache Felix 4.2.1.
I have two bundles that export package org.osgi.service.cm:
1. bundle 89 (osgi.cmpn) exports package org.osgi.service.cm of version
1.4.0
2. bundle 75 (org.apache.felix.configadmin) exports package
org.osgi.service.cm of version 1.5.0
After I start framework, all imports of org.osgi.service.cm will resolve to
2, but one resolves to 1:
1:
g! inspect cap osgi.wiring.package 89
osgi.cmpn [89] provides:
...
osgi.wiring.package; org.osgi.service.cm 1.4.0 required by:
org.apache.aries.jmx.core [72]
...
2:
g! inspect cap osgi.wiring.package 75
org.apache.felix.configadmin [75] provides:
-------------------------------------------
osgi.wiring.package; org.apache.felix.cm 1.0.0 [UNUSED]
osgi.wiring.package; org.apache.felix.cm.file 1.0.0 [UNUSED]
osgi.wiring.package; org.osgi.service.cm 1.5.0 required by:
gofer-web [300]
gofer-mongodb-connector [205]
gofer-configurationAdmin-commandlineAdapter [136]
gofer-crypto [143]
gofer-web-jetty [296]
gofer-logging-appenders [171]
gofer-configurationAdminManager [141]
org.apache.felix.scr [82]
gofer-cluster-util [135]
org.apache.felix.eventadmin [76]
gofer-configurationAdminManager-api [137]
gofer-database-datasource-c3p0 [144]
gofer-monitor-collector [210]
Bundle 72 (org.apache.aries.jmx.core) requires:
g! inspect req osgi.wiring.package 72
org.apache.aries.jmx.core [72] requires:
...
osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.cm)(version>=1.3.0))
resolved by:
osgi.wiring.package; org.osgi.service.cm 1.4.0 from osgi.cmpn [89]
After I do "refresh 72" (bundle org.apache.aries.jmx.core) then requirement
changes from 1 to 2:
g! inspect req osgi.wiring.package 72
org.apache.aries.jmx.core [72] requires:
osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.cm)(version>=1.3.0))
resolved by:
osgi.wiring.package; org.osgi.service.cm 1.5.0 from
org.apache.felix.configadmin [75]
After framework restart the dependency is reset back to 1.
Is it normal operation? I thought that framework uses automatically highest
usable version of the exported package to satisfy imports without any
manual refresh. Is it a bug? If not, how to make it to use second wiring
without manual refresh?
Thanks in advance
--
Ing. Martin Ždila
tel:+421-908-363-848
mailto:martin@zdila.sk
http://www.zdila.sk/
--
Ing. Martin Ždila
Senior Analyst / Developer
M-Way Solutions Slovakia s.r.o.
Letná 27, 040 01 Košice
Slovakia
tel:+421-908-363-848
mailto:m.zdila@mwaysolutions.com
http://www.mwaysolutions.com