Let's say I am upgrading from 2.7 to 2.8. Given that I figured out to obtain an instance of the JMX exporter SPI, how should I map the old 'interface + method name' to the new metric name? I think deprecation of the public API may be a bit harsh in this case.
чт, 16 янв. 2020 г. в 16:44, Николай Ижиков <nizhi...@apache.org>: > 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 > >
