[rules-users] Possible bug with isA operator

[Mike Melton]

Davide,

Thanks very much for the prompt reply and detailed explanation. I do
have some control over my POJO facts (and most of them do already
implement equals/hashCode correctly), so I will experiment with your
presented alternative/workaround.

I am excited about traits because they allow me to rewrite some of my
more complex rules much more cleanly/clearly. I will certainly keep in
touch with any other feedback I have.

JBRULES-3321 created.

Mike

On Wed, Dec 28, 2011 at 1:22 PM, Davide Sottara <dsotty at gmail.com> wrote:
> Thanks Mike,
> I have found and solved the problem, I'll commit the fix together with some
> other improvements in the next few days. Can you open a JIRA for this?
>
> The problem here is that, in order to be "traited", objects need a few
> additional internal structures, hence the reason for the @Traitable
> annotation. With declared beans, these structures are added automatically to
> the class generated on the fly. With "legacy" (pojo) beans, that is
> impossible - by convention we are not touching legacy classes - so a wrapper
> is generated internally instead.
> When you applied the "isA" operator to a legacy object type, the operator
> was looking for those additional structures. I have modified the operator to
> go and look for the wrapper corresponding to an object, so calling isA on a
> legacy bean WILL be possible, but discouraged.
>
> Another option would be :
>
> when
>  $p : PojoFact( ... )
>  [ not / exists ] Thing( core == $p )
> then
>
> All traits implement Thing, so this rule effectively looks for legacy
> objects which have (not) been traited. You can use more specific types than
> "Thing" if you want. With respect to "isA", which probably will be renamed
> "hasType", this will also be triggered by more specific traits. Remember
> that traits are interfaces, so inheritance is possible. The drawback here is
> that your legacy bean must implement equals() ad hashCode() appropriately,
> considering that an object might be compared not just with itself or objects
> of the same class, but also with instances of proxy subclasses.
> For example, in your case you should write something like:
>
>    @Override
>    public boolean equals(Object o) {
>        if (this == o) return true;
>        if ( ! ( o instanceof PojoFact ) ) return false;
>        PojoFact pojoFact = (PojoFact) o;
>        if ( getId() != pojoFact.getId() ) return false;
>        return true;
>    }
>
>    @Override
>    public int hashCode() {
>        return id;
>    }
>
> Feel free to ask more questions and report more bugs and suggestions ;)
> The code is very experimental and still work in progress, in time it will
> come with better robustness and documentation
> Best
> Davide
>
> --
> View this message in context: http://drools.46999.n3.nabble.com/rules-users-Possible-bug-with-isA-operator-tp3616614p3616963.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users