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

NetClientAttributesAdapter - favor composition over inheritance #5030

Merged
merged 14 commits into from
Jan 20, 2022

Conversation

breedx-splk
Copy link
Contributor

The goal here is to reduce the number of responsibilities in the NetClientAttributesExtractor (single responsibility principle) and to favor composition/delegation over inheritance. To do this, we extracted the abstract methods to an interface named NetClientAttributesAdapter, which the NetClientAtrributesExtractor delegates to. This allows it to now be made concrete (and final). The existing implementations are migrated to the new interface instead of extending NetClientAttributesAdapter.

To reduce the scope of this change (which already touches a lot of code), this does not include a similar change to the NetServerAttributesExtractor, but I think we should have parity via a follow-up PR.

@breedx-splk breedx-splk requested a review from a team January 7, 2022 04:31
@trask
Copy link
Member

trask commented Jan 7, 2022

hey @breedx-splk! there was some related discussion in #3131

it didn't seem like having the instrumentation library deal with two types was worth it (e.g. in this case NetClientAttributesExtractor and NetClientAttributesAdapter), though @anuraaga had a thought to mitigate that

also, if we decide to do this for Net(Client|Server)AttributesExtractor, I assume we would do it for Http(Client|Server)AttributesExtractor, DbAttributesExtractor, CodeAttributesExtractor, RpcAttributesExtractor, and MessagingAttributesExtractor too?

@breedx-splk
Copy link
Contributor Author

hey @breedx-splk! there was some related discussion in #3131

Thanks, I didn't realize this had come up before.

it didn't seem like having the instrumentation library deal with two types was worth it (e.g. in this case NetClientAttributesExtractor and NetClientAttributesAdapter), though @anuraaga had a thought to mitigate that

I dunno, I think it's worth it. Maybe it's worth getting @anuraaga to chime in again.

also, if we decide to do this for Net(Client|Server)AttributesExtractor, I assume we would do it for Http(Client|Server)AttributesExtractor, DbAttributesExtractor, CodeAttributesExtractor, RpcAttributesExtractor, and MessagingAttributesExtractor too?

I think definitely that would be the longer term goal....to be consistent in eliminating inheritance as an api mechanism.

@trask
Copy link
Member

trask commented Jan 12, 2022

@breedx-splk we discussed in yesterday's SIG and there is support for this change 👍

one suggestion is to rename NetClientAttributesAdapter to NetClientAttributesGetter (naming sort of matches TextMapGetter)

@breedx-splk breedx-splk force-pushed the split_attribute_adapter branch from 53aafff to 5061002 Compare January 12, 2022 16:49
Copy link
Member

@mateuszrzeszutek mateuszrzeszutek left a comment

Choose a reason for hiding this comment

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

Nice 👍

Copy link
Member

@trask trask left a comment

Choose a reason for hiding this comment

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

can you do one more pass through to change remaining adapter to getter terminology?

@breedx-splk
Copy link
Contributor Author

I think I got them all now.

@trask
Copy link
Member

trask commented Jan 15, 2022

@breedx-splk
Copy link
Contributor Author

go to https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/5030/files and search for adapter, I still see 96 matches

Ah, lots of local variable names that didn't make it through the rename. I'll get out the mop....

@breedx-splk breedx-splk force-pushed the split_attribute_adapter branch from 781fffb to 42d2122 Compare January 19, 2022 18:27
Copy link
Member

@trask trask left a comment

Choose a reason for hiding this comment

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

there's a couple remaining references to "adapter" term, if you don't mind updating those too, then let's get this merged!

@trask trask merged commit c5c0a2b into open-telemetry:main Jan 20, 2022
RashmiRam pushed a commit to RashmiRam/opentelemetry-auto-instr-java that referenced this pull request May 23, 2022
…-telemetry#5030)

* first pass at separating NetAttributesAdapter interface and make NetClientAttributesExtractor concrete

* rename the implementations extractor -> adapter

* hide constructor and make factory method

* rename to client and add javadoc

* spotless

* finish javadoc thought

* rebase

* renamed NetClientAttributesAdapter to NetClientAttributesGetter

* fix lettuce

* code review comments

* code review comments -- renaming for consistency

* adapter -> getter

* fix ratpack

* adapter -> getter
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.

3 participants