Krishna,
The problem is not really in Drools, but in the Java "erasure" behavior
for Generics.
Once you assert a List as an object into the working memory, it loses the
generic type information (AFAIK).
So, you can't really do:
when
List<SomeType>()
then
Because all lists in the working memory would match (even if we supported
the <> type syntax).
The behavior you saw when using "from" is the correct behavior, since
"from" is used to try and match (iterate) each of the elements in a
collection.
So,
genericList : SomeType ( request.getterAttributeName != null ) from
request.getterAttributeName
Will iterate and try to match each of the elements of the
"attributeName" collection, and will fire the rule for each match it finds.
Regarding your problem, you don't need to "change" your object model.
You can use it as is in the rules. What you can't do is use the generic
types do constrain your matches. It is exactly the same what you do in java
when you mix genericized classes with non-genericized classes.
[]s
Edson
2008/2/1, Krishna Satya <krishna.ksatya(a)gmail.com>:
Greetings.
I have been looking at the postings on the user group and it appears that
Java Generics is not supported in the constraint section of the rule.
In one of the postings:
http://www.nabble.com/Problem-in-using-genrics-with-drools4.0.1.-td130922...,
Mark Proctor. has indicated that this cannot be supported. I see other
postings where drools team has indicated that generics is not supported.
Given the following would be invalid:
rule "Generic Test"
request : InputRequest()
genericList : List<SomeType> ( request.getterAttributeName != null )
from request.getterAttributeName
then
end
what are the alternatives/workaround to using a model object that has
getters that return say a collection of generic types. Our object model
uses generics pretty heavily and it would be bad alternative to replicate
these model objects without generic signatures just for the sake of Drools.
Curiosity got the better of me and I tried to modify the above rule to see
what Drools would let me get away with. I cannot have a rule that has any
Generic semantics, so I had to drop <SomeType>. I tried
Approach 1 - genericList : List ( request.getterAttributeName != null )
from request.getterAttributeName
Approach 2 - genericList : SomeType ( request.getterAttributeName !=
null ) from request.getterAttributeName (forced to do this to avoid run
time exception from approach 1)
Here is what I observe:
Approach 1 - I tried to see if Drools would give me a reference to a List
Type object. The rule compiled but I was getting a classcast exception
during runtime when I tried to use the reference in the consequence. Looking
at what the root cause for the class cast shows that Drools actually was
creating a reference to "SomeType" object which is the type of the object
contained in the list.
Approach 2 - I modified the rule to avoid the class cast exception from
approach 1. The rule compiled and executed. But the rule was getting fired
as many times as the number of objects in the list.
Both of the above observations are neither intuitive nor typically
desired. I understand the rule definition was exploratory.
Questions I have :
- Is the above observation a result of a bug in drools? Can the
observation be explained.
- What is the approach recommended to using an object model that has
generic signatures ?
Hoping some one will weigh in on this subject.
Thanks a lot.
- Krishna
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @
www.jboss.com