Compatibility certification request for Open Liberty for Jakarta EE 9, Web Profile

[brideck]

• Organization Name ("Organization") and, if applicable, URL:
  
  IBM Corporation

• Product Name, Version and download URL (if applicable):
  
  Open Liberty, 21.0.0.2-beta

• Specification Name, Version and download URL:
  
  Jakarta EE Platform, Web Profile, 9

• TCK Version, digital SHA-256 fingerprint and download URL:
  
  Jakarta EE Platform TCK 9.0.1
  0f8eda91c1d574ad84d4e3f6d17d804fcfaa367901602eee64e6b3e8563f37ee

• Public URL of TCK Results Summary:
  
  Test Results

• Any Additional Specification Certification Requirements:
  
  Jakarta Injection
  jakarta.inject-tck-2.0.1-bin.zip
  7853d02d372838f8300f5a18cfcc23011c9eb9016cf3980bba9442e4b1f8bfc6

  Jakarta Contexts and Dependency Injection
  cdi-tck-3.0.1-dist.zip
  f0a3bdd81ea552ddf2c2a6cd2576f0d5ca45026665cb4a5c42606a58bf1c133d

  Jakarta Bean Validation
  beanvalidation-tck-dist-3.0.0.zip
  c975fd229df0c40947a9f0a69b779ec92bebb3d21e05fdc65fccc1d11ef5525b

  Jakarta Debugging
  jakarta-debugging-tck-2.0.0.zip
  71999815418799837dc6f3d0dc40c3dcc4144cd90c7cdfd06aa69270483d78bc

• Java runtime used to run the implementation:
  
  OpenJDK 1.8.0_252 (HotSpot)

• Summary of the information for the certification environment, operating system, cloud, ...:
  
  Linux Ubuntu 18.04 LTS, Apache Derby

• By checking this box I acknowledge that the Organization I represent accepts the terms of the EFTL.

• By checking this box I attest that all TCK requirements have been met, including any compatibility rules.

• Relevant challenges & resolution:
  signaturetest, 2 failures: logs available with public TCK results
  eclipse-ee4j/faces-api#1474

[ivargrimstad]

+1 LGTM

[scottmarlow]

+1 LGTM also

[kwsutter]

Of course, it LGTM! +1 Thanks, @brideck!

[edbratt]

I don't think it makes sense to approve a certification request with an open challenge. I would prefer that question be resolved prior to final approval of this certification request. What is the prognosis for resolving the JSF challenge??

[brideck]

I don't think it makes sense to approve a certification request with an open challenge. I would prefer that question be resolved prior to final approval of this certification request. What is the prognosis for resolving the JSF challenge??

All of our EE 8 certification requests for Liberty products were approved with the same challenge listed, only now I've added the specific result logs (per Bill Shannon's request) so approvers can affirm that we have no other issues. Per jakartaee/faces#1471, it looks like the Faces challenge may not be addressed until after EE 9.1. As the problem is in the signature tests, it was agreed that the issue cannot be resolved through the exclusion of tests.

[edbratt]

A challenge can be addressed by disabling a test or adding an alternate test. EE 8 was problematic due to the requirement that the Java EE tests were fixed by process. We don't have that issue with EE 9. In my opinion, this should have been resolved properly and I don't see an impediment to having JSF committer team considering it -- and disabling the test (or adding an alternate). A new Spec. release shouldn't be needed. My point is, that should be addressed in JSF, not here. Here we should just be tabulating the successful results.

[kwsutter]

The problem here, @edbratt, is that the resolution affects the Signature tests. And, we can't just turn off one or two signature tests -- it's all or none. @scottmarlow just resurfaced this question to the TCK mailing list. This should have been resolved after Jakarta EE 8 and it wasn't. So, @brideck is just following the process that is available to us. It's not perfect, but what's the alternative at this point?

[edbratt]

I'm okay with this specific request proceeding but I don't want elements of doubt creeping in and then continuing to slide unresolved. API teams need to work with vendors and we cannot let those issues continue to plague certifications. The only thing that will prevent this is to require that certification issues do not contain challenges. The TCKs should be passed and questions and issues such as raised here, should be handled in the respective API team, or teams and resolved with the principle parties that produce and consume them. If there is certification time-frame urgency then those teams need to respond appropriately.

[kwsutter]

I'm okay with this specific request proceeding but I don't want elements of doubt creeping in and then continuing to slide unresolved.

Thanks, @edbratt! And, I totally agree that we have to avoid this test challenge creep. As part of the test challenge, we need to ensure that an Issue is raised and followed up on to properly correct the challenge. This one seems to have fallen through the cracks and we didn't notice it until we started testing. And, then it was "too late" to correct it via the Spec project.

[ivargrimstad]

It looks like we are good to go. If no one objects, I'll add the accepted label later today.