APAR status |
Closed as program error.
| Error description
Users may experience org.omg.CORBA.MARSHAL exceptions. Note,
that these exceptions are sometimes masked by other exceptions
in WAS or users application code. And these errors are sometimes
hard to identify.
This is why we strongly recommended taht e-fixes are applied as
soon as possible to avoid future inter-op issues. Also, users
may experience this problem even after efixes have been applied,
if users have saved off their IORs. If this is the case, users
full effect.
Here are some of the Inter-op problems we have found when
passing embedded valueTypes between WAS releases.
WAS35x => WAS357 or WAS404 or higher
WAS40x => WAS357 or WAS404 or higher Local fixProblem summary
****************************************************************
* USERS AFFECTED: All WebSphere Application Server users who *
* pass embedded valueType between WebSphere *
* releases. *
****************************************************************
* PROBLEM DESCRIPTION: Inter-op problem found when passing *
* embedded valueTypes between WAS *
* releases. *
****************************************************************
* RECOMMENDATION: *
****************************************************************
User may experience org.omg.CORBA.MARSHAL exceptions. Note,
that these exceptions are sometimes masked by other exceptions
in WAS or user application code. Errors are sometimes hard
to identify.
It is strongly recommended that efixes are applied as soon
as possible to avoid future inter-op issues. The user
may experience this problem even after efixes have been
applied, if user has saved off his IORs. If this is the case,
the user needs to re-export those IORs for the efixes to take
their full effect.
Known affected combinations
WAS35x ==> WAS356+ or WAS403+ or higher releases
WAS40x ==> WAS356+ or WAS403+ or higher releases
**************** Problem conclusion
The problem is happening because the IOR's created by the 4.02
Websphere ORB do not contain an IBM_PARTNER_VERSION tag
component, whereas those created by the base JDK ORB do.
Hursley defect 27426 introduced this change into the base ORB
com.ibm.rmi.IOR class.
The problem occurs because the 1.3.1 ORB in the development
release contains a Connectathon fix to generate correctly
nested valuetype end-tag values when talking to non-IBM ORBs
or to IBM ORBs that contain a corresonding fix. When talking
to a back level IBM ORB (such as the one in 4.02) the code is
supposed to use the old, incorrect end-tag values to avoid
inter-op problems. But in this case, because the valuetype is
sent as part of the very first flow to the server, there is no
PartnerVersion information available, so we think we are
talking to a non-IBM ORB and generate the "correct" (but bad
for 4.02) end-tag values. Temporary fixComments
APAR information | APAR number | PQ72748 | Reported component name | WAS ADVANCED AI | Reported component ID | 5648C8400 | Reported release | 350 | Status | CLOSED PER | PE | NoPE | HIPER | NoHIPER | Submitted date | 2003-04-02 | Closed date | 2003-04-02 | Last modified date | 2003-04-02 |
APAR is sysrouted FROM one or more of the following: PQ63548
APAR is sysrouted TO one or more of the following:APAR is sysrouted FROM one or more of the following:PQ63548
Modules/Macros APAR is sysrouted TO one or more of the following:Modules/Macros
|
Fix information |
Fixed component name | WAS ADVANCED AI | Fixed component ID | 5648C8400 |
Applicable component levels | R350 PSY | UP |
|