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]:
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]:
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 possible issue.
Thanks,
Eric
___
rules-users mailing list
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
--
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
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
