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@kronos.com
> <mailto: eric.miles@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@kronos.com
>>     <mailto:eric.miles@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@lists.jboss.org <mailto:rules-users@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users

_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users