|Re: [jakartaee-platform-dev] [External] : Re: Interceptors TCK -- what version of Platform TCK?|
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:
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.
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).
jakartaee-platform-dev mailing list
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