[rules-users] Re: Odd static inner class behavior

Fernando Meyer fmcamargo at gmail.com
Mon Aug 20 22:59:12 EDT 2007


Hi Eric, after some tests I noticed that in java language you can't  
import the same class name twice even if the class is defined in  
different packages, ie try creating a java file and import both  
java.awt.List and java.util.List, it won't work, you will get a  
similar error from javac compiler

So, if it is really necessary you can try using two package builders  
as I did in the following example

     public void testImportColision () throws Exception  {
         final PackageBuilder builder = new PackageBuilder();
         final PackageBuilder builder2 = new PackageBuilder();
         builder.addPackageFromDrl( new InputStreamReader( getClass 
().getResourceAsStream( "nested1.drl" ) ) );
         builder2.addPackageFromDrl( new InputStreamReader( getClass 
().getResourceAsStream( "nested2.drl" ) ) );
         final Package pkg = builder.getPackage();
         final Package pkg2 = builder2.getPackage();

         final RuleBase ruleBase = getRuleBase();
         ruleBase.addPackage( pkg );
         ruleBase.addPackage( pkg2 );


         final WorkingMemory workingMemory =  
ruleBase.newStatefulSession();

         workingMemory.insert( new FirstClass() );
         workingMemory.insert( new SecondClass() );
         workingMemory.insert( new FirstClass.AlternativeKey() );
         workingMemory.insert( new SecondClass.AlternativeKey() );

         workingMemory.fireAllRules();
     }

Regards
Fernando

On Aug 1, 2007, at 1:15 PM, Eric Miles wrote:

> Edson,
>
> I was finally able to get around to making a test case to determine  
> if I did in fact see this behavior.  I can reproduce it and have  
> opened up a Jira for it.  I have also attached my test case for  
> easy reproduction. For your (and other's) knowledge, here is the link:
>
> http://jira.jboss.com/jira/browse/JBRULES-1053
>
> Truly odd behavior for sure!
>
> Thanks,
> Eric
>
> Edson Tirelli wrote:
>>     Eric,
>>     Please do! Thanks,
>>     Edson
>> 2007/7/26, Eric Miles <eric.miles at kronos.com  
>> <mailto:eric.miles at kronos.com>>:
>>     Edson,
>>     That certainly makes sense.  However I'm fairly certain that in
>>     referencing the inner class in rule definition, I always  
>> qualified it
>>     with the outer class name, ie:
>>     DataClass.AlternativeKey()
>>     or
>>     AnotherClass.AlternativeKey()
>>     I appreciate your explaination of the "merge" process.  Rather  
>> than have
>>     you spend any more time on this, I'll try to put together a  
>> test case to
>>     ensure I was seeing the behavior I thought I was seeing.  I  
>> probably
>>     won't get around to this until tonight or the weekend.
>>     If I was mistaken, I'll let you (and the mailing list) know.   
>> If I was
>>     not, would you like me to open a JIRA with the attached test  
>> case?  I
>>     would assume that if the inner classes contain the qualified  
>> name that
>>     the engine should be able to handle that?
>>     Thanks,
>>     Eric
>>     Edson Tirelli wrote:
>>      >
>>      >     Eric,
>>      >
>>      >     Thanks, I understand now.
>>      >
>>      >      What happens is that if both DRL files declare the  
>> same package
>>      > name, all their contents will be merged. It means that you  
>> would
>>     end up
>>      > with both imports in the same namespace:
>>      >
>>      > import com.company.DataClass.AlternativeKey;
>>      > import com.company.AnotherClass.AlternativeKey;
>>      >
>>      >      And so the engine will raise an error saying that it does
>>     not know
>>      > which one you are refering to when you write simply:
>>      >
>>      > AlternativeKey
>>      >
>>      >     I think the engine behavior is correct, since the idea  
>> of loading
>>      > two different files with the same name space into the same  
>> package
>>      > builder is to merge them, or even replace (update) that
>>     eventually have
>>      > the same name.
>>      >
>>      >     What do you think?
>>      >
>>      >     Edson
>>      >
>>      >
>>      > 2007/7/26, Eric Miles <eric.miles at kronos.com
>>     <mailto:eric.miles at kronos.com>
>>      > <mailto: eric.miles at kronos.com  
>> <mailto:eric.miles at kronos.com>>>:
>>      >
>>      >     Edson,
>>      >
>>      >     I have since changed my schema but here was my issue:
>>      >
>>      >     rule1.drl:
>>      >     import com.company.DataClass.AlternativeKey;
>>      >     import com.company.DataClass;
>>      >
>>      >     rule "Some rule"
>>      >         when
>>      >             DataClass.AlternativeKey(someParm == true)
>>      >         then
>>      >             ...
>>      >     end
>>      >
>>      >     Different drlf file:
>>      >     rule2.drl
>>      >     import com.company.AnotherClass.AlternativeKey;
>>      >     import com.company.AnotherClass;
>>      >
>>      >     rule "Another rule"
>>      >         when
>>      >             AnotherClass.AlternativeKey(diffParm == 1)
>>      >         then
>>      >             ...
>>      >     end
>>      >
>>      >
>>      >     This was the gist of what I was doing.  The outer  
>> classes' names
>>      >     were different, it was the INNER class of each of these
>>     classes that
>>      >     had the same name.  I was actually getting compile  
>> errors on the
>>      >     import statements.  Like I said, these rules worked  
>> fine if
>>     loaded
>>      >     separately, but once I tried to put them all int he  
>> same rule
>>     base,
>>      >     I was getting the import collision error.  Later on  
>> this evening
>>      >     (when I'm not at work), I'll try to put together a  
>> small test
>>     case
>>      >     and upload it.  In the meantime, you can look skim over  
>> this
>>     and let
>>      >     me know if something jumps out at you.
>>      >
>>      >     Thanks,
>>      >     Eric
>>      >
>>      >
>>      >     On Thu, 2007-07-26 at 10:32 -0300, Edson Tirelli wrote:
>>      >>         Eric,
>>      >>
>>      >>         Not sure if I understood your problem, but if you  
>> have
>>      >>     multiple classes with the same name, and the only  
>> difference is
>>      >>     that they are inner classes of different classes, I guess
>>     what you
>>      >>     need to do is to fully qualify your class names in  
>> your rules...
>>      >>
>>      >>     rule xxx
>>      >>     when
>>      >>         my.package.MyClass.MyInnerClass( ... )
>>      >>     ...
>>      >>     end
>>      >>
>>      >>        If this is not your problem, can you please show us an
>>     example
>>      >>     so we understand it better?
>>      >>
>>      >>        Edson
>>      >>
>>      >>
>>      >>     2007/7/25, Eric Miles < eric.miles at kronos.com
>>     <mailto:eric.miles at kronos.com>
>>      >>     <mailto:eric.miles at kronos.com  
>> <mailto:eric.miles at kronos.com>>>:
>>      >>
>>      >>         Due to how JAXB treats anonymous inner complex  
>> types, I
>>     ended
>>      >>         up with a public static inner classes named
>>     AlternativeKey in
>>      >>         several of my data classes  I have several rules  
>> written to
>>      >>         deal with each data class individually that all  
>> work ok.
>>      >>         However, when I attempt to put them all in the  
>> same rule
>>     base
>>      >>         (all belong to the same package), I get an import  
>> collision
>>      >>         exception on the AlternativeKey inner class.   
>> Depending on
>>      >>         where in the builder I add the resource depends on  
>> which
>>      >>         AlternativeKey the compiler bitches about
>>     (validity).  I'm not
>>      >>         familiar with the source at all, so I'm unsure as to
>>     where to
>>      >>         look for this.  However, this sounds like a bug to
>>     me?  There
>>      >>         is an easy workaround for this as I I just don't use
>>     anonymous
>>      >>         types and define them in my schema explicitly.  Just
>>     thought
>>      >>         I'd identify this as a possi ble issue.
>>      >>
>>      >>         Thanks,
>>      >>         Eric
>>      >>
>>      >>
>>      >>         _______________________________________________
>>      >>         rules-users mailing list
>>      >>         rules-users at lists.jboss.org
>>     <mailto:rules-users at lists.jboss.org>
>>     <mailto:rules-users at lists.jboss.org
>>     <mailto:rules-users at lists.jboss.org>>
>>      >>         https://lists.jboss.org/mailman/listinfo/rules-users
>>      >>
>>      >>
>>      >>
>>      >>
>>      >>     --
>>      >>       Edson Tirelli
>>      >>       Software Engineer - JBoss Rules Core Developer
>>      >>       Office: +55 11 3529-6000
>>      >>       Mobile: +55 11 9287-5646
>>      >>       JBoss, a division of Red Hat @ www.jboss.com
>>     <http://www.jboss.com> <http://www.jboss.com>
>>      >
>>      >
>>      >
>>      >
>>      > --
>>      >   Edson Tirelli
>>      >   Software Engineer - JBoss Rules Core Developer
>>      >   Office: +55 11 3529-6000
>>      >   Mobile: +55 11 9287-5646
>>      >   JBoss, a division of Red Hat @ www.jboss.com
>>     <http://www.jboss.com> <http://www.jboss.com>
>>      >
>>      >
>>      >
>>      
>> --------------------------------------------------------------------- 
>> ---
>>      >
>>      > _______________________________________________
>>      > rules-users mailing list
>>      > rules-users at lists.jboss.org <mailto:rules- 
>> users at lists.jboss.org>
>>      > https://lists.jboss.org/mailman/listinfo/rules-users
>>     _______________________________________________
>>     rules-users mailing list
>>     rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/rules-users
>> -- 
>>   Edson Tirelli
>>   Software Engineer - JBoss Rules Core Developer
>>   Office: +55 11 3529-6000
>>   Mobile: +55 11 9287-5646
>>   JBoss, a division of Red Hat @ www.jboss.com <http://www.jboss.com>
>> --------------------------------------------------------------------- 
>> ---
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users




More information about the rules-users mailing list