Welcome to part 4 of the OSGI module Bundle Lifecycle.
After reading this article, you should
- Know the bundle lifecycle
- Understand the bundle statuses
- Be able to write your own bundle activation listener
Lifecycle – Second OSGI Layer
Lifecycle is the second architectural layer of OSGI, the first layer just defines bundles and the way classes are imported exported by bundles.
Second layer defines what happens to the bundle when it placed it into the environment and what happens when it is removed from the environment, that’s why it is called lifecycle.
Lifecycle
OSGI specification defines the bundle lifecycle of 6 states from Installed to Uninstalled. Let’s look into those states in detail.
The first state is Installed, The bundle is in Installed state right after it has been successfully deployed in the environment. Let me remind that you can install and uninstall bundles without restarting the environment.
Before the environment resolves all the dependencies declared by the bundle it remains in the Installed state.
If you that your bundle remains in the installed state for too long, most likely that means – the environment cannot resolve the bundles dependencies.
Bundle Lifecycle : Resolved
As you have probably figured out, resolving the dependencies mean finding the packages imported by the bundle and making them available to the bundle.
If your bundle imports the package, some other bundle must export it. In turn your bundle exports the package that other bundles can us.
When your bundle dependencies are resolved the bundle, state is changed to resolved that means the bundle is ready to start.
Lifecycle : Starting
Next state is Starting that is when the bundle activation code is executed. You can create your own activation code that will be executed upon bundle activation. That is sometimes used when there is a need to do some initialization. So for that you need to have a class that implements BundleActivator interface and add logic in the start method then you declare your Activator in the Maven Bundle Plugin instructions, there is still no annotation for that-only XML.
Lifecycle : Active and Beyond
Let’s review the other states, Active is one the bundle has successfully started and can do its job, then the bundle can be Stopped. When Stopped it goes to the stopping state when the deactivation code it is executed and then becomes resolved, after that you can Uninstalled the bundle and it becomes Uninstalled.
Bundle Class Loading
Now let’s see how class loading works for bundles as you remember there is a separate class loader for every bundle. When a bundle needs a class, here is the logic that it uses.
In each bundle if a class belongs to one of the java.something packages or any packages listed in this property framework.bootdelegation the bundle class loader delegates the loading to the parent class loader.
If the class belongs to one of the packages listed in import package, so if is that class exported by some other bundle the bundle class loader delegates the loading to the class loader of the exporter bundle, if it is not one of the imported classes the bundle class loader looks for the class amongst its internal classes.
So, the classes that are present in the bundle JAR file. If not found then bundle class loader searches for internal classes of any fragments attached to the bundle.
Bundle Fragments
Fragments were designed for the deployment of localized resources, that is you have the main bundle that is the same on all instances and localized part of it, that is deployed as fragment and is different from instance to instance. or it may be a native driver specific to the operating system.
This is how it is organized; A fragment is s bundle that is not in dependent but attached to another bundle which is called host bundle that means it has a reference to the host bundle.
A fragment is deployed separately before the host bundle. The fragment is loaded by the host bundles class loader. There are several fragments that come with AEM instance out-of-the-box. I have not seen fragments used in production projects. AEM has most sophisticated features for localization.
Summary• Bundles are managed by OSGI environment
• A bundle can be in one of the six states.
o Installed – the bundle is uploaded but the references are not resolved
o Resolved – references are resolved, activation not started
o Starting – activation is in progress
o Active – ready to use or in use now
o Stopping – deactivation in progress
o Uninstalled – unloaded from the environment
• Bundles can be monitored in the Web Console
• Every bundle is loaded by its own classloader
Hope you enjoyed this article, I would like to suggest, Kindly watch video below for practical session, Thank you for your attention! In the next part we will get familiar with Services and Components. Click here to visit page!