On 1.11.2010 9:07, Wolfgang Laun wrote: > On 1 November 2010 07:45, Samuli Saarinen<[email protected]> wrote: >> On 29.10.2010 19:18, Wolfgang Laun wrote: >>> If it were possible to enhance the very same class with different >>> metadata such >>> as @expires, I'd open a JIRA and call it a bug. >> >> Should declaring the same event multiple times throw an exception then >> if it's not allowed? >> >> I don't know if it makes sense to override other metadata but I think >> with expires it could be possible to use the greater value of two >> different declarations as the engine already uses multiple sources for >> calculating the actual expires (explicit vs. implicit). >> > > I'm very much against any ad-hoc rules that would silently cover a > situation that might be an error due to oversight. Expiry is currently > a static property of an Event type and I see absolutely no benefit in > having multiple definitions. And why maximum? Why not minimum? Or > average ;-) > -W
From drools fusion UG [1] "The engine will make this analysis for the whole rulebase and find the offset for every event type. Whenever an implicit expiration offset clashes with the explicit expiration offset, then engine will use the greater of the two." Can you tell me why maximum is chosen here and not an average? But I get your point it would not be beneficial to have the kind of functionality I was hoping for. But I still suggest that the engine would report the error if event declaration is done more than once as it is currently possible although the first only counts afaik. As you can prolly see from the amount of questions I have recently posted I'm just trying to figure out the way drools works and to add my few cents to hopefully make it a better project :). Cheers, Samuli [1] http://downloads.jboss.com/drools/docs/5.1.1.34858.FINAL/drools-fusion/html_single/index.html#d0e1300 -- Remion Oy Etävalvontajärjestelmät liiketoiminnan Samuli Saarinen tehostamiseen gsm +358 (0)50 3560075 fax +358 (0)3 2125064 www.remion.com _______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
