[jira] [Commented] (KAFKA-16604) Deprecate ConfigDef.ConfigKey constructor from public APIs
[
https://issues.apache.org/jira/browse/KAFKA-16604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842412#comment-17842412
]
Chris Egerton commented on KAFKA-16604:
---
We don't necessarily have to deprecate anything. It's a little awkward to
support all the {{ConfigDef::define}} variants and a builder pattern for
{{{}ConfigKey{}}}, but this would produce no breaking changes and provide a
path forward that doesn't run the risk of accidental compatibility violations
like in KAFKA-16592. IMO that would be a reasonable compromise.
Regardless, I agree with the root sentiment of this ticket (that we should
probably change direction in how we evolve these two classes). Would love to
discuss further on a KIP thread!
> Deprecate ConfigDef.ConfigKey constructor from public APIs
> --
>
> Key: KAFKA-16604
> URL: https://issues.apache.org/jira/browse/KAFKA-16604
> Project: Kafka
> Issue Type: Improvement
>Reporter: Sagar Rao
>Assignee: Sagar Rao
>Priority: Major
>
> Currently, one can create ConfigKey by either invoking the public constructor
> directly and passing it to a ConfigDef object or by invoking the a bunch of
> define methods. The 2 ways can get confusing at times. Moreover, it could
> lead to errors as was noticed in KAFKA-16592
> We should ideally have only 1 way exposed to the users which IMO should be to
> create the objects only through the exposed define methods. This ticket is
> about marking the public constructor of ConfigKey as Deprecated first and
> then making it private eventually.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (KAFKA-16604) Deprecate ConfigDef.ConfigKey constructor from public APIs
[
https://issues.apache.org/jira/browse/KAFKA-16604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842031#comment-17842031
]
Chia-Ping Tsai commented on KAFKA-16604:
{quote}
If we want to prevent bugs like we saw in KAFKA-16592, one alternative is to
add a builder class for the ConfigKey class. This would allow us to add new
fields to the ConfigKey class without having to add new (public) constructors,
or alter existing ones.
{quote}
I love build pattern, but there are already a lot of helper methods - "define"
- which allows user to create ConfigKey object with fewer arguments. We have to
deprecate all "define" functions to encourage to use new builder, and that
means more breaking changes.
> Deprecate ConfigDef.ConfigKey constructor from public APIs
> --
>
> Key: KAFKA-16604
> URL: https://issues.apache.org/jira/browse/KAFKA-16604
> Project: Kafka
> Issue Type: Improvement
>Reporter: Sagar Rao
>Assignee: Sagar Rao
>Priority: Major
>
> Currently, one can create ConfigKey by either invoking the public constructor
> directly and passing it to a ConfigDef object or by invoking the a bunch of
> define methods. The 2 ways can get confusing at times. Moreover, it could
> lead to errors as was noticed in KAFKA-16592
> We should ideally have only 1 way exposed to the users which IMO should be to
> create the objects only through the exposed define methods. This ticket is
> about marking the public constructor of ConfigKey as Deprecated first and
> then making it private eventually.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (KAFKA-16604) Deprecate ConfigDef.ConfigKey constructor from public APIs
[
https://issues.apache.org/jira/browse/KAFKA-16604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842016#comment-17842016
]
Chris Egerton commented on KAFKA-16604:
---
I don't know if it's worth the breaking change to disallow manual instantiation
of the {{ConfigKey}} class. If we want to prevent bugs like we saw in
KAFKA-16592, one alternative is to add a builder class for the {{ConfigKey}}
class. This would allow us to add new fields to the {{ConfigKey}} class without
having to add new (public) constructors, or alter existing ones.
> Deprecate ConfigDef.ConfigKey constructor from public APIs
> --
>
> Key: KAFKA-16604
> URL: https://issues.apache.org/jira/browse/KAFKA-16604
> Project: Kafka
> Issue Type: Improvement
>Reporter: Sagar Rao
>Assignee: Sagar Rao
>Priority: Major
>
> Currently, one can create ConfigKey by either invoking the public constructor
> directly and passing it to a ConfigDef object or by invoking the a bunch of
> define methods. The 2 ways can get confusing at times. Moreover, it could
> lead to errors as was noticed in KAFKA-16592
> We should ideally have only 1 way exposed to the users which IMO should be to
> create the objects only through the exposed define methods. This ticket is
> about marking the public constructor of ConfigKey as Deprecated first and
> then making it private eventually.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (KAFKA-16604) Deprecate ConfigDef.ConfigKey constructor from public APIs
[ https://issues.apache.org/jira/browse/KAFKA-16604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840163#comment-17840163 ] Sagar Rao commented on KAFKA-16604: --- [~chia7712] , ok i have assigned it to myself. > Deprecate ConfigDef.ConfigKey constructor from public APIs > -- > > Key: KAFKA-16604 > URL: https://issues.apache.org/jira/browse/KAFKA-16604 > Project: Kafka > Issue Type: Improvement >Reporter: Sagar Rao >Assignee: Sagar Rao >Priority: Major > > Currently, one can create ConfigKey by either invoking the public constructor > directly and passing it to a ConfigDef object or by invoking the a bunch of > define methods. The 2 ways can get confusing at times. Moreover, it could > lead to errors as was noticed in KAFKA-16592 > We should ideally have only 1 way exposed to the users which IMO should be to > create the objects only through the exposed define methods. This ticket is > about marking the public constructor of ConfigKey as Deprecated first and > then making it private eventually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (KAFKA-16604) Deprecate ConfigDef.ConfigKey constructor from public APIs
[ https://issues.apache.org/jira/browse/KAFKA-16604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840075#comment-17840075 ] Chia-Ping Tsai commented on KAFKA-16604: [~sagarrao] Thanks for opening this jira. Do you have free cycle to take over it? > Deprecate ConfigDef.ConfigKey constructor from public APIs > -- > > Key: KAFKA-16604 > URL: https://issues.apache.org/jira/browse/KAFKA-16604 > Project: Kafka > Issue Type: Improvement >Reporter: Sagar Rao >Priority: Major > > Currently, one can create ConfigKey by either invoking the public constructor > directly and passing it to a ConfigDef object or by invoking the a bunch of > define methods. The 2 ways can get confusing at times. Moreover, it could > lead to errors as was noticed in KAFKA-16592 > We should ideally have only 1 way exposed to the users which IMO should be to > create the objects only through the exposed define methods. This ticket is > about marking the public constructor of ConfigKey as Deprecated first and > then making it private eventually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
