IBM Support


Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.

APAR status

  • Closed as program error.

Error description

  • The same application works fine on After upgrading too, deploying the application will receive the following
    [10/4/19 7:59:16:927 CDT] 000000ed DeploymentUti E
    CNTR5104E: The abc method on the 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,,,
    or, EJB version 1.x or 2.x applications may fail to
    start with one of the following errors:
    CNTR5104E: The xxx method on the interface must
    be defined with the java.rmi.RemoteException exception on the
    throws clause.
    CNTR5102E: The application exception that is
    defined on the xxx method of the interface must
    not be defined as a subclass of the java.rmi.RemoteException
    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

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
    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
    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 and  For more information, see
    'Recommended Updates for WebSphere Application Server':

Temporary fix


APAR Information

  • APAR number


  • Reported component name


  • Reported component ID


  • Reported release


  • Status


  • PE




  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date


  • Closed date


  • Last modified date


  • 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


  • Fixed component ID


Applicable component levels

Document information

More support for: WebSphere Application Server

Software version: 850

Reference #: PH18256

Modified date: 13 January 2020