ObjectMapper get dirty after calling PKFileBasedSigningUtil

[dailymartin]

My project uses custom object mapper as shared, aka, registered bean, as bellow.

@Primary
@Bean
public ObjectMapper objectMapper() {
    ObjectMapper objectMapper = new CustomObjectMapper();
    initializeObjectMapper(objectMapper);

    return objectMapper;
}

And PKFileBasedSigningUtil makes Object Mapper set other values.

public final class PKFileBasedSigningUtil extends PKAbstractSIgningUtil {
  private static final String FILE_SEPARATOR_UNIX = "/";
  private static final String MANIFEST_JSON_FILE_NAME = "manifest.json";
  private static final String PASS_JSON_FILE_NAME = "pass.json";
  private ObjectWriter objectWriter;

  @Inject
  public PKFileBasedSigningUtil(ObjectMapper objectMapper) {
    this.addBCProvider();
    this.objectWriter = this.configureObjectMapper(objectMapper);
  }
...

protected ObjectWriter configureObjectMapper(ObjectMapper jsonObjectMapper) {
    jsonObjectMapper.configure(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS, false);
    jsonObjectMapper.setDateFormat(new ISO8601DateFormat());
    SimpleFilterProvider filters = new SimpleFilterProvider();
    filters.addFilter("validateFilter", SimpleBeanPropertyFilter.serializeAllExcept(new String[]{"valid", "validationErrors"}));
    filters.addFilter("pkPassFilter", SimpleBeanPropertyFilter.serializeAllExcept(new String[]{"valid", "validationErrors", "foregroundColorAsObject", "backgroundColorAsObject", "labelColorAsObject", "passThatWasSet"}));
    filters.addFilter("barcodeFilter", SimpleBeanPropertyFilter.serializeAllExcept(new String[]{"valid", "validationErrors", "messageEncodingAsString"}));
    filters.addFilter("charsetFilter", SimpleBeanPropertyFilter.filterOutAllExcept(new String[]{"name"}));
    jsonObjectMapper.setSerializationInclusion(Include.NON_NULL);
    jsonObjectMapper.addMixIn(Object.class, PKAbstractSIgningUtil.ValidateFilterMixIn.class);
    jsonObjectMapper.addMixIn(PKPass.class, PKAbstractSIgningUtil.PkPassFilterMixIn.class);
    jsonObjectMapper.addMixIn(PKBarcode.class, PKAbstractSIgningUtil.BarcodeFilterMixIn.class);
    jsonObjectMapper.addMixIn(Charset.class, PKAbstractSIgningUtil.CharsetFilterMixIn.class);
    return jsonObjectMapper.writer(filters);
  }

So, after calling PKFileBasedSigningUtil once, the object mapper's attributes become jpasskit's, not my own. And then, other operations in my project are confused as below.

com.fasterxml.jackson.databind.JsonMappingException: Can not resolve PropertyFilter with id 'validateFilter'; no FilterProvider configured

I think PKFileBasedSigningUtil uses cloned Object Mapper is better.

I'm not native in English. So please feel free to ask me about this issue, if it's not clear. Thanks.

[stepio]

Hi @dailymartin, thanks for your interest!

Could you please try using 0.0.9-SNAPSHOT version?

I've changed this API there:

    public PKFileBasedSigningUtil() {
        super(new ObjectMapper());
    }

    @Inject
    public PKFileBasedSigningUtil(ObjectWriter objectWriter) {
        super(objectWriter);
    }

    /**
     * @deprecated Please use PKFileBasedSigningUtil(ObjectWriter objectWriter) instead
     * @param objectMapper
     */
    @Deprecated
    public PKFileBasedSigningUtil(ObjectMapper objectMapper) {
        super(objectMapper);
    }

So in your case just default "no-arguments" constructor PKFileBasedSigningUtil() should be Ok.

If this resolves your issue, ask @drallgood to prepare a release version with these changes.

[stepio]

The API was changed to prevent the above mentioned cases, so now you have two options:

• either use default constructor and let jpasskit to do all the initializations for you;
• or, if you'd like to configure ObjectMapper yourself, just create ObjectWriter from it and pass it to PKFileBasedSigningUtil - in this case it's expected that you add the required mix-ins yourself.

[dailymartin]

@stepio Thanks for your help. It's done with 0.0.9-SNAPSHOT :)

@drallgood Could you deploy 0.0.9 as a release version?

[drallgood]

@dailymartin @stepio Done. Sorry for the delay.

[dailymartin]

@drallgood No problem. Thanks a lot :)