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:13:20 GMT
2013/7/11 Konstantin Kolinko wrote:
>
> 2013/7/11 Violeta Georgieva <milesg78@gmail.com>:
> > 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?
> >
> > Also I'm going to report a bug for this against the spec.
> >
>
> The javadoc at
http://docs.oracle.com/javaee/7/api/javax/el/BeanELResolver.html
>  says:
>
> "If this resolver was constructed in read-only mode, this method will
> always throw PropertyNotWritableException."
>
> I think it is what should actually happen. It is also easier to check
> a boolean property either than use reflection to lookup whether a
> property exists. I see no specification bug here.

There is no bug in the specification, but in the javadoc.
I meant to open a bug to ask for a consistent javadoc.

> > 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."
> >
>
> The same as for ResourceBundleELResolver. (That resolver is inherently
> read-only but you recently changed it to return false in a similar
> method).
>
> The return value does not matter if the property has not been marked
> as resolved. The docs require the caller to ignore the return value in
> such a case.

I agree.

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