That explains. I had particularly hard time imagining the clause in the
spec. (now I have an example.)
Thanks all for help.
-Katsuya
On Wed, Apr 4, 2018 at 8:20 AM, Neil Bartlett <njbartl...@gmail.com> wrote:
> 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
> > >
> > >
> >
>
