Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG-3581] [Code Style] HttpStatus & Headers should not be imported from org.apache.hc.core5.http #3663

Conversation

prabhask5
Copy link
Contributor

@prabhask5 prabhask5 commented Nov 7, 2023

Description

Accounts for refactor of Header and HttpStatus classes from hc.cor5.http to just http by adding checkstyle test, and manually refactoring all current occurrences of the illegal import. Additionally updated spotlessApply to make the refactor automatic on future cases of illegal import.

  • Category (Enhancement, New feature, Bug fix, Test fix, Refactoring, Maintenance, Documentation)

Bug fix/refactor

  • Why these changes are required?

Refer to #3581

  • What is the old behavior before changes and new behavior after changes?

Ideally nothing.

Issues Resolved

Is this a backport? If so, please add backport PR # and/or commits #
No.

Testing

Tests have been modified and should work before merging.

Check List

  • New functionality includes testing
  • New functionality has been documented
  • Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Signed-off-by: Prabhas Kurapati <[email protected]>
Signed-off-by: Prabhas Kurapati <[email protected]>
Signed-off-by: Prabhas Kurapati <[email protected]>
Signed-off-by: Prabhas Kurapati <[email protected]>
@prabhask5 prabhask5 changed the title Pk refactor illegal hc core5 import [BUG-3581] [Code Style] HttpStatus & Headers should not be imported from org.apache.hc.core5.http Nov 7, 2023
Signed-off-by: Prabhas Kurapati <[email protected]>
@prabhask5
Copy link
Contributor Author

@cwperks @scrawfor99 @DarshitChanpura @peternied Through updating the illegal import org.apache.hc.core5.http.Header, to org.apache.http.Header I'm getting a lot of type compilation errors that try unsuccessfully to cast org.apache.hc.core5.http.Header to org.apache.http.Header. Here is an example of one such error: /Users/prabhask/Documents/Internships/opensearch-security/src/test/java/org/opensearch/security/test/helper/rest/RestHelper.java:238: error: incompatible types: org.apache.http.Header cannot be converted to org.apache.hc.core5.http.Header

To solve this problem I can either manually add a cast to org.apache.hc.core5.http.Header whenever this error appears or change the imports of all the dependent classes to also exclude core5 or client5, both of which seem like bad solutions. Is there another way to solve this problem?

@reta
Copy link
Collaborator

reta commented Nov 7, 2023

@cwperks @scrawfor99 @DarshitChanpura @peternied Through updating the illegal import org.apache.hc.core5.http.Header,

@prabhask5 why org.apache.hc.core5.http.Header is illegal? The main branch uses Apache HttpClient 5 and should import these packages, the 2.x uses Apache HttpClient 4.x and should import org.apache.http.Header, there should be no attempts to do any kind of type casting.

@prabhask5
Copy link
Contributor Author

@cwperks @scrawfor99 @DarshitChanpura @peternied Through updating the illegal import org.apache.hc.core5.http.Header,

@prabhask5 why org.apache.hc.core5.http.Header is illegal? The main branch uses Apache HttpClient 5 and should import these packages, the 2.x uses Apache HttpClient 4.x and should import org.apache.http.Header, there should be no attempts to do any kind of type casting.

I'm referencing #3581 , if its not illegal I might be misunderstanding what the issue is saying.

@reta
Copy link
Collaborator

reta commented Nov 7, 2023

I'm referencing #3581 , if its not illegal I might be misunderstanding what the issue is saying.

Me neither, the security plugin uses RestClient which directly exports some of the Apache HttpClient 5 or 4.x APIs (depending on the branch).

@stephen-crawford
Copy link
Contributor

@prabhask5 thanks for being proactive on this.

Similar to @reta:

I am not sure what the original issue was referencing. I don't think that it will be possible to standardize the versions without significant refactoring. You will need to swap to the v4 equivalents for everything in main.

Eventually we will move to 3.0 and likely swap completely to v5 when we do.

I don't think it makes sense to spend too much time converting the versions back and forth.

@prabhask5
Copy link
Contributor Author

@prabhask5 thanks for being proactive on this.

Similar to @reta:

I am not sure what the original issue was referencing. I don't think that it will be possible to standardize the versions without significant refactoring. You will need to swap to the v4 equivalents for everything in main.

Eventually we will move to 3.0 and likely swap completely to v5 when we do.

I don't think it makes sense to spend too much time converting the versions back and forth.

So is this issue irrelevant then? @peternied Do you have some insight on this?

@peternied
Copy link
Member

Illegal has weighty connotations - I'd prefer to think of direct imports of ...hc.core5... as not advisable. The rational is that it makes our great auto-backporting tool not work for nearly any case where we are authoring test cases (which I hope is often!). There is more context in the issue [1].

@reta What do you think about this rational? After we release 3.0.0, we will still be supporting 2.x builds for a least a year, anything that helps make the backport process result in less merge conflicts is a solid win to me.

@peternied
Copy link
Member

@prabhask5 Looks like there are many merge conflicts that you'll need to resolve - I'd suggest a git merge origin/main YMMV

@prabhask5
Copy link
Contributor Author

@prabhask5 Looks like there are many merge conflicts that you'll need to resolve - I'd suggest a git merge origin/main YMMV

@peternied Sounds good. How do you recommend fixing the errors I'm getting? I have them copied below for convenience.

Through updating the illegal import org.apache.hc.core5.http.Header, to org.apache.http.Header I'm getting a lot of type compilation errors that try unsuccessfully to cast org.apache.hc.core5.http.Header to org.apache.http.Header. Here is an example of one such error: /Users/prabhask/Documents/Internships/opensearch-security/src/test/java/org/opensearch/security/test/helper/rest/RestHelper.java:238: error: incompatible types: org.apache.http.Header cannot be converted to org.apache.hc.core5.http.Header

To solve this problem I can either manually add a cast to org.apache.hc.core5.http.Header whenever this error appears or change the imports of all the dependent classes to also exclude core5 or client5, both of which seem like bad solutions. Is there another way to solve this problem?

@peternied
Copy link
Member

org.apache.hc.core5.http.Header and org.apache.http.Header are different implementations, they won't translate between one another. There are a couple of options to handle this:

  1. Don't attempt to convert these objects. While it isn't idea,l if the majority of the time we are using status codes and header constants ARE converted, that solves the majority problem.
  2. Create a shared interface / use another object at object declartions. Headers aren't very complex, it would be relatively easy to create or use another object that represented this key value pairing, then convert it in the RestHelper where it needs to be type specific.
  3. An even better solution some invents.

@prabhask5
Copy link
Contributor Author

org.apache.hc.core5.http.Header and org.apache.http.Header are different implementations, they won't translate between one another. There are a couple of options to handle this:

  1. Don't attempt to convert these objects. While it isn't idea,l if the majority of the time we are using status codes and header constants ARE converted, that solves the majority problem.
  2. Create a shared interface / use another object at object declartions. Headers aren't very complex, it would be relatively easy to create or use another object that represented this key value pairing, then convert it in the RestHelper where it needs to be type specific.
  3. An even better solution some invents.

@peternied I'm pretty confused on these solutions. The majority of the errors I'm getting are either functions where the new Header is not an applicable type for the parameter, but I can't edit these functions since they are in the Apache codebase. How should I fix these errors? The only solution I'm seeing is to manually cast to the new type of Header, which again I don't think is advisable. A more specific solution would help a lot, ty!

@peternied
Copy link
Member

@prabhask5 I might recommend going with the first option, remove changes for Headers for this PR. After the status codes have been aligned take a single file and see what it takes to get it working with a draft PR.

This change is already massive and providing feedback is non-trivial if you are running into build/runtime issues.

Signed-off-by: Prabhas Kurapati <[email protected]>
Signed-off-by: Prabhas Kurapati <[email protected]>
@prabhask5
Copy link
Contributor Author

prabhask5 commented Nov 14, 2023

@prabhask5 I might recommend going with the first option, remove changes for Headers for this PR. After the status codes have been aligned take a single file and see what it takes to get it working with a draft PR.

This change is already massive and providing feedback is non-trivial if you are running into build/runtime issues.

@peternied Done! Feel free to unblock tests.

Copy link
Member

@DarshitChanpura DarshitChanpura left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see mixed usages of 4 & 5. Also some classes still import Header from 5 vs 4, is that expected?
@reta thoughts?

@@ -16,6 +16,8 @@
import java.util.Map;

import com.carrotsearch.randomizedtesting.annotations.ThreadLeakScope;
import io.jsonwebtoken.SignatureAlgorithm;
import io.jsonwebtoken.security.Keys;
import org.apache.hc.core5.http.Header;
import org.apache.hc.core5.http.message.BasicHeader;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this seems to be unrelated. The original import for hc5 still remains as is

import io.jsonwebtoken.Claims;
import io.jsonwebtoken.Jwts;
import io.jsonwebtoken.security.Keys;

import org.apache.hc.core5.http.Header;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why only 1 of these 2 changed?

@@ -20,7 +20,7 @@
import com.carrotsearch.randomizedtesting.annotations.ThreadLeakScope;
import org.apache.hc.client5.http.classic.methods.HttpPost;
import org.apache.hc.core5.http.ContentType;
import org.apache.hc.core5.http.HttpStatus;
import org.apache.http.HttpStatus;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be a mixed usage between 4 & 5?

@@ -22,7 +22,8 @@
import java.util.stream.Collectors;

import com.carrotsearch.randomizedtesting.annotations.ThreadLeakScope;
import org.apache.hc.core5.http.HttpStatus;
import joptsimple.internal.Strings;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is this import? is it being used?

@@ -15,6 +15,7 @@
import java.util.List;

import org.apache.hc.core5.http.Header;

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: seems like this import was not replaced

@@ -11,10 +11,8 @@

package org.opensearch.security.system_indices;

import java.io.IOException;

import org.apache.hc.core5.http.Header;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be org.apache.http.HttpStatus

Signed-off-by: Prabhas Kurapati <[email protected]>
@prabhask5 prabhask5 closed this Nov 19, 2023
@prabhask5 prabhask5 deleted the pk-refactor-illegal-hc-core5-import branch November 19, 2023 09:14
@prabhask5
Copy link
Contributor Author

Closed PR due to git issues new PR here: #3741

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants