Hi! Did you have checked against the latest code? It's ActiveMQServerPlugin,
something like that:
public interface ActiveMQServerPlugin extends
ActiveMQServerBasePlugin,
ActiveMQServerConnectionPlugin,
ActiveMQServerSessionPlugin,
ActiveMQServerConsumerPlugin,
ActiveMQServerAddressPlugin,
ActiveMQServerQueuePlugin,
ActiveMQServerBindingPlugin,
ActiveMQServerMessagePlugin,
ActiveMQServerBridgePlugin,
ActiveMQServerCriticalPlugin {
}
Jiri Daněk <jda...@redhat.com> 于2019年8月1日周四 上午4:48写道：
> On Tue, Aug 21, 2018 at 12:23 PM Lohmann Carsten (INST/ECS4) <
> carsten.lohm...@bosch-si.com> wrote:
>
> > >
> > > This kind of distributed tracing seems almost like logging frameworks
> > where
> > > eventually a facade like slf4j was developed to support all the
> different
> > > individual frameworks.
> > >
> > > In any event, I definitely think it's best at this point simply for the
> > > broker to expose hooks (e.g. ActiveMQServerPlugin) rather than
> integrate
> > a
> > > particular solution (as Michael has already suggested).
> >
> > ok, makes sense. I can understand the points made previously about not
> > wanting to integrate it in the broker at this point.
> >
> > > I also think the code should be hosted in a separate repository so it
> can
> > > have its own release cycle, etc. The broker documentation could
> > certainly
> > > have a chapter on distributed tracing which links to the other repo,
> > though.
> >
> > Good. So, it'll be a solution based on a broker plugin/interceptors. And
> > opentracing-contrib looks like the preferred place to put it.
> >
>
> Where does the Artemis plugin/interceptor live at this moment? I looked for
> it but did not find it. Thanks.
> --
> Mit freundlichen Grüßen / Kind regards
> Jiri Daněk
>
