Not sure I understand the issue, but IMO, the TCK should be challenged
if a backward compatible method signature change was done. For example,
Java 5 had a huge number of backward compatible signature changes
because of generics. Java EE should be the same.
BTW, I hate the TCK signature tests in general. For one, Java EE does
not allow you to upgrade JAX-RS 1.1 to 2.0 within a certified EE 6
container, even though JAX-RS 2.0 is a standalone spec and is backward
compatible. The signature tests will fail too. This is something that
needs to be fixed. I know there are a huge number of customers that
will want to stick with Java EE 6, but use JAX-RS 2.0.
On 1/17/2013 5:38 PM, Sergey Beryozkin wrote:
> Hi
>
> Comment from Marek at
>
> http://java.net/jira/browse/JAX_RS_SPEC-326
>
> got me actually concerned, though may be it is unfounded - apologies if so.
>
> Basically I do not get why the change to do with JAX-RS 1.1 TCK
> signature tests was made after JAX-RS 2.0 m10, in fact, different people
> run TCK 1.1 against CXF JAX-RS 1.1 implementation and it passed, thus
> I'm worried about this change ?
> Also - should the actual TCK be 'challenged' and the issue be fixed
> there instead of pushing it to the API level ?
>
> Looking forward to some comments
> Thanks, Sergey
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com