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@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.-td13092212.html#a13092212, 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@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