Be notified of new releases
Create your free GitHub account today to subscribe to this repository for new releases and build software alongside 28 million developers.Sign up
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.
(#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
Boot to enable the feature. For example, to enable the logging snippet timer globally, just add the following line:
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:
The logging snippet timer will be enabled for the duration of the request. You can also do the same for a session.
(#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
@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:
... 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.
- (#1868) @Bhashit contributed some very nice documentation about Dependency Injection in Lift.
- During this release cycle, we also formalized our support policy.
- (#1911) Consider
LiftRules.cometCreationwhen building comets. This
LiftRulebecame 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
- (#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
templateCachewas set to
Emptywe would auto-magically create an
InMemoryCacheand 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
buildRoundtrip. Previously, users of
buildRoundtriphad 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
onShutdownargument to the
buildRoundtripfunction 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
- (#1889) Implementation of LiftRulesGuardedSetting. This type will eventually replace everything in
LiftRulesdeclared as a
var. The idea here is that we want to avoid folks from changing things in
LiftRulesat 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
LiftRulesGuardedSettingis the way we're planning to standardize that behavior and make it more consistent.
- (#1888, #1881) Various lift-json performance improvements.
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.