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

Fixes are available

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

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.0","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
04 May 2022

Tips

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

Fixes are available

Subscribe

APAR status

Closed as program error.

Error description

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

APAR Information

APAR number

Reported component name

Reported component ID

Reported release

Status

PE

HIPER

Special Attention

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

R700 PSY

R800 PSY

R850 PSY

R900 PSY

Document Information

Share your feedback

Need support?