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 <[EMAIL PROTECTED]> 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
