0

All the examples of @JsonSerialize and JsonSerializer implementations are similar to the following.

public class JodaDateTimeJsonSerializer extends JsonSerializer<DateTime> {

    private static final String dateFormat = ("MM/dd/yyyy");

    @Override
    public void serialize(DateTime date, JsonGenerator gen, SerializerProvider provider)
            throws IOException, JsonProcessingException {

        String formattedDate = DateTimeFormat.forPattern(dateFormat).print(date);

        gen.writeString(formattedDate);
    }

}

It has a class-level variable that defines its runtime behaviour. This cannot be changed at runtime via configuration.

How can I make dateFormat above a configurable property, while using @JsonSerialize(using = JodaDateTimeJsonSerializer.class) on a property?

Right now, I'm considering just making it a static non-final property on the serializer implementation that is set at runtime by the application on run. Doesn't make for a very proper implementation. Edit: The ideal solution will allow me to ~inject~ (edit: pass in) only the required configuration into the serializer, not retrieve configuration from some global.

Note: I do not want to create a new data type for this property (they are all Strings) and I do not want to create a custom bean serializer (they can be annotated on any String property anywhere). Because of this, I also cannot use SimpleModule::addSerializer(class, serializer) method as they should not be added to all String properties.

Community
  • 1
  • 1
Daryl Teo
  • 5,394
  • 1
  • 31
  • 37

1 Answers1

0

Hello some ResourceBundle implementations provide caching capabilities. This would say that looking up a property like date format in such situation will have no performance impact on your application and you can look it up straight in your method.

In order for any change in configuration to take effect at runtime. You should clear the ResourceBundle cache either at certain intervals or alternatively when you have update the configurations files. This can be easily achieved by invoking the method:

ResourceBundle.clearCache();
Alexander Petrov
  • 9,204
  • 31
  • 70
  • This still breaks encapsulation (requires global config object) in my opinion. In my case, my options are already loaded by Dropwizard, not as a ResourceBundle. This is a slightly better option (as the values can be reloaded at runtime) but I'm still open to better options. Thank you for your response. – Daryl Teo Jul 26 '16 at 05:17
  • @DarylTeo just read your edit "The ideal solution will allow me to inject only the required configuration into the serializer, not retrieve configuration from some global" Correct me if wrong but "Injection" is just a pattern, behind the pattern you will still need a vessel to hold your configuration. If the Injection is your problem you can always inject it with a dependency injection framework. – Alexander Petrov Jul 26 '16 at 05:32
  • Bad choice of words on my part: I use the term "inject" as a verb, not necessarily the "injection" implied by a DI framework. Apologies – Daryl Teo Jul 26 '16 at 05:34