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

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

I think I see the issue. The lazy activation code works properly if it is 
triggered by class loads caused during the defineClass() operation, but not if 
the class loads occur when a lazy bundle is being activated as a result of a 
trigger (i.e., in the lazy bundle's start() method). This latter case is 
demonstrated by your example bundles.

The code doesn't expect the deferred list to grow during the activation of lazy 
bundles, so the lazy bundles added due to class loads during activation are 
effectively ignored. The code should be changed so that it grabs the deferred 
list first and inserts an empty deferred list back into the thread local before 
starting to activate. That way any subsequent class loads triggering lazy 
activation in the start() method will be handled in a similar fashion as any 
other class load triggering lazy activation.
                
> Lazy activation of bundles is not always working as expected
> ------------------------------------------------------------
>
>                 Key: FELIX-3306
>                 URL: https://issues.apache.org/jira/browse/FELIX-3306
>             Project: Felix
>          Issue Type: Bug
>          Components: Framework
>    Affects Versions: framework-4.0.2
>            Reporter: Bogdan Stefanescu
>            Assignee: Richard S. Hall
>             Fix For: framework-4.2.0
>
>         Attachments: bundle1_1.0.0.201201161439.jar, 
> bundle2_1.0.0.201201161439.jar, bundle3_1.0.0.201201161439.jar
>
>
> When loading a class from a "lazy" bundle (e.g. Bundle-ActivationPolicy: 
> lazy) the bundle is not always activated.
> More precisely, when a bundle is triggering the activation of a chain of more 
> than one lazy bundle (due to a class loading) not all the bundles in the 
> chain are activated.
> Example:
> Let say we have 3 bundles: bundle1, bundle2 and bundle3. All those bundles 
> are defining a lazy activation via: 'Bundle-ActivationPolicy: lazy'.
> In the activator of bundle1 we load a class from bundle2. In activator of 
> bundle2 we load a class from bundle3.
> By starting (from the felix command line) the bundle1 - only the bundle2 will 
> be activated even if the class from bundle3 is successfully loaded by the 
> activator of bundle2.
> You can find attached 3 bundles you can use to reproduce the bug. (they also 
> contains the source code)
> To reproduce the bug: 
> Install a felix 4.0.2 (or 4.2.0-SNAPSHOT) and add the plugin 
> "org.apache.felix.fileinstall"
> Configure the fileinstall plugin to load the bundles located inside the 
> directory ./plugins:
> felix.fileinstall.dir=./plugins
> and put there the 3 bundles attached to the issue.
> After starting Felix by typing "lb -s" I have:
> {noformat}
> START LEVEL 1
>    ID|State      |Level|Symbolic name
>     0|Active     |    0|org.apache.felix.framework (4.0.2)
>     1|Active     |    1|org.apache.felix.bundlerepository (1.6.6)
>     2|Active     |    1|org.apache.felix.fileinstall (3.1.10)
>     3|Active     |    1|org.apache.felix.gogo.command (0.12.0)
>     4|Active     |    1|org.apache.felix.gogo.runtime (0.10.0)
>     5|Active     |    1|org.apache.felix.gogo.shell (0.10.0)
>     6|Starting   |    1|bundle3 (1.0.0.201201161439)
>     7|Starting   |    1|bundle1 (1.0.0.201201161439)
>     8|Starting   |    1|bundle2 (1.0.0.201201161439)
> {noformat}
> which is OK since the 3 bundles are declared as "lazy" so they will enter the 
> STARTING state.
> Now start the bundle1 by typing "start 7". I have the following output:
> {noformat}
> >>> Bundle3Object loaded
> Sarted bundle: bundle2
> >>> Bundle2Object loaded
> Started Bundle: bundle1
> {noformat}
> and typing again "lb -s" I have:
> {noformat}
> START LEVEL 1
>    ID|State      |Level|Symbolic name
>     0|Active     |    0|org.apache.felix.framework (4.0.2)
>     1|Active     |    1|org.apache.felix.bundlerepository (1.6.6)
>     2|Active     |    1|org.apache.felix.fileinstall (3.1.10)
>     3|Active     |    1|org.apache.felix.gogo.command (0.12.0)
>     4|Active     |    1|org.apache.felix.gogo.runtime (0.10.0)
>     5|Active     |    1|org.apache.felix.gogo.shell (0.10.0)
>     6|Starting   |    1|bundle3 (1.0.0.201201161439)
>     7|Active     |    1|bundle1 (1.0.0.201201161439)
>     8|Active     |    1|bundle2 (1.0.0.201201161439)
> {noformat}
> Which is NOT OK, since the bundle2 is loading a class 'Bundle3Object' from 
> bundle3 in the activator - the bundle3 must be activated too but it is not.
> You can see in the log made by bundle2 that Bundle3Object is correctly loaded 
> (but the bundle3 not activated).
> (You can see the bundle2 was correctly activated by bundle1 by loading a 
> class from bundle2 but the bundle3 is not activated when bundle2 is loading a 
> class from bundle3)
> The fileinstall plugin seems to work correctly. I think the problem is in 
> BundleWiringImpl$BundleClassLoader.findClass()

--
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

        

Reply via email to