PI89955: JAX-RS 2.0: JAVAX.WS.RS.CORE.REQUEST.SELECTVARIANT() RETURNS INCORRECT VALUE

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

• JAX-RS 2.0: javax.ws.rs.core.Request.selectVariant() returns
  incorrect
  value
  
  Details:
  A JAX-RS application which uses content negotiation.
  To determine the content it should return they use the method
  javax.ws.rs.core.Request.selectVariant()
  which should return "the variant that best
  matches the request".
  
  On WAS v9 which uses JAX-RS 2.0 the content negotiaton no
  longer works correctly.
  The biggest problem is, that the return value of selectVariant
  differs from the returned HTTP header "Content-Type"
  

Local fix

• works fine under WAS v8
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:  All users of IBM WebSphere Application      *
  *                  Server using JAX-RS.                        *
  ****************************************************************
  * PROBLEM DESCRIPTION: The CXF implementation of               *
  *                      javax.ws.rs.core.Request.selectVariant( *
  *                      ) is not correct and the incorrect      *
  *                      Variant is chosen.                      *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  Moving from Apache Wink (JAX-RS 1.1) to
  CXF 3.0.X (JAX-RS 2.0) there are subtle differences
  in the behavior of the javax.ws.rs.core.Request.selectVariant
  method. According to the spec, the returned Variant should be
  one of the Variants passed in to the selectVariant method that
  is the closest match to the request (based on the Accept,
  Accept-Language, and Accept-Encoding headers). This is the
  behavior in Wink, but in CXF the first Variant
  in the passed-in list that matches the request's headers is
  chosen.
  For example, a request with "Accept: a/b, c/d; q=0.5" will
  return a response with "Content-Type: a/b" - assuming that the
  resource method produces a/b and c/d. However, when the user
  calls:
  List<Variant> list = new ArrayList<Variant>();
  Variant v1 = new Variant("a/b", (Locale) null, null);
  Variant v2 = new Variant("c/d", (Locale) null, null);
  Variant v3 = new Variant("not/used", (Locale) null, null);
  list.add(v3);
  list.add(v2);
  list.add(v1);
  assertSame(v1, Request.selectVariant(list));
  the assertion fails. Even though the user prefers a/b over c/d
  by a quality factor of 1 vs 0.5, the selectVariant method
  returns the Variant with c/d. This is because the
  RequestImpl's implementation of the selectVariant method only
  checks the request headers when intersecting the Mime
  (Media)Types.
  See CXF JIRA 7553 for more details:
  https://issues.apache.org/jira/browse/CXF-7553
  

Problem conclusion

• The CXF code delivered with WebSphere Application Server
  has been changed to match Wink's implementation and  take the
  request header's quality factors into account when determining
  which Variant to return.
  
  The fix for this APAR is currently targeted for inclusion in
  fix pack 9.0.0.7.  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 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