Skip to content

Conversation

@sgort
Copy link
Collaborator

@sgort sgort commented Nov 28, 2025

Closes #58

@sgort sgort requested review from a-m-zill and javahippie November 28, 2025 19:57
Copy link
Contributor

@a-m-zill a-m-zill left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @sgort, I found a small amount of too many 'x's.

To optimize the acquisition of jobs that need to be executed immediately, the `DUEDATE_` column is not set (`null`) and a (positive) null check is added as a condition for acquisition.

In case each job must have a `DUEDATE_` set, the optimization can be disabled. This can be done by setting the `ensureJobDueDateNotNull` [process engine configuration flag](../../reference/deployment-descriptors/tags/process-engine.md#ensureJobDueDateNotNull) to `true`.
In case each job must have a `DUEDATE_` set, the optimization can be disabled. This can be done by setting the `ensureJobDueDateNotNull` [process engine configuration flag](../../reference/deployment-descriptors/tags/process-engine.mdxx#ensureJobDueDateNotNull) to `true`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sgort here is one 'x' to much ;)

By default, the Job Executor executes all jobs regardless of their priorities. Some jobs might be more important to finish quicker than others, so we assign them priorities and set `jobExecutorAcquireByPriority` to `true` as described above. Depending on the workload, the Job Executor might be able to execute all jobs eventually. But if the load is high enough, we might face starvation where a Job Executor is always busy working on high-priority jobs and never manages to execute the lower priority jobs.

To prevent this, you can specify a priority range for the job executor by setting values for [`jobExecutorPriorityRangeMin`](../../reference/deployment-descriptors/tags/process-engine.md#jobExecutorPriorityRangeMin) or [`jobExecutorPriorityRangeMax`](../../reference/deployment-descriptors/tags/process-engine.md#jobExecutorPriorityRangeMax) (or both). The Job Executor will only acquire jobs that are inside its priority range (inclusive). Both properties are optional, so it is fine only to set one of them.
To prevent this, you can specify a priority range for the job executor by setting values for [`jobExecutorPriorityRangeMin`](../../reference/deployment-descriptors/tags/process-engine.mdx#jobExecutorPriorityRangeMin) or [`jobExecutorPriorityRangeMax`](../../reference/deployment-descriptors/tags/process-engine.mdxx#jobExecutorPriorityRangeMax) (or both). The Job Executor will only acquire jobs that are inside its priority range (inclusive). Both properties are optional, so it is fine only to set one of them.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sgort here is also one 'x' to much.


Further details of the session cookie like the `SameSite` flag can be configured via
[operaton.bpm.webapp.session-cookie](../spring-boot-integration/configuration.md#session-cookie) in the `application.yaml`.
[operaton.bpm.webapp.session-cookie](../spring-boot-integration/configuration.mdxx#session-cookie) in the `application.yaml`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sgort here is also one 'x' to much. :)


You can mitigate the risk of an attack by defining a limit for the maximum number of results
(`queryMaxResultsLimit`) in the [process engine configuration](../reference/deployment-descriptors/tags/process-engine.md#queryMaxResultsLimit).
(`queryMaxResultsLimit`) in the [process engine configuration](../reference/deployment-descriptors/tags/process-engine.mdxx#queryMaxResultsLimit).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sgort here is also one 'x' to much.

* Feature Secure Processing (FSP) of XML files according to [Oracle](https://docs.oracle.com/javase/8/docs/api/javax/xml/XMLConstants.html#FEATURE_SECURE_PROCESSING) which introduces [limits](https://docs.oracle.com/javase/tutorial/jaxp/limits/limits.html) for several XML properties

If the limitations on XML files introduced by XXE prevention need to be removed, XXE processing can be enabled via `enableXxeProcessing` in the [process engine configuration](../reference/deployment-descriptors/tags/process-engine.md#configuration-properties).
If the limitations on XML files introduced by XXE prevention need to be removed, XXE processing can be enabled via `enableXxeProcessing` in the [process engine configuration](../reference/deployment-descriptors/tags/process-engine.mdxx#enableXxeProcessing).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One 'x' to much.


Starting with version 7.9, by default, it is not possible to set variables of type `Object` **AND** the data format `application/x-java-serialized-object`.
The behavior can be restored with the process engine configuration flag [`javaSerializationFormatEnabled`](../reference/deployment-descriptors/tags/process-engine.md#javaSerializationFormatEnabled).
The behavior can be restored with the process engine configuration flag [`javaSerializationFormatEnabled`](../reference/deployment-descriptors/tags/process-engine.mdxx#javaSerializationFormatEnabled).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One 'x' to much.

### JSON/XML serialized objects using Spin

Therefore, we recommend enabling the whitelisting of allowed Java classes by enabling the property [deserializationTypeValidationEnabled](../reference/deployment-descriptors/tags/process-engine.md#deserializationTypeValidationEnabled) in the process engine configuration. With this, the process engine validates the class names of submitted variables against a whitelist of allowed Java class and package names. Any non-whitelisted content is rejected. The default values are safe, but may be too restrictive for your use case. You can use the engine properties `deserializationAllowedPackages` and `deserializationAllowedClasses` to extend the default whitelist with package and class names of Java types that you consider save to deserialize in your environment.
Therefore, we recommend enabling the whitelisting of allowed Java classes by enabling the property [deserializationTypeValidationEnabled](../reference/deployment-descriptors/tags/process-engine.mdxx#deserializationTypeValidationEnabled) in the process engine configuration. With this, the process engine validates the class names of submitted variables against a whitelist of allowed Java class and package names. Any non-whitelisted content is rejected. The default values are safe, but may be too restrictive for your use case. You can use the engine properties `deserializationAllowedPackages` and `deserializationAllowedClasses` to extend the default whitelist with package and class names of Java types that you consider save to deserialize in your environment.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One 'x' to much.

Using the process engine configuration flag `logEntriesPerSyncOperationLimit`, the number of created entries to the user operation log can be limited for synchronous API calls. By default, one operation log entry is written per API call, regardless of how many entities were affected (default property value is `1`).
If you choose to change `logEntriesPerSyncOperationLimit`, select a value that you are certain your system can handle.
For more information about the possible values for `logEntriesPerSyncOperationLimit`, visit the [configuration documentation](../reference/deployment-descriptors/tags/process-engine.md#logEntriesPerSyncOperationLimit).
For more information about the possible values for `logEntriesPerSyncOperationLimit`, visit the [configuration documentation](../reference/deployment-descriptors/tags/process-engine.mdxx#logEntriesPerSyncOperationLimit).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One 'x' to much.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Fix broken anchor links

2 participants