[
https://issues.apache.org/jira/browse/FELIX-3713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507110#comment-13507110
]
Richard S. Hall commented on FELIX-3713:
----------------------------------------
I'm not sure I see a great solution for this one. One possibility is to somehow
pass along the fact in the tuple that this bundle is being transiently started
as opposes to being a bundle that is persistently stopped. This still treats
the bundle asynchronously and potentially is somewhat complicated since we'd
somehow need to mark the bundle as STARTING so that it couldn't be stopped
before it was started.
Another approach is to treat transient bundles differently and directly
activate them if their start level is met (or fail if it is not). The downside
of this approach is that they may activate slightly out of order since it could
not be coordinated with the start level thread's active start level.
I think the latter approach is probably the better of the two.
> 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
