[
https://issues.apache.org/jira/browse/AVRO-1620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Blue updated AVRO-1620:
----------------------------
Attachment: AVRO-1620-1.patch
Here's a patch that implements the fix I proposed. It adds
{{newRecordInstance}} to {{GenericData}} that is used by {{deepCopy}}, which
passes in the class of the record instance that is being copied.
{{GenericData}} overrides this class and always returns {{GenericData.Record}}
instances, but {{SpecificData}} instantiates the class as it would after
resolving it, using {{newInstance}}.
This includes and passes the tests you provided, although if we want to go with
this approach, I think we should add more tests in avro, not just the compiler.
> Classloader Differences When Copying Records Results in ClassCastException
> --------------------------------------------------------------------------
>
> Key: AVRO-1620
> URL: https://issues.apache.org/jira/browse/AVRO-1620
> Project: Avro
> Issue Type: Bug
> Components: java
> Affects Versions: 1.7.7
> Reporter: Allan Shoup
> Attachments: AVRO-1620-1.patch, AVRO-1620.patch, AVRO-1620.patch
>
>
> Similar to the situation described in AVRO-1240, a parent classloader
> contains the avro classes and a separate classloader contains the avro
> specific record classes. When using the generated
> {code}
> newBuilder(SpecificRecord other)
> {code}
> or
> {code}
> newBuilder(SpecificRecord.Builder other)
> {code}
> methods to duplicate records, the generated code will cause an exception
> similar to this:
> {noformat}
> Caused by: java.lang.ClassCastException:
> org.apache.avro.generic.GenericData$Record cannot be cast to
> my.specific.Record
> at my.specific.Record$Builder.<init>(Record.java:149)
> at my.specific.Record$Builder.<init>(Record.java:121)
> at my.specific.Record.newBuilder(Record.java:115)
> ... 19 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
