TCK has to explicitly verify singletons

[mkarg]

JAX-RS Specification 2.1 Chapter 4.1 Line 1: "By default a single instance of each provider class is instantiated for each JAX-RS application."

Apparently the TCK, while currently not published, seems to have no explicit test for this rule, as (at least) the RI (Jersey) seems to have passed the TCK but actually creates multiple instances due to a bug I just reported (https://github.com/jersey/jersey/issues/3796). @spericas Confirmed that there must only be one instance (see this discussion: #605), hence it actually is a bug in Jersey but not a missing clarification in the spec. Hence, either Jersey did not actually pass the TCK, or the TCK apparently is not checking this.

To prevent implementations from passing the TCK but not behaving correctly, the TCK should get fixed in a way that guarantees that the TCK fails when creating more than one instance of a provider class which implements multiple provider interfaces.

[mkarg]

If someone could help me with jumpstarting into TCK maintenance, I would volunteer with this issue. :-)

[spericas]

@mkarg What exactly do you want to do next? We can always pick @jansupol's brain as he should be an expert in this area :)

[mkarg]

@mkarg What exactly do you want to do next? We can always pick @jansupol's brain as he should be an expert in this area :)

I want to extend the TCK by tests for SeBootstrap etc., but I have not yet built nor run the TCK before. If someone could help me with setting up the TCK on Windows that would be terrific.

[andymc12]

@mkarg, You might also want to check with @scottmarlow (RedHat) - I think he's been heavily involved in the TCK for EE9. He has set up a slack channel for TCK issues at https://eclipsefoundationhq.slack.com/archives/C0131MLD538

[jansupol]

@mkarg I have summed up a wiki about building the TCK back in the Jakarta EE 8 days. You might also check the Jenkins jobs.

[mkarg]

Thank you for your great tips! I will check Jan's wiki and Jenkins Jobs first, and when I need more help, I will ask Scott and Jan! :-)

[jansupol]

The TCK GitHub repo has its own wiki, too.

[scottmarlow]

If someone could help me with jumpstarting into TCK maintenance, I would volunteer with this issue. :-)

Here is a quick summary of TCK maintenance. For existing Jakarta EE releases, we do not add/update tests, we will only exclude challenged tests. The reason is that once an implementation has passed the TCK for a specific SPEC version, we don't add/update tests as that would change the rules of what implementations must do for that particular SPEC version.

So, I think any tests that you add would be for Jakarta EE 9.1, which is the next Jakarta EE release that we are working on (mostly for TCKs to add support for JDK 11). Hopefully that will be a very quick release but will see.

https://github.com/eclipse-ee4j/jakartaee-tck/wiki/Instructions-for-Building-&-Running-Jakarta-EE-Standalone-TCKs isn't for Windows but gives some information on building from Linux via Linux shell scripts (sorry, there are no .bat or .cmd files).

I suspect that you could just fork https://github.com/eclipse-ee4j/jakartaee-tck and make your change, push your branch to github and ask someone to build it for you. Then, you could try to run the resulting TCK zip locally. That is idea #1.

Another path that doesn't initially involve source control, is setting up the TCK to run locally. Once you can run the TCK, you can also hack in test changes that you build via ant build compile. If you get the test passing, then create a github pull request with your change.

Another path is to use Centos (or other Linux) on your Windows machine (via whatever virtualization tool). https://github.com/eclipse-ee4j/jakartaee-tck/wiki/Instructions-for-running-the-nightly-engineering-build-of-Platform-TCK-with-Podman-(currently-for-EE-9) is an example of running the an existing build of the Platform TCK. If that sounds interesting, let me know and I'll see if the wiki needs any obvious updates.

We have also been discussing ways to make it easier to add new TCK tests as we will be doing a lot of that in the future. This could be related to jakartaee/platform-tck#51 but I think that more discussion is needed for the different options.

[arjantijms]

@scottmarlow

I wonder if it's an option already (or soon) to start adding new tests based on Junit/TestNG + Arquillian in a separate test project, which are then executed just like the CDI, Jakarta Validation and Jakarta Batch tests are. Something like this was recently on the Faces list as a way forward for us, and maybe it's a useful strategy for other projects as well.

[jansupol]

There is an activity like that on JSONB, but JSON-B is basically a standalone technology, no deployment, no servlet, no CDI (the only CDI test is not part of the TCK and has been removed, it is only part of the CTS and as far as I know there is no consensus about how the CTS tests - EJB, CDI, and BV tests in case of JAX-RS should work as a part of the Junit based TCK). But the discussion suggested that Arguillian is capable of the deployment. The bootstrap API tests would possibly be easily implemented with Arquillian, there is no deployment and servlet.