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