PH18256: CNTR5104E RECEIVED WHEN DEPLOYING EJB APPLICATION

PH18256: CNTR5104E received when deploying EJB application
8.5.5.17: WebSphere Application Server V8.5.5 Fix Pack 17
9.0.5.3: WebSphere Application Server traditional Version 9.0.5 Fix Pack 3

APAR status

• Closed as program error.

Error description

• The same application works fine on 8.5.5.14. After upgrading too
  8.5.5.16, deploying the application will receive the following
  error:
  
  [10/4/19 7:59:16:927 CDT] 000000ed DeploymentUti E
  CNTR5104E: The abc method on the xxx.xxx.xxx.xxx.xxxx interface
  must be defined with the java.rmi.RemoteException exception on
  the throws clause.
  

Local fix

• N/A
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:  All users of IBM WebSphere Application      *
  *                  Server with EJB 1.x or 2.x applications     *
  ****************************************************************
  * PROBLEM DESCRIPTION: CNTR5104E or CNTR5102E occurs           *
  *                      starting EJB 1.x or 2.x application     *
  *                      after upgrading WebSphere version       *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  After upgrading to WebSphere version 8.5.5.16, 9.0.5.0,
  9.0.5.1, or 9.0.5.2, EJB version 1.x or 2.x applications may
  fail to start with one of the following errors:
  CNTR5104E: The xxx method on the xxx.xxx.xxxxx interface must
  be defined with the java.rmi.RemoteException exception on the
  throws clause.
  CNTR5102E: The xxx.xxx.yyyyy application exception that is
  defined on the xxx method of the xxx.xxx.xxxxx interface must
  not be defined as a subclass of the java.rmi.RemoteException
  exception.
  A new feature was added in WebSphere v8.5.5.16 and v9.0.5.0
  that allows older EJB modules to be just-in-time deployed,
  removing the requirement to use EJBDeploy when Entity beans are
  not present.  The new support should only take effect when
  EJBDeploy has not been used to generate EJB artifacts.
  Unfortunately, the enhancement does not correctly identify
  EJBDeploy generated artifacts when an older level of EJBDeploy
  has been used, and attempts to dynamically generate the EJB
  artifacts. This would normally work fine, except the new
  just-in-time deployment support has more restrictive checking
  to ensure applications comply with the EJB specification. The
  result is that the just-in-time deployment feature may identify
  an application as not complying with the specification and
  prevent it from starting, where EJBDeploy allowed the
  application to start and work properly. In some cases, the
  application may comply with the specification, but the checking
  is incorrect.
  Typically the above failure occurs when a version of EJBDeploy
  prior to WebSphere version 7.0 has been used, or a version
  from an older level of Rational Application Developer for
  WebSphere.
  

Problem conclusion

• The EJB container in WebSphere Application Server has been
  updated to allow previously working applications to continue
  working. There are two parts to this update:
  
  1 - checking for EJBDeploy generated artifacts has been improved
  to identify artifacts generated by older levels of EJBDeploy.
  This will avoid any application validation performed by the new
  just-in-time deployment support.
  
  2 - the application validation performed by the new
  just-in-time deployment support has been both corrected and
  relaxed to support the same applications as supported by
  EJBDeploy.
  
  EJB remote interfaces that extend java.rmi.Remote that contain
  methods that throw a superclass of RemoteException would have
  previously resulted in CNTR5104E, but will now be correctly
  identified as compliant with the specification and start
  properly.
  
  EJB interfaces that throw subclasses of java.rmi.RemoteException
  are not compliant with the specification, but the checking has
  been changed to allow this behavior. The new just-in-time
  deployment support will ignore such exceptions in the same way
  they are ignored by EJBDeploy.
  
  Note that deploying with a newer version of EJBDeploy should
  workaround the problem, but applying the iFix for PH18256 will
  correct the behavior.
  
  Use of a system property is not required to activate.
  Installing the iFix will correct the behavior.
  
  The fix for this APAR is targeted for inclusion in fix packs
  8.5.5.17 and 9.0.5.3.  For more information, see
  'Recommended Updates for WebSphere Application Server':
  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

• R900 PSY

     UP