Hello, Alexey. > * DataRegionMetric public interface is deprecated, however, the suggested > replacement class GridMetricsManager is internal and cannot be acquired by a > user. This makes impossible for the user to fix their code to not use > deprecated API
May be it’s not clear text here. My point here, that user should obtain metrics values via configured metric exporters and don’t use *Metric interfaces. > * In ReadOnlyMetricsRegistry there is a Consumer<MetricRegistry>, but > MetricRegistry is again an internal class. This is a real issue. We should expose MetricRegistry interface to the public API and keep internal implementation. I will create ticket and fix it, shortly. > 16 янв. 2020 г., в 16:39, Alexey Goncharuk <alexey.goncha...@gmail.com> > написал(а): > > Igniters, Nikolay, > > I was adding a new metric in the scope of the ticket [1] and was surprised by > a few things: > * DataRegionMetric public interface is deprecated, however, the suggested > replacement class GridMetricsManager is internal and cannot be acquired by a > user. This makes impossible for the user to fix their code to not use > deprecated API > * In ReadOnlyMetricsRegistry there is a Consumer<MetricRegistry>, but > MetricRegistry is again an internal class. This will cause the user code > compilation to break when MetricRegistry is changed > > These things violate the public-private API separation and need to be fixed > prior 2.8 is released. Let's discuss what changes need to be made to the API > or perhaps move incomplete IEP-35 interfaces to the private package and > remove deprecations until the API is ready. > > --AG
