aggregating DefaultValueProcessor classes

[Arnold Reuser]

This is a feature request.
Would it be possible to add a property to JsonConfig so that I can set my custom implementation of DefaultDefaultValueProcessor?

Just as a real life example of the additional benefit : Imagine I would like the default value of a Number to be null instead of 0
To implement this feature the classes Byte, Short, Integer, Long, Float, Double,.. all require their own custom DefaultValueProcessor.
Furthemore because Number is an interface, and DefaultDefaultValueProcessor uses a class as it's type,
the list of required custom DefaultValueProcessors always constraints me to a certain set of classes.
As a result I currently can't implement a generic solution that applies to all implementations of the interface Number.
When I would be able to set my custom implementation of DefaultDefaultValueProcessor this wouldn't be a problem and the implementation
would be along the lines of the current implementation of DefaultDefaultValueProcessor.

Thanks for your time.

[aalmiray]

Hmm, wouldn't a DefaultValueProcessorMatcher help you in this case? the whole point of having matchers is that they allow you to break free of the Class -> Processor constraint, you may register a processor with Number.class then have a DefaultValueProcessorMatcher impl, like the one shown at http://json-lib.sourceforge.net/xref-test/net/sf/json/TestJSONObject.html#821

Please let me know if this would help you.

[Arnold Reuser]

Thanks for your guidance. This is indeed a workaround/solution for the specified example.
I would however still prefer to use one custom DefaultDefaultValueProcessor instead of combinations of a DefaultValueProcessorMatcher
and a DefaultValueProcessor. Otherwise what is the point of having a DefaultDefaultValueProcessor as part of your codebase?