I've discovered behavior in Felix and its OBR implementation that
seems wrong to me, and I'd like to figure out whether it's a bug or
working as intended.
First, the scenario: Say that an application wishes to deploy a bundle
using the OBR, and it knows the bundle's symbolic name. It uses a
filter like
(symbolicname=my.bundle)
fed to RepositoryAdmin.discoverResources(), then feeds the returned
Resources to Resolver.resolve() and, upon a successful return, calls
on Resolver.deploy(true). The boolean parameter passed to
Resolver.deploy() indicates whether to start all the bundles deployed.
This all works fine the first time. The bundle "my.bundle" gets
installed and marked to be started (as the current start level may be
lower than the initial bundle start level), as well as any other
bundles it depends on.
Now, say that I stop the "my.bundle" bundle and shut down the
framework, but I leave the cache in place. The next time I start the
framework, if we try to deploy the same "my.bundle" bundle, OBR
correctly figures out that it's already present locally, and checks to
see if it can be updated. If so, it compares the OBR-provided Resource
to the locally-installed bundle. If they match, the deploy() method
moves on, doing nothing further with this bundle.¹ That is, deploy()
does not mark the already-installed bundle to be started.
If we then raise the framework start level high enough to include this
(re-)deployed bundle, it doesn't start, apparently because it had been
stopped in some prior run. But reading the OSGi R4 Start Level Service
Specification, it sounds like even a previously-stopped bundle should
be started:
,----[ OSGi Start Level Service Specification, Section 8.2.2 ]
| If the requested start level is higher than the active start level,
| the Framework must increase the start level by one and then start all
| bundles that meet the following criteria:
|
| . Bundles that are persistently marked started, and
| . Bundles that have a bundle start level equal to the new active start
| level.
|
| The Framework continues increasing the active start level and starting
| the appropriate bundles until it has started all bundles with a bundle
| start level that equals the requested start level.
`----
This is really two problems I'm noting at once:
o First, I think that Resolver.deploy() should mark an
already-installed bundle to be started if called with a true "start"
parameter.
Move lines 431-436 in ResolverImpl.java down to line 446 so that a
local bundle gets started regardless of its eligibility for
updating. Felix._startBundle() already accommodates restarting an
already started bundle.
o Second, increasing the start level should start bundles that have
been previously stopped.
Consider the framework sitting at start level 3, with a bundle with a
start level of 4. The bundle cannot be active. Try to start that
bundle and it gets marked to be started, but the framework start level
is still too low to actually start the bundle. Now raise the framework
start level to 4. The bundle should start.
Now stop the bundle, then lower the start level back down to 3. If we
then raise the framework start level back up to 4, should the bundle
start again? By my reading of the specification, it should, but
by my testing Felix does not start the bundle.
In the specification quote above, the "and" conjunction between the
two bullets is vague. Does this mean that a bundle not persistently
marked started need not be started here, or does such a bundle merely
fail the first condition but satisfy the second? Does "meet the
following criteria" mean that a bundle must meet both conditions or
either condition?
If the behavior of Resolver.deploy() were changed per my suggestion, I
wouldn't care as much how the start level specification is
interpreted, as the bundle wolud be "persistently marked started" as
intended.
I do have a use case in mind that gets foiled by the current behavior,
if we need to add some justification to the inquiry.
Footnotes:
¹ Look around line 424 in ResolverImpl.java.
--
Steven E. Harris
