Fixes are available
17.0.0.1: WebSphere Application Server Liberty 17.0.0.1
17.0.0.2: WebSphere Application Server Liberty 17.0.0.2
17.0.0.3: WebSphere Application Server Liberty 17.0.0.3
17.0.0.4: WebSphere Application Server Liberty 17.0.0.4
18.0.0.1: WebSphere Application Server Liberty 18.0.0.1
18.0.0.2: WebSphere Application Server Liberty 18.0.0.2
18.0.0.3: WebSphere Application Server Liberty 18.0.0.3
18.0.0.4: WebSphere Application Server Liberty 18.0.0.4
19.0.0.1: WebSphere Application Server Liberty 19.0.0.1
19.0.0.2: WebSphere Application Server Liberty 19.0.0.2
19.0.0.3: WebSphere Application Server Liberty 19.0.0.3
19.0.0.4: WebSphere Application Server Liberty 19.0.0.4
19.0.0.5: WebSphere Application Server Liberty 19.0.0.5
19.0.0.6: WebSphere Application Server Liberty 19.0.0.6
19.0.0.7: WebSphere Application Server Liberty 19.0.0.7
19.0.0.8: WebSphere Application Server Liberty 19.0.0.8
19.0.0.9: WebSphere Application Server Liberty 19.0.0.9
19.0.0.10: WebSphere Application Server Liberty 19.0.0.10
19.0.0.11: WebSphere Application Server Liberty 19.0.0.11
19.0.0.12: WebSphere Application Server Liberty 19.0.0.12
20.0.0.1: WebSphere Application Server Liberty 20.0.0.1
20.0.0.2: WebSphere Application Server Liberty 20.0.0.2
20.0.0.3: WebSphere Application Server Liberty 20.0.0.3
20.0.0.4: WebSphere Application Server Liberty 20.0.0.4
20.0.0.5: WebSphere Application Server Liberty 20.0.0.5
20.0.0.6: WebSphere Application Server Liberty 20.0.0.6
20.0.0.7: WebSphere Application Server Liberty 20.0.0.7
20.0.0.8: WebSphere Application Server Liberty 20.0.0.8
20.0.0.9: WebSphere Application Server Liberty 20.0.0.9
20.0.0.10: WebSphere Application Server Liberty 20.0.0.10
20.0.0.11: WebSphere Application Server Liberty 20.0.0.11
20.0.0.12: WebSphere Application Server Liberty 20.0.0.12
21.0.0.3: WebSphere Application Server Liberty 21.0.0.3
21.0.0.4: WebSphere Application Server Liberty 21.0.0.4
21.0.0.5: WebSphere Application Server Liberty 21.0.0.5
21.0.0.6: WebSphere Application Server Liberty 21.0.0.6
21.0.0.7: WebSphere Application Server Liberty 21.0.0.7
21.0.0.8: WebSphere Application Server Liberty 21.0.0.8
21.0.0.9: WebSphere Application Server Liberty 21.0.0.9
21.0.0.1: WebSphere Application Server Liberty 21.0.0.1
21.0.0.2: WebSphere Application Server Liberty 21.0.0.2
21.0.0.10: WebSphere Application Server Liberty 21.0.0.10
21.0.0.11: WebSphere Application Server Liberty 21.0.0.11
21.0.0.12: WebSphere Application Server Liberty 21.0.0.12
22.0.0.1: WebSphere Application Server Liberty 22.0.0.1
22.0.0.2: WebSphere Application Server Liberty 22.0.0.2
22.0.0.3: WebSphere Application Server Liberty 22.0.0.3
22.0.0.4: WebSphere Application Server Liberty 22.0.0.4
APAR status
Closed as program error.
Error description
On 8.5.5.9 com.ibm.ws.eba.tx.TxInterceptorImpl. postCallWithException(TxInterceptorImpl.java:83) throws java.lang.IllegalStateException: java.lang.Object@4d83b21e On 8.5.5.8, it throws java.lang.IllegalStateException: CWSAB1000E: No active transaction on the thread.
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All users of IBM WebSphere Application * * Server Liberty - EBA Applications * **************************************************************** * PROBLEM DESCRIPTION: IllegalStateException thrown by OSGi * * transaction interceptor contains * * incorrect message when invoked by * * blueprint framework * **************************************************************** * RECOMMENDATION: * **************************************************************** OSGi applications may define a transaction element in blueprint that requires the transaction interceptor to throw an exception in certain circumstances, for example if a method's transaction element is defined with a mandatory value attribute and the method is invoked with no transaction context. In such a case an IllegalStateException is generated but a change in the Apache Aries blueprint interceptor framework caused it to invoke the blueprint transaction interceptor's postCallWithException method to be invoked with an invalid token resulting in a completely different IllegalStateException to be raised. This defective behavior only occurs if there is a single blueprint interceptor to be invoked by the framework, if multiple blueprint interceptors are defined then the blueprint framework invokes the interceptor's postCallWithException with the correct token.
Problem conclusion
The Apache Aries blueprint interceptor framework was fixed so that the value of the token passed to a blueprint interceptor's postCallWithException has the same value as before the breaking change. This is also the same value passed when multiple interceptors are configured. The fix for this APAR is currently targeted for inclusion in fix pack 17.0.0.1. 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
PI61885
Reported component name
LIBERTY PROF -
Reported component ID
5655W6514
Reported release
850
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2016-05-05
Closed date
2017-02-03
Last modified date
2017-02-03
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
LIBERTY PROF -
Fixed component ID
5655W6514
Applicable component levels
R850 PSY
UP
Document Information
Modified date:
04 May 2022