tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Violeta Georgieva <miles...@gmail.com>
Subject Re: Couple of question about javax.el.BeanELResolver
Date Thu, 11 Jul 2013 14:23:11 GMT
2013/7/11 Mark Thomas wrote:
>
> On 11/07/2013 13:49, Violeta Georgieva wrote:
> > Hi,
> >
> > I have the following question about:
> >
> > 1. Method setValue
> > There is some mismatch in the javadoc. In the method description there
is
> > the following statement:
> >
> > "If the property exists but does not have a setter, then a
> > PropertyNotFoundException is thrown."
> >
> > But the throws clause states:
> >
> > "PropertyNotWritableException - if this resolver was constructed in
> > read-only mode, or if there is no setter for the property."
> >
> > Our implementation currently throws PropertyNotFoundException.
> > I'm going to change it to throw PropertyNotWritableException.
> > What do you think?
>
> On balance, PropertyNotWritableException seems the better option in this
> case.
>
> > Also I'm going to report a bug for this against the spec.
>
> +1.

thanks

>
> > 2. Method isReadOnly
> > There is not explicit statement what should be returned in case
> > base/property are null.
> > However there is statement that:
> >
> > "If this resolver was constructed in read-only mode, this method will
> > always return true."
> >
> > What do you think about this change:
> >
> > @@ -195,7 +195,7 @@
> >              throw new NullPointerException();
> >          }
> >          if (base == null || property == null) {
> > -            return false;
> > +            return readOnly;
> >          }
>
> If base != null and property == null my reading of the javadoc is a
> PropertyNotFoundException should be thrown.

you are right on a second reading this should throw exception

>
> Generally, I think there needs to be a tightening up of language
> throughout the EL Javadoc. I'm not sure how best to raise this with the
> EG. A bug per ambiguity could be a lot of bugs but I suspect a single
> bug won't result in the issue being fully addressed. Maybe one bug per
> class is the way to go and list all the ambiguities in the Javadoc for
> that class.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message