[jira] [Commented] (FELIX-3411) The implementation of org.osgi.service.startlevel.StartLevel#setStartLevel(int) does not follow the spec

["Richard S. Hall (Commented) (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FELIX-3411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241348#comment-13241348 ] 

Richard S. Hall commented on FELIX-3411:
----------------------------------------

Your description of the framework's behavior is not correct. If you check Felix.setActiveStartLevel() you can see that it takes a sorted snapshot of the existing bundles:

                    // Get a sorted snapshot of all installed bundles
                    // to be processed during the start level change.
                    // We also snapshot the start level here, since it
                    // may change and we don't want to consider any
                    // changes since they will be queued for the start
                    // level thread.
                    bundles = getBundles();
                    for (Bundle b : bundles)
                    {
                        m_startLevelBundles.add(
                            new StartLevelTuple(
                                (BundleImpl) b,
                                ((BundleImpl) b).getStartLevel(
                                    getInitialBundleStartLevel())));
                    }

It then processes this list (which is sorted by bundle start level and then bundle ID) in forward or reverse order depending on whether it is raising or lowering:

                    if (lowering)
                    {
                        tuple = m_startLevelBundles.last();
                    }
                    else
                    {
                        tuple = m_startLevelBundles.first();
                    }

And for each bundle processed in order it counts up or down the framework's current active start level depending upon whether we are lowering or raising, e.g.:

                            // Count up the active start level.
                            if (m_activeStartLevel != tuple.m_level)
                            {
                                m_activeStartLevel = tuple.m_level;
                            }

So, while it is possible there are some bugs, it definitely is attempting to implement the spec as described. There is the potential for a bundle to be started/stopped out of order if you are manipulating its state at the same time the start level operation is going on, but it is a small window and will still end up in the proper state.

At any rate, if you experience any bugs, would it be possible to create an example to demonstrate the issue? Thanks.
                
> The implementation of org.osgi.service.startlevel.StartLevel#setStartLevel(int) does not follow the spec
> --------------------------------------------------------------------------------------------------------
>
>                 Key: FELIX-3411
>                 URL: https://issues.apache.org/jira/browse/FELIX-3411
>             Project: Felix
>          Issue Type: Bug
>          Components: Framework
>    Affects Versions: framework-4.0.2
>            Reporter: Yasuhiro Kawame
>
> I think that the implementation of Changing the Active Start Level is different from Spec.
> see:
> OSGi Service Platform Core Specification Release 4, Version 4.3, Figure 8.2 page154
> Move to requested start level R, active level is A, B is a bundle's start level
> Spec:
> if (A < R) 
>   while (A < R) {
>     A = A + 1
>     Start All bundles where B = A
>   }
> Implementation:
> if (A < R) 
>   Start All bundles where B <= R
> A = R
> Similarly, if A > R.
> Javadoc:
> http://www.osgi.org/javadoc/r4v43/org/osgi/service/startlevel/StartLevel.html#setStartLevel%28int%29
> http://www.osgi.org/javadoc/r4v43/org/osgi/framework/startlevel/FrameworkStartLevel.html#setStartLevel(int, org.osgi.framework.FrameworkListener...)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira