Oh, before I forget,I'd also like to give a special thanks to Michael Youngstrom, our newest Seam committer, for his work on the Spring integration module.
Many thanks to Michael!
P.S. I should mention a couple of the seam-gen enhancements:
* support for composite keys
* Ajax4JSF integration
* many-to-one association editing
and also that Seam/Security now supports:
* auto-redirect to HTTPS via the scheme=https in pages.xml
* auto-redirect to the login page via login-required=true
So there is actually a lot of new stuff in this release.
Oh and thanks Norman for doing the release. (We have decided to always do RCs from now on, in order to avoid the kind of probs we had with 1.1.5.)
Any chance the release candidates and the actual releases could be posted to the seam maven repository?
Currently, http://repository.jboss.com/maven2/jboss/jboss-seam/ just has 1.0.1 and 1.1.0
It would make testing just a little easier.
Shane said that the SeamMultipartFilter has been replaced with a universal Seam filter, but in the s:fileUpload section in 1.1.7 RC1 docs, the SeamMultipartFilter is still there:
For multipart requests, the Seam Multipart servlet filter must also be configured in web.xml: <filter> <filter-name>Seam Multipart Filter</filter-name> <filter-class>org.jboss.seam.servlet.SeamMultipartFilter</filter-class> </filter> <filter-mapping> <filter-name>Seam Multipart Filter</filter-name> <url-pattern>*.seam</url-pattern> </filter-mapping>Should it be replaced by
<filter> <filter-name>Seam Filter</filter-name> <filter-class>org.jboss.seam.web.SeamFilter</filter-class> </filter> <filter-mapping> <filter-name>Seam Filter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
In addition, it seems that s:fileUpload attributes missed the fileSize attribute in 1.1.7 docs of s:fileUpload section.
I am not sure if this is something worth mentioning.
But the latest API changes to the FacesMessages might cause unexpected form validation behavior for people who are migrating from 1.1.6.
With 1.1.6, I used the method
FacesMessages.add(String id, String messageTemplate, Object... params)
to associate a validation error message with a UI component.
Now with 1.1.7 the same method will map to
FacesMessages.add(String messageTemplate, Object... params)
which will add the component id string as a global message and therefore prevents the validation system from detecting that the UI component has a validation error.
The solution, of course, is to use
addToControl(String id, String messageTemplate, Object... params)
Yes, I should have mentioned it. I hated breaking that API, but it was already broken (I screwed up totally). We needed to get rid of the ambiguity there, and deprecation was not going to help.