Lift Framework 3.2.0-M2

The Lift Committers are pleased to announce the release of Lift 3.2.0-M2 on September 15th, 2017. This release is the second of three milestone releases for Lift 3.2.0. The next milestone release is tentatively scheduled for November 15th, 2017 with plans to finalize Lift 3.2 around the end of the year. As always, you can follow along with our progress in the GitHub Milestone View.

Please read below for the changes in this milestone.

Changes

New Features

(#1906) Snippet Timers

Page loading slowly and you're not sure what code to blame? Want to just report all snippet timings to a metrics system for monitoring? Snippet Timers are for you! Snippet Timers enable global, per-request, or per-session timing of Snippet execution throughout your Lift application. By default, we package a LoggingSnippetTimer that spits out these timings to the log system, but anything implementing the SnippetTimer interface can be provided.

To get started you'll need to invoke LiftRules.installSnippetTimer in Boot to enable the feature. For example, to enable the logging snippet timer globally, just add the following line:

LiftRules.installSnippetTimer(LoggingSnippetTimer)

If you're only interested in logging in certain sessions or requests, you'll still need to invoke installSnippetTimer at boot with the NoOpSnippetTimer to enable the feature. Then, to enable logging snippet timing at some point in a request invoke:

LiftRules.snippetTimer.get.map(_.request(LoggingSnippetTimer))

The logging snippet timer will be enabled for the duration of the request. You can also do the same for a session.

LiftRules.snippetTimer.get.map(_.session(LoggingSnippetTimer))

(#1893) ContainerVar serialization for anything Serializable

Lift has provided ContainerVar for awhile for storing values in the underlying container session. (This is as opposed to the SessionVar that stores things in Lift's session.) However, to use a ContainerVar you need to provide some sort of ContainerSerializer for the type that you're trying to serialize. Even though Lift has provided a handful of implementations for awhile, none of them would handle something as simple as Box[String].

@joescii was kind enough to add a ContainerSerializer that works for anything extending Serializable. This should give Lift developers using ContainerVar a much more "batteries included" experience.

(#1866) New Optional Mongo Fields

@Bhashit made a number of additions to the optional mongo fields as a part of mongodb-record. Some fun additions that your code might benefit from include:

• OptionalCaseClassField
• OptionalJObjectField
• OptionalUUIDRefField
• OptionalObjectIdField

... and more! We've also deprecated some legacy field names and parameter names (e.g. rec is now owner) so you'll probably see some deprecation warnings crop up if you're using any of those.

Documentation

• (#1868) @Bhashit contributed some very nice documentation about Dependency Injection in Lift.
• During this release cycle, we also formalized our support policy.

Bug Fixes

• (#1911) Consider LiftRules.cometCreation when building comets. This LiftRule became ignored by accident during the great comet upgrade of the 3.0 release. We've added the line back that was missing, and plan to back-port this fix to the 3.0 and the 3.1 series.
• (#1903) Provide context path to session reload handler. There was a subtle change in behavior in Lift 3.0 that caused bad things to happen when a Lift application was deployed under a context path in an application server (so, somewhere other than /) and that Lift application detected that the comet session had disappeared. In previous versions of Lift this would just reload the page. In Lift 3.0, we changed that behavior to take you to the root of your application. However, / is not always the root of the application. Now, we'll properly consider the context path when detecting what URL to send you to. This is, as always, customizable with LiftRules.noCometSessionCmd.

Improvements

• (#1918) Logging improvements for various exceptions. @andreak had located a few spots that weren't properly printing the exception stack trace when exceptions were hit, and delivered a Quick Fix™ to that.
• (#1910) Clarification of LAPinger documentation.
• (#1909) Move template cache defaulting to LiftRules. This change addresses some confusing behavior in how Lift creates the default template cache. Previously, if you were running in production mode and the templateCache was set to Empty we would auto-magically create an InMemoryCache and use that instead. Due to the way this was written, this effectively meant that turning off template caching in production was impossible. With this change we moved where the default gets calculated so it's actually possible to turn off the template cache in production mode if you would like to do that.
• (#1907) Addition of onShutdown to buildRoundtrip. Previously, users of buildRoundtrip had no way to get notified that the underlying comet actor had been shut down. This meant that they had no way to really know if they could free resources that might be associated with that connection in their application level code. To address this, we've added an onShutdown argument to the buildRoundtrip function so developers can pass a handler when the underlying comet is actually shut down.
• (#1895) Make the servlet session ID configurable. Previously, Lift's servlet session identifier was hard-coded. This worked fine for a long time. However, recently we discovered that it doesn't play nice when used in conjunction with Jetty's Mongo persisted sessions plugin because of the $s in it. To resolve that, we've made it configurable through LiftRules.servletSessionIdentifier.
• (#1889) Implementation of LiftRulesGuardedSetting. This type will eventually replace everything in LiftRules declared as a var. The idea here is that we want to avoid folks from changing things in LiftRules at runtime. We do that in a bit of an ad-hoc way now, in the sense that some settings will blow up in your face if you attempt to do so, but moving forward the LiftRulesGuardedSetting is the way we're planning to standardize that behavior and make it more consistent.
• (#1888, #1881) Various lift-json performance improvements.

About Lift

The Lift Framework is a mature, advanced framework for the modern software engineer. There are Seven Things that set Lift apart from the other frameworks out there today: it's secure-by-default, developer-centric, scalable, capable of rich interactive behavior, modular, and designer-friendly. If you're new to Lift or interested in checking out what these things mean, we recommend checking out Simply Lift and The Lift Cookbook.

The Lift Mailing List is also a good resource for anyone to ask questions or just meet other Lift users. The Lift README is a good resource for figuring out how to use Lift in your project.