eclipse / microprofile-context-propagation

Apache License 2.0
33 stars 23 forks source link

TCK dependency on certain EE APIs #178

Closed manovotn closed 4 years ago

manovotn commented 4 years ago

In the current state, the TCKs try to avoid dependency on some APIs (CDI and transactions) and use reflection to test that certain functionality works. A good example is ThreadContextTest#clearTransactionContextJTA().

Apparently somewhere in the past we decided to do it that way, probably so that some implementations can implement MP CP without support for certain features. I don't really see a strong argument for that now as we have two impls, both of which use CDI in one way or another and both have transactions existing and either want or don't want to propagate their contexts. Plus we haven't heard of another which would want to go down that road yet. Plus we now have another integrator (Quarkus) that wants to execute TCKs but has to perform certain CL magic to execute them. This yields problems with the aforementioned test where you get some illegal access exceptions.

I suggest we make that TCK test depend on pure APIs and then use those API methods to determine whether certain functionality is supported. The test can still succeed even if it isn't in place. For instance, with CDI you should be able to do:

try {
  CDI<Object> cdi = CDI.current();
  } catch (IllegalStateException e) {
    // no CDI provider, we can end the test here
    return;
  }
cdi.select(...).get().doWhatTheTestNeeds();