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.
For more information click here
|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|
|It contains html, xml and even bundle||It is basically a jar with extra manifest headers|
|deploy into 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 lookingfor 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.
Repository nodes with type sling:OsgiConfig under /apps/*/config configuration settings take over precedence on start-up.
The OSGi installer service a central service for handling installs, updates and uninstall of artifacts.
Apache Felix Web console
Go to Apache Felix Web console
Nothing. Changes are automatically applied.
A restart is not required. Check this link
The OSGi Componendium Configuration Admin Service specifies a service, which allows for easy management of configuration data for configurable components. Basicaly 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 are 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.
It will use the default configuration for the unspecified property.
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 identifier can be any unique name.