Op 18-01-12 11:00, Wolfgang Laun schreef: > On 18/01/2012, Geoffrey De Smet<[email protected]> wrote: > >> throw new IllegalStateException("The factClass (" + factClass + ") >> has a property (" + property + ") that has a @Modifies annotation, but >> the class isn't annotated with @PropSpecific."); > Use less words: > "In class (" + factClass + ") property (" + property + ") is annotated > with @Modifies, but the class isn't annotated with @PropSpecific." +1 > However, there's a good case for permitting this: testing to try both > ways, to track down a (user) bug,... Commenting out @PropSpecific is > just like turning off the main switch. If you get errors, you'll have > to mess with all the @Modifies, too. -1 The other case, where a user adds @Modifies but forgets to add @PropSpecific and then sees in production that drools doesn't behave as expected (it just ignores the @Modifies) is worse imo. > >> 2) @Modifies( "firstName, lastName" ) should not put the comma (,) >> inside the quotes. Go for: >> @Modifies( "firstName", "lastName" ) > Then it must be: > @Modifies( { "firstName", "lastName" } ) Yep, true. Not sure if that still allows to use @Modifies("firstname").
Anyway, I still think we need to use a new annotation to combine multiple @Modifies annotations, to avoid the other problems (2 modifies that have different other values, such a ifImplementsClass) and specific annotations implementation limitations (you can't define the same annotation twice on 1 method). It's Mario's call. > >> 3) What's the point of doing a @PropSpecific on a field instead of a class? >>> declare Person >>> @propSpecific >>> firstName : String > The answer is: DRL syntax requires it this way. ah yes, my bad. Confusing though :) > Cheers > Wolfgang > _______________________________________________ > rules-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-dev > -- With kind regards, Geoffrey De Smet _______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
