Geoffrey,
My guess is that ShadowProxyFactory is failing to match a method that
is declared in a superclass or interface with the overriden method in a
subclass. Because of this, it is trying to proxy 2 times the same
method. I will take a look in it asap.
Regarding your question, what I mean is to use JBRules as a
"classification (discrimination) network". It means your rules will
simply match objects with the single intent of identifying or grouping
the objects and will not change bound/constrained fields in the objects.
This is a valid use case, but not that common I guess. And when you
don't change bound/constrained field values during the fact lifecycle,
you don't need shadow facts.
[]s
Edson
Geoffrey De Smet wrote:
http://jira.jboss.com/jira/browse/JBRULES-575
I can't seem to manage to isolate the problem :/
It's not just because I have 2 different references to Team in Match
- because I wrote an integration test with Cheese and CheeseCouple
that worked.
See the issue for more info.
I am using drools3 in a single-threaded context - would that suffice
to have no need of shadow facts? What does "using it as an
discrimination network only" mean in practice?
With kind regards,
Geoffrey De Smet
Edson Tirelli wrote:
Geoffrey,
Plz, if you can open a JIRA with a sample it would be great.
Probably some kind of unexpected method name conflict.
Regarding the feature, right now it is mandatory, but I was talking
to Mark to make it optional. Unfortunally Shadow Facts are one of
those necessary evils. If you ever change a fact attribute in your
network, that fact needs a shadow fact. So, unless you use the engine
simply as a discrimination network, you will need them, but the idea
is to make them optional and better yet on an object type basis, in a
way that users can turn it ON only for those types where it is really
needed.
[]s
Edson
Michael Neale wrote:
Geoffrey, yes that does sound like a bug. The automatic
proxy/scheduling is quite new, and will take some time to stabilise
- could you create a test case and JIRA, and email me please (with
the JIRA, so I make sure it is not lost) ? I will then (with edson)
take a look into it, as there will have to be changes to the ASM
code that generates the proxy no doubt. I am not sure if
proxy/shadowing will be optional or not - haven't been tracking
progress with that (in any case it should be transparent to you) -
Mark or Edson can fill in on the details for that for 3.2.
Michael.
On 11/30/06, *Geoffrey De Smet* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
If it isn't a known bug, I 'll happily make another testcase patch.
I am pretty sure it's because I have 2 different references to
Team in
Match, namely homeTeam and awayTeam.
With kind regards,
Geoffrey De Smet
Geoffrey De Smet wrote:
> I just tried the trunk (to compare a benchmark between it and the
> branch), but I got an error, anything I can do about it?
> Are shadow facts optional? (or are they better always anyway?)
>
> java.lang.ClassFormatError: Repetitive field name/signature in
class
> file
net/sf/taseree/samples/travelingtournament/domain/MatchShadowProxy
>
>
> Here's my Match class:
>
> public class Match extends AbstractPersistable implements
> Comparable<Match>, Solution {
>
> private Team homeTeam;
> private Team awayTeam;
>
> private Day day;
>
> // getters, setters, clone(), toString()
>
> }
>
> AbstractPersistable has a Long id with getters/setters
>
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3124-6000
Mobile: +55 11 9218-4151
JBoss, a division of Red Hat @ www.jboss.com
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
