When you upgrade the application server to a newer version, be aware of the following settings that you might want to change.
In the WebSphere® Application Server Version 7 Feature Pack for OSGi Applications and Java Persistence API 2.0, bundle changes to the asset are applied by restarting the business-level application. In Version 8, these changes are applied by updating the composition unit. The new approach in Version 8 means that many bundle changes can be applied in place, without restarting the running business-level application. To enable this new approach, the UpdateAppContentVersionsStep parameter has been replaced with the UpdateAppContentVersions parameter, and instead of restarting the business-level application you run the editCompUnit command with the CompUnitStatusStep parameter.
JAX-WS dynamic ports, which are those added using the service method addPort, might have additional memory requirements starting in WebSphere Application Server Version 8.0. In previous releases, a single instance of a dynamic port could be shared across multiple service instances. In version 8, dynamic ports are now scoped to the instance of the service that added them. If a JAX-WS client has multiple service instances which refer to a dynamic port of the same name, those instances are no longer shared. This can potentially increase the memory requirements for that client. The memory used by dynamic ports is released when the service instance goes out of scope. However, if you encounter issues related to increased memory usage, it is possible to revert the behavior so that dynamic ports are again shared across service instances. To do this, set the system property jaxws.share.dynamic.ports.enable to the value true. However, note that doing so can cause some other issues, such as having policy set attachments incorrectly applied across shared dynamic ports. If you set this flag to true and encounter some of these issues, then you should remove the flag setting.
In previous releases, if a SOAP Action was not provided by the Dispatch client application, the correct SOAP Action was not sent on the outbound message. Instead, the SOAP action was set to an anonymous operation. Starting in WebSphere Application Server Version 8, if the SOAP Action is not provided by the Dispatch client application, the JAX-WS runtime environment parses the outgoing message. It determines the operation being invoked and uses that information to determine the appropriate value for the SOAP Action. The operation resolution of the outbound message is based on the SOAP Body and the message encoding, for example, Doc/Lit/Bare, Doc/Lit/Wrapped. Since this parsing can be expensive, a property can be set. To always disable the parsing, set the property at the System level. To disable parsing on a per-message basis, set the property on the JAX-WS Request Message Context. The property is defined as a constant org.apache.axis2.jaxws.Constants.DISPATCH_CLIENT_OUTBOUND_RESOLUTION with a String value of jaxws.dispatch.outbound.operation.resolution.enable. The default value of the property is null which is interpreted as the String true, which enables the outbound operation resolution. Setting the property to false disables the outbound operation resolution. If parsing is disabled, then the SOAP Action in the outbound message is set to an anonymous operation as in previous releases. If the client provides a SOAP Action through the JAX-WS javax.xml.ws.BindingProvider properties, SOAPACTION_USE_PROPERTY and SOAPACTION_URI_PROPERTY, then that SOAP Action is used. Therefore, parsing of the outbound message does not occur regardless of the setting of the property. Setting a SOAP Action explicitly by the client is considered a best practice, particularly for performance on the service-provider. This practice prevents the inbound message from being parsed, to be routed to the correct endpoint operation.
To specify user-defined bindings information for EJB 3.x modules, place the file ibm-ejb-jar-bnd.xml, in the META-INF directory for the EJB Java archive (JAR) file. The suffix on this file is XML, not XMI, as in prior versions of product.
The enableEndToEndMonitoringFeature custom property is deprecated in the WebSphere Application Server V7.0.0.1 environment, because PEEI feature is enabled by default. PEEI can be controlled by the disableEndToEndClientMonitoringFeature custom property, which has a default of false. If you use the enableEndToEndMonitoringFeature custom property, Application Server will issue an OBSOLETE_PROPERTY_SPECIFIED warning.
In WebSphere Application Server Version 7.0 Fix Pack 7 and later releases, the WS-Security runtime environment takes a SAML token Issuer name to represent the foreign security realm name. WS-Security takes the NameID element in the case of SAML 2.0 security tokens or the NameIdentifier element in the case of SAML 1.1 security tokens to represent user security name. Alternatively, you can explicitly specify which SAML token attribute to use to represent user security name. Moreover, you can also specify which SAML token attribute to use to represent user group membership. Read about SAML assertions across WebSphere Application Server security domains for a detailed discussion of the SAML token assertion trust model and binding configuration.
Version 8.x can propagate the contents of com.ibm.websphere.security.cred.WSCredential in a SAML token. You must set a tokenRequest custom property with an issueByWSCredential property value in the WS-Security binding configuration of the web services client. Read about propagating SAML tokens for a detailed description of this binding option. When the crossDomainIdAssertion property is set to true in Version 8, WS-Security checks whether a SAML token contains a SAML Attribute UniqueSecurityName with a NameFormat element with a value of com.ibm.websphere.security.cred.WSCredential. If found, WS-Security uses the NameQualifier attribute value of the NameID element or NameIdentifier element to represent the user security realm name. WS-Security also uses the UniqueSecurityName attribute value and the GroupIds attribute value to represent a unique user name and group membership. This default behavior is different between Version 7 and Version 8 of the product. You can add a CallbackHandler property, IssuerNameForRealm, and set its value to true to configure Version 8 to preserve the Version 7 behavior. Alternatively, you can add a CallbackHandler property, NameQualifierForRealm, and set its value to true to configure Version 8 to always use the NameQualifier attribute to represent the user security realm name.
Starting with WebSphere Application Server Version 7.0 and later, Java EE 5 application modules (web application modules version 2.5 or above, or EJB modules version 3.0 or above) are scanned for annotations to identify JAX-WS services and clients. However, pre-Java EE 5 application modules (web application modules version 2.4 or before, or EJB modules version 2.1 or before) are not scanned for JAX-WS annotations, by default, for performance considerations. In the Version 6.1 Feature Pack for Web Services, the default behavior is to scan pre-Java EE 5 web application modules to identify JAX-WS services and to scan pre-Java EE 5 web application modules and EJB modules for service clients during application installation. Because the default behavior for WebSphere Application Server Version 7.0 and later is to not scan pre-Java EE 5 modules for annotations during application installation or server startup, to preserve backward compatability with the feature pack from previous releases, you must configure either the UseWSFEP61ScanPolicy property in the META-INF/MANIFEST.MF of a web application archive (WAR) file or EJB module or define the Java virtual machine custom property, com.ibm.websphere.webservices.UseWSFEP61ScanPolicy, on servers to request scanning during application installation and server startup. To learn more about annotations scanning, see the JAX-WS annotations information.
The default JavaServer Faces implementation is now MyFaces 2.0, which provides full compliance with the updated JSF 2.0 specification.
To ensure the most successful migration, the return type of the StoredResponse getHeaderNames method was changed to com.ibm.websphere.servlet.response.CollectionEnumerationHybrid<String>. This type implements both Collection<String> and Enumeration.
When a SIP application sends a request to a SIP URI over Transport Layer Security (TLS) in version 6.1, the request URI scheme changes from "sip" to "sips." In version 7.0, the scheme does not change. You can reverse the new behavior in version 7.0 by changing the application code. With a "sips" URI, the behavior remains the same after upgrading from version 6.1 to 7.0. See the information center topic Premigration considerations for more information.
Import-Package: commonj.sdo;version="[2.0.0,3.0.0)"
yourLtpaAuthSecHandler.setSSLRequired(false);
secHandler.setSSLRequired(false);
In WebSphere Application Server Version 7.0.0.7 and later, to use the SAML default policy sets, sample SAML general bindings, and JAAS login configuration settings for SAML, you were required to set up the SAML configuration, which is stored in a profile. In WebSphere Application Server Version 8.0, the SAML feature is available in all profiles by default.
Starting in WebSphere Application Server Version 8, the SOAPMessage.getSOAPHeader and getSOAPBody methods now throw a SOAPException if there is no corresponding element in the message. A System property is provided to revert the behavior to return null rather than throw an exception. The property is defined in com.ibm.websphere.webservices.soap.IBMSOAPMessage.ENABLE_LEGACY_GETSOAP_BEHAVIOR as a String value of com.ibm.websphere.webservices.soap.enable.legacy.get.behavior. The default value of the property is null which is interpreted as false. To revert the behavior to returning a null, set the property to the String value true. The previous behavior of returning null is not compliant with the specification.
Existing JAX-RPC applications wanting to use JAX-WS features must be rewritten using the JAX-WS programming model.