Раньше согласование заявок происходило по "hardcoded" бизнес-процессу Activity. Теперь за это отвечает Camunda (собственно, тут ничего не пришлось переделывать, потому что Camunda - это форк Activity)
Мы не рассматривали Camunda 8, потому что он может работать только в виде независимого оркестратора, а нам важно сохранить BPM-движок в виде embedded engine. Сами разработчики говорят, что будут поддерживать Camunda 7 еще несколько лет.
"If you’re using an embedded engine, you might want to stick with Camunda Platform 7, unless you have good reason to migrate. This is a perfectly reasonable choice as Camunda Platform 7 will remain fully supported for at least the next five years".
В целом, Camunda 8 - это уже другой продукт (больше не форк Activity, совершенно другая модель данных, ориентир на SaaS и т.д.)
Привет! Мы управляем потоками через ExecutorService, который по умолчанию создает non-daemon потоки. И, похоже, что сейчас Java 16 работает строго по доке. Поэтому нужно либо явно передавать ThreadFactory, которая устанавливает для потоков setDaemon(true), либо аккуратно завершать ThreadPool при останове приложения.
Раньше согласование заявок происходило по "hardcoded" бизнес-процессу Activity. Теперь за это отвечает Camunda (собственно, тут ничего не пришлось переделывать, потому что Camunda - это форк Activity)
Мы не рассматривали Camunda 8, потому что он может работать только в виде независимого оркестратора, а нам важно сохранить BPM-движок в виде embedded engine.
Сами разработчики говорят, что будут поддерживать Camunda 7 еще несколько лет.
"If you’re using an embedded engine, you might want to stick with Camunda Platform 7, unless you have good reason to migrate. This is a perfectly reasonable choice as Camunda Platform 7 will remain fully supported for at least the next five years".
В целом, Camunda 8 - это уже другой продукт (больше не форк Activity, совершенно другая модель данных, ориентир на SaaS и т.д.)
Привет!
Solar InRights состоит из примерно 400 тысяч строк кода и 4 тысяч классов без учета сторонних зависимостей.
Сакрального смысла в этом нет :)
Олег Гетманский
Привет! Мы управляем потоками через ExecutorService, который по умолчанию создает non-daemon потоки. И, похоже, что сейчас Java 16 работает строго по доке. Поэтому нужно либо явно передавать ThreadFactory, которая устанавливает для потоков setDaemon(true), либо аккуратно завершать ThreadPool при останове приложения.
Олег Гетманский
Похоже на то, потому что даже Tomcat для Java 9+ добавляет свои --add-opens
Олег Гетманский