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

Reply via email to