PI83886: CORRECTIONS ARE NEEDED TO THE DOCUMENTATION IN THE KNOWLEDGE CENTER FOR IBM WEBSPHERE APPLICATION SERVER VERSION 9.0

APAR status

• Closed as documentation error.

Error description

• This APAR describes the issues that customers encountered with
  IBM WebSphere Application Server Version 9.0.  These issues were
  resolved as knowledge center updates in July, 2017.
  

Local fix

• N/A
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:  This APAR provides a cumulative list of     *
  *                  the documentation issues for month_year     *
  *                  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: We update our knowledge centers monthly. The following
  Version 9.0 modifications will be available in the
  July, 2017 update to the Knowledge Centers. To access the
  latest on-line documentation, go to the product library page at
  http://www.ibm.com/software/webservers/appserv/library 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: PI83886 and 784823
  
  Problem: The directive SSLSNIMap in topic, SSL directives, is
  only available in HTTP Server V9.0 and with using Apache 2.4.
  HTTP Server V8.5 uses Apache 2.2, but the V8.5 level of this
  topic documents the ability to use this directive. The
  customer on HTTP Server V8.5 tried to use SSLSNIMap and got an
  error and wondered why.....after reading the knowledge center
  topic. The V8.5 level of the topic is in error in documenting
  SSLSNIMap and the description needs to be removed (V8.5 only
  update).
  
  Resolution: V8.5 Topic, SSL directives, is update to remove
  the description of SSLSNIMap.  The V9.0 level of the topic
  remains unchanged.
  
  ----------
  
  ID: 244243 (RTC)
  Problem: Two problems arise for users in WebSphere Application
  Server traditional who are using Liberty.
  1)In configuring data base session persistence, users want to
  apply the server.xml to some EAR/WAR files and not to others.
  This is not possible for Liberty and should be documented as a
  restriction.
  2) WebSphere Application Server traditional locally
  transacted JMS sessions are do not operate properly in
  Liberty.  Porting these applications in hopes of operating
  them as locally transacted JMS sessions is not allowed in
  Liberty.  This restriction needs to be documented.
  
  Resolution:
  1) Topic, Liberty:Runtime environment known issues and
  restrictions, is update for problem (1).  A new restriction is
  added to read as follows:
  Configuring session persistence
  There is only one server.xml file per server (NOT a server.xml
  for each EAR/WAR file). You set
  session persistence in a database by adding
  the following:
  
  <httpSessionDatabase id="SessionDB" dataSourceRef="SessionDS"
  ... />
  
  In Liberty, this setting for the database applies to ALL
  EAR/WAR files. It is not possible to set up some databases
  with session persistence and others without.
  
  (2) Topic, Liberty:Runtime environment known issues and
  restrictions, is update for problem (2).  A new restriction is
  added to read as follows:
  Ported locally transacted JMS sessions do not work in Liberty
  In WebSphere Application Server traditional, you could develop
  applications to take advantage of locally transacted JMS
  sessions. When you port these applications to Liberty, these
  application will no longer work (or at least, will behave
  differently).
  
  Even though WebSphere Application Server traditional allows
  locally transacted JMS sessions, porting a WebSphere
  Application Server traditional locally transacted JMS session
  to Liberty is not allowed.
  
  These updates also apply to V8.5 of the knowledge center.
  -------------
  
  ID: 244244 (RTC)
  Problem: Two topics in the knowledge center refer to using the
  v8.5.0.jar file when they should indicate the ... v9.0.jar file.
  This would confuse the user and mislead.   These topics need
  correction.
  
  Resolution:
  Topic, Running an unmanaged web services JAX-RPC client,
  and
  Topic, Running an unmanaged web services JAX-WS client
  are updated
  
  References to the ......V8.5.0.jar are replaced with
  references to the .....v9.0.jar
  
  ----------------
  ID: 244245 (RTC)
  Problem: There is need to clarify the reason of the difference
  between tWAS and Liberty with respect to this condition:
  If there are many servlet login users and they use a same JMS
  connection pool, frequent connection destroy and creation
  happens because login user A can't re-use the connection
  generated by user B because of the subject missmatch. The
  customer is thinking this behavior is not so good from
  performance perspective.
  
  Resolution: Topic, Liberty:Runtime environment known issues
  and restrictions, is updated by adding the following general
  restriction:
  Liberty's use of WebSphere MQ messaging
  When Liberty is using WebSphere MQ as a messaging
  provider, the reuse criteria in free connection of JMS
  connection pool is different from the reuse criteria in
  WebSphere Application Server traditional. If a JMS application
  uses container authentication for a connection factory and
  several authenticated users use the same connection pool,
  the reuse rate of WebSphere Liberty is much less than the
  reuse rate of WebSphere Application Server traditional.
  Liberty reuse rate is less because the free connection created
  by an authenticated user cannot be reused by other
  authenticated users in the Liberty and can result in
  frequent connection regeneration.   Should this Liberty
  behavior be unacceptable as a strict performance requirement,
  you can use  application authentication with username and
  password properties of properties.wmqJms.
  
  This update also applies to the V8.5 knowledge center.
  ---------
  
  ID: 244302 (RTC)
  Problem: Topic, Configuring relational database connectivity
  in Liberty, is missing configuration information for the data
  source that is associated with the Oracle Call Interface
  (OCI) JDBC provider.
  
  Resolution: Topic, Configuring relational database connectivity
  in Liberty, is updated with the Oracle Call Interface
  (OCI) JDBC provider connectivity information.  The connection
  information is updated in the topic as follows:
  For Oracle Call Interface (OCI)
      <code>
      <dataSource id="DefaultDataSource"
  jndiName="jdbc/oracleOCI">
        <jdbcDriver libraryRef="OracleOciLib"/>
        <properties.oracle
      URL="jdbc:oracle:oci:@//localhost:1521/SAMPLEDB"/>
      </dataSource>
      <library id="OracleOciLib">
        <fileset dir="C:/Oracle/OCI/instantclient"/>
      </library>
      </code>
  Configure the Liberty environment to recognize the OCI
  native client libraries by setting the path to the libraries -
  in the Liberty server.env file on the path environment
  variable for your operating system.
  ----
  
  ID: 245988 (RTC)
  Problem: Topic, JSP engine, indicates that WebSphere
  Application Server Version 9.0 supports the JSP 2.1
  specification, but this is inaccurate.  Version 9.0 supports
  JSP 2.3 specification.  This is causing confusion to users.
  
  Resolution: Topic, JSP engine, is update.  The second sentence
  in the topic now reads:
  WebSphere Application Server Version 9.0 supports the JSP 2.3
  specification.
  
  ----
  
  ID: 244075 (RTC)
  Problem: Topic, [9.0.0.1 or later]
  Discovering REST API documentation, has an example (step 1.a)
  that is in error.  The example has singe quotes, but you must
  use double quotes and a step 4, second bullet, a. in the
  procedure is containing a typo.  Users can produce system
  errors because of this.
  
  Resolution: Topic, [9.0.0.1 or later]
  Discovering REST API documentation, is updated as follows:
  (1) Step 1.a  is updated to read as follows:
  Run the deploySwaggerUI script to install Swagger applications
  onto a target.
  
  wsadmin -user user_name -password user_password -f
  deploySwaggerUI.py
  install "WebSphere:cell=cell01,node=node01,server=server1"
  
  (2) Step 4, second bullet, part a. now reads:
  Open your browser and navigate to
  https://host:https_port/ibm/api/explorer.
  
  ------
  ID: 244245 (RTC)
  Problem: Topic,
  Liberty:Runtime environment known issues and restrictions,
  needs another new issue item about  Liberty's use of WebSphere
  MQ messaging.  There is confusion between how WebSphere
  Application Server traditional and Liberty performs MQ
  messaging.
  Resolution: Topic,
  Liberty:Runtime environment known issues and restrictions,
  is updated to read:
  Title: Liberty's use of WebSphere MQ messaging
  
  Description:
  When Liberty is using WebSphere MQ as a messaging
  provider, the reuse criteria in free connection of JMS
  connection pool is different from the reuse criteria in
  WebSphere Application Server traditional. If a JMS application
  uses container authentication for a connection factory and
  several authenticated users use the same connection pool, the
  reuse rate of WebSphere Liberty is much less than the reuse
  rate of WebSphere Application Server traditional. Liberty reuse
  rate is less because the free connection created by an
  authenticated user cannot be reused by other authenticated
  users in the Liberty and can result in frequent connection
  regeneration.   Should this Liberty behavior be unacceptable
  as a strict performance requirement, you can use application
  authentication with username and password properties of
  properties.wmqJms.
  
  -------
  

Temporary fix

Comments

APAR Information

• 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