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