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

fix(secret): fix wrong representation of Secret values & add payload #1088

Merged
merged 8 commits into from
Oct 9, 2017

Conversation

rschollmeyer
Copy link
Contributor

Some minor fixes to match the Barbican API.

@auhlig auhlig added this to the 3.1.1 Release milestone Sep 22, 2017
@auhlig
Copy link
Member

auhlig commented Sep 27, 2017

Many thanks @rschollmeyer. Could you extend the tests accordingly?

@rschollmeyer
Copy link
Contributor Author

Oh right. I'm on it!

@rschollmeyer
Copy link
Contributor Author

Actually there was not much to extend since the changes were mainly changes in representation.

Copy link
Member

@auhlig auhlig left a comment

Choose a reason for hiding this comment

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

Can we extend the getSecret() test by an assertEquals(secret.getExpiration, <some Date>)

Look very good besides comments.

@JsonProperty("updated")
private Date updateTime;
private String updateTime;
Copy link
Member

Choose a reason for hiding this comment

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

Why Date -> String?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because it is listed as a String in the Barbican API.

See here

Copy link
Member

Choose a reason for hiding this comment

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

I was asking, because changing the type is a breaking change and it might be more convenient for our Java client to have a Date here instead of a String. But since you're the author I would leave that up to you.
Besides this, this PR is ready to merge from my side.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Well, i get your point & Date would probably be better. I'll change it back

@rschollmeyer
Copy link
Contributor Author

rschollmeyer commented Sep 28, 2017

I thought of that too, but the Secret object that is returned when creating seems to only contain the reference.

Edit: Forget what i said. I read "createSecret()" instead of "getSecret()". Sure i can do that!

@rschollmeyer
Copy link
Contributor Author

Done the changes. Note that the output of Dates when calling GET for a secret is now "Mon Dec 28 19:17:44 UTC 2015" instead of "2015-12-28T19:14:44.180394" (as specified in the barbican API)

@@ -47,14 +48,25 @@ public void testGetSecret() throws IOException {
Secret secret = osv3().barbican().secrets().get(secretId);
assertNotNull(secret);
assertNotNull(secret.getName());
assertEquals(secret.getExpiration().toString(), expiration);
Copy link
Member

Choose a reason for hiding this comment

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

Instead of comparing the strings, I'd suggest to compare the Date types. Make sense? I promise that's the last comment @rschollmeyer.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure i can do that. Don't worry, i am thankful for every good critique!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

To be sure: do you mean to compare the date formats?

Copy link
Member

Choose a reason for hiding this comment

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

Compare assertEquals(secret.getExpiration(), expiration); where expiration is a Date object

@auhlig
Copy link
Member

auhlig commented Oct 9, 2017

Perfect. Thanks for all the work @rschollmeyer 💯

@auhlig auhlig merged commit a5a66aa into ContainX:master Oct 9, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants