入れ子クラスのDroolsスコア計算は派生クラスでは失敗します

Question

私のコンテキストはスコア計算にDroolsを使用するJava Optaplannerアプリケーションです（optaplannerの例に似ています）。

は、基底クラスと派生クラスでいくつかのクラスを分割した後、私はスコア計算にエラーが表示されます。ネストされた変数へ

Exception in thread "main" java.lang.IllegalStateException: There are errors in a score DRL: 
Error Messages: 
Message [id=1, kieBase=defaultKieBase, level=ERROR, path=de/.../Rules.drl, line=77, column=0 
    text=Unable to Analyse Expression var.type.prop2: 
[Error: unable to resolve method using strict-mode: de...PropType.prop2] 

のアクセスは、メインのJavaコードで正常に動作します。

第2レベル（class1.class2.param）が派生クラスである場合、Droolsルールのネストされた変数へのアクセスに問題があります。私は私のより複雑なコードから抽出された小さな例でこれを説明しよう（私は小さなそれを維持しようとした完全な最小限の例が良いだろうと、私はそれを拡張しようとすることができます）：

計画エンティティ：

@PlanningEntity 
public class PlanningE{ 
    // ... 

    @PlanningVariable(valueRangeProviderRefs = {"something"}) 
    private SomePlanningVar var; 
} 

これは、計画変数になります。いくつかの値を保持し、

public class SomePlanningVar{ 
    private PropType type; 

    //getter, setter, constructor 
    } 
} 

と計画変数で使用される最終的なクラス。 （PropTypeBがPropTypeを拡張することに注意してください）：

public class PropType{ 
    private Integer prop1; 

    //getter, setter, constructor 
} 

public class PropTypeB extends PropType{ 
    private Integer prop2; 

    // getter setter constructor 
} 

セットアップ擬似コード

... 
PropTypeB prop = new PropTypeB(...) 
SomePlanningVar pvar = new SomePlanningVar(prop) 
... 

問題のDroolsのルールは次のとおりです。

rule "prop" 
    when 
     PlanningE($value : var.type.prop2) 
    then 
     scoreHolder.addSoftConstraintMatch(kcontext, -$value); 
end 

私はPropTypeを分割していない場合は、このルールは正常に動作します基底クラスと派生クラスで（ちょうどprop2をPropTypeに追加します）、この種の継承はかなり可能性があります 一般。

Droolsは、Javaコードでは問題なく動作しますが、何らかの形で派生クラスに正しいシグネチャが表示されないようです。

Javaおよび/またはDrools（強力なPythonの背景を持ちますが、Javaに比較的新しいもの）で継承がどのように機能するかは間違っていますが、今は何も見えません。

何か問題が起こっている人はいますか？

Answer 1

実際これは非常に簡単です。アクセサにvarがクラスSomePlanningVarのものであり、その型がクラスPropTypeであることを検出した（行うことができますコンパイラは一つだけである）

var.type.prop2 

静的解析を見て。これは物語の終わりのprop2というプロパティを持っていません。

ジレンマのうち方法の一つは、親クラスにPROP2を追加することです：

public class PropType{ 
    private Integer prop2; 
    public Integer getProp2(){ return prop2; } 
} 

PropTypeBがPropType方法getProp2をオーバーライドします。誤った呼び出しを捕捉したい場合は、PropType.getProp2に例外をスローすることができます。

また、PropTypeとPropTypeを作成します。getProp2 abstractは、PropTypeクラスのオブジェクトを決して作成しない場合に可能です。

あなたのクラスのデザインも見直したいかもしれません。なぜあなたはPropTypeBを期待するとき、ルールにPropTypeを持っていますか？サブクラスに対してルールを書く方が良いのではないでしょうか？