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

Do not use empty system properties for endpoint #135

Closed
wants to merge 1 commit into from

Conversation

timuralp
Copy link
Contributor

@timuralp timuralp commented Mar 3, 2022

When configuring the endpoint, jclouds should use the default endpoint
value if an empty string is passed via system properties.

When configuring the endpoint, jclouds should use the default endpoint
value if an empty string is passed via system properties.
putAllAsString(propertiesPrefixedWithJcloudsApiOrProviderId(getSystemProperties(), apiMetadata.getId(), providerId), defaults);
Map<String, Object> system = propertiesPrefixedWithJcloudsApiOrProviderId(getSystemProperties(), apiMetadata.getId(), providerId);
if (Strings.isNullOrEmpty((String) system.get(PROPERTY_ENDPOINT))) {
system.remove(PROPERTY_ENDPOINT);
Copy link
Member

Choose a reason for hiding this comment

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

I don't strongly oppose this but why does the caller set an empty string? Should we check all keys to see if they are empty? Should we do other input validation like checking whether the endpoint is a URL?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think storing endpoint as a URL rather than a string would be preferable. I think the confusing part is that setting a system property like -Djclouds.endpoint= means an empty endpoint, rather than one that is not set, like here: https://github.com/gaul/s3proxy/blob/master/Dockerfile#L35

Copy link
Member

Choose a reason for hiding this comment

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

Does it make more sense for the application not to set a value when it doesn't have a value? This seems like a weird quirk of an application's configuration (environment variables) that makes more sense to address in the application than in jclouds itself.

Also I believe that System.getProperties().remove() is thread-safe but can mess up iteration order and anyway modifying global state is a bad idea.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe. I'll submit an s3proxy change for the same.

The above doesn't mutate System.getProperties() -- the map is populated with the values from system properties, API metadata, and provider metadata and then the key is removed from that map. Maybe I should've used a better variable name, but I don't see how the global state is mutated.

Copy link
Member

Choose a reason for hiding this comment

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

Sorry I did not realize that propertiesPrefixedWithJcloudsApiOrProviderId returned a new Map instead of mutating the existing one.

@gaul
Copy link
Member

gaul commented Oct 13, 2022

Closing since I'm not comfortable with this change.

@gaul gaul closed this Oct 13, 2022
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.

2 participants