I’m bringing this old topic back to life as it is the only one about this - and the proposed workaround 3 seems to be not working (at least since 7.7, but I guess it is identical for 7.6).
Please adjust the jira ticket “applies to” to all versions, as the problem is still the same.
I personally cannot understand why it isn’t fixed already and created a PR with the fix, hoping that there will be a solution by “merge click” after 18 months.
Until the bug is fixed and a new camunda-engine is available I’d like to implement a workaround.
That can be done by subclassing
convertToModelValue method could return
null in case an empty String is handed to it and that should avoid the exception you see. The default date type can be replaced by implementing a process engine plugin and in its
postInit method […]
this all works fine (using the corresponding camunda maven archetype). But now it gets complicated/confusing (with the 7.7 code base)
… the collection returned by
ProcessEngineConfigurationImpl#getFormTypes can be modified. The instance of
org.camunda.bpm.engine.impl.form.type.DateFormType should be removed and an instance of your custom subclass can be added.
Seems like this isn’t useful any more (or I don’t understand it). While its possible to do
we immediately must question what datePattern we want to add. This question leads to
parseFormPropertyType in FormTypes.class and shows it is actually extracted from the
Element. Which brings us back to the question: where should we insert our bug-fix? Overriding FormTypes.class, too (using our
FixDateFormType instead of
DateFormType) and directly overriding the previously set FormTypes by doing
Any help (and a merge of the PR) would be welcome.