Add a way to specify "inject-only" with @JacksonInject

[cowtowncoder]

Currently all injectable properties also allow binding of data from input, so if there is a JSON value for property, it will override anything injected. But this may not always be what user wants; sometimes it may be preferable to only use injection (and quietly drop value from data, if any). Or possible even reverse, that is, allowing injection to optional override value, but if no injectable value given to default to value from input data.

To support this change, some other changes are needed:

1. Create JacksonInject.Value to contain aspects (name, precedence for now, possibly more in future)
2. Create a new enum type for JacksonInject to indicate if and how input data value is to be used.
3. Change introspection method in AnnotationIntrospector to produce new value object but allow chaining with old implementations, to support some level of interoperability
4. Change introspectors (Guice module uses one I think; OSGi too?)

As to enum to use (JacksonInject.Input?), perhaps:

• Primary: (default) if input data has property, use that, not injected value
• Secondary: input data only used if no injected value can be found
• Never: input data never used, only injected value

Another possible improvement could be to add another property (required?) to indicate whether it is acceptable to not have an injectable value defined, when one is needed (which is in all cases except with Primary, and finding actual data).
If no value is found, and injection is NOT required (required would be the default for now) null would be injected.

[cowtowncoder]

Note: for 2.x light-weight solution via #1565, but need to rewrite for 3.0 to do proper checking, if (and only if) we can keep track of actual declaration location.

[Marcono1234]

Has this been partially solved through FasterXML/jackson-annotations#120?

[cowtowncoder]

Annotation issue can only add new properties but not actual handling (package only contains annotation declarations/definitions).

[giulong]

@cowtowncoder may I work on this one? If yes, given #5131, does the last paragraph still apply?👇🏻

Another possible improvement could be to add another property (required?) to indicate whether it is acceptable to not have an injectable value defined, when one is needed (which is in all cases except with Primary, and finding actual data).
If no value is found, and injection is NOT required (required would be the default for now) null would be injected.

[cowtowncoder]

Yes definitely, feel free to work on this. And for second part I think.... yes? (I am open to being convinced otherwise)

[giulong]

Ok, let's leave that part as last, when I'll have a clearer view on the overall feature. To start, I need clarifications on this:

2. Create a new enum type for JacksonInject to indicate if and how input data value is to be used.

This was 2016, but in 2017 you added useInput(). Should I still introduce the enum like this:

public @interface JacksonInject {

    // already present
    public OptBoolean useInput() default OptBoolean.DEFAULT;

    // new field
    public Input input() default Input.PRIMARY;

    public enum Input {
        PRIMARY, SECONDARY, NEVER
    }
}

or should I fix/augment the current useInput behavior? I'm asking this because looking at the tofix JacksonInject2678Test, it looks like the current implementation completely ignores the value of useInput: whether it's true or false, the injected value always overrides the data from input, which is the opposite of what's described in the very beginning of this issue:

Currently all injectable properties also allow binding of data from input, so if there is a JSON value for property, it will override anything injected.

Or, am I missing something?

[cowtowncoder]

This was 2016, but in 2017 you added useInput(). Should I still introduce the enum like this:

Right, should have updated: useInput is not yet used for anything and was planned to part of work here. So addition to Annotation type was done, but no changes to make any use of it.

Now as to new Enum... hmmh. One possibility would be to start first by supporting useInput to allow ignoring input (always use Injected) and see if there is further need for priority overrides.
But behavior that exists currently (I wouldn't remember it off-hand but sounds like you checked) needs to be preserved for default settings (i.e. can't just change in minor version) -- and by default I mean @JacksonInject that does NOT include explicit useInput setting.

Does this make sense?