Eric, Please do! Thanks,
Edson 2007/7/26, Eric Miles <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>>: > > 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 <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>>: >> >> 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 >> [email protected] <mailto:[email protected] > >> 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> > > > > > -- > 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 > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list [email protected] 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
_______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
