[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[jakarta.ee-spec.committee] Questions regarding Interceptors and CDI from Committee meeting of 2022.02.09
|
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).
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