[
https://issues.apache.org/jira/browse/AVRO-4040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bartosz Gałek updated AVRO-4040:
--------------------------------
Description:
While generating a class from my Avro schema, the `getSpecificData` and
`getSchema` [methods are added
automaticaly.|https://github.com/apache/avro/blob/main/lang/java/compiler/src/main/velocity/org/apache/avro/compiler/specific/templates/java/classic/record.vm#L180-L183]
These methods are not defined in user schemas, which can be confusing.
It's particularly problematic when analyzing such a class (i.e., via reflection
or serialization).
Libraries like `Jackson`, `Gson`, or `Springdoc` should ignore these fields.
However, each library has its way of ignoring public fields/getters (i.e.
`@JsonIgnore`, `@Expose`).
The Avro class generator should allow other libraries to handle those
"internal" methods/fields without introducing additional coupling to those
libraries in the Avro project, of course.
*I suggest annotating those methods with some kind of `@AvroGeneratedMethod`
(or existing `@AvroGenerated`) to address this problem.*
Any library that tries to do something with Avro-generated classes can be
configured to ignore those Avro-specific methods.
If this plan is ok for maintainers, I could try to make a pull request with my
team.
was:
While generating a class from my Avro schema, the `getSpecificData` and
`getSchema` [methods are added
automaticaly.|https://github.com/apache/avro/blob/main/lang/java/compiler/src/main/velocity/org/apache/avro/compiler/specific/templates/java/classic/record.vm#L180-L183]
These methods are not defined in user schemas, which can be confusing.
It's particularly problematic when analyzing such a class (i.e., via reflection
or serialization).
Libraries like `Jackson`, `Gson`, or `Springdoc` should ignore these fields.
However, each library has its way of ignoring public fields/getters (i.e.
`@JsonIgnore`, `@Expose`).
The Avro class generator should allow other libraries to handle those "special"
methods/fields without introducing additional coupling to those libraries in
the Avro project, of course.
*I suggest annotating those methods with some kind of `@AvroGeneratedMethod`
(or existing `@AvroGenerated`) to address this problem.*
Any library that tries to do something with Avro-generated classes can be
configured to ignore those Avro-specific methods.
If this plan is ok for maintainers, I could try to make a pull request with my
team.
> annotate `getSpecificData` and `getSchema` methods in Avro generated classes
> ----------------------------------------------------------------------------
>
> Key: AVRO-4040
> URL: https://issues.apache.org/jira/browse/AVRO-4040
> Project: Apache Avro
> Issue Type: Improvement
> Reporter: Bartosz Gałek
> Priority: Major
>
> While generating a class from my Avro schema, the `getSpecificData` and
> `getSchema` [methods are added
> automaticaly.|https://github.com/apache/avro/blob/main/lang/java/compiler/src/main/velocity/org/apache/avro/compiler/specific/templates/java/classic/record.vm#L180-L183]
> These methods are not defined in user schemas, which can be confusing.
> It's particularly problematic when analyzing such a class (i.e., via
> reflection or serialization).
> Libraries like `Jackson`, `Gson`, or `Springdoc` should ignore these fields.
> However, each library has its way of ignoring public fields/getters (i.e.
> `@JsonIgnore`, `@Expose`).
> The Avro class generator should allow other libraries to handle those
> "internal" methods/fields without introducing additional coupling to those
> libraries in the Avro project, of course.
> *I suggest annotating those methods with some kind of `@AvroGeneratedMethod`
> (or existing `@AvroGenerated`) to address this problem.*
> Any library that tries to do something with Avro-generated classes can be
> configured to ignore those Avro-specific methods.
> If this plan is ok for maintainers, I could try to make a pull request with
> my team.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
