This repository has been archived by the owner on Jun 10, 2020. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 120
Ability to add telemetry processors through DI #445
Merged
dnduffy
merged 2 commits into
microsoft:develop
from
karolz-ms:dev/karolz/telemetry-processor-di
May 16, 2017
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
26 changes: 26 additions & 0 deletions
26
test/Microsoft.ApplicationInsights.AspNetCore.Tests/FakeTelemetryProcessor.cs
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,26 @@ | ||
namespace Microsoft.ApplicationInsights.AspNetCore.Tests | ||
{ | ||
using System; | ||
using Microsoft.ApplicationInsights.Channel; | ||
using Microsoft.ApplicationInsights.Extensibility; | ||
|
||
internal class FakeTelemetryProcessor : ITelemetryProcessor | ||
{ | ||
private readonly ITelemetryProcessor next; | ||
|
||
public FakeTelemetryProcessor(ITelemetryProcessor next) | ||
{ | ||
if (next == null) | ||
{ | ||
throw new ArgumentNullException(nameof(next)); | ||
} | ||
|
||
this.next = next; | ||
} | ||
|
||
public void Process(ITelemetry item) | ||
{ | ||
this.next.Process(item); | ||
} | ||
} | ||
} |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Actually, I wonder if we should remove the if statement altogether and let it fall through to the (potentially empty)
foreach
followed by.Build()
. In the case where users have manually added to theTelemetryProcessorChainBuilder
, someone needs to call.Build()
and this might be the most appropriate place.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 think whoever adds manually to the
TelemetryProcessorChainBuilder
should also take care of callingBuild()
. We do, so we call. CallingBuild()
"just in case" is a little dubious. The original code did not do that and I did not want to change this.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.
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.
BTW, quick pulse telemetry module and telemetry processor need to know about each other. This link between them will not survive thru the re-
Build()
. SoInitialize
on module should be called afterBuild
on the chain.Can this be achieved in this case?
(real solution will be to change the design of quick pulse)
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.
@karolz-ms and @pharring Would we have a "race" condition where someone could add a processor factory after we call Build()? Something like the issue with calling both UseApplicationInsights and AddApplicationInsightsTelemetry?
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.
@SergeyKanzhelev The code that this change is adding runs before quick pulse telemetry module and processor are added/initialized. So I believe we are fine here?
I agree that quick pulse implementation should probably be changed. This dependency between its telemetry module and telemetry processor is making things unnecessarily fragile. Do you want me to open an issue for this?
@dnduffy In general TelemetryProcessorChainBuilder.Use() is just adding a TP factory to the chain builder. The Build() call is what instantiates the chain. Each time Build() is called the chain is instantiated from scratch, or at least this is the current implementation. So it is fine to Use(TP factory), then call Build(), then Use(another TP factory), then call Build() again. That is--IF there are no dependencies like quick pulse has today. But that is a separate issue that I am not trying to address here.
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 just realized what I was thinking of, it wasn't the Use/Build of the processor chain but the fact that internal helper methods were causing the re-adding of the extra processors etc.