[
https://issues.apache.org/jira/browse/KAFKA-12849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias J. Sax updated KAFKA-12849:
------------------------------------
Description:
In KIP-740 we had to go through a deprecation cycle in order to change the
constructor from the original one which accepted the taskId parameter as a
string, to the new one which takes a TaskId object directly. We had considered
just changing the signature directly without deprecation as this was never
intended to be instantiated by users, rather it just acts as a pass-through
metadata class. Sort of by definition if there is no reason to ever instantiate
it, this seems to indicate it may be better suited as a public interface with
the implementation and constructor as internal APIs.
KIP-744:
[https://cwiki.apache.org/confluence/display/KAFKA/KIP-744%3A+Migrate+TaskMetadata+and+ThreadMetadata+to+an+interface+with+internal+implementation]
was:In KIP-740 we had to go through a deprecation cycle in order to change
the constructor from the original one which accepted the taskId parameter as a
string, to the new one which takes a TaskId object directly. We had considered
just changing the signature directly without deprecation as this was never
intended to be instantiated by users, rather it just acts as a pass-through
metadata class. Sort of by definition if there is no reason to ever instantiate
it, this seems to indicate it may be better suited as a public interface with
the implementation and constructor as internal APIs.
> Consider migrating TaskMetadata to interface with internal implementation
> -------------------------------------------------------------------------
>
> Key: KAFKA-12849
> URL: https://issues.apache.org/jira/browse/KAFKA-12849
> Project: Kafka
> Issue Type: Improvement
> Components: streams
> Reporter: A. Sophie Blee-Goldman
> Assignee: Josep Prat
> Priority: Major
> Labels: kip, newbie, newbie++
> Fix For: 3.0.0
>
>
> In KIP-740 we had to go through a deprecation cycle in order to change the
> constructor from the original one which accepted the taskId parameter as a
> string, to the new one which takes a TaskId object directly. We had
> considered just changing the signature directly without deprecation as this
> was never intended to be instantiated by users, rather it just acts as a
> pass-through metadata class. Sort of by definition if there is no reason to
> ever instantiate it, this seems to indicate it may be better suited as a
> public interface with the implementation and constructor as internal APIs.
> KIP-744:
> [https://cwiki.apache.org/confluence/display/KAFKA/KIP-744%3A+Migrate+TaskMetadata+and+ThreadMetadata+to+an+interface+with+internal+implementation]
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
