Do you propose to keep these interfaces forever?

> 16 янв. 2020 г., в 16:52, Alexey Goncharuk <alexey.goncha...@gmail.com> 
> написал(а):
> 
> 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
>> 
>> 

Reply via email to