Issue 1:
Adam Murray opened SPR-2128 and commented

The form implementation class org.springframework.web.servlet.tags.form.FormTag doesn't implement support for all the attributes it claims to support in the spring-form.tld. Specially, the attributes supported by code in the AbstractHtmlElementTag class are missing. This isn't a major problem on Tomcat, where things work fine until you try to use one of the unsupported attributes, like cssClass, and then the JSP fails to compile with the following error:

Unable to find setter method for attribute: cssClass

But the situation is worse on WebLogic 8.1, which appears to validate the TLD just by including the taglib on a page. I have a common taglibs.jsp page that includes all the taglibs needed by my app, even if they aren't used on a particular page. So I can't view any page in my application when using the spring form taglib and this "global include" type of approach, because all pages will display the following error:

Error in using tag library uri='http://www.springframework.org/tags/form' prefix='form': The Tag class 'org.springframework.web.servlet.tags.form.FormTag ' has no setter method corresponding to TLD declared attribute 'cssClass', (JSP 1.1 spec, 5.4.1)

I think ideally the FormTag class would extend from AbstractHtmlElementTag like most of the other tags, but this class in turn extends from AbstractDataBoundFormElementTag, which contains behavior that doesn't apply to the form tag. So I guess you might need to rework the inheritence hierarchy slightly?

I don't need these attributes so as a temporary workaround I removed them from my spring-forms.tld.

Affects: 2.0 M5

Issue Links:

#6829 form:form tag does not support all documented attributes ("duplicates")

Issue 2:
Dr. Christoph G. Jung opened SPR-2727 and commented

I just stumbled over an issue when dealing with a reasonable Java5 feature, that is covariant method overrides.

Suppose you define a general access interface

public interface Foo {

public Number getVersion();

}

and implement it in a bean like this (to my knowledge a really nice by-product of the lang spec extension that came with the introduction of Generics)

public class Bar implements Foo {

private double version;

public Double getVersion() {

return this.version;

}

public void setVersion(Double theDouble) {

this.version=theDouble;

}

}

the JavaBeans Introspector will upon reflecting Bar.class return a PropertyDescriptor for property "version" that has type "java.lang.Number", a read method java.lang.Number Bar.getVersion() and no write method! This leads to surprising NotWritablePropertyExceptions when trying to configure the Bar bean with Spring.

The attached patch would lead to a CachedIntrospectionResults version that still is conformant to JavaBeans, but can deal with those covariant properties with a (AFAICS)

minimal processing overhead (one additional "canonical" getter lookup per asymetric propertydescriptor, another one for identifying the corresponding setter).

This would be really convenient and helpful (and I suppose there will be more such cases when dealing with generics in properties which can't be easily worked around by adding another getter/setter).

Affects: 2.0 final

Attachments:

patch.txt (2.51 kB)

Issue Links:

#7570 Data Binding to Class Extending Abstract Class Uses Volatile Abstract Methods Instead of Overridden Final Method ("is depended on by")

#9928 The parameter type of the setter should not need to match the return type of the getter ("is duplicated by")

1 votes, 3 watchers