felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger" <Felix.Meschber...@day.com>
Subject Re: OBR Resolver.deploy() and framework start level
Date Fri, 09 Feb 2007 10:46:49 GMT
Hi Steven,

Let me comment your second question first:

There is a tiny little adjective in the spec: "permanently marked". So, when
you start a bundle, regardless of it actually startes or not due to start
level restrictions, the bundle is permanently marked started. If you stop
the bundle, the bundle is stopped (if not started) and permanently marked
stopped.

If stop and restart the framework, the bundle is still permanently makred
stopped and will not be started even though it could be started as per the
start level.

Consequently, the system works as specified.

Regarding, whether Resolver.deploy(boolean) should start resources added to
the resolver but not selected for deployment: I am more happy with the
situation of the Resolver not touching the state existing bundles. That
said, I am in favor of not having the resolver start bundles not elected for
deployment.

Regards
Felix

On 2/9/07, Steven E. Harris <seh@panix.com> wrote:
>
> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message