Filed: https://issues.apache.org/jira/browse/KAFKA-1049
On Fri, Sep 6, 2013 at 2:04 PM, Joel Koshy <jjkosh...@gmail.com> wrote:
> I'll have to try it out, but I think we can just have
> VerifiableProperties extend from java.util.Properties (so your encoder
> can just have Properties in its constructor). The producer can
> internally instantiate VerifiableProperties, pass that in to
> instantiate the encoder and do verification afterward. Can you file a
> jira for this?
>
> On Fri, Sep 6, 2013 at 11:00 AM, Joel Koshy <jjkosh...@gmail.com> wrote:
> >> public class MyKafkaEncoder<MyType> implements Encoder<MyType> {
> >> // This constructor is expected by the kafka producer, used by
> reflection
> >> * public MyKafkaEncoder(VerifiableProperties props) {*
> >> * // what can I do with this?*
> >> * }*
> >>
> >
> > You don't need to do anything with the argument - the producer config
> > class internally does a "verification" on it after the producer (and
> > serializer) has been instantiated to check if there are unused and/or
> > invalid configs - mainly to help the user detect a potential
> > misconfiguration. I agree that it is a bit unintuitive as a public API
> > - ideally it should just be a Properties map and do an internal
> > conversion to VerifiableProperties. However, the problem is that we
> > take a bag of properties in the ProducerConfig and pass those in to
> > the constructor of the serializer.
>
