IBM Support

PI68375: LOCAL EJB REFERENCES CREATED FROM ANNOTATIONS INCORRECTLY RESOLVED AS REMOTE REFERENCES.

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error description

  • The following exception appears in the logs for an application
    with EJB annotations:
    
    [28.06.16 11:53:44:450 CEST] 00000025 EJBInjectionB E
    CWNEN0030E: The
    com.ibm.ws.ejbcontainer.injection.factory.EJBLinkObjectFactory
    factory
    encountered a problem getting the object instance
    Reference:de.gfos.
    xtimeweb.lib.awkorejb.sessionbeans.interfaces.KorbelegInterfaceL
    ocal binding object.
    [28.06.16 11:53:44:816 CEST] 00000025 BusinessExcep E
    CNTR0019E: EJB
    threw an unexpected (non-declared) exception during invocation
    of
    method "getAllItems". Exception data: javax.ejb.EJBException:
    Use of ejb-ref for local
    
    CNTR0019E javax.ejb.EJBException: Use of ejb-ref for local
    

Local fix

  • N/A
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED:  All users of IBM WebSphere Application      *
    *                  Server with EJB applications containing     *
    *                  local EJB references which are resolved     *
    *                  as remote references in the                 *
    *                  ejb-jar_merged.xml file.                    *
    ****************************************************************
    * PROBLEM DESCRIPTION: Local EJB references might be           *
    *                      resolved as remote when the             *
    *                      application server merges annotation    *
    *                      metadata with XML metadata.             *
    ****************************************************************
    * RECOMMENDATION:  If correct EJB bindings are provided using  *
    *                  a bindings file (META-INF/ibm-ejb-bnd.xml,  *
    *                  for EJB JAR files; WEB-INF/ibm-ejb-bnd.xml  *
    *                  for WAR files which contain EJB content),   *
    *                  the EJB references will be correctly        *
    *                  resolved.                                   *
    *                  For information about EJB bindings refer to *
    *                  http://ibmurl.hursley.ibm.com/NUWJ          *
    ****************************************************************
    WebSphere Application Server processes Java EE annotations
    found in application class files for each module in the
    application.  It then merges this metadata with the module
    deployment descriptors to create "merged" descriptors. For EJB
    modules, the generated metadata is written to
    "META-INF/ejb-jar_merged.xml". For web modules with EJB
    content, the generated metadata is written to
    "WEB-INF/ejb-jar_merged.xml".
    The generated metadata can be marked as "metadata-complete"
    during deployment for each module. When this deployment
    option is used, the "merged" descriptor replaces the deployment
    descriptor. For an EJB module, the generated metadata
    is written back into the EJB deployment descriptor,
    "META-INF/ejb-jar.xml". For a WEB module, the generated EJB
    metadata is written back to "WEB-INF/ejb-jar.xml".
    Part of the generated module metadata is EJB reference
    information. This appears as "<ejb-ref>" and as
    "<ejb-local-ref>" elements in the generated file.  The problem
    is that local EJB references from annotations might be
    incorrectly written as <ejb-ref> elements instead of
    <ejb-local-ref> elements when the referenced EJB resides in
    another EJB module.
    The problem does not occur unless the option to mark modules
    as "metadata-complete" is used.  If "metadata-complete" is
    false in the module deployment descriptor, the EJB runtime
    container ignores the generated metadata, and uses data
    directly from the EJB classes.
    A problem occurs on a module which is marked at deployment
    time using the "metadata-complete" option. When this is done,
    the EJB reference information, which was generated incorrectly,
    is used by the EJB container. The result will be a failure of
    the EJB runtime container to access the EJB. The failure will
    be reported using an EJB exception, for example:
    [28.06.16 11:53:44:816 CEST] 00000025 BusinessExcep E
    CNTR0019E: EJB threw an unexpected (non-declared) exception
    during invocation of method "getAllItems". Exception data:
    javax.ejb.EJBException: Use of ejb-ref for local &#233; &#225;
    

Problem conclusion

  • Several methods are provided to resolve the problem.
    
    First, the problem can be avoided by specifying EJB bindings
    using bindings files.  This is the safest mechanism for
    resolving the problem and is the method recommended by
    IBM.  For more information refer to the IBM Knowledge Center:
    http://ibmurl.hursley.ibm.com/NUWJ.
    
    Second, the problem can be avoided by not setting the module
    as "metadata-complete" when deploying the application which
    encounters the problem.
    
    Third, the problem can be avoided by forcing the application
    server to always generate a local EJB reference when it cannot
    find an EJB; that is, when an EJB reference is unresolved.
    This option is not recommended if your application
    also references remote EJBs.
    
    To force unresolved EJB references to be generated as local EJB
    references for a single application, add the following
    attribute to the application manifest (META-INF/MANIFEST.MF):
    
    IBM-UNRESOLVED-EJB-REFS-ARE-LOCAL-PI68735: true
    
    To force unresolved EJB references to be generated as local EJB
    references for all applications on the server, set the
    following JVM custom property before deploying the application:
    
    org.eclipse.jst.j2ee.commonarchivecore.unresolvedEjbRefsAreLocal
    =true
    
    Setting the property in the application or in the server has
    an effect only during application deployment. An application
    which has already been deployed and which has incorrect EJB
    reference information will need to be redeployed after setting
    the property and restarting the server.
    
    Use caution: If your application uses remote EJBs, setting
    the property might cause the opposite problem.  That is,
    a remote EJB might be set as local in the
    ejb-jar_merged.xml.  For this reason, it is better to consider
    using bindings or not setting the module to metadata-complete
    instead of setting the property in the application or the
    server.  If you do use the property, it is recommended that
    you set the property in the specific application that exhibits
    the problem rather than at the server level.
    
    The fix for this APAR is currently targeted for inclusion in
    fix pack 7.0.0.43, 8.0.0.14, 8.5.5.12, 9.0.0.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 number

    PI68375

  • Reported component name

    WEBS APP SERV N

  • Reported component ID

    5724H8800

  • Reported release

    700

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2016-08-31

  • Closed date

    2017-01-31

  • Last modified date

    2017-01-31

  • 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

  • R700 PSY

       UP

  • R800 PSY

       UP

  • R850 PSY

       UP

  • R900 PSY

       UP



Document information

More support for: WebSphere Application Server
General

Software version: 7.0

Reference #: PI68375

Modified date: 31 January 2017