avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Cutting (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AVRO-1024) Allow users to subclass JsonEncoder
Date Wed, 08 Feb 2012 22:54:59 GMT

    [ https://issues.apache.org/jira/browse/AVRO-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204085#comment-13204085

Doug Cutting commented on AVRO-1024:

This exposes more of the implementation.  It means we could not easily switch from using the
Parser or from using Jackson to implement this without potentially breaking applications that
use this API.  The Parser is already largely exposed, since the base class is ParsingEncoder,
and we're unlikely to use a different JSON library than Jackson, so perhaps this is okay.
 What do others think?

On the patch itself, it would be better to access these via accessor methods rather than protected
fields.  And once something's public or protected then it needs javadoc.  We should include
a unit test for this.  Perhaps the example you provide above of changing the way unions are
serialized would make a good test?

> Allow users to subclass JsonEncoder
> -----------------------------------
>                 Key: AVRO-1024
>                 URL: https://issues.apache.org/jira/browse/AVRO-1024
>             Project: Avro
>          Issue Type: Improvement
>          Components: java
>    Affects Versions: 1.5.4
>            Reporter: Elliott Clark
>         Attachments: AVRO-1024-1.patch
> Users who want to use a different representation of json from the JsonEncoder are forced
to re-implement all of it since JsonEncoder's internals are all private. For example I wanted
to make the json not contain type hints for unions.  That required only overriding one method
after this fix.
> To fix this making things protected will allow users to change just code that is needed.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message