Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jsonb-dev] Verifying TCK on Application Servers


On 2/25/22 10:42 AM, Kyle Aure wrote:
Hello Scott,

Also the previous Standalone JSONB TCK (generated from Platform TCK) did not contain any EE container testing.

I was thinking of https://download.eclipse.org/jakartaee/jsonb/2.0/jakarta-jsonb-tck-2.0.1.zip as the prior JSONB Standalone TCK, sorry that I didn't point that out.


Actually, that is incorrect.  Prior to PR https://github.com/eclipse-ee4j/jsonb-api/pull/276 the JSONB Standalone TCK was using Arquillian to deploy these tests to a container which is why the change confused me.

So, there are two possible paths that the JSONB 3.0 Standalone TCK could follow.

  1. JSONB Standalone TCK includes the (Platform Specification) required EE container tests.  Call this a composite TCK as it tests more than one EE Specification.
  2. Or JSONB Standalone TCK does not include the (Platform Specification) required EE container tests.  Call this a non-composite TCK as it tests only one EE Specification.

We currently have #2 currently and the agreement that the Platform TCK will keep a small number of JSONB tests to validate the Platform requirements.

I think that so long as everyone agrees with the assertion made by Dmitry

  • Make sure that your platform implementation passes Platform TCK
  • Make sure that JSONB implantation you use passes standalone JSONB TCK tests. If you are using Yasson, you don’t need to do anything. Yasson is going to be certified as JSONB compatible implementation.

    • I don't think we should recommend that EE 10 implementations skip running the standalone JSONB TCK tests with their JSONB SPEC API jar + JSONB implementation.  For example, with WildFly, we are including Yasson but how do I really know that the Yasson implementation has passed the Standalone JSONB TCK tests without actually running that test myself?  Certainly, I would expect that Yasson 3.0.0 will pass the Standalone JAXB TCK but copying TCK results from the Yasson teams certificate of compatibility request (CCR) into a Jakarta EE 10 CCR, doesn't sound right to me.


    Then I would welcome the change as these tests will run much faster the way they are now and lessens the burden on platforms to re-test known passing implementations.

    I wouldn't expect the Platform team to accept CCRs that do not include (non-composite) Standalone TCK test results, but that is a question for them.  Are you thinking that your CCRs would include a link to the Yasson Standalone TCK results in place of JSONB Standalone TCK results?



    Thanks,
    Kyle Jon Aure

    Back to the top