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