[
https://issues.apache.org/jira/browse/FELIX-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard S. Hall closed FELIX-3306.
----------------------------------
Resolution: Fixed
I'm closing this issue as fixed. The code actually did catch BundleExceptions
and continued to activate; however, I modified it to catch Throwable and log
exception too.
> 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
