Folks When I have my Java beans set in the Eclipse project and I am writing conditions for these I don't see the help window that document suggest that pops up in terms of showing all getter APIs or RULE conditions like AND, bracket etc. If I mistype properties of beans I get red error blocks but don't get the popup completion help like other Eclipse Java projects have. Is there some other plug-in required or some setup in eclipse required achieving this? Any help is appreciated
Thanks -Uday ________________________________ From: Michael Neale [mailto:[EMAIL PROTECTED] Sent: Friday, December 08, 2006 8:57 AM To: [email protected] Subject: Re: [drools-user] What is a ShadowFact? - crash course 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
