Camunda-spin - how can jackson be configured

[ia.sre...@gmail.com]

Hi,

in [0] you described that camunda-spin can be used to serialize variables from/to json. Camunda-spin uses Jackson for the serialization. How is it possible to configure the Jackson ObjectMapper?

1. When creating the ProcessEngineConfigurationImpl you can define config.setDefaultSerializationFormat("application/json; implementation=tree");
With this configuration camunda-spin is used for serialization/deserialization.

2. To serialize/deserialize types like joda DateTime, the JodaModule [1] can be registered in the ObjectMapper.
ObjectMapper mapper = new ObjectMapper();
mapper.registerModule(new JodaModule());

3. Camunda uses org.camunda.spin.impl.json.tree.JsonJacksonTreeDataFormat#getConfiguredObjectMapper to get the already configured ObjectMapper. How can I define this configuration?
Theoretically you can use
JsonJacksonTreeDataFormat.INSTANCE.getConfiguredObjectMapper().registerModule()
to register a module, but camunda-spin returns spinjar.com.fasterxml.jackson.databind.ObjectMapper and not com.fasterxml.jackson.databind.ObjectMapper

Kind regards,
Stefan

[0] http://docs.camunda.org/latest/guides/user-guide/#process-engine-variable-serialization
[1] https://github.com/FasterXML/jackson-datatype-joda

[thorben....@camunda.com]

Hi Stefan,

First of all thank you for reporting this and for using the bleeding edge features of camunda :)

For configuration in general: Note that some jackson configuration can be applied by using Spin's configuration API like DataFormats.jsonTreeFormat().mapper()... However, this does currently not support registering Jackson modules. Spin is still in an early stage and we decided to evolve its configuration API as the community requests it (or provides pull requests ;) ). Please keep in mind that while JsonJacksonTreeDataFormat.INSTANCE.getConfiguredObjectMapper().registerModule() works, it is not very reliable. For example, Spin discards the current object mapper as soon as any configuration on the data format is changed. So the best solution in my opinion would indeed be extending Spin's configuration API, either by allowing to register modules or by allowing users to implement a callback that is invoked whenever the object mapper gets configured. I'll discuss this with my colleagues tomorrow.

For the namespace issues: There are two spin artifacts, one is spin-all, the other is spin-core. spin-all packs all dependencies in one jar and therefore relocates the jackson classes to not interfere with other jackson versions on the classpath. In the case that you want to configure the jackson object mapper from outside (or use Jackson annotations, etc.), we recommend to exclude the spin-all dependency and instead use spin-core. Then, jackson is pulled in as a transitive dependency.
This is still missing in the docs, for which I just created a ticket: https://app.camunda.com/jira/browse/CAM-2612

Best regards,
Thorben

[ia.sre...@gmail.com]

Hi,

I configured camunda-spin in my project and it seems to work as expected. I have one question about how the json string is mapped into the database.

The table ACT_RU_VARIABLE has 2 text columns (text_ and text2_). text_ seems to contain the json serialized variable content and text2_ contains the type information. text_ is restricted to varchar(4000) in h2 and to NVARCHAR2(2000) in oracle.

What happens when the json string is longer then the column length of text_?

Kind regards,
Stefan

[thorben....@camunda.com]

Hi Stefan,

It is good to read that it is working out for you.
The strategy in such a case is to store a byte array in the ACT_GE_BYTEARRAY table. The current implementation makes a check if the serialized String exceeds 4000 bytes which I realized, thanks to your mentioning of the oracle field declaration, is not sufficient. This check should rather depend on the character length of the serialized value and be more restrictive on Oracle (and perhaps also other databases), for which I just created a ticket: https://app.camunda.com/jira/browse/CAM-2693

So please keep experimenting with this variable type as it helps us a lot to identify these kinds of problems :)

As a side note: We renamed the variable type "SpinSerialization" to "spin-serialization" today, so if you should upgrade an existing camunda installation to the next alpha version, variable retrieval might be broken unless you update the TYPE_ field manually.

Best regards,
Thorben

[ia.sre...@gmail.com]

Hi,

thanks for the hint abount the renamed variable type!

Till when CAM-2693 will get fixed? We plan to use camunda-spin in our next release and so it has to work on an oracle installation.

Kind regards,
Stefan

[thorben....@camunda.com]

Hi Stefan,

CAM-2693 is planned for camunda 7.2.0-Final which is scheduled for the end of October (please don't pin me down to this estimation though ;) ). Until then, we are planning two release two more alphas, one in the next week which will very likely not yet have this fixed. Perhaps it gets fixed in the last alpha before Final but I cannot guarantee anything in that matter.

Best regards,
Thorben