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