The idea here is that many serializers actually need some configuration
properties and without this there is no way to pass these in. We could try
to be a little more user friendly by looking for a constructor that takes
properties, and, if that doesn't exist looking for a no-arg constructor. If
this sounds reasonable it would be good to file a JIRA for it.
-Jay
On Fri, Sep 6, 2013 at 9:50 AM, Jason Rosenberg <j...@squareup.com> wrote:
> So, it seems that if I want to set a custom serializer class on the
> producer (in 0.8), I have to use a class that includes a special
> constructor like:
>
> 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?*
> * }*
>
> @Override
> public byte[] toBytes(MyType message) {
> return message.toByteArray();
> }
> }
>
> It seems odd that this would be a requirement when implementing an
> interface. This seems not to have been the case in 0.7.
>
> What could my encoder class do with the VerifiableProperties?
>
> Also, in general, there are a set of classes under kafka.javaapi, but in
> order to do anything useful from java, one does have to use classes (such
> as Encoder), from outside the javaapi package. I'm guessing ultimately,
> the idea would be to provide a java api that might include everything a
> client would need.
>
> Jason
>
