[
https://issues.apache.org/jira/browse/AVRO-1620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14241913#comment-14241913
]
Ryan Blue commented on AVRO-1620:
---------------------------------
Thanks! It's great to see some tests for this and I think you're right that
it's a bug.
I'm wondering if there isn't an easier way of fixing it than making sure the
SpecificData instance's ClassLoader matches the one for the record that is
begin copied. Shouldn't deepCopy use the class of the record that was passed in
rather than resolving the class in a ClassLoader? If we have an instance, then
we should be able to get the class object and use it. That would simplify the
patch quite a bit.
> 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.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)
