[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [microprofile-wg] : Re: : Re: : [Discussion] Context Propagation 1.3 Specification Release Review
|
Ed,
There are no maintenance updates in 1.3. The classes within the 1.3 API
jar should be literally identical to those within the 1.2 API jar apart
from the timestamps indicating when they were built. The sole purpose of
the 1.3 release is to provide a TCK that Jakarta EE 9-based
implementations can use to certify their MicroProfile Context Propagation
implementation alongside their MicroProfile 5.0 features. I agree there
is no reason why an EE 8 user should want 1.3 rather than 1.2, because
nothing is gained from 1.3 unless you want a TCK with jakarta packages,
which you don't want if you are on EE 8.
From: "Ed Bratt" <ed.bratt@xxxxxxxxxx>
To: "Nathan Rauh" <nathan.rauh@xxxxxxxxxx>
Cc: "Microprofile WG discussions" <microprofile-wg@xxxxxxxxxxx>
Date: 11/18/2021 01:22 PM
Subject: Re: [External] : Re: : Re: [microprofile-wg] :
[Discussion] Context Propagation 1.3 Specification Release Review
Nathan, I'm okay with some type of compromise. I don't hold a controlling
vote and I also can't speak to what other members might think. My goal is
that we inform our users correctly and consistently so that we aren't
later, trying to recover ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Nathan,
I'm okay with some type of compromise. I don't hold a controlling vote and
I also can't speak to what other members might think.
My goal is that we inform our users correctly and consistently so that we
aren't later, trying to recover from unmet expectations. Some type of text
that indicates the core of this thread, that is 'likely' to be seen by a
prospective user/implementation vendor, would probably suffice.
I would not be in favor of suggesting that users change the TCKs -- unless
that is explicitly allowed for, in the TCK instructions and/or
documentation. Once this option starts to be available it becomes hard to
keep "oh, just this minor tweak" from happening. We should try to promote
the position that the TCKs as fixed -- with only very explicit, documented
exceptions allowed.
My preference would be that EE 8 users stick with 1.2 and EE 9 (and
beyond) users use 1.3. I'm not sure if there is already maintenance that
is in 1.3 that a 1.2 user would desire. That might complicate things.
Thank you for working with me on this question.
Cheers,
-- Ed
On 11/18/2021 7:11 AM, Nathan Rauh wrote:
> If there is an explicit statement in the specification text that says
this specification must be used with any particular version of Jakarta EE,
it didn't change.
This is correct. The specification has no statement requiring a particular
Jakarta EE version.
> If an implementer wants to upgrade their existing implementation from CP
1.2 to 1.3 -- and edit their POM.xml to point to CP 1.3 -- Would that new
implementation pass the TCK?
It depends on how well the existing implementation is written, whether
written in a modular fashion that implements only MicroProfile Context
Propagation, versus written in a tightly coupled manner with unrelated
stuff that might have other dependencies. If written in a modular
fashion, then yes, just swap out the binaries underneath and run it
against the TCK. The 1.3 TCK is provided in terms of jakarta package
names, so if anyone wants to run it with javax package names, they would
either need to transform it first or just use the identical 1.2 TCK which
is already in javax packages.
I understand your argument for wanting a new major version, but this exact
scenario was already brought forward and decided on for this release and
the 1.3 version is consistent with the decision that was made. Could a
compromise here be to revisit that discussion for subsequent MicroProfile
releases?
From: "Ed Bratt" <ed.bratt@xxxxxxxxxx>
To: "Microprofile WG discussions" <microprofile-wg@xxxxxxxxxxx>,
"Nathan Rauh" <nathan.rauh@xxxxxxxxxx>
Date: 11/17/2021 07:44 PM
Subject: Re: [External] : Re: [microprofile-wg] : [Discussion]
Context Propagation 1.3 Specification Release Review
Sorry, I wasn't trying to take a position, one way or another. I'm asking
what is required. It sounds like you are asserting that the CP spec. is
required to run with elements of an EE Platform. That's perfectly
reasonable. ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Sorry, I wasn't trying to take a position, one way or another. I'm asking
what is required. It sounds like you are asserting that the CP spec. is
required to run with elements of an EE Platform. That's perfectly
reasonable.
In the CP 1.3 spec. document the code-examples are all modified from javax
to jakarta. The other textual change is in "Other Changes" under Release
Notes for 1.3, at the end which says (paraphrasing): the TCK and Code
Examples are updated to use the Jakarta EE 9 namespace. If there is an
explicit statement in the specification text that says this specification
must be used with any particular version of Jakarta EE, it didn't change.
I think we agree, if the TCK is changed, that implies the Spec. is
changed.
If an implementer wants to upgrade their existing implementation from CP
1.2 to 1.3 -- and edit their POM.xml to point to CP 1.3 -- Would that new
implementation pass the TCK?
If the TCK can support either -- Jakarta EE 8 (and javax) or Jakarta EE 9
(and jakarta) -- then the answer to the previous question could be 'yes.'
If the TCK doesn't provide compatibility verification for EE 8 then, I
think the answer is 'no.'
Perhaps where I'm getting to is: if the 1.3 TCK can be used to verify
compatibility for EITHER Jakarta EE 8 or Jakarta EE 9, the minor release
increment is appropriate. If the TCK can ONLY verify compatibility for EE
9 -- to my way of thinking -- the upgrade is incompatible since we know
that EE 8 (with javax namespace) is incompatible with Java 9 (jakarta
n.s.).
I understand there are no substantive changes to CP. Honestly, it seems
easier to me (well, it would have been two months ago) to just change the
release designation to a major release -- rather than update the TCK to
support both versions of Jakarta EE. We already have a TCK that supports
EE 8 -- that's the CP 1.2 TCK. I've worked on other Specs. where we
decided that, even though there we were proposing no incompatible changes,
would be dependent on an updated Spec., that does contain incompatible
changes -- and we propagated that incompatible notion forward declaring a
major release.
Thanks,
-- Ed
On 11/17/2021 2:11 PM, Nathan Rauh wrote:
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
_______________________________________________
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
