Red Hat Bugzilla – Bug 1314322
It is not possible to create Business Process on Windows server with I18n Business Process names
Last modified: 2018-01-30 18:39:44 EST
Description of problem:
You can't create Business Process with I18n name like (日本語, Русский) and so on. See attachment.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start Business Central on Windows server
2. Create new Business Process with I18n name like 日本語 or Русский on Windows
It is not possible to create this Business Process with error (just for first try, from the second try it will be no messages at all just not working button OK):
Unable to complete your request. The following exception occurred: java.lang.RuntimeException: org.eclipse.jgit.dircache.InvalidPathException: Invalid path: NewProject/src/main/resources/example/newproject/???.bpmn2.
No I18n restrictions for Windows
There are no specific information about errors in server log
Created attachment 1132745 [details]
I18n Business Process names on Windows
See also bug 1122342
Update: After first try of I18n named Business Process creation it is not possible to create new Asset (any asset) even with English "correct" name. Server reboot needed.
Created attachment 1137101 [details]
server log with stack trace
This is a case of a more general problem creating resources with i18n characters in names when BPMS is running on Windows. For example, if you try to create a new DRL File with name drl日本語, a popup with this error appears:
Unable to complete your request. The following exception occurred: java.lang.RuntimeException: org.eclipse.jgit.dircache.InvalidPathException:
Invalid path: jdlproj1/src/main/resources/drl??????? .drl.
A similar error occurs when trying to create a BP with i18n chars, and when trying to create a Project with i18n chars, the UI hangs.
I've attached the server log for the case of creating a DRL file.
Eder - I've assigned this over to you as it seems to be a general UF problem when creating resources with i18n characters in names. Toni wonders whether it's an issue with the way we configure jgit.
The workaround is confirmed effective. This is not a regression, 6.2 behaves in the exact same way.