[
https://issues.apache.org/jira/browse/FELIX-3713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13496854#comment-13496854
]
Richard S. Hall commented on FELIX-3713:
----------------------------------------
Yep, that's why we opened an issue on it. Thanks.
> Bundle.start() returns without starting the bundle
> --------------------------------------------------
>
> Key: FELIX-3713
> URL: https://issues.apache.org/jira/browse/FELIX-3713
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: framework-4.0.2
> Reporter: Sahoo
> Fix For: framework-4.2.0
>
>
> See email exchange between Sahoo & Richard that happened in dev alias on 16th
> Oct 2012 for issue details:
> > While investigating some issues in GlassFish, what we are seeing is that
> > even if our code is calling bundle.start(START_TRANSIENT), the bundle is
> > not getting started immediately, nor is the code blocking. It simply
> > returns without Bundle's activator getting called and bundle.getState() ==
> > RESOLVED. We see this happening when there is a start level change in
> > progress. We are currently using Felix 4.0.2. Looking at the code, I see
> > this to be by design, but isn't it a non-compliant behavior? Should
> > bundle.start() not wait until the bundle is started?
> The spec has always been a little lenient about how start levels are
> processed to give leeway to the frameworks. For us, we viewed this as
> somewhat of a race condition between threads starting bundles and the start
> level thread.
> However, in the transient case, I wouldn't expect it to remain in RESOLVED
> state. If its start level wasn't met, it should have thrown an exception. Yet
> there is a chance in the transient case that it could start
> asynchronously...not sure if this would really be problematic for you or
> not...
> But it shouldn't remain in the RESOLVED state. Looking at the code, I think
> there is a bug in this scenario where a transient bundle that is handled
> asynchronously will not actually end up getting started since the start level
> thread checks the persistent state of the bundle, which is not set for
> transient bundles.
> You could definitely open up a bug for this last issue...
> -> richard
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira