PQ58584: A CALL TO THE REFLECT API GETFIELD RESULTS IN A NOSUCHFIELDEXCEPTION

 Fixes are available

PQ63130; 4.0.2,4.0.3,4.0.4: Transaction context changes to tx_not_supported
EJB Container; 4.0.2-4.0.7: Component Cumulative fix for EJB Container



APAR status
Closed as program error.

Error description
On some platforms, a problem has been found where a call to the
reflection api getField(name) results in a NoSuchFieldException
even though the field does exist.  This may be an intermittent
problem which will be seen when installing an application with
an Entity Bean with Container Managed Peristence fields.
Local fix Problem summary
****************************************************************
* USERS AFFECTED: WebSphere Application Server users of        *
*                 Entity Beans with container managed          *
*                 persistance on Solaris machines.             *
****************************************************************
* PROBLEM DESCRIPTION: ContainerException occurs when starting *
*                      an application in a server process,     *
*                      with message: CNTR0035E: EJB container  *
*                      caught java.lang.NoSuchFieldException   *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
ContainerException occurs when starting an application in a
server process, with message: CNTR0035E: EJB container
caught java.lang.NoSuchFieldException.

This would occur either when starting an application in a
server process, or starting a server process, which may
also start an application.  Ths stack of the exception in
a trace would look similar to this:

at java.lang.Class.getField0(Native Method)
at java.lang.Class.getField(Class.java:826)
at com.ibm.ejs.container.BeanMetaData.completeInitialization
                                       (BeanMetaData.java:778)
at com.ibm.ejs.container.EJSContainer.loadBeanMetaData
                                       (EJSContainer.java:828)
at com.ibm.ejs.container.EJSContainer.getHomeInstance
                                       (EJSContainer.java:565)
at com.ibm.ejs.container.EJSContainer.startBean
                                       (EJSContainer.java:529)
at com.ibm.ws.runtime.BeanHelper.startBean
                                         (BeanHelper.java:154)

Note that the failure occurs when calling the getField()
reflection api.
Problem conclusion
There is some type of initialization or multi-threaded
problem in the JDK used on Solaris machines, such that
the getField() reflections api does not always work
correctly.

To work around this, a change has been made in WebSphere
to catch the exception and retry the reflection api
call to getField().

Currently, this does resolve the problem.
Temporary fix
eFix PQ58584_eFix.jar has been provided to the customer for
testing.
Comments
APAR information
APAR number PQ58584
Reported component name WEBSPHERE AE NT
Reported component ID 5630A2201
Reported release 400
Status CLOSED PER
PE NoPE
HIPER NoHIPER
Submitted date 2002-03-01
Closed date 2002-03-27
Last modified date 2002-03-27

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Modules/Macros
EJBCONTR          

SRLS

Fix information
Fixed component name WEBSPHERE AE NT
Fixed component ID 5630A2201

Applicable component levels
R400 PSY    UP


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > General
Operating system(s):
Software version: 400
Software edition:
Reference #: PQ58584
IBM Group: Software Group
Modified date: Mar 27, 2002