[rules-users] Re: Odd static inner class behavior
Eric Miles
eric.miles at kronos.com
Thu Jul 26 10:15:43 EDT 2007
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>>:
>
> 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>>:
>>
>> 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>
>> 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
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
More information about the rules-users
mailing list