On 10/07/2013 13:00, Violeta Georgieva wrote: > 2013/7/10 Mark Thomas wrote: >> >> On 10/07/2013 12:11, violet...@apache.org wrote: >>> Author: violetagg >>> Date: Wed Jul 10 11:11:23 2013 >>> New Revision: 1501719 >>> >>> URL: http://svn.apache.org/r1501719 >>> Log: >>> javax.el.ResourceBundleELResolver: >>> According to javadoc: >>> 1. When creating FeatureDescriptors shortDescription must be empty > string >>> 2. isReadOnly returns true only if the base is instance of > ResourceBundle >>> Unit tests are added >> >> No objection to the commit but I am going to be picky. It doesn't matter >> in this case but there might be other cases where it does - hence why I >> want to highlight this issue. >> >> With reference to point 2 in the commit message, the specification >> language doesn't say that exactly. >> >> It states: >> <quote> >> If the base object is not null and an instanceof ResourceBundle, return >> true. >> ... >> Returns: if the propertyResolved property of ELContext was set to true, >> then true; otherwise undefined. >> </quote> >> >> If the first sentence in the quote above was "If and only if the >> base..." then point 2 in the commit message would be valid. > > The ResourceBunldeELResolver does not specify when propertyResolved is set > to true in isReadOnly, but its parent (ELResolver) has > " > If this resolver handles the given (base, property) pair, the > propertyResolved property of the ELContext object must be set to true by > the resolver, before returning. > " > > > Then we have in ResourceBunldeELResolver > " > This resolver handles base objects of type java.util.ResourceBundle > ... > Returns: if the propertyResolved property of ELContext was set to true, > then true ... > " > > Doesn't that mean "if and only if"?
No. Firstly because "if" is not exclusive. Secondly because the remainder of the returns definition states that the return value is undefined if propertyResolved is false. Another way of looking at it is that there is no language that requires a return value of false for any given input. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org