AEM Introduction
The OSGi Alliance, formerly known as the Open Services Gateway initiative. The OSGi specification describes a modular system and a service platform for the Java programming language that implements a complete and dynamic component model, something that does not exist in standalone Java/VM environments. Applications or components, coming in the form of bundles for deployment, can be remotely installed, started, stopped, updated, and uninstalled without requiring a reboot; management of Java packages/classes is specified in great detail. Application life cycle management is implemented via APIs that allow for remote downloading of management policies. The service registry allows bundles to detect the addition of new services, or the removal of services, and adapt accordingly.
The OSGi has a layered model that is depicted in the following figure.
OSGi
For more information click here
The OSGi has a layered model. The following list contains a short definition of the terms:
- Bundles – Bundles are normal jar components with extra manifest headers.
- Services – The service layer, which holds the service side of the framework, keeps the service registry and manages it.
- Life-Cycle – The lifecycle layer manages and keeps track of the frameworks and bundle's lifecycle state. It is used to install or uninstall framework objects and start or stop them.
- Modules – The module layer, which is the bundle space, holds the bundles that are installed on the framework and are managed through the lifecycle layer.
- Security – The security layer, which extends the java 2 security architecture, is optional. When active, it validates the bundle signatures and controls the component access rights . Execution Environment – The execution environment layer, which is the bottom layer on which the bundles live, is selected to fit the underlying hardware or operating system.
Please refer to this link.
https://www.osgi.org/resources/what-is-osgi/
- The bundle life cycle states are as follows.
- INSTALLED: The bundle has been successfully installed. The framework knows enough about this bundle to attempt to load it.
- RESOLVED: All resources needed for this bundle have been loaded successfully and the bundle is ready to be started. This is also the state the bundle would be in, once successfully stopped.
- STARTING: The bundle is being started, but has not finished starting.
- ACTIVE: The bundle has been successfully activated and is running, ready to be used.
- STOPPING: The bundle is being stopped but has not finished stopping.
- UNINSTALLED: The bundle has been uninstalled. Once uninstalled, nothing can be done with the module.
| JAR | Bundle |
|---|---|
| have manifest file | have manifest file |
| They are not meant to be run in an OSGi runtime container | They are meant to be run in an OSGi runtime container |
| To create jar, we have to select jar option into packaging tag in pom.xml | To create bundle, we have to put "bundle" as value into packaging tag in pom.xml |
| you can consume jar by calling its public methods | You can consume bundle by calling their services. Which are mentioned in export packages of manifest file |
| Package | Bundle |
|---|---|
| It contains HTML, XML and even a bundle | It is basically a jar with extra manifest headers |
| deploy into the package manager | install into Felix console |
| To create package, we have to put "content-package" as value into packaging tag in pom.xml | To create bundle, we have to put "bundle" as value into packaging tag in pom.xml |
The process of linking a bundle to provide its access to another bundle's content is called bundle wiring. When the framework resolves a bundle for installation, it reads the bundle manifest looking for its capabilities (the packages it provides or exports) and its requirements (those that it imports). It uses this information to wire the bundles together in a mesh of dependencies, thus constructing the class space visible to each bundle.
- groupId will identify your project uniquely across all projects, so we need to enforce a naming schema. It has to follow the package name rules, what means that has to be at least as a domain name you control, and you can create as many subgroups as you want. eg. org.apache.maven, org.apache.commons
- artifactId is the name of the jar without version. If you created it then you can choose whatever name you want with lowercase letters and no strange symbols. If it's a third party jar you have to take the name of the jar as it's distributed. eg. maven, commons-math
- version if you distribute it then you can choose any typical version with numbers and dots (1.0, 1.1, 1.0.1, ...). Don't use dates as they are usually associated with SNAPSHOT (nightly) builds. If it's a third party artifact, you have to use their version number whatever it is, and as strange as it can look. eg. 2.0, 2.0.1, 1.3.1
Please follow the instruction from the link.
https://experienceleague.adobe.com/docs/experience-cloud-kcs/kbarticles/KA-17475.html
Repository nodes with type sling:OsgiConfig under /apps/*/config configuration settings take over precedence on start-up.
Please go through the video for more details.
https://youtu.be/Z7kDntKsS6w
The OSGi installer service a central service for handling installs, updates and uninstall of artifacts.
Apache Felix Web console
Go to the Apache Felix Web console
- switch to the Configuration tab.
- select Configurations item CRX Sling Client Repository and configure it.
- set the value for the property Admin Password to the same password configured above in the repository.
- click save which immediately takes effect.
Nothing. Changes are automatically applied.
- Comment according servlet mappings in web.xml
- Connect to the Felix Management Console, per default running on http://:/system/console
- In the list of Bundles, find the bundle named Sling - Simple WebDAV Access to repositories
- Stop this bundle by clicking on the stop-button
A restart is not required. Check this link
The OSGi Compendium Configuration Admin Service specifies a service, which allows for easy management of configuration data for configurable components. Basically, a configuration is a list of name-value pairs. Configuration is managed by management applications by asking the Configuration Admin Service for such configuration. After updating the configuration, it is sent back to the Configuration Admin Service. The Configuration Admin Service is like a central hub, which cares for persisting this configuration and also for distributing the configuration to interested parties. One class of such parties is the components to be configured. These are registered as ManagedService services. There is also a notion of ManagedServiceFactory, which allows for multiple configurations of the same kind to be applied.
Use the CRX browser to create a folder in /apps/myproject called “config.author” and then create a new node and select “sling:OsgiConfig” as the node type.
Copy the bundle into the /apps/install folder.
Append "-<"identifier"> to the name, where the identifier can be any unique name.
Leave a Reply