[rules-users] Java Generics - Using a object model that has generic signatures.

[Edson Tirelli]

   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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20080204/10e44c80/attachment.html