Исчезающие объявления, добавление артефактов Kie в KieFileSystem

Мы используем KieFileSystem для динамического управления правилами Drools. Когда у меня есть новое правило, я добавляю его в KieServices с помощью KieFileSystem, но я перезаписываю свои правила, а не добавляю их. Как только я вставляю другое правило, объявлений, которые я создал в предыдущих правилах, больше нет.

Должен быть способ добавить эти правила, или не было бы способа их изменить? Эффект, который я ищу, может быть достигнут с помощью метода, указанного в AddRemoveRulesTest.java.

KnowledgeBuilder builder = KnowledgeBuilderFactory.newKnowledgeBuilder();
builder.add( ResourceFactory.newReaderResource( new StringReader( ruleBuilder.getRule() ) ), ResourceType.DRL);
if(builder.hasErrors()){
    _log.error( builder.getErrors().toString() );
    return;
}

//This is where the magic happens.  How equivalent with versioned deployable artifacts?  
base.addKnowledgePackages(builder.getKnowledgePackages());

Если я правильно следую IncrementalCompilationTest, мне кажется, что мне нужно будет найти способ получить существующие правила и добавить их в новую банку с новым правилом, как AddRemoveRuleTest. Я бы предпочел не возвращаться к базе данных, чтобы подобрать существующие правила. Как?

Если я продвигаюсь вперед с этим более неудобным, но совместимым с maven методом, мне нужно выяснить, какой из них является лучшим способом динамического добавления правил в сеанс? Насколько я могу судить, мы используем добавление версионированных артефактов Kie в качестве практики maven, а метод AddRemoveRulesTest не использует эту практику. См. drools-6-add-rules-to-a-running-kiession


person pjc    schedule 02.12.2015    source источник
comment
Интеграционные тесты, на которые вы ссылаетесь здесь, а также в stackoverflow.com/questions/34055637/, является тестом и на самом деле не предназначен для использования в качестве примера для реализации приложений Drools. Обратите внимание, что импорт включает пакеты ниже org.kie.internal, все из которых не включены в стабильную часть API и не включены в набор документов Javadoc, поставляемый с установками Drools. Вы продвигаетесь на неизведанную территорию, опасность впереди. Общий совет — не основывать приложения на этом коде.   -  person laune    schedule 03.12.2015
comment
Спасибо за ваши комментарии и рассмотрение этого вопроса laune. Я удалил другой вопрос, чтобы у нас не было одинаковых комментариев в двух местах. Мне все еще интересно, есть ли ответ. Что касается практики, есть много людей, использующих динамическое построение правил, я не просто проснулся и решил, что собираюсь создать реализацию с использованием внутренних библиотек, этот метод был рекомендован сильными нападающими на доске org.drools. от РедХат. С Uncharted все в порядке, все эти библиотеки были перенесены в большую реорганизацию кода.   -  person pjc    schedule 03.12.2015
comment
Короче говоря, изменение набора правил на уровне DRL — это действие CM, которое должно выполняться с помощью инструментов CM. Восстановление после такой модификации — это этап сборки, который лучше всего повторить с полным (новым) набором. Я не знаю, как Drools автоматически обрабатывает переключение на новую базу правил и новый сеанс, но я бы предпочел не полагаться на процесс, который может соответствовать или не соответствовать требованиям приложения. Если вы найдете документ с обязательством, что определенная процедура делает то-то и то-то, и вам это нравится: во что бы то ни стало. В противном случае: берегите себя.   -  person laune    schedule 04.12.2015