Fixes are available
9.0.0.5: WebSphere Application Server traditional V9.0 Fix Pack 5
9.0.0.6: WebSphere Application Server traditional V9.0 Fix Pack 6
9.0.0.7: WebSphere Application Server traditional V9.0 Fix Pack 7
9.0.0.8: WebSphere Application Server traditional V9.0 Fix Pack 8
9.0.0.9: WebSphere Application Server traditional V9.0 Fix Pack 9
9.0.0.10: WebSphere Application Server traditional V9.0 Fix Pack 10
9.0.0.11: WebSphere Application Server traditional V9.0 Fix Pack 11
9.0.5.0: WebSphere Application Server traditional Version 9.0.5 Refresh Pack
9.0.5.1: WebSphere Application Server traditional Version 9.0.5 Fix Pack 1
9.0.5.2: WebSphere Application Server traditional Version 9.0.5 Fix Pack 2
9.0.5.3: WebSphere Application Server traditional Version 9.0.5 Fix Pack 3
9.0.5.4: WebSphere Application Server traditional Version 9.0.5 Fix Pack 4
9.0.5.5: WebSphere Application Server traditional Version 9.0.5 Fix Pack 5
WebSphere Application Server traditional 9.0.5.6
9.0.5.7: WebSphere Application Server traditional Version 9.0.5 Fix Pack 7
9.0.5.8: WebSphere Application Server traditional Version 9.0.5.8
9.0.5.9: WebSphere Application Server traditional Version 9.0.5.9
9.0.5.10: WebSphere Application Server traditional Version 9.0.5.10
9.0.5.11: WebSphere Application Server traditional Version 9.0.5.11
APAR status
Closed as program error.
Error description
If a sub-resource locator class defines a method with the @OPTIONS annotation, it will not be invoked. Instead, the most likely result will be a "404 Not Found" response. For example, suppose you have a resource method like this: @Path("/myRootUri") public class MyRootResource { @Path("/sub") public MySubResource sub() { return new MySubResource(); } } and a sub-resource locator class like below: public class MySubResource { @OPTIONS public Response options() { return Response.ok("...").build(); } @GET public Response get() { return Response.ok("...").build(); } } Invoking /myRootUri/sub with a GET request will return the expected 200 response, but invoking the same URI with an OPTIONS request will get an unexpected 404 response.
Local fix
N/A
Problem summary
**************************************************************** * USERS AFFECTED: All users of IBM WebSphere Application * * Server * **************************************************************** * PROBLEM DESCRIPTION: JAX-RS 2.0 OPTIONS METHODS ARE NOT * * INVOKED WHEN USED IN SUB-RESOURCE * * LOCATOR CLASSES. * **************************************************************** * RECOMMENDATION: * **************************************************************** If a sub-resource locator class defines a method with the @OPTIONS annotation, it will not be invoked. Instead, the most likely result will be a "404 Not Found" response. For example, suppose you have a resource method like this: @Path("/myRootUri") public class MyRootResource { @Path("/sub") public MySubResource sub() { return new MySubResource(); } } and a sub-resource locator class like below: public class MySubResource { @OPTIONS public Response options() { return Response.ok("...").build(); } @GET public Response get() { return Response.ok("...").build(); } } Invoking /myRootUri/sub with a GET request will return the expected 200 response, but invoking the same URI with an OPTIONS request will get an unexpected 404 response.
Problem conclusion
The fix for this APAR ensures that sub-resource locator classes are correctly scanned for @OPTIONS annotations. If a method exists that matches the user's URI, then it will be invoked. If not, then the normal return with a list of applicable HTTP methods for that URI will be returned. The fix for this APAR is currently targeted for inclusion in fix pack 9.0.0.5. 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
PI80165
Reported component name
WEBS APP SERV N
Reported component ID
5724H8800
Reported release
900
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2017-04-18
Closed date
2017-06-26
Last modified date
2017-06-26
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
R900 PSY
UP
Document Information
Modified date:
04 May 2022