-
-
Notifications
You must be signed in to change notification settings - Fork 222
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hard coding for Indexed type item/wrapper name removes all possiblity of customization #356
Comments
I suspect that comment and hard-coding might predate time when root name was being passed (and perhaps assumption was that I hope I'll have time in medium-term future to look into this, but if anyone has time to see if a PR was possible, I would make time to review it at least. And timing would be right for inclusion in 2.10.0.pr2 (or final 2.10.0) if so. |
@cowtowncoder I have submitted a pull request can you please review. Also please have a look on this line where the logic could be faulty else everything else I am confident of being right. |
Hi @perilbrain! Thank you for contribution -- I did notice it, but haven't had time to look. I hope to get to it some time this week. I'll probably have some questions, mostly regarding if use of existing annotations was not possible. |
Use of existing annotation is possible but will break backward compatibility. Anyone consuming will have to update their existing client application. |
@perilbrain Not really, actually: JDKs handling of annotations is somewhat more forgiving wrt finding unrecognized annotations, properties thereof. There is dependency across components, sure, but new annotations are regular added in Jackson minor releases and these are rarely problematic wrt versioning, compared to other changes. In this case much depends on annotation being used: if one from this package is used (like is the case in your PR), there should be even fewer issues. But it is certainly true that additions to annotation definitions are only possible in minor versions (and removal, changes, in major versions if ever). |
Ok. I'll have to read this a few more times as I am not sure what to think of it, except for one concern: adding annotation in value type seems wrong to me, somehow. I can see why it is done, just not sure I like it. But maybe thinking it through again makes things more clear for me. One other thing: testing is also needed for deserialization side, to ensure that works. |
Ok. So, some more thoughts. I added couple of tests to remind myself on root name handling, and ignoring
Conceptually, it seems as if root-name info should, then, contain another fully-qualified name. Unfortunately part about root name override is trickier as So I think that might be better way to go. |
jackson-dataformat-xml/src/main/java/com/fasterxml/jackson/dataformat/xml/ser/XmlSerializerProvider.java
Line 146 in 6bd59fb
In following function
Although
rootName
has been passed it is not being used. This makes it impossible to change array type wrapper name. If someone needsitem
as their wrapper they can set@JacksonXmlRootElement(localName="item")
but otherwise is not possible.Alternatively we can have another attribute in annotation like
@JacksonXmlRootElement(localName="some_node", wrapperForIndexedType="some_node")
having interface declaration of JacksonXmlRootElement.java as
Problem:
Trying to generate output like
getting:
However if hard-coding is removed it would be easier to generate json and xml from a same function and entity definition with some varied level of alteration at XML layer. This avoids re-declaring everything to get two different representation of output i.e. json and xml.
For example in my case I have to port an old API which has response format for json:
for xml:
but I cannot achieve the xml format without rewriting all POJOs.
The text was updated successfully, but these errors were encountered: