Skip to content

Make OtlpExporter class internal#1528

Merged
cijothomas merged 5 commits intoopen-telemetry:masterfrom
alanwest:alanwest/internalize-exporter-class
Nov 13, 2020
Merged

Make OtlpExporter class internal#1528
cijothomas merged 5 commits intoopen-telemetry:masterfrom
alanwest:alanwest/internalize-exporter-class

Conversation

@alanwest
Copy link
Member

The constructor on all of our exporter classes is internal. I think making the class internal is the right thing to do. If so, I can expand this PR to make this change to zipkin, jaeger, etc.

Changes

Please provide a brief description of the changes here.

For significant contributions please make sure you have completed the following items:

  • CHANGELOG.md updated for non-trivial changes
  • Design discussion issue #
  • Changes in public API reviewed

@alanwest alanwest requested a review from a team November 12, 2020 22:43
/// the OpenTelemetry protocol (OTLP).
/// </summary>
public class OtlpExporter : BaseExporter<Activity>
internal class OtlpExporter : BaseExporter<Activity>
Copy link
Member

Choose a reason for hiding this comment

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

the ctor() was already internal, so we wont break anyone right?

Copy link
Member Author

@alanwest alanwest Nov 12, 2020

Choose a reason for hiding this comment

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

By the class being public, the type is visible, so a user can type var exporter = new OtlpExporter() ... but with no way to construct it, is there any value in exposing it?

Ah, sorry, I misread your question... it does not appear to break anything.

Copy link
Member

Choose a reason for hiding this comment

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

Agree.
I was thinking -- if a user want to write own Batching/SimpleExportprocessor, then they wont be able to do that, as they cannot construct the exporter. But its okay, as spec talks about only 2 ExportingProcessors. and #1504 will solve customization issues as well.

Copy link
Member Author

Choose a reason for hiding this comment

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

Right, if #1504 is the pattern we want going forward, then I don't think we need to expose the classes. We could always re-expose the classes with a public constructor if we saw some need for that in the future.

@codecov
Copy link

codecov bot commented Nov 12, 2020

Codecov Report

Merging #1528 (e38e168) into master (6c2c19a) will decrease coverage by 0.01%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1528      +/-   ##
==========================================
- Coverage   81.40%   81.39%   -0.02%     
==========================================
  Files         233      233              
  Lines        6358     6358              
==========================================
- Hits         5176     5175       -1     
- Misses       1182     1183       +1     
Impacted Files Coverage Δ
...try.Exporter.OpenTelemetryProtocol/OtlpExporter.cs 58.53% <ø> (ø)
...emetry.Api/Internal/OpenTelemetryApiEventSource.cs 79.41% <0.00%> (-2.95%) ⬇️

Copy link
Member

@cijothomas cijothomas left a comment

Choose a reason for hiding this comment

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

changelog please before merge.

@cijothomas cijothomas merged commit d363df8 into open-telemetry:master Nov 13, 2020
@alanwest alanwest deleted the alanwest/internalize-exporter-class branch March 9, 2021 18:47
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