[
https://issues.apache.org/jira/browse/HTRACE-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14648143#comment-14648143
]
Colin Patrick McCabe commented on HTRACE-222:
---------------------------------------------
bq. This implicitly expect that constructer taking HTraceConfiguration as
argument. Should we add SpanReceiver#init(HtraceConfiguration) or catch
NoSuchMethodException and fall back to default constructor?
The current {{SpanReceiverFactory}} code already assumes that all
{{SpanReceiver}} constructors take an {{HTraceConfiguration}} as an argument.
So this isn't changing anything. It's simpler that way-- if the span receiver
doesn't need the configuration, it can just ignore that parameter. On the
other hand, if you want to add configurability to the span receiver later, this
makes it straightforward.
bq. Adding test below to TestSpanReceiverPool results in NoSuchMethodException.
Hmm. I think it makes sense to propagate the {{NoSuchMethod}} exception out of
{{SpanReceiverPool#getOrCreate}}. The only other thing we could do is swallow
the exception and return null, which seems more confusing than just letting the
calling code handle it (probably by logging it).
> Add SpanReceiverPool
> --------------------
>
> Key: HTRACE-222
> URL: https://issues.apache.org/jira/browse/HTRACE-222
> Project: HTrace
> Issue Type: Sub-task
> Affects Versions: 4.0
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
> Attachments: HTRACE-222.001.patch, HTRACE-222.002.patch
>
>
> Add SpanReceiverPool, a pool of span receivers which can be used by multiple
> Tracer objects.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)