A bug fix and minor enhancement release for 4.0.0.

Highlights:

  • session handling is pluggable
  • missing view handling has been enhanced
  • a new onReload() extension point is available
  • testing (and the Continuous Integration process) has been simplified and now uses CommandBox and TestBox
  • bug fixes in error handling, transient bean population under heavy load, and some other areas

Summary

The 4.1 release is intended to be a minor maintenance release over 4.0.

Breaking Changes

  • 466 – Clojure integration is no longer provided out of the box, so that Lucee 5.x can be officially supported.

Enhancements

  • 472 – Since Adobe ColdFusion 9 is no longer supported, dynamic method invocations are done via invoke() rather than evaluate() (and so they might be slightly faster).
  • 467 – Session scope handling is now pluggable (but still uses session scope by default).
  • 465 – The tests have been switched from MXUnit to TestBox and the CI system has been switched from Ant (and explicitly download CFML engines) to CommandBox. The test matrix now includes: Adobe ColdFusion 10, 11, 2016; Lucee 4.5, 5 (current 5.1).
  • 460 – New framework option missingview can specify an action to take on a FW1.viewNotFound exception, rather than the default error action.
  • 452baseURL with trailing / no longer causes // to appear in URLs (when calling buildURL()).
  • 424 – To partially support the desire to unload bean factory data when FW/1 is reloaded, there is a new extension point onReload().

Bug Fixes

  • 463 – A potential XSS vulnerability in the default exception reporting function has been addressed.
  • 462 – Addresses a race condition around resolving transients under heavy load. Thanks to John Whish and jcberquist for chasing this down!
  • 458 – If an exception occurs during bean discovery, and an application’s error handling causes any DI/1 method to be invoked, it’s likely that discoverBeans() will be run a second time. Previously, that caused beans to be loaded twice and, if you had omitDirectoryAliases : true, you would get a new exception (that bean names were not unique) which masked the original exception. Now, if an exception occurs during initialization, bean discovery is considered complete, which should allow the original exception to propagate (even if your exception handling then crashes and burns!).
  • 456onError() now resets setLayout() so that if an error occurs in a subsystem, the error handling is rendered correctly, using only layouts from the error action.
  • 383redirect() now accepts a struct for the queryString argument: this was introduced in version 3.5 but never actually worked until now!

By Sean Corfield.

Leave a Reply