[ 
https://issues.apache.org/jira/browse/FELIX-3713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall updated FELIX-3713:
-----------------------------------

    Fix Version/s: framework-4.2.0
    
> 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

Reply via email to