You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Guillaume Nodet (Created) (JIRA)" <ji...@apache.org> on 2012/02/24 10:51:48 UTC
[jira] [Created] (FELIX-3361) Bundle#start does not comply with the
spec
Bundle#start does not comply with the spec
------------------------------------------
Key: FELIX-3361
URL: https://issues.apache.org/jira/browse/FELIX-3361
Project: Felix
Issue Type: Bug
Affects Versions: framework-4.0.2
Reporter: Guillaume Nodet
The spec says: "When the start method returns without an exception, the state of the bundle will either be ACTIVE or STARTING, depending on the declared activation policy and whether it was used. If the start method throws an exception, then the bundle will not be in either of these states and the stop method will not be called for this Bundle Activator instance."
However there are cases where this does not happen:
* when the bundle start level is greater than the framework target start level
* if the start level thread is already running
I think the Bundle#start should either activate the bundle or wait for the bundle to be activated before returning in order to comply with the spec.
--
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
[jira] [Commented] (FELIX-3361) Bundle#start does not comply with
the spec
Posted by "Guillaume Nodet (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13215545#comment-13215545 ]
Guillaume Nodet commented on FELIX-3361:
----------------------------------------
Yeah, but the second case is against the spec. I don't have any problem with the fact that the actual start of the bundle is delegated to the start level thread, however, the return value of Bundle#start should be deterministic and that's not the case.
In that case, waiting for the bundle to be started by the start level thread before returning should do the trick.
> Bundle#start does not comply with the spec
> ------------------------------------------
>
> Key: FELIX-3361
> URL: https://issues.apache.org/jira/browse/FELIX-3361
> Project: Felix
> Issue Type: Bug
> Affects Versions: framework-4.0.2
> Reporter: Guillaume Nodet
>
> The spec says: "When the start method returns without an exception, the state of the bundle will either be ACTIVE or STARTING, depending on the declared activation policy and whether it was used. If the start method throws an exception, then the bundle will not be in either of these states and the stop method will not be called for this Bundle Activator instance."
> However there is a case where this does not happen, which is when the start level thread is already running
> I think the Bundle#start should either activate the bundle or wait for the bundle to be activated before returning in order to comply with the spec.
--
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
[jira] [Issue Comment Edited] (FELIX-3361) Bundle#start does not
comply with the spec
Posted by "Felix Meschberger (Issue Comment Edited) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13215539#comment-13215539 ]
Felix Meschberger edited comment on FELIX-3361 at 2/24/12 10:08 AM:
--------------------------------------------------------------------
If start levels come into play the StartLevel service dictates the actual bundle states.
> * when the bundle start level is greater than the framework target start level
The bundle is not expected to start until the framework start level is increased to at least the bundle's start level. Start levels are increased step-wise. So if a bundle is at 5, the current is 2 and the target is 6, the start level is increased to 3, 4, 5, and 6 and bundles assigned to the respective start levels are actually started.
Thus a bundle at level x with the framework start level being y < x will at most be in the RESOLVED state.
> * if the start level thread is already running
Right, if the start level is being increased, the bundle is only actually started when passing the bundle's start level.
Bundle.start in these situations will only persistently mark the bundle started (for later start level operations to actually start the bundle).
was (Author: fmeschbe):
If start levels come into play the StartLevel service dictates the actual bundle states.
> * when the bundle start level is greater than the framework target start level
The bundle is not expected to start until the framework start level is increased to at least the bundle's start level. Start levels are increased step-wise. So if a bundle is at 5, the current is 2 and the target is 6, the start level is increased to 3, 4, 5, and 6 and bundles assigned to the respective start levels are actually started.
Thus a bundle at level x with the framework start level being y < x will at most be in the RESOLVED state.
* if the start level thread is already running
Right, if the start level is being increased, the bundle is only actually started when passing the bundle's start level.
Bundle.start in these situations will only persistently mark the bundle started (for later start level operations to actually start the bundle).
> Bundle#start does not comply with the spec
> ------------------------------------------
>
> Key: FELIX-3361
> URL: https://issues.apache.org/jira/browse/FELIX-3361
> Project: Felix
> Issue Type: Bug
> Affects Versions: framework-4.0.2
> Reporter: Guillaume Nodet
>
> The spec says: "When the start method returns without an exception, the state of the bundle will either be ACTIVE or STARTING, depending on the declared activation policy and whether it was used. If the start method throws an exception, then the bundle will not be in either of these states and the stop method will not be called for this Bundle Activator instance."
> However there is a case where this does not happen, which is when the start level thread is already running
> I think the Bundle#start should either activate the bundle or wait for the bundle to be activated before returning in order to comply with the spec.
--
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
[jira] [Commented] (FELIX-3361) Bundle#start does not comply with
the spec
Posted by "Felix Meschberger (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13215569#comment-13215569 ]
Felix Meschberger commented on FELIX-3361:
------------------------------------------
See 8.3.5 Starting a Bundle:
If a bundle is started by calling the Bundle.startmethod, then the OSGi Framework must mark the bundle as persistently started. The OSGi Framework must not actually start a bundle when the active start level is less than the bundle’s start level. In that case, the state must not change.
Also the Bundle.start(int) JavaDoc clarifies this.
> Bundle#start does not comply with the spec
> ------------------------------------------
>
> Key: FELIX-3361
> URL: https://issues.apache.org/jira/browse/FELIX-3361
> Project: Felix
> Issue Type: Bug
> Affects Versions: framework-4.0.2
> Reporter: Guillaume Nodet
>
> The spec says: "When the start method returns without an exception, the state of the bundle will either be ACTIVE or STARTING, depending on the declared activation policy and whether it was used. If the start method throws an exception, then the bundle will not be in either of these states and the stop method will not be called for this Bundle Activator instance."
> However there is a case where this does not happen, which is when the start level thread is already running
> I think the Bundle#start should either activate the bundle or wait for the bundle to be activated before returning in order to comply with the spec.
--
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
[jira] [Closed] (FELIX-3361) Bundle#start does not comply with the
spec
Posted by "Guillaume Nodet (Closed) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Guillaume Nodet closed FELIX-3361.
----------------------------------
Resolution: Won't Fix
I do understand what you say, but that's the first case I mentioned.
In my second case, the StartLevel#getStartLevel() > Bundle#getStartLevel() but the start level thread is still running. So I think this situation is not really in the use case mentioned in the spec (which is StartLevel#getStartLevel() < Bundle#getStartLevel()).
Anyway, given fixing this won't really prevent my problem since the behavior is different depending on the exact timing between StartLevel#setStartLevel() and Bundle#start(), i'll just close the issue.
For reference, the problem has been captured by http://team.ops4j.org/browse/PAXEXAM-356 and we have a working work around.
> Bundle#start does not comply with the spec
> ------------------------------------------
>
> Key: FELIX-3361
> URL: https://issues.apache.org/jira/browse/FELIX-3361
> Project: Felix
> Issue Type: Bug
> Affects Versions: framework-4.0.2
> Reporter: Guillaume Nodet
>
> The spec says: "When the start method returns without an exception, the state of the bundle will either be ACTIVE or STARTING, depending on the declared activation policy and whether it was used. If the start method throws an exception, then the bundle will not be in either of these states and the stop method will not be called for this Bundle Activator instance."
> However there is a case where this does not happen, which is when the start level thread is already running
> I think the Bundle#start should either activate the bundle or wait for the bundle to be activated before returning in order to comply with the spec.
--
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
[jira] [Updated] (FELIX-3361) Bundle#start does not comply with the
spec
Posted by "Guillaume Nodet (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Guillaume Nodet updated FELIX-3361:
-----------------------------------
Description:
The spec says: "When the start method returns without an exception, the state of the bundle will either be ACTIVE or STARTING, depending on the declared activation policy and whether it was used. If the start method throws an exception, then the bundle will not be in either of these states and the stop method will not be called for this Bundle Activator instance."
However there is a case where this does not happen, which is when the start level thread is already running
I think the Bundle#start should either activate the bundle or wait for the bundle to be activated before returning in order to comply with the spec.
was:
The spec says: "When the start method returns without an exception, the state of the bundle will either be ACTIVE or STARTING, depending on the declared activation policy and whether it was used. If the start method throws an exception, then the bundle will not be in either of these states and the stop method will not be called for this Bundle Activator instance."
However there are cases where this does not happen:
* when the bundle start level is greater than the framework target start level
* if the start level thread is already running
I think the Bundle#start should either activate the bundle or wait for the bundle to be activated before returning in order to comply with the spec.
> Bundle#start does not comply with the spec
> ------------------------------------------
>
> Key: FELIX-3361
> URL: https://issues.apache.org/jira/browse/FELIX-3361
> Project: Felix
> Issue Type: Bug
> Affects Versions: framework-4.0.2
> Reporter: Guillaume Nodet
>
> The spec says: "When the start method returns without an exception, the state of the bundle will either be ACTIVE or STARTING, depending on the declared activation policy and whether it was used. If the start method throws an exception, then the bundle will not be in either of these states and the stop method will not be called for this Bundle Activator instance."
> However there is a case where this does not happen, which is when the start level thread is already running
> I think the Bundle#start should either activate the bundle or wait for the bundle to be activated before returning in order to comply with the spec.
--
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
[jira] [Commented] (FELIX-3361) Bundle#start does not comply with
the spec
Posted by "Felix Meschberger (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13215539#comment-13215539 ]
Felix Meschberger commented on FELIX-3361:
------------------------------------------
If start levels come into play the StartLevel service dictates the actual bundle states.
> * when the bundle start level is greater than the framework target start level
The bundle is not expected to start until the framework start level is increased to at least the bundle's start level. Start levels are increased step-wise. So if a bundle is at 5, the current is 2 and the target is 6, the start level is increased to 3, 4, 5, and 6 and bundles assigned to the respective start levels are actually started.
Thus a bundle at level x with the framework start level being y < x will at most be in the RESOLVED state.
* if the start level thread is already running
Right, if the start level is being increased, the bundle is only actually started when passing the bundle's start level.
Bundle.start in these situations will only persistently mark the bundle started (for later start level operations to actually start the bundle).
> Bundle#start does not comply with the spec
> ------------------------------------------
>
> Key: FELIX-3361
> URL: https://issues.apache.org/jira/browse/FELIX-3361
> Project: Felix
> Issue Type: Bug
> Affects Versions: framework-4.0.2
> Reporter: Guillaume Nodet
>
> The spec says: "When the start method returns without an exception, the state of the bundle will either be ACTIVE or STARTING, depending on the declared activation policy and whether it was used. If the start method throws an exception, then the bundle will not be in either of these states and the stop method will not be called for this Bundle Activator instance."
> However there is a case where this does not happen, which is when the start level thread is already running
> I think the Bundle#start should either activate the bundle or wait for the bundle to be activated before returning in order to comply with the spec.
--
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