Brandon Johnson

From a cursory glance at the code, I don't think `otel.jmx.groovy.script` is configurable through the receiver. The jmx gatherer config is completely generated by the receiver in this function, and...

> @BinaryFissionGames I'm working on this issue and needed a clarification. So what you want basically is to transfer all the settings that additonal parameter http.Client brings (transport, timeout, JAR)...

I think logically, you'd consider this part of the `AgentDescription`. I'd personally advocate for adding it there if possible. I think the primary advantage we discussed for the separate message...

Regarding the structure of the field, how would you propose representing the components for the collector in a map[string]string? Additionally, I feel like arbitrary metadata describing agent is already covered...

We discussed this again today at the SIG. We primarily discussed adding this information to the ComponentHealth message, or to the AgentDescription.

Here's what I'm thinking in terms of concrete details: We could imagine doing something like this: ```protobuf message AgentDescription { // ... snip ... // // The list of components...

@tigrannajaryan @andykellr Seeing any immediate issues with the above? If not, I can write it up and put it in a PR.

Mirroring ComponentHealth definitely makes sense, I think that would end up something like this: ```protobuf message AgentDescription { // ... snip ... // ComponentDetails component_details = 4; } message ComponentDetails...

This makes sense to me. I think we'd use the same structure that exists in the current PR right now, just move it out of AgentDetails to the top level:...

> would adding a hash for the entire message be of use? - Meaning the server could compare and only take whatever action it desired should the hash be different...