Hi,
I am finding increasing problems with Camel's internal properties being (implicitly) brought into Activiti as process variables. I make extensive use of the copyVariablesFromProperties=true parameter on the Activiti Consumer URL.
Unfortunately, this parameter results in a number of process variables beginning with "Camel", such as CamelToEndpoint, CamelHttpResponseCode, CamelFilterMatched, CamelExternalRedelivered, CamelCreatedTimestamp and CamelCharsetName. This is annoying, but fairly benign. Starting with Camel 2.12.0, there is a new variable - "CamelMessageHistory" being added to the process variables, and this variable is of type org.apache.camel.impl.DefaultMessageHistory, which is not serializable, and so throws an exception.
A second observation is that ActivitiProducer creates one or two properties in the Camel route called PROCESS_ID_PROPERTY and PROCESS_KEY_PROPERTY. After the Camel route completes, these properties should not be implicitly saved as process variables if the "copyVariablesFromProperties" parameter is set. In my opinion, this exposes too much implementation. If the value of these properties are desired, the Camel route should copy the value to a domain-specific name, not rely on the internal implementation.
I am an enthusiastic user of the Activiti-Camel integration (thanks so much, guys!)
My questions are:
1. Should these be considered to be defects in the activiti-camel library?
2. Do I need to extend the Activiti consumer/producer/endpoint classes to prevent these properties being saved as process variables?
I would appreciate any thoughts on the matter (solutions or sympathy, even)
Thanks,
Nick.
