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