You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've started incorporating the generated AVRO classes into my code. In the process, I noticed the generated Java attribute names aren't the same as the XMLtags. This makes it impossible to use reflection to automatically copy XML values into Java attributes.
For example "assignedAlt_08a" is changed to "assignedAlt08A". The underscore is removed, and the final letter is changed to upper case. I understand that removing underscores follows Java naming conventions, but I'm not sure the tradeoff between following the convention and losing exact match between the xml and the Java should take that route.
One solution might be for me to change the XML XSD, but this is a public XSD we have no control over.
Are the name changes intentional due to some restrictions on AVRO attribute naming or something along those lines?
Thanks,
Vick
The text was updated successfully, but these errors were encountered:
Hey there Vick. The names you see are generated by JAXB. The schemagen plugin is built on top of this tool, so it's unlikely that the names can be changed without finding a way to tell JAXB your intentions. I'm open to suggestions, but it's somewhat outside of the scope of the tool right now.
Hi Ben,
I've started incorporating the generated AVRO classes into my code. In the process, I noticed the generated Java attribute names aren't the same as the XMLtags. This makes it impossible to use reflection to automatically copy XML values into Java attributes.
For example "assignedAlt_08a" is changed to "assignedAlt08A". The underscore is removed, and the final letter is changed to upper case. I understand that removing underscores follows Java naming conventions, but I'm not sure the tradeoff between following the convention and losing exact match between the xml and the Java should take that route.
One solution might be for me to change the XML XSD, but this is a public XSD we have no control over.
Are the name changes intentional due to some restrictions on AVRO attribute naming or something along those lines?
Thanks,
Vick
The text was updated successfully, but these errors were encountered: