Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] [External] : Re: Interceptors TCK -- what version of Platform TCK?


On 9/2/22 5:33 PM, Ed Bratt wrote:

Sorry -- I see that I am confused about interceptors. Thank you Steve for jogging my memory.

Currently there is a TCK on the Interceptors 2.1 specification page -- That TCK link points to CDI 4 TCK. Previously versions of Interceptors used the Platform TCK. I now recall that we couldn't use the Platform TCK at the time we wanted to finalize CDI and CDI has a dependency on Interceptors.

We now have a TCK tracking/consistency issue --  Interceptors refers to CDI 4.0.0 TCK, but CDI is up to 4.0.6.

The CDI TCK user documentation and it doesn't explicitly state that implementations that pass the CDI TCK qualify as compatible for Interceptor compatibility (it does say there are lots of tests but nothing formally conveying a compatibility statement). I think we want the CDI documents to say that. In the Platform TCK User Guide it is very explicit: "Jakarta EE 10 Platform TCK provides compatibility certification verification for implementations contained in the Platform for the following component specifications:" (Interceptors appears in the following bullet list)

In the GlassFish CDI test run (using CDI 4), there are 108 references to Interceptor in the test result. In the Platform TCK test results, there are 175 tests. This needs to be reconciled so that we can be confident that the TCK results in consistent and compatible implementations of Interceptor functionality. The two suites would, ideally use the same tests for interceptors (and some of the tests with keyword interceptor may be CDI specific, not necessarily Interceptor specific).

I know the subject of reorganizing Interceptors to be part of CDI was raised but I don't recall us making any formal decision about that. I suspect I was (and likely still would be) reluctant to actually support that change. I am certain that I at least stressed caution about not having the same tests in both places.

I think we need to formally decide what we are going to do with this -- I guess for EE 11. There are differences between what is tested (or at least reported) by the CDI and Platform TCK under the keyword Interceptor. This may cause problems if someone were to complete their certification using only the CDI TCK only later to find problems when they attempt to complete a Platform certification that then asserts problems with their (previously validated) Interceptor implementation.

Since the Platform Spec. team is currently the 'owner' of Interceptors, that problem would come to this team.

If it's possible, I think the best would be to refactor what remains in the Platform TCK -- into an independent TCK. Would this be feasible for EE 11 or was there some structural problem with creating this as a completely separate TCK? How much investigation about this has already been accomplished?

During the Platform TCK call today, we talked about a few different options for refactoring what remains in the Platform TCK with different costs.  Keeping in mind that the Platform TCK still has around 2.2 million lines of test code (based on `find -type f| xargs cat | wc -l` in src folder).  Refactoring all of the Platform TCK tests has the highest risk that it could cause the EE 11 release to take longer than 1-2 years (IMO since we cannot validate any SPEC API Ballots until completing refactoring).  If we refactor a small subset of Platform TCK tests, we would see a lower risk to the overall EE 11 release duration depending on how we do the refactoring. 

Some options to discuss/consider:

  1. Completely refactor all remaining tests in the Platform TCK and take as much time as that takes.  Cost is very high from an EE 11 release scheduling perspective as the Platform TCK project wouldn't be able to produce any standalone TCKs until the refactoring is complete, so the schedule impact is the first SPEC wave is blocked on starting the ballot until the Platform TCK refactoring is complete.  Impact on EE11 release is that we have some initial overlap period where EE 11 SPECs are developed + TCK tests are refactored but the TCK refactoring does become a blocker for the EE 11 release starting the first SPEC ballot wave.  Further cost is that we don't know how long the complete refactoring would take.
  2. Refactor a subset of each Platform TCK test bucket (e.g. specification being tested) but do not refactor all tests.  The cost on the EE 11 implementations is that they still have to run both the old (Ant based Platform TCK tests) + new (refactored Platform TCK tests).  To minimize the cost on EE 11 implementations, the Ant based Platform TCK tests would continue to be configured/run the same way as run with Platform TCK in EE 10.  There is also a EE 11 implementors complexity cost of having some tests run via Ant and some tests run via Maven/Arquillian.
  3. Refactor a subset of each Platform TCK test bucket (e.g. specification being tested) but do not refactor all tests.  The tests that are not refactored would be removed from the EE 11 release but could be refactored and added in future EE releases.  The cost of reduced coverage varies depending on how much of each test bucket is refactored.  The cost of risk to the EE 11 release also varies based on how much of each test bucket is refactored.  The reduced test coverage could impact the quality of EE implementations.
  4. Something else.

I think we all get the idea of how the first SPEC wave (and other SPEC API waves) are blocked on being able to run the relevant TCK.  Perhaps we could be clever and come up with a solution for removing the SPEC API ballot bottleneck on the TCK with a contract that guarantees that any subsequent refactored TCK test changes must pass implementations that have submitted a compatibility certification request for the respective specification (e.g. think of a cooperative communications process that coordinates with the spec implementations that communicate their subsequent TCK test results back on a tracking Platform TCK issue).  There could be other ways to improve our processes to allow SPEC API development to proceed forward in parallel while the TCK refactoring might still be happening throughout the EE 11 development process.

Scott

Thanks,

-- Ed

On 9/2/2022 1:42 AM, Scott Marlow wrote:


On Thu, Sep 1, 2022, 9:02 PM Ed Bratt <ed.bratt@xxxxxxxxxx> wrote:

I'm looking over the various specifications and I notice that Interceptors 2.0 just lists the Jakarta EE 9 platform TCK. I believe we are also allowing Jakarta EE 10 Platform TCK as a certification TCK for interceptors (all Platform TCKs can validate for interceptor compatibility). Also (if I recall) CDI implementations do not need to run an additional TCK yet will certify compatible implementations, compatible with Interceptor API.


EE 9 implementations can run the EE 9  Platform TCk but I don't think they can expect to run the EE 10 Platform TCK until they implement interceptors 2.1 (updates dependencies for EE 10 and adds a JPMS module-info descriptor) and implement other EE 10 specs. 

So it seems fine to me the way Interceptors 2.0 just lists EE 9 Platform TCK.

I'm wondering how we should convey this information on the Specification page.

I think at the least, we ought to list the Jakarta EE 10 Platform TCK as an approved compatibility validation TCK. I do not believe we want to imply that one must run the EE 9 Platform TCK to certify Interceptors. I think we can consider saying nothing on the interceptors Spec. page about CDI TCK, relying on the CDI TCK to call out the requirement for interceptor compatibility as well as the validation that the TCK verifies interceptor compatibility. By extension, we could say nothing on the Interceptors page but that, at least to me, leaves me wondering -- what would a vendor be expected to do. Perhaps something calling out (on the Spec. page) "Platform products may certify Interceptors compatibility for their product using the latest Platform TCK of the Platform version they are releasing."

Anyone have thoughts on this?

(I realize this is kind of an low priority issue since few if any implementations are going to certify Interceptors outside of one of the other specification bodies (EE Platform or CDI TCKs).

-- Ed

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!O674Cxc7wX7g-y9jgaZwr6HEPq7pBlH9gNPrZYEcZuCTpAWwEN24fmvhsQgukpBlyS6yn0APpCpIIto$

Back to the top