[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [microprofile-wg] : [Discussion] Context Propagation 1.3 Specification Release Review
|
Ed,
MicroProfile Context Propagation has dependencies on Jakarta EE only in
that it defines a mechanism for capturing, establishing, clearing and
removing Jakarta EE context from threads (this includes java:comp namspace
of application components, JTA transactions, as well as other types, such
as CDI). It explicitly enumerates the interactions with these and other
types of context within the Context Propagation API and describes the
behaviors that you get, all without the Context Propagation API/SPI having
any direct code dependencies on the corresponding Jakarta EE components. I
have to disagree with your assertion that the lack of such dependencies
means that the TCK contains tests that are beyond the scope of the
specification. The fact that the specification defines
interactions/behaviors with Jakarta EE components is alone sufficient to
justify the TCK testing with this same set of Jakarta EE components that
the spec defines interactions with. The TCK should be testing these
things because, as you stated, the specification is ALL OF the written
documents, binaries, ... and so forth. And that makes the interactions
that are defined within those documents fair game for TCK testing.
From: "Ed Bratt" <ed.bratt@xxxxxxxxxx>
To: "Microprofile WG discussions" <microprofile-wg@xxxxxxxxxxx>
Date: 11/17/2021 01:24 PM
Subject: Re: [microprofile-wg] [External] : [Discussion] Context
Propagation 1.3 Specification Release Review
Sent by: "microprofile-wg" <microprofile-wg-bounces@xxxxxxxxxxx>
Emily, Thank you for starting a discussion 'side' thread. I didn't see
that happen before so I didn't realize that was our custom. I thought
there had been other plan reviews for MicroProfile component
specifications, but I see that I was mistaken ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Emily,
Thank you for starting a discussion 'side' thread. I didn't see that
happen before so I didn't realize that was our custom.
I thought there had been other plan reviews for MicroProfile component
specifications, but I see that I was mistaken in that impression. I would
encourage us to adopt that in future releases but I'm willing to concede
this is not an issue for MP 5 specifications and I apologize for raising
it as an concern for CP 1.3.
If the CP Specification truly has no dependencies on the Jakarta EE
components, I wonder if perhaps the TCK contains tests that are beyond the
scope of this Specification. I'd ask the development team: Is there an
Assertion that is traceable to the Specification (text or Java Docs),
tested in the TCK, that requires a specific Jakarta EE version. If there
is no such assertion, perhaps the Jakarta EE version elements in the TCK
are incorrect and should be removed. If the Specification documentation
does require a specific version of Jakarta EE -- then, this test should
remain. This would be consistent with David's suggestion, but changing the
TCK, at least in my book -- is a change to the Specification, to wit ...
I would encourage us to adopt the position that the Specification is ALL
OF the written document (the Specification document and/or Java Docs), the
Binary Artifacts (API JARs, etc), AND the TCK. These each provide
important aspects of the Specification and any change to a component
element, should be considered a change in the Specification.
In summary, if it is determined the CP 1.3 specification /does/ require
Jakarta EE 9, I'd encourage us to communicate that incompatibility to our
users and fellow implementer groups by designating this a major release,
not a minor release. If EE 9 is not a CP requirement, the minor version
change is totally appropriate and (probably) the TCK should omit those
tests.
I apologize for raising this so far into this project program.
Thank you,
-- Ed
On 11/17/2021 4:15 AM, Emily Jiang via microprofile-wg wrote:
I have a suggestion on the voting thread. If there are comments related to
the voting, I suggest we start a new thread so that the voting thread can
stay focused with the voting.
I started this discussion thread to follow the discussion on Context
Propagation 1.3 release.
As for MP Context Propagation 1.3, the spec and api are identical to MP
Context Propagation 1.2. I would say the api and spec produced in MP
Context Propagation 1.3 will work with either Jakarta EE 8 or Jakarta EE
9. In this context, the spec 1.3 is backward compatible with 1.2. In other
words, if you drop MP Context Propagation 1.3 api jar in your Jakarta EE 8
runtime, it works without any problem.
If you want to run the certification, you can use the tck jar produced by
MP Context Propagation 1.2, and use 1.3 for Jakarta EE 9. Therefore, you
may not need to transform any jakarta or javax.
Does this address your question, Ed?
p.s For minor vs. major releases for Jakarta EE 9.1 alignment, we
discussed this topic on one of our live hangouts (6th July). I asked the
minor release vs. major release question and suggested we do a minor
release for the specs with only tck dependencies on Jakarta EE. There were
no objections.
Thanks
Emily
On Tue, Nov 16, 2021 at 10:53 PM Emily Jiang <emijiang6@xxxxxxxxxxxxxx>
wrote:
As for plan review, after MicroProfile Working Group was established in
2020, we started with a release view. We did not put the plan review in
the process. We can revisit this in 2022. As a matter of fact, we will
start using the Plan Creation Review for new specs (see here). We should
follow the steps laid out by EFSP 1.3.
As for the minor vs major changes for Context Propagation, as mentioned in
the release plan, the api jar has no dependencies on javax, this release
is purely for any runtime that wishes to run its tcks using jakarta
namespace. I think minor changes make sense.
Therefore, I think the top option as suggested by David makes sense.
- Keep the minor version change and:
- be ok to accept CCRs from Jakarta EE 8 based impls that have used
bytecode tools to modify the CP 1.3 TCK itself back to the 'javax'
namespace
Thanks
Emily
On Tue, Nov 16, 2021 at 9:15 PM David Blevins <dblevins@xxxxxxxxxxxxx>
wrote:
On Nov 16, 2021, at 12:38 PM, Ed Bratt <ed.bratt@xxxxxxxxxx> wrote:
1) Was there an approved plan review for Context Propagation 1.3? (I'm
missing my record of that and apologize if I just lost this.)
Good callout. I think we've missed Plan Reviews in general:
- https://github.com/microprofile/microprofile-wg/labels/Plan%20Review
We definitely need to do those from now on.
2) All the other specifications are making major releases due to the
incompatible changes required by Jakarta 9.1. While the Context
Propagation API may not have a direct dependency on Jakarta EE APIs, it
seems the TCKs may. Is it confirmed this is a minor-release compatible
update? Should a user running on Jakarta EE 8, expect to be able to
upgrade their implementation to Context Propagation 1.3 successfully
without also upgrading their Jakarta EE dependency? Should a vendor
anticipate supporting both EE 8 and 9 with this release?
More good questions. I see that we did update the namespaces in the TCK.
I'd be hesitant to establish a rule where major changes in the TCK need to
result in a major version change. That said, we're not talking strictly
about changes in the TCK (say moving from Junit to TestNG) that do not
have an impact on the server itself. The change in the TCK does require a
change in the server and that creates some ambiguity in my mind.
Here are some potential resolutions that seem to make sense to me:
- Keep the minor version change and:
- be ok to accept CCRs from Jakarta EE 8 based impls that have used
bytecode tools to modify the CP 1.3 TCK itself back to the 'javax'
namespace OR
- issue our own javax version of the CP 1.3 TCK, which Jakarta EE 8
based impls can chose as an alternate to the jakarta namespace CP 1.3 TCK
- Update the major version
Any other options people see?
-David
_______________________________________________
microprofile-wg mailing list
microprofile-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/microprofile-wg
--
Thanks
Emily
--
Thanks
Emily
_______________________________________________
microprofile-wg mailing list
microprofile-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/microprofile-wg
_______________________________________________
microprofile-wg mailing list
microprofile-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/microprofile-wg
