Hi Carlos,
I am not sure about @JsonInject - never needed it and looks like
mixing layers. But anyway if we would go this way I would just get an
abstraction for IoC - surely linked to CDI in term of defaults in the
spec. That said this sounds useless if you run with CDI since this
last one already has all the needed API so not sure jsonb should care
at all about it.
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2015-09-12 13:01 GMT-07:00 Carlos Guzman <carlosguzmang_at_hotmail.com>:
> Hi guys,
> Regarding the point 4.6, not only the instantiation of classes with no
> default constructor is needed, but the support of injected objects at
> @JsonbCreator methods. (@JsonbInject?)
> There are cases when the object requires a parent object not part of the
> json document. So, before the unmarshalling operation returns the created
> object, it should be properly assigned.
> There should be a way to have a map of objects ready to inject, so when the
> @JsonbInject is found, it should be properly assigned. (Map of objects to
> inject should be available at Jsonb level or at a Jsonb::fromJson level).
> Please, see the @JsonInject implementation in Jackson, this is what I'm
> talking about.
> I just needed this feature few days ago and it was amazing to discover it.
>
> Regarding the point 3.7, with the use of the @JsonbCreator, there is no need
> of this restriction. Or at least make it conditional:
> "Any instance passed to an unmarshalling operation must have a public or
> protected no-argument constructor if there is no JsonbCreator method
> declared."
> And this will fulfill the case where at least a parent (non-related json)
> object is required to construct a object. I don't want to leave open the
> possibility of an unassigned required-object only because the unmarshalling
> operation does not support it.
>
> Let me know your comments.
> Thanks,
> Carlos
>