add debug exporter, move code from logging exporter into internal

[codeboten]

Alternative to #8375

This moves most of the code from the logging exporter into two internal packages that will eventually end up in the debugexporter once the loggingexporter has been removed.

Fixes #7769

[codeboten]

@dmitryax @jpkrohling please have a look at this PR as an alternative to "aliasing" the logging exporter.

Pros:

• not causing the debug exporter to depend on the logging exporter
• no longer adds a new public method to the logging exporter.

Cons:

• code that was internal to the logging exporter is now in an exporter/internal package
• there is some amount of duplication in the code

[codecov]

Codecov Report

Patch coverage is 89.25% of modified lines.

Files Changed	Coverage
client/client.go	ø
exporter/internal/common/logging_exporter.go	ø
exporter/internal/otlptext/databuffer.go	ø
exporter/internal/otlptext/known_sync_error.go	ø
exporter/internal/otlptext/logs.go	ø
exporter/internal/otlptext/metrics.go	ø
exporter/internal/otlptext/traces.go	ø
exporter/internal/otlptext/sync.go	58.33%
exporter/internal/common/factory.go	81.81%
cmd/otelcorecol/components.go	100.00%
... and 3 more

📢 Thoughts on this report? Let us know!.

[dmitryax]

Why can't we move this one to internal?

[codeboten]

We could, it just didn't seem to really fit, i guess i could create an exporter/internal/loggingcommonexporter package or something like it

[dmitryax]

Yeah, something like that. I'm just thinking of how we can reduce the code duplication. Looks like it's technically possible. If so, I'd merge this PR and do that later rather than #8375

[jpkrohling]

Is this to address this comment?

I believe it's better to have all the code in the new module to avoid making changes to the deprecated one.

If so, wouldn't it be sufficient to move the code from logging to debugging, keeping logging as the wrapper to the new one?

[codeboten]

• not causing the debug exporter to depend on the logging exporter
• no longer adds a new public method to the logging exporter.

@jpkrohling the advantages are really not having to create a dependency between the two modules moving forward and avoiding having to add a public method. With the latest change, there's little code duplication. PTAL

[jpkrohling]

the advantages are really not having to create a dependency between the two modules moving forward

Is it a big problem? I mean, you are in the end creating the same dependency through a proxy, which is the common library, no? If you change the debug exporter, we need to either change the common library or fork the code, which is pretty much what we'd have to do if we had the logging exporter wrapping the debug exporter.

and avoiding having to add a public method

It was caused by the desire to share the createDefaultConfig implementation in the factory, right? It's such a small function. Wouldn't it be worth just having two implementations of it and of the factory? The logging exporter's factory could just use the debug exporter's factory. Wouldn't it work?