According to the most recent discussions regarding Enabled SDK implementation (see: https://github.com/open-telemetry/opentelemetry-specification/issues/4207) there looks to be a tendency to lean towards simplifying the SDK.
The current preference is that the users should use the collector for setting up multiple log processing pipelines. E.g.
To be honest, the design to prioritize multiple independent logging pipelines, each with their own filter, doesn't resonate with me. Its too different from the other signals, and adds complexity for what I consider to be a niche use case. I think those types of use cases are better served by the collector, instead of adding the burden to all the language implementations.
The users can still create workarounds e.g. by deep cloning of a ReadWriteLogRecord and make log record processor decorators.
There is no need to deprecate the isolating processor as AFAIK nobody has implemented it (there was only a prototype for OTel Go: https://github.com/open-telemetry/opentelemetry-go-contrib/pull/5861).
Changes
Remove the in-development isolating log record processor introduced in https://github.com/open-telemetry/opentelemetry-specification/pull/4062 by myself.
Reasons
According to the most recent discussions regarding
EnabledSDK implementation (see: https://github.com/open-telemetry/opentelemetry-specification/issues/4207) there looks to be a tendency to lean towards simplifying the SDK. The current preference is that the users should use the collector for setting up multiple log processing pipelines. E.g.The users can still create workarounds e.g. by deep cloning of a
ReadWriteLogRecordand make log record processor decorators. There is no need to deprecate the isolating processor as AFAIK nobody has implemented it (there was only a prototype for OTel Go: https://github.com/open-telemetry/opentelemetry-go-contrib/pull/5861).