-
Notifications
You must be signed in to change notification settings - Fork 218
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
AmazonS3InstallationService add constructor #1168
base: main
Are you sure you want to change the base?
AmazonS3InstallationService add constructor #1168
Conversation
Thanks for the contribution! Before we can merge this, we need @smallufo to sign the Salesforce Inc. Contributor License Agreement. |
Codecov Report
@@ Coverage Diff @@
## main #1168 +/- ##
============================================
- Coverage 75.25% 75.20% -0.06%
- Complexity 4004 4005 +1
============================================
Files 430 430
Lines 12528 12538 +10
Branches 1261 1262 +1
============================================
+ Hits 9428 9429 +1
- Misses 2355 2362 +7
- Partials 745 747 +2
... and 1 file with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for submitting this PR, but we're yet unable to merge this PR as-is. There are a few things to consider:
- decide better constructor interface design
- need to do the same for AmazonS3OAuthStateService
- write some tests as much as possible
We may add built-in constructor for your use case in the near future (it may be based on this PR) but it's not our top priority right now. So, if you're already happy with your own implementation, please go ahead with it.
Thanks again for your time to work on this!
import org.jetbrains.annotations.NotNull; | ||
import org.jetbrains.annotations.Nullable; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you remove these annotations? We consistently don't use them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure ,please do as you wish. I add them because I see them in the dependency graph
public AmazonS3InstallationService(String bucketName) { | ||
this.bucketName = bucketName; | ||
} | ||
|
||
@Override | ||
public Initializer initializer() { | ||
return (app) -> { | ||
if (region != null) { | ||
System.setProperty("AWS_REGION" , region); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the system prop name can be the same with env variable. The key should be "aws.region"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, modifying the global system properties this way is not a generally recommended programming pratice. Instead, you can simply instantiate credential object to avoid affecting any other parts of your app.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I saw different codes ("AWS_REGION" , "aws.region") in the whole AWS code base , I am not familiar with this (searching environment / system variables). I am not also favor of this type.
You can modify to the correct variable name
private final String bucketName; | ||
private boolean historicalDataEnabled; | ||
|
||
public AmazonS3InstallationService(@Nullable String region, @NotNull String accessKey, @NotNull String secretKey, @NotNull String bucketName) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having four string arguments is not a very easy-to-use interface. more importantly this is not flexible enough for future enhancement. I think receiving a single object representing crendential inputs (either AWS SDK's class or a custom class with builder interface) + bucketName works better for this use case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, depends on you. Just provide a constructor for user to prepare necessary values/keys. Rather than deep digging the system looking for variables.
This also eases testing / mocking.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Point : Let user control what is inputed .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we also think to migrate to newer version of AWS SDK v2? I have attached the screenshot of official announcement from Amazon SDK Github: https://github.com/aws/aws-sdk-java
@acharyashashank Oh, thanks for letting us know this! We'll resolve the issue separtely and ship a new minor version that upgrades the version as early as possible. |
This pull request may resolve #1165
Category (place an
x
in each of the[ ]
)Requirements
Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you agree to those rules.