All Versions
12
Latest Version
Avg Release Cycle
101 days
Latest Release
1238 days ago

Changelog History
Page 1

  • v3.4.3-release Changes

    November 28, 2020

    🚀 The Lift Committers are pleased to announce the release of Lift 3.4.2 on November 28, 2020. This is a minor release.

    🔄 Changes

    👌 Improvements

    • Delegate equals comparison in Record to Field (#1976)
    • ⬆️ Bump scala-xml to 1.3.0 (#1981)
    • 👍 Lift-mapper with Scala 2.13 support (#1982)
    • 🗄 Lift-mongodb support for Scala 2.13 and various mongodb deprecation fixes (#1984, #1987)

    About Lift

    0️⃣ 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. 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.

  • v3.4.2-release Changes

    August 30, 2020

    🚀 The Lift Committers are pleased to announce the release of Lift 3.4.2 on August 30th, 2020. This is a minor release.

    🔄 Changes

    🐛 Bug Fixes

    • Recompiled with Scala 2.12.12 and Scala 2.13.2 to resolve bug for users of Metals.

    About Lift

    0️⃣ 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. 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.

  • v3.4.1 Changes

    January 18, 2020

    🛠 The Lift Committers are pleased to announce the release of Lift 3.4.1 on January 18th, 2020. This is a minor bugfix release.

    🔄 Changes

    🐛 Bug Fixes

    • (#1978) Disable auto-rewrite of requests for lift.js, json.js, and json2.js. In Lift 3.4.0 we upgraded sbt, which caused some incompatibilities with a plugin we developed to minify our Javascript during release. Until we get the chance to further revisit how to minify Javascript as a part of our release build, we are disabling the automatic filename rewrite that happens in production so that these scripts start working again without the workaround described in the Lift 3.4.0 release notes.

    About Lift

    0️⃣ 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. 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.

  • v3.4.0-release Changes

    October 23, 2019

    The Lift Committers are pleased to announce the release of Lift 3.4.0 on October 22nd, 2019. Given the importance of this release and it's Scala 2.13 support, we've decided to short-circuit our normal Milestone and RC process in favor of getting out a final build with full support from the committers.

    About Lift

    0️⃣ 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.

    Known Issues

    🛠 This version of Lift shipped with a bug in the build process that resulted in minified javascript files not being included in the Lift Webkit JAR. A bugfix release is forthcoming, but in the interim you can use this release by adding the following to your Boot class:

    ResourceServer.pathRewriter = { case anything =\> anything }

    🔄 Changes

    🚀 Below is a list of changes since Lift 3.3 organized by the type of change and sorted by the PR number. The big headline here is that we now support building some, but not all, modules for 2.13. We expect to release patch versions shortly to add the additional modules. The various record, mapper, and webkit modules are the significant omissions from the 2.13 release.

    🆕 New Features

    🚀 No significant new features are added in this release.

    👌 Improvements

    • 🏗 (#1953) Add JDK11 and JDK12 support to CI build
    • ⚡️ (#1954) SBT updates
    • ⬆️ (#1958) Upgrade nu validator
    • ✅ (#1960) Add tests for the Crudify trait
    • 👍 (#1973) Scala 2.13 support for some modules

    🚀 This release also includes various Scala and minor SBT version bumps.

    🐛 Bug Fixes

    • (#1952) Fix behavior in tryo that could cause exceptions to be thrown when not expected
    • (#1959) Fix Crudify.doCrudAll
    • (#1963) Fix confusing DontMergeAttributes modification
    • 🏗 (#1968) Fix snapshot builds

    Final Notes

    As always, please reach out to us with any questions or concerns on the mailing list. We hope you enjoy Lift 3.4.0!

  • v3.3.0-release Changes

    July 11, 2018

    The Lift Committers are pleased to announce the release of Lift 3.3.0 on July 11th, 2018. This release continues our release cadence. This release has no code changes from the 3.3.0-RC1 release.

    🚀 This year has been a busy one in the personal lives of the Lift Committers so far, and sometimes it's hard to find the time to contribute to open source or... you know... do the final release on time. (cough sorry folks cough.) We hope you'll enjoy this release all the same, though!

    About Lift

    0️⃣ 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.

    🔄 Changes

    🚀 This release of Lift is composed of the following component releases:

    Below is a list of changes since Lift 3.2 organized by the type of change and sorted by the PR number.

    💥 BREAKING CHANGES

    It is rare for Lift to decide to ship what amounts to a breaking change in a minor point release. However, during this release cycle we discovered a bug in the implementation of LAFuture that resulted in the aborted_? check method not working as users expect. Unbeknownst to us, the aborted_? check method was looking at the satisfied internal state setting instead of the aborted internal state setting. This meant that satisfied_? and aborted_? always returned the same result even though they were not the same internal state.

    With a lot of consideration, we decided to correct the behavior in Lift 3.3.0 in Pull Request #1940, because it never worked as advertised and the expected impact to user code is that it starts working as the user intended. We are not going to backport this change to avoid user code behavior changing on a patch release.

    🆕 New Features

    🔧 (#1933) Configurable asset path for Lift-specific assets

    0️⃣ By default, Lift will attempt to load an AJAX Spinner gif when doing certain server-to-client operations. Some folks turn this off, but it remains one of the niceties that folks can lean on when waiting on the server and the client to finish talking to each other. Historically, Lift has insisted that for this feature to work the ajax gif must be located at /images/ajax-loader.gif, however not everyone wants to lay out their application in that fashion.

    🔧 There is a new lift rule located at LiftRules.assetRootPath that makes the location of your assets configurable. Its default value is /, which preserves the existing behavior. You can, however, make it whatever you like.

    🍱 You could put your AJAX loader at /assets/images/ajax-loader.gif. You could put it between two slices of bread. You could put it on Amazon S3, instead. You'll be amazed at the places you can put this gif, if you only use your head.

    Many thanks to @heharkon!

    (#1939) Customizable Service Timers

    0️⃣ Many folks using Lift are familiar with the classic timer log messages that appear by default to tell you how long each request in Lift is taking. By default they tend to look like this:

    INFO net.liftweb.util.TimeHelpers - Service request (GET) / returned 200, took 455 Milliseconds

    Lift now provides the ability to implement custom timing methods through the implementation of the ServiceRequestTimer trait. Using a ServiceRequestTimer you can:

    • Control how messages are timed.
    • Control where that timing information gets reported.

    ✅ You could, for example, report all request timings to a metrics aggregator and graph the various percentiles of response times as a part of your monitoring. You could only time a subset of requests (those testing newer functionality, for example).

    🚚 These changes provide a new LiftRules.installServiceRequestTimer function to install the timer of your choice. net.liftweb.http.StandardServiceTimer implements the current behavior. Further, the LiftRules.logServiceRequestTiming is now deprecated and will be removed in Lift 4 in favor of installServiceRequestTimer.

    Many thanks to @andreak!

    👌 Improvements

    • 📄 (#1846) @Shadowfiend's much anticipated in-repo getting started tutorial is now in master! Check it out
    • (#1931) Some readme improvements courtesy of @kohrVid
    • 🐎 (#1935, #1936) Various performance improvements to lift-json courtesy of @chriswebster
    • 🏗 (#1938) Fixed issues with building the project in IntelliJ courtesy of @andreak
    • (#1940) Correction to LAFuture.isAborted_? and a variable allocation cleanup. Thank you to @zhongsigang
    • 🚚 (#1942, #1945) Deprecated our internal BCrypt implementation in lift-util in favor of using the publicly-available jBCrypt library. net.liftweb.util.BCrypt was just a copy/paste of version 0.3 of jBCrypt. It is now officially deprecated and is now simply a proxy class to org.mindrot.jbcrypt.BCrypt. net.liftweb.util.BCrypt will be removed in Lift 4.0. (h/t @eltimn)
    • ⬆️ (#1943) Upgraded the Mongo driver to 3.6.3 (h/t @eltimn)
    • (#1944) Some code gardening courtesy of @eltimn!
    • 🏗 (#1950) Dependency and build version bumps. Including:
      • Scala 2.12.4 -> 2.12.6
      • commons-codec 1.10 -> 1.11
      • commons-fileupload 1.3.1 -> 1.3.3
      • joda-time 2.9.2 -> 2.10
      • joda-convert 1.8.1 -> 2.1
      • mongodb-driver 3.6.3 -> 3.7.1
      • mongodb-driver-async 3.6.3 -> 3.7.1
      • scalaz_core 7.2.7 -> 7.2.24
      • scala-xml 1.0.5 -> 1.0.6
      • rhino 1.7.7.1 -> 1.7.10

    🐛 Bug Fixes

    • 🛠 (#1949) Fixed a bug where in certain cases attempting to evaluate a Loc could result in surprise NPEs. In particular this could happen if you tried to evaluate the currentValue of a Loc that was not the Loc for the current URL your end-user was on.

    Final Notes

    🚀 This release represents six months of hard work on behalf of the contributors. Most of the contributions made to Lift are made on the contributor's own time without any kind of payment. If you use Lift, please take the time to thank a contributor the next time you see them. They'll appreciate knowing their work is valued.

    🚀 Now, we look forward to Lift 3.4.0 around the beginning of next year. Lift 3.4.0-M1 is currently scheduled to be released August 1, 2018. How the time flies. If you're interested in our progress, you can follow along from the Milestones page.

    As always, please reach out to us with any questions or concerns on the mailing list. We hope you enjoy Lift 3.3.0!

  • v3.3.0-RC1 Changes

    June 17, 2018

    The Lift Committers are pleased to announce the release of Lift 3.3.0-RC1 on June 17th, 2017. This release is the first (and hopefully last) release candidate for Lift 3.3.0. We encourage all Lift Framework users to bump their applications to this version as quickly as possible. We'd like to collect feedback on how it works and spot any show-stopping bugs before we declare this release final.

    🚀 Per our release schedule, we'll have a two week testing period for this release. If we don't get bug reports in that time frame, we'll be releasing the final build of Lift 3.3.0 sometime after July 1st.

    Please read below for the changes in this milestone since Lift 3.3.0-M3.

    🔄 Changes

    👌 Improvements

    • 🏗 (#1950) Dependency and build version bumps. Including:
      • Scala 2.12.4 -> 2.12.6
      • commons-codec 1.10 -> 1.11
      • commons-fileupload 1.3.1 -> 1.3.3
      • joda-time 2.9.2 -> 2.10
      • joda-convert 1.8.1 -> 2.1
      • mongodb-driver 3.6.3 -> 3.7.1
      • mongodb-driver-async 3.6.3 -> 3.7.1
      • scalaz_core 7.2.7 -> 7.2.24
      • scala-xml 1.0.5 -> 1.0.6
      • rhino 1.7.7.1 -> 1.7.10

    About Lift

    0️⃣ 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.

  • v3.3.0-M3 Changes

    June 02, 2018

    The Lift Committers are pleased to announce the release of Lift 3.3.0-M3 on June 2nd, 2018. This release is the third of three milestone releases for Lift 3.3.0. The first release candidate is tentatively scheduled for June 15th, 2018. As always, you can follow along with our progress in the GitHub Milestone View.

    Please read below for the changes in this milestone.

    🔄 Changes

    🐛 Bug Fixes

    • 🛠 (#1949) Fixed a bug where in certain cases attempting to evaluate a Loc could result in surprise NPEs. In particular this could happen if you tried to evaluate the currentValue of a Loc that was not the Loc for the current URL your end-user was on.

    About Lift

    0️⃣ 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.

  • v3.3.0-M2 Changes

    April 14, 2018

    The Lift Committers are pleased to announce the release of Lift 3.3.0-M2 on April 14th, 2018. This release is the second of three milestone releases for Lift 3.3.0. The next milestone release is tentatively scheduled for June 1st, 2018. As always, you can follow along with our progress in the GitHub Milestone View.

    Please read below for the changes in this milestone.

    🔄 Changes

    💥 BREAKING CHANGES

    It is rare for Lift to decide to ship what amounts to a breaking change in a minor point release. However, during this release cycle we discovered a bug in the implementation of LAFuture that resulted in the aborted_? check method not working as users expect. Unbeknownst to us, the aborted_? check method was looking at the satisfied internal state setting instead of the aborted internal state setting. This meant that satisfied_? and aborted_? always returned the same result even though they were not the same internal state.

    With a lot of consideration, we decided to correct the behavior in Lift 3.3.0 in Pull Request #1940, because it never worked as advertised and the expected impact to user code is that it starts working as the user intended. We are not going to backport this change to avoid user code behavior changing on a patch release.

    🆕 New Features

    🔧 (#1933) Configurable asset path for Lift-specific assets

    0️⃣ By default, Lift will attempt to load an AJAX Spinner gif when doing certain server-to-client operations. Some folks turn this off, but it remains one of the niceties that folks can lean on when waiting on the server and the client to finish talking to each other. Historically, Lift has insisted that for this feature to work the ajax gif must be located at /images/ajax-loader.gif, however not everyone wants to lay out their application in that fashion.

    🔧 There is a new lift rule located at LiftRules.assetRootPath that makes the location of your assets configurable. Its default value is /, which preserves the existing behavior. You can, however, make it whatever you like.

    🍱 You could put your AJAX loader at /assets/images/ajax-loader.gif. You could put it between two slices of bread. You could put it on Amazon S3, instead. You'll be amazed at the places you can put this gif, if you only use your head.

    Many thanks to @heharkon!

    (#1939) Customizable Service Timers

    0️⃣ Many folks using Lift are familiar with the classic timer log messages that appear by default to tell you how long each request in Lift is taking. By default they tend to look like this:

    INFO net.liftweb.util.TimeHelpers - Service request (GET) / returned 200, took 455 Milliseconds

    Lift now provides the ability to implement custom timing methods through the implementation of the ServiceRequestTimer trait. Using a ServiceRequestTimer you can:

    • Control how messages are timed.
    • Control where that timing information gets reported.

    ✅ You could, for example, report all request timings to a metrics aggregator and graph the various percentiles of response times as a part of your monitoring. You could only time a subset of requests (those testing newer functionality, for example).

    🚚 These changes provide a new LiftRules.installServiceRequestTimer function to install the timer of your choice. net.liftweb.http.StandardServiceTimer implements the current behavior. Further, the LiftRules.logServiceRequestTiming is now deprecated and will be removed in Lift 4 in favor of installServiceRequestTimer.

    Many thanks to @andreak!

    👌 Improvements

    • 📄 (#1846) @Shadowfiend's much anticipated in-repo getting started tutorial is now in master! Check it out
    • (#1940) Correction to LAFuture.isAborted_? and a variable allocation cleanup. Thank you to @zhongsigang
    • 🚚 (#1942, #1945) Deprecated our internal BCrypt implementation in lift-util in favor of using the publicly-available jBCrypt library. net.liftweb.util.BCrypt was just a copy/paste of version 0.3 of jBCrypt. It is now officially deprecated and is now simply a proxy class to org.mindrot.jbcrypt.BCrypt. net.liftweb.util.BCrypt will be removed in Lift 4.0. (h/t @eltimn)
    • ⬆️ (#1943) Upgraded the Mongo driver to 3.6.3 (h/t @eltimn)
    • (#1944) Some code gardening courtesy of @eltimn!

    About Lift

    0️⃣ 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.

  • v3.3.0-M1 Changes

    February 08, 2018

    The Lift Committers are pleased to announce the release of Lift 3.3.0-M1 on February 7th, 2018. This release is the first of three milestone releases for Lift 3.3.0. The next milestone release is tentatively scheduled for April 1st, 2018. As always, you can follow along with our progress in the GitHub Milestone View.

    Please read below for the changes in this milestone.

    🔄 Changes

    👌 Improvements

    About Lift

    0️⃣ 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.

  • v3.2.0-release Changes

    January 27, 2018

    The Lift Committers are pleased to announce the release of Lift 3.2.0 on January 27th, 2018. This release continues our new release cadence. This release has no code changes from the 3.2.0-RC1 release.

    🚀 The Lift 3.2.0 release makes many notable improvements, but the biggest single theme throughout all the changes is that of improvement of Lift's failover and clustering story. This release, coupled with @joescii's lift-cluster module represents a giant leap forward in Lift's scalability story.

    About Lift

    0️⃣ 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.

    🔄 Changes

    🚀 This release of Lift is composed of the following component releases:

    Below is a list of changes since Lift 3.1 organized by the type of change and sorted by the PR number.

    🆕 New Features

    (#1770) Comet Rehydration

    0️⃣ Since Comets were first introduced in Lift, it's been the case that if the Lift app server got restarted in the middle of a user's session and comets were involved then the user would need to refresh their entire page to reconnect to the server and have their comets start working again. By default, Lift is kind enough to do this page refresh for the users. However, this is a less than ideal experience for obvious reasons.

    Now, after over a year's worth of work, @joescii has delivered Comet Rehydration to the Lift Framework.

    🚀 Comet Rehydration is an optional feature that, when enabled, allows a user's browser to seamlessly reconnect to the comets on the server without needing to reload the page in many circumstances. In cases where significant changes have been delivered to an application, reloading the entire page may still be desirable. However, when deploying small bug fixes to users Comet Rehydration is a useful tool to do so without interrupting their experience in your application.

    There are a couple of prerequisites to use rehydration effectively. Specifically,

    • ⚡️ The CometActors in your application should have a mechanism for reconstructing their intended state from cookies or by invoking methods on the client via paritalUpdate that will cause the client to transmit its current state to a new Comet.
    • 💻 If there is a significant amount of client-side JavaScript interacting with the comet, it would be advisable to version the RPC calls between the client and server so that the client knows when a full page reload is required. Such versions could be incremented to indicate changes in the protocol between the Comet and the browser or indicate that the browser needs to reload the page to fetch new JavaScript that the comet depends on (for example, a new version of jQuery).

    We encourage all Lift developers to take a closer look at Comet Rehydration. We believe it will significantly improve the user experience for end-users of Lift applications when implemented with the prerequisites described above.

    To start using rehydration, add the following to your Boot.boot implementation:

    LiftRules.enableCometRehydration()

    (#1864) Add transform and flip methods to Box

    Our Box data type has learned a few new tricks.

    The new transform method allows callers to take a Box and, via PartialFunction, turn it into any other Box. If the PartialFunction fails, the original Box is returned.

    Some examples:

    // Returns Full("alternative") because the partial function covers the case.Full("error") transform { case Full("error") =\> Full("alternative") }// Returns Full(1), this Full box unchanged, because the partial function doesn't cover the case.Full(1) transform { case Full(2) =\> Failure("error") }// Returns this Failure("another-error") unchanged because the partial function doesn't cover the case.Failure("another-error") transform { case Failure("error", Empty, Empty) =\> Full("alternative") }// Returns Full("alternative") for an Empty box since `partialFn` is defined for EmptyEmpty transform { case Empty =\> Full("alternative") }// Returns Empty because the partial function is not defined for EmptyEmpty transform { case Failure("error", Empty, Empty) =\> Full("alternative") }

    The new flip method allows callers to take a Box and, if it is an EmptyBox (which is an Empty or any sort of Failure), flip it into a Full with a specific type. If it is a Full, an Empty is returned.

    Many thanks to @Bhashit for this contribution!

    (#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.

    👌 (#1874) Support for HTTP patch method in RestHelper.

    🏗 We now support the Patch verb when using RestHelper to build APIs. Also, as you would expect, there are XmlPatch and JsonPatch variants as there are with Get, Post, etc.

    (#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.

    (#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))

    👌 Improvements

    • 🚀 During this release cycle, we also formalized our support policy.
    • (#1865) Ensure the server/port combo of the original request is preserved. This resolves bug #1794, wherein our snapshotting of the underlying request object during some async operations was incomplete. This periodically caused misbehavior that broke the ability to retrieve the host and path of the request being handled by the async operations.
    • 📚 (#1868) @Bhashit contributed some very nice documentation about Dependency Injection in Lift.
    • ⬆️ (#1871) Bumped our logback version. This shouldn't affect applications using Lift directly, since we treat the logback dependency as something the application using Lift will provide. However, we do recommend that, if you haven't, you also upgrade to 1.2.3 or higher to resolve a security issue.
    • 🐎 (#1888, #1881) Various lift-json performance improvements.
    • (#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.
    • 🔧 (#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.
    • ➕ (#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.
    • (#1908) MetaProtoExtendedSession cookies can now be restricted to the context path of your application. Or, really, any path you want - though we're skeptical restricting your cookies to /bananas if your application isn't hosted at /bananas would really be that useful.
    • 🚚 (#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.
    • 📚 (#1910) Clarification of LAPinger documentation.
    • 🌲 (#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.
    • 👍 (#1921) @joescii shipped some minor tweaks to support session serialization with lift-cluster.

    🐛 Bug Fixes

    • (#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.
    • 🏗 (#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.
    • (#1923) Validate that no-arg comet constructor doesn't exist before attempting backup constructor. This fixes a long-standing bug in Lift regarding Comet instantiation. Previously, if you had a comet that threw an exception in it's no-argument constructor we would unintentionally swallow that exception and attempt the backup, comet info constructor. Then we'd complain to the developer that the comet info constructor didn't exist. We're now a bit smarter about how we handle those errors, and check the Exception that the no-arg instantiation returns. If it's anything other than a "no such method" Exception, we'll re-throw immediately instead of trying the comet info constructor.
    • 📜 (#1924) Correctly override list item markup in lift-markdown. This resolves an issue (#1810) where InlineParser would ignore custom decorators for list items. Thanks @ricsirigu for the fix!
    • 🔧 (#1928) Add a configurable maxIdLength to mongo-record's string primary keys. Previously this was hard-coded to 12.
    • ✅ (#1930) Added a null guard to address tests that touch stateful features. Resoles an issue (#1929) where an alarming, but harmless NullPointerException would occur in tests that destroy a LiftSession. Hat tip to @joescii for spotting it and delivering the fix.

    Final Notes

    🚀 This release represents six months of hard work on behalf of the contributors. Most of the contributions made to Lift are made on the contributor's own time without any kind of payment. If you use Lift, please take the time to thank a contributor the next time you see them. They'll appreciate knowing their work is valued.

    🚀 Now, we look forward to Lift 3.3.0 around July. Lift 3.3.0-M1 is currently scheduled to be released February 1, 2018 — only a few days from now. If you're interested in our progress, you can follow along from the Milestones page.

    As always, please reach out to us with any questions or concerns on the mailing list. We hope you enjoy Lift 3.2.0!