Skip to content
This repository has been archived by the owner on Jul 1, 2022. It is now read-only.

Polish configuration API #411

Merged

Conversation

pavolloffay
Copy link
Member

@pavolloffay pavolloffay commented May 15, 2018

Resolves #394

  • there are getters for all configuration properties
  • codec configuration can be created programmatically
  • allow overriding service name

Configuration can be created programmatically o via env. If it is created via env all properties can be changed programmatically.

Signed-off-by: Pavol Loffay ploffay@redhat.com

@ghost ghost assigned pavolloffay May 15, 2018
@ghost ghost added the review label May 15, 2018
@codecov
Copy link

codecov bot commented May 15, 2018

Codecov Report

Merging #411 into master will increase coverage by 0.09%.
The diff coverage is 92.3%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master     #411      +/-   ##
============================================
+ Coverage     82.24%   82.33%   +0.09%     
- Complexity      487      490       +3     
============================================
  Files            66       66              
  Lines          2033     2044      +11     
  Branches        247      247              
============================================
+ Hits           1672     1683      +11     
+ Misses          280      279       -1     
- Partials         81       82       +1
Impacted Files Coverage Δ Complexity Δ
.../src/main/java/io/jaegertracing/Configuration.java 81.56% <92.3%> (+0.97%) 37 <3> (+4) ⬆️
...aegertracing/samplers/RemoteControlledSampler.java 77.77% <0%> (-1.02%) 17% <0%> (-1%)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6f75dfe...ec99621. Read the comment docs.

public CodecConfiguration() {
}

public CodecConfiguration withCodec(Format<?> format, Codec<TextMap> codec) {

Choose a reason for hiding this comment

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

Yay!!

@aaronkorver
Copy link

A note, not necessary on this PR as I can open a separate issue, the withTags() would be great if there was exposed a withTagsFromEnv() as well that could use the private method that is currently in the config.

@pavolloffay
Copy link
Member Author

@aaronkorver you can call c = Configuration.fromEnv() then c.getTags() and then c.withTags(tags) to fully manipulate with tags.

@aaronkorver
Copy link

right, but I can't call the parser function in Configuration as it is private right now. I have some teams that want to take advantage of the JAEGER_TAGS environment. My team has been providing a library for tracing and want them to use it as well, but have basically cut/paste that function into our library so we can configure certain things from the ENV, but override other pieces. Hence the suggestion to do withTagsFromEnv()

@pavolloffay
Copy link
Member Author

I am not sure whether method c.withTagsFromEnv() makes sense as the tags from env are obtained during Configuration.fromEnv().

We could perhaps expose map = Configuration.tracerTagsFromEnv() , then you can get tags from env and programmatically mix things together. Oh wait actually right now you can call fromEnv() and get parsed tags from the configuration.

@@ -280,8 +280,14 @@ public void setStatsFactory(StatsFactory statsFactory) {
/**
* @param metricsFactory the MetricsFactory to use on the Tracer to be built
*/
public void withMetricsFactory(MetricsFactory metricsFactory) {
public Configuration withMetricsFactory(MetricsFactory metricsFactory) {
Copy link
Member Author

Choose a reason for hiding this comment

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

This shouldn't break clients

Signed-off-by: Pavol Loffay <ploffay@redhat.com>
Signed-off-by: Pavol Loffay <ploffay@redhat.com>
@pavolloffay pavolloffay force-pushed the polish-configuration-api branch from d3e436e to 17ea0a1 Compare May 15, 2018 17:52
@aaronkorver
Copy link

So are you recommending that you should first do myConfig = Configuration.fromEnv() and then change things within myConfig? The unfortunate part on that is the getTracerTags() returns an unmodifiableMap() that I can't merge things.

@pavolloffay
Copy link
Member Author

So are you recommending that you should first do myConfig = Configuration.fromEnv() and then change things within myConfig

Yes, the map is unmodifiable for a purpose, you can do m = new HasMap<>(unmodifiableMap)

@pavolloffay pavolloffay requested a review from jpkrohling May 16, 2018 08:10
Signed-off-by: Pavol Loffay <ploffay@redhat.com>
Copy link
Collaborator

@jpkrohling jpkrohling left a comment

Choose a reason for hiding this comment

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

Apart from a small request, this LGTM

@@ -328,6 +333,14 @@ public void testNoServiceName() {
new Configuration(null);
}

@Test
public void testOverrideServiceName() {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can you add a test using withServiceName(null), and another with withServiceName("")? This should document what is expected to happen in such case.

Copy link
Member Author

Choose a reason for hiding this comment

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

It's not strictly related to this PR, but I am happy to add it.

Test for null service name is already there, I have added only for empty case.

Signed-off-by: Pavol Loffay <ploffay@redhat.com>
@@ -328,6 +333,19 @@ public void testNoServiceName() {
new Configuration(null);
}

@Test(expected = RuntimeException.class)
public void testEmptyServiceName() {
new Configuration("");
Copy link
Collaborator

Choose a reason for hiding this comment

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

I actually thought about having the null overriding a valid existing name:

new Configuration("Test").withServiceName(null);

This way, you'd be documenting the expected behavior for this scenario, as it might be ambiguous. This is not required, so, I'm giving my +1 to this PR.

Copy link
Member Author

Choose a reason for hiding this comment

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

The check is also in tracer constructor, but in this case we wanted to fail before tracer-init time

@pavolloffay pavolloffay merged commit 818d741 into jaegertracing:master May 16, 2018
@ghost ghost removed the review label May 16, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants