[standalone@localhost:9999 /] /subsystem=osgi:read-attribute(name=activation)
{
"outcome" => "success",
"result" => "lazy"
}
The JBoss OSGi Framework in JBoss AS 7 can be controlled via the AS 7 Command Line Interface (CLI).
The CLI supports an interactive mode as well as a scripted mode, for more information on using and launching the CLI, see the Command Line Interface documentation.
Supported operations:
Framework configuration is stored in the AS 7 XML configuration file (e.g. standalone.xml). The CLI provides a management interface to this configuration.
The activation mode of the OSGi subsystem within AS 7 is specified in the activation attribute. It specifies whether the OSGi subsystem is activated on startup of the Application Server (eager) or only once the first bundle is deployed (lazy). By default the activation mode is set to lazy.
To read the current activation mode:
[standalone@localhost:9999 /] /subsystem=osgi:read-attribute(name=activation)
{
"outcome" => "success",
"result" => "lazy"
}
To change the activation mode to eager
[standalone@localhost:9999 /] /subsystem=osgi:write-attribute(name=activation,value=eager)
{"outcome" => "success"}
Framework properties are stored as resources in the /subsystem=osgi/property location. Note that any changes to OSGi framework properties require a framework restart in order to become effective.
Adding a property: the following command adds the org.osgi.framework.system.packages.extra framework property with value org.foo.bar;version=1.2.
[standalone@localhost:9999 /] /subsystem=osgi/property=org.osgi.framework.system.packages.extra:add(value=org.foo.bar;version=1.2)
{"outcome" => "success"}
To list the framework properties use the ls command:
[standalone@localhost:9999 /] ls /subsystem=osgi/property org.osgi.framework.startlevel.beginning org.osgi.framework.system.packages.extra
To read the value of an individual framework property:
[standalone@localhost:9999 /] /subsystem=osgi/property=org.osgi.framework.startlevel.beginning:read-resource
{
"outcome" => "success",
"result" => {"value" => "1"}
}
To remove a framework property:
[standalone@localhost:9999 /] /subsystem=osgi/property=org.osgi.framework.system.packages.extra:remove
{"outcome" => "success"}
The capability name is an abstract identifier for some functional capability. We currently support module identifiers (i.e. a pointer to some bundle or module available in the AS 7 product repository) and maven coordinates (i.e. a maven artifact identifier availbale in the public jboss nexus repository). Capabilities are automatically loaded when the OSGi framework is launched. In the case of bundle capabilities, these can also be started as part of this process. The modules repository can be found in the modules/ subdirectory of the AS 7 installation, while the bundles repository can be found in the bundles/ subdirectory.
The example command below adds a bundle capability org.projectodd.stilts. The system will look for capabilities at startup in the modules/ and bundles/ directories. In this example the org.projectodd.stilts module/bundle jar is searched in the modules/org/projectodd/stilts/main/ and bundles/org/projectodd/stilts/main/ locations.
[standalone@localhost:9999 /] /subsystem=osgi/capability=org.projectodd.stilts:add(startlevel=2)
{"outcome" => "success"}
Note that only bundles can be started, so specifying the startlevel as is done in this example does not apply to modules.
To list configured capabilities use the ls command:
[standalone@localhost:9999 /] ls /subsystem=osgi/capability javax.servlet.api:v25 javax.transaction.api org.apache.felix.configadmin org.apache.felix.log org.jboss.as.osgi.configadmin org.jboss.osgi.logging org.projectodd.stilts
To inspect a capability, use the read-resource command:
[standalone@localhost:9999 /] /subsystem=osgi/capability=org.projectodd.stilts:read-resource
{
"outcome" => "success",
"result" => {"startlevel" => 2}
}
Removing a capability can be done with the remove command:
[standalone@localhost:9999 /] /subsystem=osgi/capability=org.projectodd.stilts:remove
{"outcome" => "success"}
Framework management refers to the monitoring and manipulating the OSGi Framework runtime state.
The framework can be activated using the activate command.
[standalone@localhost:9999 /] /subsystem=osgi:activate
{"outcome" => "success"}
The current framework start level can be in found in the startlevel attribute in the osgi subsystem. For example:
[standalone@localhost:9999 /] ls subsystem=osgi bundle capability property activation=lazy startlevel=1
To change the start level, write the desired new value to the startlevel attribute:
[standalone@localhost:9999 /] /subsystem=osgi:write-attribute(name=startlevel,value=3)
{"outcome" => "success"}
The CLI can be used to deploy, undeploy, start and stop bundles and to inspect the current bundle state.
Deployment and un-deployment of bundles is done through the regular deployment channels in AS 7. To deploy a bundle:
[standalone@localhost:9999 /] deploy /home/someuser/test-osgi-bundle.jar
Undeploying is done with the undeploy command:
[standalone@localhost:9999 /] undeploy test-osgi-bundle.jar
Note that deploying a bundle will place it in the INSTALLED state, to become functional OSGi bundles need to be started.
To start the test-osgi-bundle.jar as deployed above, use the following command:
[standalone@localhost:9999 /] /subsystem=osgi/bundle=test-osgi-bundle.jar:start
{"outcome" => "success"}
To inspect the bundle state:
[standalone@localhost:9999 /] /subsystem=osgi/bundle=test-osgi-bundle.jar:read-resource(include-runtime=true)
{
"outcome" => "success",
"result" => {
"id" => 8L,
"location" => "test-osgi-bundle.jar",
"startlevel" => 1,
"state" => "ACTIVE",
"symbolic-name" => "TestOSGiBundle",
"type" => "bundle",
"version" => "1.0.0"
}
}
To stop the bundle, issue one of the following commands:
[standalone@localhost:9999 /] /subsystem=osgi/bundle=8:stop
{"outcome" => "success"}
or
[standalone@localhost:9999 /] /subsystem=osgi/bundle=test-osgi-bundle.jar:stop
{"outcome" => "success"}
Bundles can be listed by bundle ID using the ls command:
[standalone@localhost:9999 /] ls /subsystem=osgi/bundle 0 1 2 3 4 5 6 8
or in more detail using the read-children-resources command:
[standalone@localhost:9999 /] /subsystem=osgi:read-children-resources(child-type=bundle,include-runtime=true)
{
"outcome" => "success",
"result" => {
"0" => {
"id" => 0L,
"location" => "System Bundle",
"startlevel" => 0,
"state" => "ACTIVE",
"symbolic-name" => "system.bundle",
"type" => "bundle",
"version" => "0.0.0"
},
"1" => {
"id" => 1L,
...and so on...
OSGi Configuration Admin support is provided through the configadmin subsystem. By default the JBoss OSGi runtime in AS 7 provides the Configuration Admin Service. For more information on the OSGi Configuration Admin Service see chapter 104 in the OSGi Compendium Specification.
Configuration Admin is a dynamic system that supports re-configuration during operation, therefore all the related management operations take effect immediately and value changes will be propagated to the relevant configuration consumers without the need for a restart.
Configuration Admin configurations objects are identified by a Persistent Identified (PID) and carry an associated map of configuration values. Create a configuration using the add command:
[standalone@localhost:9999 /] /subsystem=configadmin/configuration=org.example.myPid:add(entries={"key"=>"value","anotherkey"=>"another value"})
{"outcome" => "success"}
List all the available configurations with the ls command:
[standalone@localhost:9999 /] ls /subsystem=configadmin/configuration org.example.myPid
Read the configuration data with the read-resource command:
[standalone@localhost:9999 /] /subsystem=configadmin/configuration=org.example.myPid:read-resource
{
"outcome" => "success",
"result" => {"entries" => {
"key" => "value",
"anotherkey" => "another value"
}}
}
Configuration objects can be removed by issuing the remove command on the configuration pid resource:
[standalone@localhost:9999 /] /subsystem=configadmin/configuration=org.example.myPid:remove
{"outcome" => "success"}