On Mon, May 14, 2018 at 2:13 AM, Psycho Punch <[email protected]> wrote:
> Thank you very much for that response.
>
> However, while the concept of default heuristics is a bit clearer to me now,
> the heuristics itself seems to be a little hard to predict, and, as you say
> fragile. I asked this question because I'm working on a code base that
> suddenly stopped working properly because of this fragility. The project
> uses Spring Boot, so I initially suspected the problem was caused by some
> underlying autoconfiguration. However, it turned out to be a problem with
> how the default mode works in Jackson as it's rather unpredictable.
Yes, and this is why I am thinking of simply removing it.
The fix in your case is to add `mode` property.
But let's see....
> In the code base, there are classes structured similarly to the following
> (ignore for now whether the domain is well represented):
>
> public class abstract Book {
>
> private Object content;
>
> protected Book(String code, Object content) { ... }
>
> public Object getContent() { ... }
>
> }
>
> public class FictionBook extends Book {
>
> @JsonCreator
> public FictionBook(Object content) {
> super("fiction-code", content);
> }
>
> }
>
> FictionBook class' constructor annotated with @JsonCreator has always worked
> under delegating mode. However, after adding dependency to Jackson's XML
> module, the code base started breaking as the constructor began running in
> properties mode. I'm just not sure what exactly changed as the classes in
> question remained untouched. What did the ObjectMapper find different to run
> the JsonCreator in a different mode in this case?
This is highly speculative but perhaps Java 8 parameter names module
got added to the project?
That would bring implicit parameter name, "content", in, and in turn
link with field "content",
to indicate existence of property. That in turn would make heuristics
detect linkage.
Some projects use classpath auto-discovery, which I think is just
asking for trouble, but is fairly common
in Spring world for some reason. That could further cause mysterious
problems because now a transitive
dependency could pull in a new module; and new module's feature
(implicit parameter names) would have
effect of changing behavior.
Alternate hypothesis would be that compilation settings project use
have changed, and formerly parameter
names were not included in bytecode. But a change to settings could
have enabled inclusion, similarly causing
parameter name to be found and linked.
I hope this helps,
-+ Tatu +-
--
You received this message because you are subscribed to the Google Groups
"jackson-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/d/optout.
