APAR status
Closed as documentation error.
Error description
This APAR describes the issues that customers encountered with IBM WebSphere Application Server Version 9.0.5. These issues were resolved as knowledge center updates in December 2019.
Local fix
N/A
Problem summary
**************************************************************** * USERS AFFECTED: This APAR provides a cumulative list of * * the documentation issues for December, * * 2019 and January 2020 * * that affect users of IBM WebSphere * * Application Server Version 9.0. * **************************************************************** * PROBLEM DESCRIPTION: The Knowledge Centers for WebSphere * * Application Server Version 9.0 need * * to reflect customer enhancement * * requests received in problem * * management records (PMRs). These * * enhancements can include fixing * * technical inaccuracies or clarifying * * vague information. * **************************************************************** * RECOMMENDATION: * **************************************************************** See the Problem conclusion section for a description of the issues, which are described in customer PMRs, and the documentation change or changes that will address these issues.
Problem conclusion
Note: As we update our knowledge centers, the following Version 9.0 modifications will be available. To access the latest on-line documentation, go to the product library page at https://www.ibm.com/support/knowledgecenter/en and select the version and product that is appropriate for your WebSphere Application Server environment. The following Version 9.0 issues will be addressed: ID: 1725 (GHE) Problem: Topic, Multiple components monitoring, for Liberty needs to indicate that you cannot filter JAX-WS counters as you do for the rest of the monitor-1.0 modules. This additional information will help users who are interested in JAX-WS counters in Liberty. Resolution: Topic, Multiple components monitoring, is updated with a NOTE at the end of step #1 that reads: IMPORTANT: You cannot filter JAX-WS counters as you do for the rest of the monitor-1.0 modules. JAX-WS metrics are implemented differently than the rest of the metrics and have no filter option. -------- ID: 1768 (GHE) Problem: Topic, Securing Liberty by using HTTP Strict Transport Security (HSTS), describes the ability to secure Liberty by adding STS response header for HTTPS requests, but does not provide instructions on how to accomplish this. The information is missing. Resolution: Topic, Securing Liberty by using HTTP Strict Transport Security (HSTS),is updated by adding to the Procedure section of the topic a third step to the procedure: Add STS response header for HTTPS requests that will link to URL: https://www.ibm.com/support/docview.wss?uid=swg1PI67099 - which provides the necessary instructions. --------- ID: 2767 (GHE) Problem: Topic, Object Request Broker custom properties, has a property, com.ibm.ws.orb.transport.SSLHandshakeTimeout, documented with a default of 0 (zero), but the default should be 10000 milliseconds. This needs updating. Resolution: Topic, Object Request Broker custom properties, is updated for property, com.ibm.ws.orb.transport.SSLHandshakeTimeout. The default is corrected to read 10000 milliseconds. This update also applies to the V8.5 level of the knowledge center. --------- ID: 2839 (GHE) Problem: The administrative console and the knowledge center topics that reference the admin console do not match in specific navigation. Topic, Configuring servlet caching, indicates a navigation on the admin console that points to an check box titled, Enable servlet caching. In the admin console the check box is titled, Enable servlet and command caching. The KC instructions should match what is viewable in the admin console. Resolution: Two topics are updated, (1) Configuring servlet caching, and (2) Web container settings, so that in each topic the navigated titled is: Enable servlet and command caching. This update also applies to the V8.5 level of the knowledge center. ----- ID: 2811 (GHE) Problem: Topic, Unshareable and shareable connections, has a note at the end of the Connection property requirements section that is out of date and doesn't explain in proper detail, unshareable and shareable connections. Resolution: Topic, Unshareable and shareable connections, is updated. The NOTE at the end of the Connection property requrements section is expanded and the NOTE now reads: Note Java Message Service (JMS) connections cannot be shared with non-JMS connections. JMS connections for the IBM ? ? MQ cannot be shareable because they are non-transactional, and the Java ? ? ? ? EE Connector Architecture. (JCA) specification allows only transactional resources to be shareable. If the res-sharing-scope is set to shareable in a JMS resource reference, the setting is ignored and unshareable connections are used. However, JMS sessions for IBM MQ are transactional, and can be shareable. JMS sessions are shareable by default. APAR PK59605 provides a mechanism to make JMS Sessions unshareable. Every JMS Connection maintains its own pool of sessions. Most applications create a JMS connection, followed by a JMS session. The JMS session is used for work. When the work is finished, the JMS session is closed. If the application needs to do more work, it creates a new JMS session, uses it and then closes it. When the application finishes, it closes the JMS connection. When a JMS application runs inside of WebSphere ? ? Application Server and calls Connection.createSession(), a session is created and is shareable by default. The JMS session that the application receives is taken from the session pool that is associated with the JMS Connection that used the method. The session, being shareable is automatically enlisted in any active transaction. After an application finishes with the session, it calls Session.close(). The session remains enlisted in the transaction and retains its shareable state. The session returns to the session pool when the transaction completes. There are instances in JMS session processing where the shareable state of these sessions can prolong the attachment of the session to the transaction. This prolonged attachment can lead to inefficiencies in managing the session pool and reduce transaction processing efficiency. You can use the session.sharing.scope custom property to make JMS sessions unshareable. For an unshareable JMS session, whenever an application calls Session.close() and if the JMS session's work is completed, then the JMS session is no longer associated with any transaction and is returned to the session pool as a free session. As a result, sessions can be cleaned up and removed from the session pool even if the application that created the session is still running. Refer to these sources for more details on the session.sharing.scope custom property. Configuring a queue connection factory for the WebSphere MQ messaging provider Configuring a topic connection factory for the WebSphere MQ messaging provider Configuring a unified connection factory for the WebSphere MQ messaging provider JMS connections for the Default Messaging Provider are different. With the Default Messaging Provider, connections can be shareable. Sessions, on the other hand, are not managed by a connection pool, and therefore cannot be shareable or unshareable. ----- ID: 2839 (GHE) Problem: Topic, Configuring servlet caching, and topic, Web container settings, do not accurately describe what is visible in the administrative console. Both topics need to specifically mirror what is seen in the administrative console. Resolution: Topic, Configuring servlet caching, step 2 of the procedure now reads: Select Enable servlet and command caching under the Configuration tab. For Topic, Web container settings, The section title, Enable servlet caching, has been changed to, Enable servlet and command caching. This update also applies to the V8.5 level of the knowledge center. ----- ID: #2949 (GHE) Problem: The knowledge center does not have enough specific requirements information about EJB 2.x and its applicability to the WebSphere Application Server Releases. Resolution: (1) V90 and V85 Topic, Developing EJB applications, is updated with the following NOTE: NOTE: (EJB) entity beans have been stabilized since WebSphere Application Server Version 7.0. There are no further enhancements to this technology, but this technology is still part of the product. Also, EJBDeploy has been deprecated in WebSphere Application Server version 8.5, and may be removed from the product in the future. EJBDeploy is no longer required for session beans, but is required for EJB 2.x and 1.x entity beans. If EJBDeploy is removed, it would still be available external to the product and entity beans would still be supported by the product. (2) V9.0 Topic,Developing EJB 2.x enterprise beans, is updated.The About this Task now reads: WebSphere Application Server supports the Java EE 7 specifications, which includes Enterprise JavaBeans (EJB) 3.2. The EJB 3.2 specification requires backward compatibility support for the EJB 2.x API group, except for some optional features which includes support of entity beans. WebSphere Application Server continues to support the EJB 2.X APIs, including the optional features, and remains compliant with the Java EE 7 specifications. Use the steps in this task to develop EJB 2.X enterprise beans. V855 topic, Developing EJB 2.x enterprise beans, is updated. The About this task now reads: WebSphere Application Server supports the Java EE 6 specifications, which includes Enterprise JavaBeans (EJB) 3.1. The EJB 3.1 specification requires backward compatibility support for the EJB 2.x API group. WebSphere Application Server continues to support the EJB 2.X APIs and remains compliant with the Java EE 6 specifications. Use the steps in this task to develop EJB 2.X enterprise beans. (3)V85 Topic, Specifications and API documentation, is updated. Table 5: Enterprise bean (EJB) applications is updated in the Enterprise JavaBeans(EJB) to read: Specification or API (*) Enterprise JavaBeans (EJB) specificationBased on the Enterprise JavaBeans (EJB) specification, enterprise beans are Java components that typically implement the business logic of Java 2 Platform, Enterprise Edition (J2EE) applications as well as access data. Enterprise JavaBeans (EJB) specifications for a given release require support of all prior API levels. (EJB) entity beans have been stabilized since WebSphere Application Server Version 7.0. There are no further enhancements to this technology, but this technology is still part of the product. EJBDeploy has been deprecated in WebSphere Application Server version 8.5, and may be removed from the product in the future. EJBDeploy is no longer required for session beans, but is required for EJB 2.x and 1.x entity beans. If EJBDeploy is removed, it would still be available external to the product and entity beans would still be supported by the product. Version 8.5 EJB 3.1 (*) Verions 8.0 EJB 3.1 New (*) Version 7.0 EJB 3.0 (*) Version 6.1 EJB 3.0 New for Feature Pack for EJB 3.0 (*) Version 6.0 EJB 2.1 New (*) EJB 2.0 (*) EJB 1.1 (*) These updates also apply to the V8.5 level of the knowledge center. ------
Temporary fix
Comments
APAR Information
APAR number
PH19696
Reported component name
WEBSPHERE APP S
Reported component ID
5724J0800
Reported release
900
Status
CLOSED DOC
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2019-12-02
Closed date
2020-01-08
Last modified date
2022-06-06
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Applicable component levels
[{"Line of Business":{"code":"LOB45","label":"Automation"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"9.0"}]
Document Information
Modified date:
07 June 2022