[rules-users] Re: Odd static inner class behavior
Edson Tirelli
tirelli at post.com
Thu Jul 26 12:52:00 EDT 2007
Eric,
Please do! Thanks,
Edson
2007/7/26, Eric Miles <eric.miles at kronos.com>:
>
> 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
>
> _______________________________________________
> rules-users mailing list
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20070726/d1d59eed/attachment.html
More information about the rules-users
mailing list