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.
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
- Configure all elements of the composition unit except the
HTTP session manager.
Each of the following substeps
describes the syntax for modifying a single element of the composition
unit using the editCompUnit command. You can run
the command once for each element, or you can modify several elements
in a batch.
For several of the elements, the values you specify include bundle identifiers. If your EBA asset includes or references composite bundles, the command syntax is slightly different. For clarity, the differences for composite bundles are described, step by step, in a linked topic.
- Identify the composition unit that you want to edit.
You identify a particular composition unit by specifying
its business-level application ID and composition unit ID. Whenever
you run the
editCompUnit command, you must always
include these two parameters in the command.
- -blaID
- Specifies the configuration ID of the business-level application.
- -cuID
- Specifies the ID of the composition unit.
The Jython syntax for this aspect of the command is as follows:
AdminTask.editCompUnit('[
-blaID WebSphere:blaname=bla_name
-cuID WebSphere:cuname=cu_name
...
]')
For example:
AdminTask.editCompUnit('[
-blaID WebSphere:blaname=helloWorldService
-cuID WebSphere:cuname=com.ibm.ws.eba.helloWorldService_0001.eba
...
]')
- Map the target node and server, or the target cluster.
You cannot edit the deployable unit URI (which, for a composition
unit that contains an OSGi application, is ebaDeploymentUnit).
You can edit the target node and server, or the target cluster. To add an additional target, you use the plus sign character ( + ) as a prefix.
If the target is one cluster, the Jython syntax for this aspect of the command is as follows:AdminTask.editCompUnit('[
-blaID WebSphere:blaname=bla_name
-cuID WebSphere:cuname=cu_name
-MapTargets [[ebaDeploymentUnit WebSphere:cluster=cluster_name]]
]')
For example:
AdminTask.editCompUnit('[
-blaID WebSphere:blaname=helloWorldService
-cuID WebSphere:cuname=com.ibm.ws.eba.helloWorldService_0001.eba
-MapTargets [[ebaDeploymentUnit WebSphere:cluster=cluster1]]
]')
If the target is two servers, the Jython syntax for this aspect of the command is as follows::
AdminTask.editCompUnit('[
-blaID WebSphere:blaname=bla_name
-cuID WebSphere:cuname=cu_name
-MapTargets [
[ebaDeploymentUnit WebSphere:node=node_name,server=server_name+
WebSphere:node=node2_name,server=server2_name]]
]')
For example:
AdminTask.editCompUnit('[
-blaID WebSphere:blaname=helloWorldService
-cuID WebSphere:cuname=com.ibm.ws.eba.helloWorldService_0001.eba
-MapTargets [
[ebaDeploymentUnit WebSphere:node=node01,server=server1+
WebSphere:node=node01,server=web1]]
]')
- Map context root for web modules.
Context roots determine where the web pages of a particular web application bundle (WAB) are found at run time. The context root that you specify here is combined with the defined server mapping to compose the full URL that you enter to access the pages of the WAB. For example, if the application server default host is www.example.com:8080 and the context root of the WAB is /sample, the web pages are available at www.example.com:8080/sample.
The Jython syntax for this aspect of the command is as follows.
The list of bundles under the ContextRootStep must contain all the WABs contained in the OSGi application.
AdminTask.editCompUnit('[
-blaID WebSphere:blaname=bla_name
-cuID WebSphere:cuname=cu_name
-ContextRootStep [
[bundle_symbolic_name_1 bundle_version_1 context_root_1]
[bundle_symbolic_name_2 bundle_version_2 context_root_2]]
]')
For example, for an EBA file that contains two WABs (com.ibm.ws.eba.helloWorldService.web at version 1.0.0, which is to be mapped to /hello/web, and com.ibm.ws.eba.helloWorldService.withContextRoot at version 0.9.0, which is to be mapped to /hello/service), this aspect of the command is as follows:AdminTask.editCompUnit('[
-blaID WebSphere:blaname=helloWorldService
-cuID WebSphere:cuname=com.ibm.ws.eba.helloWorldService_0001.eba
-ContextRootStep [
[com.ibm.ws.eba.helloWorldService.web 1.0.0 "/hello/web"]
[com.ibm.ws.eba.helloWorldService.withContextRoot 0.9.0 "/hello/service"]]
]')
- Bind listeners for message-driven beans
For each message-driven bean (MDB) that is defined in either an ejb-jar.xml file or in an @MessageDriven annotation in the composition unit, you can specify the settings necessary to bind an MDB listener to the MDB. By binding a listener to an MDB, you configure the association of the MDB with the JMS destination from which the MDB receives messages.
The Jython syntax for this aspect of the command is as follows.
AdminTask.editCompUnit('[
-blaID WebSphere:blaname=bla_name
-cuID WebSphere:cuname=cu_name
-MDBBindingsStep [
[bundle_symbolic_name_1 bundle_version_1 uri_1
activation_spec_1 destination_jndi_name_1 authentication_alias_1]
[bundle_symbolic_name_2 bundle_version_2 uri_2
activation_spec_2 destination_jndi_name_2 authentication_alias_2]]
]')
In the following example, an EBA file contains two EJB bundles, com.ibm.ws.eba.currencyService at version 1.0.0, and com.ibm.ws.eba.accountService at version 0.9.0. The currencyService bundle contains a message-driven bean called ExchangeRateMDB, bound to an activation specification with a JNDI name of eis/ExchangeRate_Act_Spec; the destination JNDI name that is defined in the activation specification is overridden by a destination whose JNDI name is jms/ExchangeRateQueue, and the authentication alias that is defined in the activation specification is overridden by an authentication alias called ExchangeRate_Auth_Alias. The accountService bundle contains an MDB called CustomerDetailsMDB, bound to an activation specification with a JNDI name of eis/CustomerDetails_Act_Spec; the destination JNDI name that is defined in the activation specification is overridden by a destination whose JNDI name is jms/CustomerDetailsQueue, and the authentication alias that is defined in the activation specification is overridden by an authentication alias called CustomerDetails_Auth_Alias.AdminTask.editCompUnit('[
-blaID WebSphere:blaname=financeService
-cuID WebSphere:cuname=com.ibm.ws.eba.financeService_0001.eba
-MDBBindingsStep [
[com.ibm.ws.eba.currencyService 1.0.0 META-INF/ejb-jar.xml/ExchangeRateMDB
eis/ExchangeRate_Act_Spec jms/ExchangeRateQueue ExchangeRate_Auth_Alias]
[com.ibm.ws.eba.accountService 0.9.0 META-INF/ejb-jar.xml/CustomerDetailsMDB
eis/CustomerDetails_Act_Spec jms/CustomerDetailsQueue CustomerDetails_Auth_Alias]]
]')
- Provide EJB JNDI names
For each Session enterprise bean in the composition unit, you can specify the JNDI name by which the enterprise bean is known in the runtime environment.
The Jython syntax for this aspect of the command is as follows.
AdminTask.editCompUnit('[
-blaID WebSphere:blaname=bla_name
-cuID WebSphere:cuname=cu_name
-EJBMappingsStep [
[bundle_symbolic_name_1 bundle_version_1 ejb_name_1
ejb_interface_1 ejb_iterface_type_1 jndi_name_1]
[bundle_symbolic_name_2 bundle_version_2 ejb_name_2
ejb_interface_2 ejb_iterface_type_2 jndi_name_2]]
]')
In the following example, an EBA file contains two EJB bundles, com.ibm.ws.eba.currencyService at version 1.0.0, and com.ibm.ws.eba.accountService at version 0.9.0. The currencyService bundle contains an enterprise bean called ExchangeRate_ejb, with a Local interface called com.ibm.ws.eba.ejb.ExchangeRate, that is mapped to a JNDI name of ejb/ExchangeRate. The accountService bundle contains an enterprise bean called CustomerDetails_ejb, with a Remote interface called com.ibm.ws.eba.ejb.CustomerDetails, that is mapped to a JNDI name of ejb/CustomerDetails.AdminTask.editCompUnit('[
-blaID WebSphere:blaname=financeService
-cuID WebSphere:cuname=com.ibm.ws.eba.financeService_0001.eba
-EJBMappingsStep [
[com.ibm.ws.eba.currencyService 1.0.0 ExchangeRate_ejb
com.ibm.ws.eba.ejb.ExchangeRate Local ejb/ExchangeRate]
[com.ibm.ws.eba.accountService 0.9.0 CustomerDetails_ejb
com.ibm.ws.eba.ejb.CustomerDetails Remote ejb/CustomerDetails]]
]')
- Map EJB references
For each EJB reference that is defined in either an ejb-jar.xml file, a web.xml file, or an @EJB annotation in the composition unit, you can specify the JNDI name by which the EJB reference is known in the runtime environment.
The Jython syntax for this aspect of the command is as follows.
AdminTask.editCompUnit('[
-blaID WebSphere:blaname=bla_name
-cuID WebSphere:cuname=cu_name
-EJBRefStep [
[bundle_symbolic_name_1 bundle_version_1 uri_1
ejb_reference_name_1 business_interface_1 jndi_name_1]
[bundle_symbolic_name_2 bundle_version_2 uri_2
ejb_reference_name_2 business_interface_2 jndi_name_2]]
]')
The uri parameter specifies the location where the EJB reference is defined.
In the following example, an EBA file contains two bundles, com.ibm.ws.eba.currencyService at version 1.0.0, and com.ibm.ws.eba.accountService at version 0.9.0. The currencyService bundle contains an EJB reference called ExchangeRate, from the CurrencyExchange enterprise bean, defined in META-INF/ejb-jar.xml, that is mapped to a JNDI name of ejb:ExchangeRate. The accountService bundle contains an EJB reference called CustomerDetails, defined in web.xml, that is mapped to a JNDI name of ejb:CustomerDetails.AdminTask.editCompUnit('[
-blaID WebSphere:blaname=financeService
-cuID WebSphere:cuname=com.ibm.ws.eba.financeService_0001.eba
-EJBRefStep [
[com.ibm.ws.eba.currencyService 1.0.0 META-INF/ejb-jar.xml/CurrencyExchange
ExchangeRate com.ibm.ws.eba.ejb.ExchangeRate ejb:ExchangeRate]
[com.ibm.ws.eba.accountService 0.9.0 WEB-INF/web.xml
CustomerDetails com.ibm.ws.eba.ejb.CustomerDetails ejb:CustomerDetails]]
]')
- Map EJB resource references to resources
Binding a resource reference maps a resource dependency of an enterprise bean to an actual resource available in the server runtime environment. At a minimum, you can be achieve this mapping by specifying the JNDI name under which the resource reference is known in the runtime environment. By default, the JNDI name is retrieved from pre-existing bindings, or set to the value of the mapped-name specified in the resource reference definition. Use this option to bind resources of type resource-ref (resource reference), as defined in the Java™ specification JSR-250: Common Annotations for the Java Platform.
The Jython syntax for this aspect of the command is as follows.
AdminTask.editCompUnit('[
-blaID WebSphere:blaname=bla_name
-cuID WebSphere:cuname=cu_name
-EJBResourceRefs [
[
bundle_symbolic_name
bundle_version
ejb_name
resource_reference_id
resource_type
target_jndi_name
resource_authentication_method
mapping_properties
extended_properties
]]
]')
The
mapping_properties parameter
defines arbitrary name and value pairs for extended data source properties,
in the following format (one continuous string):
WebSphere:name=property_name1,value=property_value1,description=property_description1
+WebSphere:name=property_name2,value=property_value2,description=property_description2
+ ...
The
extended_properties parameter
defines extended data source custom properties in the following format
(one continuous string):
property_name1=property_value1+property_name2=property_value2+ ...
For
example:
AdminTask.editCompUnit('[
-blaID WebSphere:blaname=financeService
-cuID WebSphere:cuname=com.ibm.ws.eba.financeService_0001.eba
-EJBResourceRefs [
[com.ibm.ws.eba.currencyService 1.0.0 ExchangeRate
dataSource1 javax.sql.DataSource ref/ds1 ClientContainer
"WebSphere:name=mprop1,value=val1,description=desc1"
"exprop1=expropval1+exprop2=expropval2"]
[com.ibm.ws.eba.accountService 0.9.0 CustomerDetails
dataSource2 javax.sql.DataSource ref/ds2 WSLogin "" ""]]
]')
- Bind EJB message destination references to administered objects.
Binding a message destination reference or resource environment reference maps a resource dependency of an enterprise bean to an actual resource available in the server runtime environment. At a minimum, you can achieve this mapping by specifying the JNDI name under which the message destination reference or resource environment reference is known in the runtime environment. By default, the JNDI name is retrieved from pre-existing bindings, or set to the value of the mapped-name specified in the message destination reference definition. Use this option to bind resources of type message-destination-ref (message destination reference) or resource-env-ref (resource environment reference), as defined in the Java specification JSR-250: Common Annotations for the Java Platform.
The Jython syntax for this aspect of the command is as follows.
AdminTask.editCompUnit('[
-blaID WebSphere:blaname=bla_name
-cuID WebSphere:cuname=cu_name
-EJBMsgDestRefs [
[
bundle_symbolic_name
bundle_version
ejb_name
resource_reference_id
resource_type
target_jndi_name
]]
]')
For example:
AdminTask.editCompUnit('[
-blaID WebSphere:blaname=financeService
-cuID WebSphere:cuname=com.ibm.ws.eba.financeService_0001.eba
-EJBMsgDestRefs [
[com.ibm.ws.eba.currencyService 1.0.0 ExchangeRate
jms/myQ javax.jms.Queue jms/workQ]
[com.ibm.ws.eba.accountService 0.9.0 CustomerDetails
jms/myT javax.jms.Topic jms/notificationTopic]]
]')
Map EJB environment entries. For each simple environment entry that is defined in either an env-entry element in an ejb-jar.xml file or in an @Resource annotation in the composition unit, you can specify the value of the environment entry.
The Jython syntax for this aspect of the command is as follows.
AdminTask.editCompUnit('[
-blaID WebSphere:blaname=bla_name
-cuID WebSphere:cuname=cu_name
-EJBEnvEntryStep [
[
bundle_symbolic_name
bundle_version
ejb_name
env_entry_name
env_entry_type
env_entry_description
env_entry_value
]]
]')
For example:
AdminTask.editCompUnit('[
-blaID WebSphere:blaname=financeService
-cuID WebSphere:cuname=com.ibm.ws.eba.financeService_0001.eba
-EJBEnvEntryStep [
[com.ibm.ws.eba.currencyService 1.0.0
ExchangeRate CommissionRate java.lang.Double
"Commission rate applied to currency exchange transactions." 5.75]]
]')
- Map virtual hosts for web modules.
You use a virtual host to associate a unique port with a web application. The aliases of a virtual host identify the port numbers defined for that virtual host. A port number specified in a virtual host alias is used in the URL that is used to access artifacts such as servlets and JavaServer Page (JSP) files in a web application. For example, the alias myhost:8080 is the host_name:port_number portion of the URL http://myhost:8080/sample.
Each WAB that is contained in a deployed asset must be mapped to a virtual host. WABs can be installed on the same virtual host, or dispersed among several virtual hosts.
If you specify an existing virtual host in the ibm-web-bnd.xml or .xmi file for a WAB, the specified virtual host is set by default. Otherwise, the default virtual host setting is default_host,
which provides several port numbers through its aliases:
- 80
- An internal, insecure port used when no port number is specified
- 9080
- An internal port
- 9443
- An external, secure port
Unless you want to isolate your WAB from other WABs or resources on the same node, default_host is a suitable virtual host. In addition to default_host, WebSphere® Application Server provides admin_host, which is the virtual host for the administrative console system application. admin_host is on port 9060. Its secure port is 9043. Do not select admin_host unless the WAB relates to system administration.
The Jython syntax for this aspect of the command is as follows.
AdminTask.editCompUnit('[
-blaID WebSphere:blaname=bla_name
-cuID WebSphere:cuname=cu_name
-VirtualHostMappingStep [
[bundle_symbolic_name_1 bundle_version_1
web_module_name_1 virtual_host_1]
[bundle_symbolic_name_2 bundle_version_2
web_module_name_2 virtual_host_2]]
]')
For example, for an EBA file containing two WABs (com.ibm.ws.eba.helloWorldService.web at version 1.0.0, which is to be mapped to default_host, and com.ibm.ws.eba.helloWorldService.withContextRoot at version 0.9.0, which is to be mapped to test_host), this aspect of the command is as follows:AdminTask.editCompUnit('[
-blaID WebSphere:blaname=helloWorldService
-cuID WebSphere:cuname=com.ibm.ws.eba.helloWorldService_0001.eba
-VirtualHostMappingStep [
[com.ibm.ws.eba.helloWorldService.web 1.0.0
"HelloWorld service" default_host]
[com.ibm.ws.eba.helloWorldService.withContextRoot 0.9.0
"HelloWorld second service" test_host]]
]')
- Map security roles to users or groups.
The Jython syntax for this aspect of the command is as follows:
AdminTask.editCompUnit('[
-blaID WebSphere:blaname=bla_name
-cuID WebSphere:cuname=cu_name
-MapRolesToUsersStep [
[role_name everyone?
all_authenticated_in_realm?
usernames groups]]
]')
Key: - role_name is a role name defined in the application.
- everyone? is set to Yes or No,
to specify whether everyone is in the role.
- all_authenticated_in_realm? is set to Yes or No,
to specify whether all authenticated users can access the application
realm.
- usernames is a list of WebSphere Application Server user names, separated
by the "|" character.
- groups is a list of WebSphere Application Server groups, separated
by the "|" character.
Note: For usernames, and groups, the empty string "" means "use the default or existing value". The default value is usually that no users or groups are bound to the role. However, when an application contains an ibm-application-bnd.xmi file, the default value for usernames is obtained from this file. If you are deploying an application that contains an ibm-application-bnd.xmi file, and you want to remove the bound users, specify just the "|" character (which is the separator for multiple user names). This setting explicitly specifies "no users", and therefore guarantees that no users are bound to the role.
For
example:
AdminTask.editCompUnit('[
-blaID WebSphere:blaname=helloWorldService
-cuID WebSphere:cuname=com.ibm.ws.eba.helloWorldService_0001.eba
-MapRolesToUsersStep [
[ROLE1 No Yes "" ""]
[ROLE2 No No WABTestUser1 ""]
[ROLE3 No No "" WABTestGroup1]
[ROLE4 Yes No "" ""]]
]')
For more information about the -MapRolesToUsersStep option, see the information for the $AdminApp install command "MapRolesToUsers" option. This is the equivalent option for Java EE applications. For more general information, see Security role to user or group mapping.
- Map RunAs roles to users
You can map a specified user identity and password to a RunAs role. This mapping enables you to specify application-specific privileges for individual users, so that they can run specific tasks using another user identity. The Jython syntax for this aspect of the command is as follows:
AdminTask.editCompUnit('[
-blaID WebSphere:blaname=bla_name
-cuID WebSphere:cuname=cu_name
-MapRunAsRolesToUsersStep [
[role_name user_name password]]
]')
For example:
AdminTask.editCompUnit('[
-blaID WebSphere:blaname=helloWorldService
-cuID WebSphere:cuname=com.ibm.ws.eba.helloWorldService_0001.eba
-MapRunAsRolesToUsersStep [
[Role1 User1 password1]
[AdminRole User3 password3]]
]')
For more information about the -MapRunAsRolesToUsers option, see the information for the $AdminApp install command "MapRunAsRolesToUsers" option. This is the equivalent option for Java EE applications. For more general information, see Map RunAs roles to users.
- Add authentication aliases to Blueprint resource references.
Blueprint components can access WebSphere Application Server resource references. Each reference is declared in a Blueprint XML file, and can be secured using a Java Platform, Enterprise Edition (Java EE) Connector Architecture (JCA) authentication alias. Each bundle in an OSGi application can contain any number of resource reference declarations in its various Blueprint XML files.
When you secure resource references, those resource references can be bound only to JCA authentication aliases that exist on every server or cluster on which the application is deployed. An OSGi application can be deployed to multiple servers and clusters that are in the same security domain. Therefore, each JCA authentication alias must exist in either the security domain of the target servers and clusters, or the global security domain.
You must declare the resource references
in the Blueprint XML file. For example:
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:rr="http://www.ibm.com/appserver/schemas/8.0/blueprint/resourcereference">
<!-- Other Blueprint declarations ... -->
<rr:resource-reference id="resourceRef"
interface="javax.sql.DataSource"
filter="(osgi.jndi.service.name=jdbc/Account)">
<rr:res-auth>Container</rr:res-auth>
<rr:res-sharing-scope>Shareable</rr:res-sharing-scope>
</rr:resource-reference>
</blueprint>
This declaration includes the resource
reference ID (for example
resourceRef), the service
filter (for example
jdbc/Account), the authentication
type (for example
Container), and the sharing setting
(for example
Shareable).
The Blueprint
resource references to authentication alias bindings for each bundle
are stored in a file
ibm-eba-bnd.xml in the
META-INF directory
of that bundle. If an OSGi application contains any of these files
when it is deployed as an asset, these files provide the default authentication
alias values that are used when binding the resource references. For
example:
<eba-bnd>
<resource-ref>
<jndi-name>jdbc/Acount</jndi-name>
<authentication-alias>Alias1</authentication-alias>
<interface>javax.sql.DataSource</interface>
<authentication>Container</authentication>
<sharing-scope>Shareable</sharing-scope>
<id>resourceRef</id>
</resource-ref>
</eba-bnd>
The Jython syntax for this aspect of the command is as follows.
AdminTask.editCompUnit('[
-blaID WebSphere:blaname=bla_name
-cuID WebSphere:cuname=cu_name
-BlueprintResourceRefPostDeployStep [
[
bundle_symbolic_name
bundle_version
blueprint_resource_reference_id
interface_name
jndi_name
authentication_type
sharing_setting
authentication_alias_name
]]
]')
Note: The value for jndi_name must match the JNDI name that you declare in the filter attribute of the resource reference element in the Blueprint XML file.
For example, for an EBA file that contains a bundle com.ibm.ws.eba.helloWorldService.properties.bundle.jar at Version 1.0.0, which is to be bound to authentication alias alias1, the command is as follows:AdminTask.editCompUnit('[
-blaID WebSphere:blaname=helloWorldService
-cuID WebSphere:cuname=com.ibm.ws.eba.helloWorldService_0001.eba
-BlueprintResourceRefPostDeployStep[
[com.ibm.ws.eba.helloWorldService.properties.bundle 1.0.0 resourceRef
javax.sql.DataSource jdbc/Account Container Shareable alias1]]
]')
- Bind web module message destination references to administered objects.
Binding a resource reference maps a resource dependency of the web application to an actual resource available in the server runtime environment. At a minimum, you can achieve this mapping by specifying the JNDI name under which the resource is known in the runtime environment. By default, the JNDI name is the resource ID that you specified in the web.xml file during development of the web application bundle (WAB). Use this option to bind resources of type message-destination-ref (message destination reference) or resource-env-ref (resource environment reference), as defined in the Java specification JSR-250: Common Annotations for the Java Platform.
The Jython syntax for this aspect of the command is as follows.
AdminTask.editCompUnit('[
-blaID WebSphere:blaname=bla_name
-cuID WebSphere:cuname=cu_name
-WebModuleMsgDestRefs [
[
bundle_symbolic_name
bundle_version
resource_reference_id
resource_type
target_jndi_name
]]
]')
For example:
AdminTask.editCompUnit('[
-blaID WebSphere:blaname=helloWorldService
-cuID WebSphere:cuname=com.ibm.ws.eba.helloWorldService_0001.eba
-WebModuleMsgDestRefs [
[com.ibm.ws.eba.helloWorldService.web 1.0.0
jms/myQ javax.jms.Queue jms/workQ]
[com.ibm.ws.eba.helloWorldService.web 1.0.0
jms/myT javax.jms.Topic jms/notificationTopic]]
]')
- Map web module resource references to resources.
Binding a resource reference maps a resource dependency of the web application to an actual resource available in the server runtime environment. At a minimum, you can achieve this mapping by specifying the JNDI name under which the resource is known in the runtime environment. By default, the JNDI name is the resource ID that you specified in the web.xml file during development of the web application bundle (WAB). Use this option to bind resources of type resource-ref (resource reference), as defined in the Java specification JSR-250: Common Annotations for the Java Platform.
The Jython syntax for this aspect of the command is as follows.
AdminTask.editCompUnit('[
-blaID WebSphere:blaname=bla_name
-cuID WebSphere:cuname=cu_name
-WebModuleResourceRefs [
[
bundle_symbolic_name
bundle_version
resource_reference_id
resource_type
target_jndi_name
login_configuration
login_properties
extended_properties
]]
]')
For example:
AdminTask.editCompUnit('[
-blaID WebSphere:blaname=helloWorldService
-cuID WebSphere:cuname=com.ibm.ws.eba.helloWorldService_0001.eba
-WebModuleResourceRefs [
[com.ibm.ws.eba.helloWorldService.web 1.0.0
jdbc/jtaDs javax.sql.DataSource
jdbc/helloDs "" "" ""]
[com.ibm.ws.eba.helloWorldService.web 1.0.0
jdbc/nonJtaDs javax.sql.DataSource
jdbc/helloDsNonJta "" "" "extprop1=extval1"]]
]')
Note: If you use multiple extended properties, the jython syntax is "extprop1=extval1,extprop2=extval2".
- Configure the HTTP session manager.
To configure the HTTP session manager, you use the AdminConfig commands to configure the deployed object represented by the appDeploy variable. Session management for OSGi applications is configured in the same way as for enterprise applications, except for a minor difference in syntax when getting the deployed object.
- Get the deployed object.
Use the instructions given in Configuring applications for session management using scripting. Note that, for enterprise applications, you use the following two line script:deployments = AdminConfig.getid('/Deployment:myApp/')
appDeploy = AdminConfig.showAttribute(deployments, 'deployedObject')
For OSGi applications, the equivalent script is the following single line:appDeploy = AdminTask.getOSGiApplicationDeployedObject('-cuName cu_name')
where
cu_name is
the name of the composition unit. For example:
appDeploy = AdminTask.getOSGiApplicationDeployedObject('
-cuName com.ibm.ws.eba.helloWorldService_0001.eba')
- Create or modify the session management options.
Use the instructions given in Configuring applications for session management using scripting. The
command usage for creating and modifying session management options
is exactly the same for enterprise applications and OSGi applications.
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.