yeah that is the downside of a dynamic proxy: the no arg constructor is
needed. Otherwise we would have to do class load time weaving (nasty).
On 12/7/06, Dirk Bergstrom <[EMAIL PROTECTED]> wrote:
Edson Tirelli was heard to exclaim, On 12/07/06 04:18:
> Would you please submit your error as a JIRA bug?
My error was a long-winded complaint about the lack of a no-arg
constructor for
the object type. The "beans" I'm using don't really conform to the
javabean
standard. I can file a bug asking for a friendly error message, but
otherwise
the error was my fault.
What I really want is the ability to turn off ShadowFacts on a per-class
basis.
For one of my classes they're doing nothing but consuming memory and CPU,
with
no benefit to me. Is there a JIRA for that, if not, I'll be happy to file
one.
> Dirk Bergstrom wrote:
>
>>I just finished a big refactoring/rewriting, fired up my application
with the
>>latest code from Trunk, and got a nasty error about shadow facts...
>>
>>Edson Tirelli was heard to exclaim, On 12/03/06 15:05:
>>
>>
>>> But, if you have a pattern in your application that, lets say,
always
>>>retract objects from the working memory, changes its attributes and
>>>assert the object again, :) then you don't need ShadowFacts... but I
>>>think this use case is not a real use case... is it? :)
>>>
>>>
>>
>>Yes, it is.
>>
>>I am doing almost exactly that. In my case, I have a hundred or so
objects of a
>>specific type that I cycle through the WM with
assert/fireAllRules/retract (and
>>another few hundred objects of two different types that stay in the WM
all the
>>time). I do this assert/retract dance because there is no value in
having them
>>in the memory once I've checked their compliance with the rules -- I
need to
>>update them with current data before running the rules again.
>>
>>So creating a ShadowFact for each one after I retract it does nothing
for me.
>>Well, except for crashing my system.
>>
>>
>>
>>>>>>Edson Tirelli wrote:
>>>>>>
>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>
>>This would be very useful for me. I have three types, two of which stay
in the
>>WM, and get changed (I have PropertyChangeListeners on them), and one
which is
>>asserted and retracted. I'd like to turn off shadow facts for the third
type.
>>
>>
>>
>
>
--
Dirk Bergstrom [EMAIL PROTECTED]
_____________________________________________
Juniper Networks Inc., Computer Geek
Tel: 408.745.3182 Fax: 408.745.8905
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
