9:02 a.m.
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(a)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(a)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 possible issue.
Thanks,
Eric
_______________________________________________
rules-users mailing list
rules-users(a)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
9:15 a.m.
New subject: Odd static inner class behavior
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(a)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(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
11:52 a.m.
New subject: Odd static inner class behavior
Eric,
Please do! Thanks,
Edson
2007/7/26, Eric Miles <eric.miles(a)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(a)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(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)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
11:15 a.m.
New subject: Odd static inner class behavior
Edson,
I was finally able to get around to making a test case to determine if I
did in fact see this behavior. I can reproduce it and have opened up a
Jira for it. I have also attached my test case for easy reproduction.
For your (and other's) knowledge, here is the link:
http://jira.jboss.com/jira/browse/JBRULES-1053
Truly odd behavior for sure!
Thanks,
Eric
Edson Tirelli wrote:
Eric,
Please do! Thanks,
Edson
2007/7/26, Eric Miles <eric.miles(a)kronos.com
<mailto:eric.miles@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(a)kronos.com
<mailto:eric.miles@kronos.com>
> <mailto: eric.miles(a)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(a)kronos.com
<mailto:eric.miles@kronos.com>
>> <mailto: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(a)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(a)lists.jboss.org <mailto:rules-users@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
9:59 p.m.
New subject: Odd static inner class behavior
Hi Eric, after some tests I noticed that in java language you can't
import the same class name twice even if the class is defined in
different packages, ie try creating a java file and import both
java.awt.List and java.util.List, it won't work, you will get a
similar error from javac compiler
So, if it is really necessary you can try using two package builders
as I did in the following example
public void testImportColision () throws Exception {
final PackageBuilder builder = new PackageBuilder();
final PackageBuilder builder2 = new PackageBuilder();
builder.addPackageFromDrl( new InputStreamReader( getClass
().getResourceAsStream( "nested1.drl" ) ) );
builder2.addPackageFromDrl( new InputStreamReader( getClass
().getResourceAsStream( "nested2.drl" ) ) );
final Package pkg = builder.getPackage();
final Package pkg2 = builder2.getPackage();
final RuleBase ruleBase = getRuleBase();
ruleBase.addPackage( pkg );
ruleBase.addPackage( pkg2 );
final WorkingMemory workingMemory =
ruleBase.newStatefulSession();
workingMemory.insert( new FirstClass() );
workingMemory.insert( new SecondClass() );
workingMemory.insert( new FirstClass.AlternativeKey() );
workingMemory.insert( new SecondClass.AlternativeKey() );
workingMemory.fireAllRules();
}
Regards
Fernando
On Aug 1, 2007, at 1:15 PM, Eric Miles wrote:
Edson,
I was finally able to get around to making a test case to determine
if I did in fact see this behavior. I can reproduce it and have
opened up a Jira for it. I have also attached my test case for
easy reproduction. For your (and other's) knowledge, here is the link:
http://jira.jboss.com/jira/browse/JBRULES-1053
Truly odd behavior for sure!
Thanks,
Eric
Edson Tirelli wrote:
> Eric,
> Please do! Thanks,
> Edson
> 2007/7/26, Eric Miles <eric.miles(a)kronos.com
> <mailto:eric.miles@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(a)kronos.com
> <mailto:eric.miles@kronos.com>
> > <mailto: eric.miles(a)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(a)kronos.com
> <mailto:eric.miles@kronos.com>
> >> <mailto: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(a)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(a)lists.jboss.org <mailto:rules-
> users(a)lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/rules-users
> _______________________________________________
> rules-users mailing list
> rules-users(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
6311
days inactive
6337
days old
4 comments
3 participants
participants (3)
-
Edson Tirelli -
Eric Miles -
Fernando Meyer