aggregating DefaultValueProcessor classes

  • Arnold Reuser

    Arnold Reuser - 2008-07-03

    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

      aalmiray - 2008-07-04

      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

      Please let me know if this would help you.

    • Arnold Reuser

      Arnold Reuser - 2008-07-04

      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?


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks