Modifying the configuration of an OSGi composition unit by using wsadmin commands

You can use the editCompUnit command and the AdminConfig commands to modify the configuration information for a composition unit that contains an enterprise OSGi application. An OSGi composition unit consists of an EBA asset, (optionally) one or more composite bundle extensions, and configuration information for running the asset and composite bundle extensions in a business-level application. The configuration information can include HTTP session management, context roots, virtual hosts, security roles, run-as roles, JNDI mappings for Session enterprise beans, JNDI mappings for EJB references, and web application or Blueprint resource reference bindings for your OSGi application.

Before you begin

You can modify the configuration of an OSGi composition unit by using wsadmin commands as described in this topic, or by using the administrative console as described in Modifying the configuration of an OSGi composition unit.

About this task

An OSGi composition unit consists of an EBA asset, (optionally) one or more composite bundle extensions, and some or all of the following configuration information:
  • Mappings from the composition unit to a target application server, web server, or cluster.
  • Configuration of the session manager, context roots or virtual hosts of the application.
  • Mappings from enterprise beans to JNDI names.
  • Bindings to any associated web applications or blueprint resource references.
  • Mappings from security roles to particular users or groups.

You first specify the configuration of an EBA asset or composite bundle extension when you add it to a composition unit. If bundles in the asset or composite bundle extension are later changed, or if you have to remap resources, you can update the configuration. For example, if you update a bundle in an EBA asset, or replace a composite bundle extension, you might introduce a resource that requires additional configuration, such as a new or changed Blueprint resource reference, or security role mapping.

To configure all elements of the composition unit except the HTTP session manager, you use the editCompUnit command. To configure the HTTP session manager, you use the AdminConfig commands to configure the deployed object represented by the appDeploy variable.

In the following procedure, all the steps and substeps are optional. You only need to re-configure the elements that have changed.

Procedure

What to do next

After using these commands, save your changes to the master configuration by using the following command:

AdminConfig.save()

When you save the changes to the composition unit, the associated business-level application is updated to use the new configuration. If the business-level application is running, the bundle and configuration updates are applied immediately.

If possible (that is, depending on the nature of the updates) the system applies the updates without restarting the application. If you update a bundle that provides only OSGi services to the rest of the application, then only that bundle is restarted. If you update a bundle that provides one or more packages to other bundles, then those bundles and any bundles to which they provide packages are restarted. If, however, a new package or service dependency is added, or an existing package or service dependency is removed, then the application is restarted; a newly added package and service can come from a newly-provisioned bundle, or from a bundle that has already been provisioned.

If your application has a client bundle that references an enterprise bean in a service bundle, then to prevent the application being restarted if the service bundle is updated, configure the enterprise bean dependency in one of the following ways:
  • Declare the enterprise bean in the Export-EJB header in the bundle manifest file of the service bundle, so that the enterprise bean is registered in the OSGi service registry, and use a reference element in the Blueprint XML file of the client bundle to inject and call the enterprise bean; for more information, see References and the Blueprint Container. This procedure is the preferred way to configure the EJB dependency.
  • In the client bundle, declare an EJB reference to the target enterprise bean, in either an @EJB annotation or a binding XML file, and map the EJB reference to the EJB JNDI name when the application is deployed; for more information, see EJB references [Settings].
If you do not declare the enterprise bean by using the Export-EJB header or by binding the EJB reference into JNDI, then a JNDI binding is generated automatically when you deploy the application, provided that there is exactly one match between the interface that the EJB class implements, and an interface that is specified in an EJB reference. However, the JNDI name that is generated contains the bundle version, which changes if you update the bundle; in this case, when you update the composition unit, the JNDI is regenerated to contain the updated version, and this configuration change results in the application being restarted.

Icon that indicates the type of topic Task topic

Terms and conditions for information centers | Feedback


Timestamp icon Last updated: Monday, 21 April 2014
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-express-iseries&topic=ta_admin_mod_acu_wsadmin
File name: ta_admin_mod_acu_wsadmin.html