Return-Path: 
 <issues-return-34664-apmail-cxf-issues-archive=cxf.apache.org@cxf.apache.org>
X-Original-To: apmail-cxf-issues-archive@www.apache.org
Delivered-To: apmail-cxf-issues-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id D981B17F0D
	for <apmail-cxf-issues-archive@www.apache.org>;
 Mon,  1 Jun 2015 13:31:18 +0000 (UTC)
Received: (qmail 76077 invoked by uid 500); 1 Jun 2015 13:31:18 -0000
Delivered-To: apmail-cxf-issues-archive@cxf.apache.org
Received: (qmail 76046 invoked by uid 500); 1 Jun 2015 13:31:18 -0000
Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:issues-help@cxf.apache.org>
List-Unsubscribe: <mailto:issues-unsubscribe@cxf.apache.org>
List-Post: <mailto:issues@cxf.apache.org>
List-Id: <issues.cxf.apache.org>
Reply-To: dev@cxf.apache.org
Delivered-To: mailing list issues@cxf.apache.org
Received: (qmail 75879 invoked by uid 99); 1 Jun 2015 13:31:18 -0000
Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Jun 2015 13:31:18 +0000
Date: Mon, 1 Jun 2015 13:31:18 +0000 (UTC)
From: "Neal Hu (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: <JIRA.12834167.1433144407000.82362.1433165478597@Atlassian.JIRA>
In-Reply-To: <JIRA.12834167.1433144407000@Atlassian.JIRA>
References: <JIRA.12834167.1433144407000@Atlassian.JIRA>
 <JIRA.12834167.1433144407599@arcas>
Subject: [jira] [Updated] (CXF-6429) Provider matching when nested generic
 type
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


     [ https://issues.apache.org/jira/browse/CXF-6429?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:all-tabpanel ]

Neal Hu updated CXF-6429:
-------------------------
    Description:=20
This is TCK case:
resource class:=20
JAXBElement<String> method(JAXBElement<String> jaxb){

}
Provider 1(applicaiton provided provider):=20
public class Provider1=C2=A0 implements MessageBodyReader<JAXBElement<Strin=
g>>, MessageBodyWriter<JAXBElement<String>>
Provider 2: JAXBElementProvider
@Comsumes("...")
@Produces("...")
public class Provider2=C2=A0 implements MessageBodyReader<T>, MessageBodyWr=
iter<T>

The case intends to match the pre-packaged provider, we challenged the case=
 but spec leads rejected the challenge. They mentioned the inside generic t=
ype <String> should be ignored, and compare the JAXBElement then compare me=
dia type(provider2 has concrete media type). But we think according to spec=
 4.2.2|#4 provider1 is the nearest class of the resource java type. What's =
your thinking, please share with us.


  was:
This is TCK case:
resource class:=20
JAXBElement<String> method(JAXBElement<String> jaxb){

}
Provider 1(applicaiton provided provider):=20
public class Provider1=C2=A0 implements MessageBodyReader<JAXBElement<Strin=
g>>, MessageBodyWriter<JAXBElement<String>>
Provider 2: JAXBElementProvider
@Comsumes("...")
@Produces("...")
public class Provider2=C2=A0 implements MessageBodyReader<T>, MessageBodyWr=
iter<T>

The case intends to match the pre-packaged provider, we challenged the case=
 but Oracle spec leads rejected the challenge. They mentioned the inside ge=
neric type <String> should be ignored, and compare the JAXBElement then com=
pare media type(provider2 has concrete media type). But we think according =
to spec 4.2.2|#4 provider1 is the nearest class of the resource java type. =
What's your thinking, please share with us.



> Provider matching when nested generic type
> ------------------------------------------
>
>                 Key: CXF-6429
>                 URL: https://issues.apache.org/jira/browse/CXF-6429
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-RS
>    Affects Versions: 3.0.3
>         Environment: Windows
>            Reporter: Neal Hu
>             Fix For: 3.0.6
>
>
> This is TCK case:
> resource class:=20
> JAXBElement<String> method(JAXBElement<String> jaxb){
> }
> Provider 1(applicaiton provided provider):=20
> public class Provider1=C2=A0 implements MessageBodyReader<JAXBElement<Str=
ing>>, MessageBodyWriter<JAXBElement<String>>
> Provider 2: JAXBElementProvider
> @Comsumes("...")
> @Produces("...")
> public class Provider2=C2=A0 implements MessageBodyReader<T>, MessageBody=
Writer<T>
> The case intends to match the pre-packaged provider, we challenged the ca=
se but spec leads rejected the challenge. They mentioned the inside generic=
 type <String> should be ignored, and compare the JAXBElement then compare =
media type(provider2 has concrete media type). But we think according to sp=
ec 4.2.2|#4 provider1 is the nearest class of the resource java type. What'=
s your thinking, please share with us.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)