2.1.x-Backport

[mkarg]

This PR is a backport of select bug fixes between 2.1.5 and master:HEAD into 2.1.6-SNAPSHOT (EE4J_8).

As these are no API changes, and as all these changes are already contained in master I propose a fast-track review period of just one day as per our recently update committer rules.

[mkarg]

@mszabo-wikia Can you please renew your Eclipse Contributor Agreement?

[asoldano]

@mkarg , I'm not sure we should really be merging this changes to EE4J_8 branch. Wouldn't that mean breaking backward compatibility? We would end up with EE8 and JakartaEE8 having different behavior when it comes to MediaType#isCompatible, wouldn't we?

[mkarg]

@asoldano Yes the behaviour would be changed, but in the way of a bug fix, so I think it is correct to backport it.

[mkarg]

Now that we have reactivated the branch EE4J_8 we should take care to keep it up-to-date wrt to bug fixes and clarifications. Hence I propose to cherry-pick (at least) the these two commits attached. If you think we should add more, let's keep things simple: Instead of having one PR per commit to cherry-pick, you can simply send a commit number to add to this PR. So we only need one voting for all. :-)

Regarding the Travis fail: This is a bug of Travis, I already opened a ticket with their support.

[mkarg]

Thanks to Travis CI Support! All checks now have passed now.

[chkal]

+1 for backporting both commits.

[spericas]

Although these are really good changes and clarifications, I'm on the fence about pushing them to Jakarta EE 8. As I understand it, existing EE 8 implementations will not be updated for Jakarta EE 8, and the clarification regarding MBR's and MBW's may result in existing implementations to be "incompatible". I'm less worried about the other changes, but I see @asoldano has some concerns.

[mkarg]

@spericas We had the discussion already, and the majority was for backporting it into Jakarta EE 8. The justification was that the existing products are not incompatible but simply buggy. Hence they SHOULD get fixed, but won't lose their compliance state even if not.

[chkal]

@spericas You already agreed to backport those fixes. See #700 (comment) and #711 (comment). Any reason for changing your opinion about this?

[spericas]

@chkal Yes, it's in my comment above. I didn't considered at the time that only API jars will be touched for Jakarta EE 8. Also note that I didn't vote -1, but simply shared the concern from @asoldano.

[spericas]

@spericas We had the discussion already, and the majority was for backporting it into Jakarta EE 8. The justification was that the existing products are not incompatible but simply buggy. Hence they SHOULD get fixed, but won't lose their compliance state even if not.

If you get the votes, you should push it. I'm +0.

[mkarg]

@spericas @chkal Let's ask the one why is affected mostly...: @asoldano What is your vote on this?

[asoldano]

@mkarg @spericas @chkal please give me a bit of time to check a couple of things here before answering.

[jimma]

If this change will break backward compatibility somehow, I think we'd better to only fix this in 2.2 and
don't back port to 2.1.x branch. This will be helpful for user migrate to JakartaEE8 with less pain. If user's application, provider or filer uses jaxrs 2.1 version isCompatible() works, it's better that this still works in JakartaEE8 without change their code and rebuild all things.

[spericas]

@asoldano If you can provide some feedback today, it would help with the release process. Thanks.

[asoldano]

I've been thinking about this for some time and frankly I'm still concerned about backward compatibility here. My understanding is that JakartaEE 8 is expected to be equivalent to JavaEE 8. Vendors are most likely going to "move" to JakartaEE in minor releases, as it comes with no new features. Users will be expecting the same behaviour out of their applications after having moved to JakartaEE 8. Because of that, the change to MediaType is risky, as an application might be directly relying on it. This looks like an edge case and not really a critical fix, which is what would justify the merge on EE4J_8 branch.
As for the other change, as long as the TCK does not enforce the clarified behaviour and hence implementations that have been assuming a different behaviour so far would still be considered as compliant, I would be fine with merging. Even if that's not a great situation (spec implementors would have to be fixed while having a configuration option for retaining the previous backward compatible behavior), at least user application wouldn't be affected by default.
As a consequence, despite the changes here being good, I'm sorry but think I need to cast a -1 to this PR. These changes fit 2.2+ IMO.

[asoldano]

-1, as per my previous comment

[spericas]

Thanks for the feedback @asoldano. In that case, I think we should close this PR. Do you agree @mkarg?

[mkarg]

@spericas I agree to drop all commits that are -1, but do I understand that @asoldano is OK with eacb77e. Is that correct? So I would reduce the PR to that one.

[mkarg]

@asoldano @chkal Dropped the disputed commited from the PR. LGTY?

[asoldano]

@mkarg I still see the MediaType changes included here.

[mkarg]

@mkarg I still see the MediaType changes included here.

Sorry, my fault. Fixed it. Thanks! :-)

[spericas]

@mkarg Once we get this one in, I'd like to initiate the release process and work with the TCK team.

[mkarg]

@spericas Agreed. @asoldano +1?

[asoldano]

@mkarg @spericas for the MBR/MBW related change, my comment (#741 (comment)) still applies. So assuming the TCK won't be enforcing this, I'm +0 on this and we can proceed, considering approvals from others ;-)

[mkarg]

Alessio's vote means that the backport will not happen, as we do not have enough +1's. @spericas Do not wait for this PR, it will not make it in time.

[mkarg]

@eclipse-ee4j/eclipse-jaxrs I'm a bit disappointed to see that the majority of committers do not even vote with 0, but completely abstain from casting votes at all. :-(

[mkarg]

@asoldano Can you please remove your -1 as we fixed your requested changes?

[asoldano]

+0

Fixed

[spericas]

Given that it has not received the necessary votes, I will initiate the release process for Jakarta EE 8 without this PR. We can later decide to close it or revisit this discussion (if another release is necessary).