Thank you, now the answer is clear.
You can see that the lower version of rbl-osgi (bundle ID 9) has zero
active exports, and it is importing the package com.basistech.rbl.osgi from
the higher version of itself. This is because rbl-osgi has both an import
and an export of that package. When this happens, OSGi chooses either the
import OR the export to be active, but never both. When the higher version
is present, the export of the lower version is hidden. This is why bundle
13 does not resolve: because of its tight import range, there is no
matching export.
Like Ray, I think that your tight import range in bundle 13 is wrong. You
should not have semantic differences at the level of the micro version.
However if you really, really need such a tight range then you should also
use the same tight range on the import from bundle rbl-osgi.
Regards,
Neil
On Wed, Apr 4, 2018 at 1:04 PM, Katsuya Tomioka <katsuya.tomi...@gmail.com>
wrote:
> Thanks for the explanation. The narrow import range is intentional, I
> manually set the import in bnd (via bnd-maven-pugin) to satisfy functional
> requirements; I need to consume the version specifically. The runtime
> currently happened to have both versions of the component.
>
>
> g! inspect cap osgi.wiring.package 9
> 08:01:30
> rbl-osgi [9] provides:
> ----------------------
> osgi.wiring.package [EMPTY]
> g! inspect cap osgi.wiring.package 10
> 08:01:49
> rbl-osgi [10] provides:
> -----------------------
> osgi.wiring.package; com.basistech.rbl.osgi 7.24.104.c592 required by:
> rbl-osgi [9]
> g! inspect req osgi.wiring.package 13
> 08:01:57
> Bundle 13 is not resolved.
>
> Thanks,
> -Katsuya
>
>
> On Tue, Apr 3, 2018 at 11:58 PM, Neil Bartlett <njbartl...@gmail.com>
> wrote:
>
> > What Ray said is absolutely true, but I don’t think it actually explains
> > the problem. As far as I can tell, the range should actually catch the
> > export from the "rbl-osgi (7.24.0.c592)” bundle.
> >
> > Katsuya-san: just to be sure, please type the following commands and send
> > the output:
> >
> > inspect cap osgi.wiring.package 9
> > inspect cap osgi.wiring.package 10
> > inspect req osgi.wiring.package 13
> >
> > Regards,
> > Neil
> >
> >
> >
> > > On 4 Apr 2018, at 03:39, Raymond Auge <raymond.a...@liferay.com>
> wrote:
> > >
> > > I think that, as James was alluding to, your problem is in the package
> > > import range you stated in your original message:
> > >
> > > "[7.24.0,7.24.1)"
> > >
> > > Do you know how the import range came to be so narrow? Typically the
> > range
> > > is something like
> > >
> > > "[7.24.0,7.25.0)"
> > >
> > > Perhaps the import policy was altered?
> > >
> > > - Ray
> > >
> > >
> > > On Tue, Apr 3, 2018, 19:10 Katsuya Tomioka, <katsuya.tomi...@gmail.com
> >
> > > wrote:
> > >
> > >> Thanks for the reply. I hugely omitted details, I realized.
> > >>
> > >>
> > >> This is the error from gogo with felix 5.6.10:
> > >>
> > >> ERROR: Bundle rex-osgi [13] Error starting file:/Users/kt/work/felix/
> > >>
> > >> felix-framework-5.6.10/bundle/com.basistech.rex-je-rex-osgi-
> > 7.33.101.c59.2.jar
> > >> (org.osgi.framework.BundleException: Unable to resolve rex-osgi
> [13](R
> > >> 13.0): missing requirement [rex-osgi [13](R 13.0)]
> osgi.wiring.package;
> > >>
> > >> (&(osgi.wiring.package=com.basistech.rbl.osgi)(version>=
> > 7.24.0)(!(version>=7.24.1)))
> > >> Unresolved requirements: [[rex-osgi [13](R 13.0)] osgi.wiring.package;
> > >> (&(osgi.wiring.package=com.basistech.rbl.osgi)(version>=
> > >> 7.24.0)(!(version>=7.24.1)))])
> > >> org.osgi.framework.BundleException: Unable to resolve rex-osgi [13](R
> > >> 13.0): missing requirement [rex-osgi [13](R 13.0)]
> osgi.wiring.package;
> > >>
> > >> (&(osgi.wiring.package=com.basistech.rbl.osgi)(version>=
> > 7.24.0)(!(version>=7.24.1)))
> > >> Unresolved requirements: [[rex-osgi [13](R 13.0)] osgi.wiring.package;
> > >> (&(osgi.wiring.package=com.basistech.rbl.osgi)(version>=
> > >> 7.24.0)(!(version>=7.24.1)))]
> > >> at org.apache.felix.framework.Felix.resolveBundleRevision(
> > Felix.java:4149)
> > >> at org.apache.felix.framework.Felix.startBundle(Felix.java:2119)
> > >> at org.apache.felix.framework.Felix.setActiveStartLevel(
> > Felix.java:1373)
> > >> at org.apache.felix.framework.FrameworkStartLevelImpl.run(
> > >> FrameworkStartLevelImpl.java:308)
> > >>
> > >> The package is used in component interface.
> > >>
> > >> lb of exporting (component) bundles:
> > >> 9|Active | 1|rbl-osgi (7.24.0.c592)|7.24.0.c592
> > >> 10|Active | 1|rbl-osgi (7.24.104.c592)|7.24.104.c592
> > >>
> > >> scr:list lists two components (one for each bundle):
> > >> [ 9] com.basistech.rbl.osgi.impl.BlComponentService enabled
> > >> [ 1] [satisfied ]
> > >> ...
> > >>
> > >> g! inspect cap service 9 (correct one)
> > >> rbl-osgi [9] provides:
> > >> ----------------------
> > >> service; com.basistech.rbl.osgi.RblRosetteComponentService with
> > properties:
> > >> ...
> > >>
> > >> I can see the same thing for the bundle 10.
> > >> [ 10] com.basistech.rbl.osgi.impl.BlComponentService enabled
> > >> [ 5] [satisfied ]
> > >>
> > >>
> > >> Export:
> > >> com.basistech.rbl.osgi {version=7.24.0.c592}
> > >>
> > >> (from 7.24.104)
> > >> com.basistech.rbl.osgi {version=7.24.104.c592}
> > >>
> > >> Importing side:
> > >> com.basistech.rbl.osgi {version=[7.24.0,7.24.1)}
> > >>
> > >>
> > >> On Tue, Apr 3, 2018 at 5:27 PM, Neil Bartlett <njbartl...@gmail.com>
> > >> wrote:
> > >>
> > >>>
> > >>>> On 3 Apr 2018, at 22:17, Katsuya Tomioka <katsuya.tomi...@gmail.com
> >
> > >>> wrote:
> > >>>>
> > >>>> Felix users,
> > >>>>
> > >>>> I have same bundles (say "A") installed only different by micro
> > >> versions,
> > >>>> 7.24.0 and 7.24.100. I have then another ("B") imports packages from
> > >> "A"
> > >>>> such that: "[7.24.0,7.24.1)". This works fine if I installed 7.24.0
> > >> only.
> > >>>> But soon as 7.24.100 installed, the bundle B fails to resolve with
> > >>>> unresolved requirements.
> > >>>>
> > >>>> Would that be possible to resolve the bundle B even with both
> versions
> > >>> of A
> > >>>> installed? Or is even allowed in the spec?
> > >>>
> > >>> This is definitely possible.
> > >>>
> > >>> Please post the actual error message so that we can work out what is
> > >>> happening. It would also be helpful to see:
> > >>>
> > >>> * the list of bundles;
> > >>> * the exact exports of the “A” bundles, and;
> > >>> * the exact imports of the “B” bundle.
> > >>>
> > >>> Regards,
> > >>> Neil
> > >>>
> > >>>
> > >>>>
> > >>>> Thanks,
> > >>>>
> > >>>> -Katsuya
> > >>>
> > >>>
> > >>> ------------------------------------------------------------
> ---------
> > >>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> > >>> For additional commands, e-mail: users-h...@felix.apache.org
> > >>>
> > >>>
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> > For additional commands, e-mail: users-h...@felix.apache.org
> >
> >
>
