All field constraints should start with a field name. Thus it should always
be
X( state == X,State.INIT )
There are some possibilities for using qualified names on the left of a
relational operator,
but they are (mostly) intended to let you access fields via variables bound
to objects.
-W
On 7 April 2011 09:38, Hezi Stern <he...@delegatecom.com> wrote:
> Hi All,
>
>
>
> I believe that I have encountered two potential bugs (Expert), I am using
> Drools 5.1.1.
>
> It seems that they are related to namespaces and inner classes in
> particularly.
>
>
>
> I have a class with an internal inner class (enum):
>
>
>
> public class X {
>
>
>
> public enum State {
>
> INIT,
>
> DONE;
>
> }
>
>
>
> Private State state;
>
> }
>
>
>
> In the DRL file I would import the class X (e.g. import com.stub.X)
>
> And in the LHS of the rule I could state something like
>
>
>
> $x: X(X.State.INIT == state)
>
>
>
> As far as I understand this is a legal syntax, the problem is that I get
> the following exception: “Exception executing predicate X.State.INIT ==
> state”
>
> I found that I can work around this by importing com.stub.X.State and
> changing the LHS rule to
>
> $x: X(State.INIT == state)
>
>
>
> This brings me to the second issue. If I have an additional class let’s say
>
>
>
>
> public class Y {
>
>
>
> public enum State {
>
> ALIVE,
>
> TERMINATED;
>
> }
>
>
>
> Private State state;
>
> }
>
>
>
> In this case importing both classes using the workaround above, hence:
>
> import com.stub.X.State
>
> import com.stub.Y.State
>
> result in an import collision with the State class so it is kind of a
> deadlock situation.
>
>
>
> I can always overcome this by changing the names of the inner classes
> (which is what I am currently doing) but I thought it would be helpful to
> state this.
>
> Perhaps this is not a bug but rather something I am doing wrong.
>
>
>
> Hezi
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
