With kind regards,
Geoffrey De Smet
Edson Tirelli wrote:
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.
thanks Edson, though there is no real rush, but it's probably something
critical for the m1 release for most use cases ;)
Anyway, here's my class:
public class Match extends AbstractPersistable
implements Comparable<Match>, Solution {
// ...
// Implemented from Comparable<Match>
public int compareTo(Match lesson) {
// Overwritten from Object, implemented from Solution
public Match clone() {
// Overwritten from AbstractPersistable
public String toString() {
}
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.
- I don't modify constraints field in the RHS of rules, but I do modifty
them outside the rule engine (in the same thread), just before calling
modified + fireAllRules
- I do assert some logical objects in the RHS of rules.
Do either or both of these violate a "classification (discrimination)
network"?
[]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
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
