TL;DR summary:
- Looking at the included signature tests, CDI 4.0 TCK in my opinion, does not sufficiently cover compatibility requirements for Interceptors and should not, as it exists today, be used to verify compatible implementations of Interceptors;
- CDI 4.0 specification, in my opinion, may be finalized using any version of Interceptors that meets the requirements of the CDI 4.0 TCK. If an implementation is based on a pre-final API implementation of Interceptor 2.1 -- and that pre-final API later passes
the final interceptor 2.1 TCK -- no further changes are needed to either the Implementation nor the CDI TCK. A conflict would only occur if changes to Interceptor 2.1 were implemented
after CDI 4.0 was finalized and these changes invalidated or changed the requirements Interceptors imposes on CDI. We don't contemplate a conflict like this occurring in EE 10.
In the Specification Committee meeting we had a discussion about Interceptors and it's relationship to CDI. The discussion involved several points, one of which was, could the CDI TCK be considered a compatibility verification for Interceptor implementations.
I looked at the Interceptor signature tests from the Jakarta EE Platform TCK and I can see several tests that do not appear in the
CDI signature test collection. I would not position my research as necessarily exhaustive, however based on this level of analysis, I don't think we should remove these compatibility tests as certification requirement of a compatible Interceptors implementation.
I did not look at Interceptor specific compatibility tests (i.e. non-signature tests) in the Jakarta EE Platform TCK but I would be surprised if there are none. These tests would also need to be factored into any independent Interceptor compatibility requirement
(and a proposed TCK).
From my look at the CDI signature map files, not all of the jakarta.interceptor classes are recorded. The Platform TCK signature map files do seem to have all of the jakarta.interceptor classes recorded.
If it is important for the CDI signature map files to be able to validate that the jakarta.interceptor API methods haven't been super/sub-setted, we could investigate adding additional `sigtest` options for use with the Maven plugin that may help implement
a deeper scan. The negative of the deeper scan is that the JDK classes may end up in the signature map file, which will mean we will need to also pass -IgnoreJDKClass to the `sigtest` maven plugin (see example here).
A task could be undertaken to enhance the CDI TCK to include the core of Interceptor compatibility requirements. A different task could be to extricate the Interceptor core compatibility requirements currently delivered in the Jakarta EE Platform TCK and
refactor this into a stand-alone TCK. I am not aware that either of these tasks are currently in the EE 10 plan. I would support developing a plan to create a stand-alone Interceptor TCK and if it can be staffed, completing that plan. I'd be reluctant impose
any of this on EE 10 if doing so were to further delay EE 10's release date.
I would not support using the CDI TCK, as it appears to be implemented today, as certification of a compatible Interceptor implementation.
If there were a separate Interceptor TCK the CDI Spec. team could consider requiring that all CDI compatible implementations
also pass the Interceptor TCK. However, today, that additional compatibility requirement isn't part of CDI specification.
With regard to the question -- can the CDI Specification be promoted to final status without a final release of Interceptors?
The only specification that certifies Interceptor is Jakarta EE Platform. Recall, the normative specification artifacts we produced are: The written specification and the TCK. The API is a convenience artifact and it there is no implementation requirement
to include any specific API jar. An implementation that passes the signature and other CDI TCK tests and meets all the requirements of the Specification, is deemed CDI compatible. This has been the status quo for all CDI releases to date. I maintain that this
continues to be acceptable.
If a pre-release Interceptor API is included in an implementation of CDI, and that API meets all the requirements for CDI -- CDI TCK has verified compatibility requirement of the
CDI specification. If that pre-release Interceptor API is later found to be compatible with the final
Interceptor release -- the implementation has no requirement to change. The Implementation
may elect change it's API (i.e. update maven GAV) to pull in the promoted final convenience JAR, but that does not decertify the previous CDI certification. If Interceptor did change -- then all of this might need to be revisited. That is a complication/risk
that we have lived with for many releases. It is not currently envisioned that Interceptors will change at all between now and it's final release with EE 10.
Could we do better? Probably. So far, this problem hasn't risen to the level of staffing the task to create a separate Interceptor TCK. In my opinion, we should strive to keep the component certifications as independent as possible -- where we can, we can
tighten up requirements for non-platform implementations and bolster those with independent TCKs -- however that is a goal that we continue to work toward.
The CDI specification refers to other specifications as well. These other specifications may not be as central to the operation of CDI but the fact those specifications are not yet final could also have a knock-on impact to a final CDI promotion.
We can and should work to improve this web of dependencies. It's imperfect and we can improve it, but I believe it does a good job of preserving component independence and providing strong compatibility for our users.
From what I've seen, when it's ready, CDI should proceed to ballot using the currently defined Interceptor 2.1 API -- we can promote CDI 4.0 RC to final status once the ballot succeeds and so long as there are no further substantive changes to Interceptor
2.1, Interceptor can later be promoted to final status without forcing us to re-release CDI or re-release previously produced applications.
I'd appreciate your reactions.
Cheers,
-- Ed
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
