-
Notifications
You must be signed in to change notification settings - Fork 867
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
NetClientAttributesAdapter - favor composition over inheritance #5030
Conversation
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? |
Thanks, I didn't realize this had come up before.
I dunno, I think it's worth it. Maybe it's worth getting @anuraaga to chime in again.
I think definitely that would be the longer term goal....to be consistent in eliminating inheritance as an api mechanism. |
@breedx-splk we discussed in yesterday's SIG and there is support for this change 👍 one suggestion is to rename |
53aafff
to
5061002
Compare
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.
Nice 👍
...n/java/io/opentelemetry/instrumentation/api/instrumenter/PeerServiceAttributesExtractor.java
Outdated
Show resolved
Hide resolved
...pentelemetry/javaagent/instrumentation/apachehttpclient/v2_0/ApacheHttpClientSingletons.java
Outdated
Show resolved
Hide resolved
...src/main/java/io/opentelemetry/javaagent/instrumentation/lettuce/v4_0/LettuceSingletons.java
Outdated
Show resolved
Hide resolved
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.
can you do one more pass through to change remaining adapter to getter terminology?
...in/java/io/opentelemetry/instrumentation/api/instrumenter/net/NetClientAttributesGetter.java
Outdated
Show resolved
Hide resolved
I think I got them all now. |
go to https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/5030/files and search for |
Ah, lots of local variable names that didn't make it through the rename. I'll get out the mop.... |
…lientAttributesExtractor concrete
781fffb
to
42d2122
Compare
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.
there's a couple remaining references to "adapter" term, if you don't mind updating those too, then let's get this merged!
…-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
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 namedNetClientAttributesAdapter
, which theNetClientAtrributesExtractor
delegates to. This allows it to now be made concrete (and final). The existing implementations are migrated to the new interface instead of extendingNetClientAttributesAdapter
.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.