Declarative config: output_stream is not implemented for otlp_file/development

[robintra]

What is missing

The declarative configuration schema defines an output_stream option on ExperimentalOtlpFileExporter and ExperimentalOtlpFileMetricExporter, accepting stdout or a scheme + destination such as file:///path/to/file.jsonl (schema/common.yaml).

The project's own support table reports Java as not_implemented for that option, while C++ and PHP report supported (language-support-status.md, sourced from meta_schema_language_java.yaml).

language	ExperimentalOtlpFileExporter	output_stream
C++	supported	supported
PHP	supported	supported
Java	supported	not_implemented

What already exists in this repo

Everything except the wiring:

• OtlpStdout{Span,Metric,LogRecord}ExporterBuilder.setOutput(OutputStream) already accepts an arbitrary stream (OtlpStdoutSpanExporterBuilder.java).
• The generated config model already carries the field, with the file:///path/to/file.jsonl javadoc (ExperimentalOtlpFileExporterModel.java).
• The component providers read memory_mode (and temporality / default aggregation for metrics) but never read output_stream (OtlpStdoutSpanExporterComponentProvider.java).

So the file destination is reachable programmatically, but not through configuration.

Why it matters

Producing an OTLP file from a CI run currently requires either application code or running a Collector purely to turn a network endpoint into a file.

experimental-otlp/stdout is not a usable substitute under a forked test runner: Maven Surefire and Failsafe use the fork's standard output as their command channel, so exporter output lands there and is reported as channel corruption in a .dumpstream. Observed with Failsafe 3.5.0, 3.2.5 and 2.22.2.

Relation to #7230

#7230 asked for an OTLP file exporter and was answered by pointing at OtlpStdout{Signal}Exporter, noting it "could be a rotating file output stream if you're willing to write some custom code". It was then closed as not_planned on 2026-01-02 by the stale bot after the author stopped responding, so the underlying question was never decided on its merits. This issue is narrower: not a new exporter, just the schema option the exporter already supports programmatically.

Open question

The file exporter spec has a "Streaming appending" section but does not state explicitly whether an existing file should be appended to or truncated. Appending seems the intent for a JSON lines file, and is what I implemented, but it is worth confirming.

I have a working patch (spans, metrics and logs, with tests) and am happy to open a PR.

[jack-berg]

The file exporter spec has a "Streaming appending" section but does not state explicitly whether an existing file should be appended to or truncated. Appending seems the intent for a JSON lines file, and is what I implemented, but it is worth confirming.

Please open an issue in https://github.com/open-telemetry/opentelemetry-configuration and/or https://github.com/open-telemetry/opentelemetry-specification for clarification.

[robintra]

Opened open-telemetry/opentelemetry-specification#5243 for the append vs truncate question. I filed it against the specification repo rather than opentelemetry-configuration since file-exporter.md is where the write behaviour would be defined, but I mirror it there if you would rather have the schema description carry the answer.