PI18432: APPLICATION UPDATE RESULTS IN LOST BINDINGS

8.5.5.4: WebSphere Application Server V8.5.5 Fix Pack 4
8.5.5.5: WebSphere Application Server V8.5.5 Fix Pack 5
8.5.5.6: WebSphere Application Server V8.5.5 Fix Pack 6
8.5.5.7: WebSphere Application Server V8.5.5 Fix Pack 7
8.5.5.8: WebSphere Application Server V8.5.5 Fix Pack 8
8.5.5.9: WebSphere Application Server V8.5.5 Fix Pack 9
8.5.5.10: WebSphere Application Server V8.5.5 Fix Pack 10
8.5.5.11: WebSphere Application Server V8.5.5 Fix Pack 11
8.5.5.12: WebSphere Application Server V8.5.5 Fix Pack 12
8.5.5.13: WebSphere Application Server V8.5.5 Fix Pack 13
8.5.5.14: WebSphere Application Server V8.5.5 Fix Pack 14
8.5.5.15: WebSphere Application Server V8.5.5 Fix Pack 15
8.5.5.14: WebSphere Application Server V8.5.5 Fix Pack 14
8.5.5.17: WebSphere Application Server V8.5.5 Fix Pack 17
8.5.5.20: WebSphere Application Server V8.5.5.20
8.5.5.18: WebSphere Application Server V8.5.5 Fix Pack 18
8.5.5.19: WebSphere Application Server V8.5.5 Fix Pack 19
8.5.5.16: WebSphere Application Server V8.5.5 Fix Pack 16
8.5.5.21: WebSphere Application Server V8.5.5.21

APAR status

• Closed as program error.

Error description

• When updating an application with the 'use existing bindings'
  option, the previously configured JNDI names for the EJB
  references get erased.
  
  The error after the update seems to be caused by the update
  process overlaying the ejb-jar_merged.xml that was generated
  during the original deployment with the original one from the
  .ear.
  
  On the initial deploy the archive is opened with the flag set
  to invalidate the EJB deployment descriptor. This will result
  in ignoring the existing ejb-jar_merged.xml in the application
  and doing an annotation scan/merge instead. Then the Archive is
  saved in the temp workarea and deployed.
  
  During the application update, the invalidate flag is never
  set so we will always reload the existing ejb-jar_merged.xml.
  So in the updated case when the Archive is saved, it is saved
  with the old merged deployment descriptor and then the deploy
  process installs this merged deployment descriptor.
  

Local fix

• The customer can circumvent the problem by removing any
  *_merged.xml files from the EAR before deploying and updating.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:  All users of IBM WebSphere Application      *
  *                  Server version 8.5.5                        *
  ****************************************************************
  * PROBLEM DESCRIPTION: When updating an application that       *
  *                      contains the completed deployment       *
  *                      descriptor created from the initial     *
  *                      application deployment, the             *
  *                      annotation scanning was not performed   *
  *                      during an update.                       *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  When updating an application that contains the completed
  deployment descriptor created from the initial application
  deployment, the annotation scanning was not performed during
  an update.
  

Problem conclusion

• The logic to determine whether to read the completed
  deployment descriptor or perform annotation scanning has been
  corrected.
  
  The fix for this APAR is currently targeted for inclusion in
  fixpack 8.5.5.4. Please refer to the Recommended Updates page
  for delivery information:
  http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
  

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

• Fixed component name

  WEBS APP SERV N

• Fixed component ID

  5724H8800

Applicable component levels

• R850 PSY

     UP