Lift Framework 3.1.0-RC1

The Lift Committers are pleased to announce the release of Lift 3.1.0-RC1 on June 16, 2017. This release continues our new release cadence. This will be the final pre-release 3.1.0 build unless we find regressions or need to make critical fixes to the 3.1.0 line before declaring it final.

Provided we do not need to make an additional release candidate, this release will become the final 3.1.0 build at the end of June. For the latter half of the year, we'll start the release cycle over for 3.2.0. You can follow the milestone progress in the Github milestone view.

Below is a summary of the changes that have been made since 3.1.0-M3.

The following new features or improvements have been made in this release:

• (#1857) Addition of the BoxLogging helpers. The new BoxLogging helper provides functions for logging boxes and then continuing to operate on the box, allowing logging to become a fluent part of the Box interaction. It provides methods that can allow for logging empties and failures, or just failures. It also allows logging these to different log levels, and allows for different adapters to be applied.
• (#1862) Improve error messages when we can't find a correct implicit conversion for CSS transforms. When things went wrong while trying to resolve implicit conversions to make a working CSS transform, the compiler error generated was pretty opaque. With this change, we've improved that error message to be more friendly to people without a ton of Lift experience.

Additionally, the following bug fixes have been made in this release:

• (#1852) Always suspend Comet Requests before resuming them. When a container supports request suspension, we were first scheduling a function to resume the request on a different thread and then suspending the request. While the function was scheduled in the future, the fact that it was scheduled before the suspend had definitively occurred meant there were thread schedulings where the resume could occur before the suspend had executed, leading to exceptions. We now suspend the request before scheduling the resume.
• (#1844) Properly handle missing servlet http requests in buildDeferredFunction. Sometimes S.req returns a Req without a servlet HTTPRequest inside. Ergo, when code would call HttpRequest.snapshot in Req.snapshot, we would get a NullPointerException. To fix this, we modify currentReq in both definitions of buildDeferredFunction so that they filter out null requests. Shout out to first-time contributor @arigoldx!
• (#1861) Add special handling for UnavailableException in boot. This code adds special handling for javax.servlet.UnavailableException. Previously, if this exception was thrown during boot, we'd swallow it because we swallowed all exceptions during boot. However, this exception is an idiomatic way to signal a full abort to the Java Application Server running the application. From now on, we will log and re-throw this exception if we see it.
• (#1863) Resolve some issues with swallowing exceptions in lift-json. In some cases extraction in lift-json would go horribly wrong and swallow exceptions that occur during class instantiation. This was due to us failing to pass on an underlying exception when we run into these errors. That has now been fixed.
• (#1859) Fix LAFuture.collect/collectAll when sub-futures fail. Before, a single failed LAFuture rolled up in a collect or collectAll would cause the overall future to hang forever. We now properly fail the overall future if any contained future fails.
• (aeeac27) Some minor liftsh changes to deal with some build problems.

This release is immediately available on Maven Central. Please let us know what you think on the mailing list!

Lift Framework 3.1.0-M3

The Lift Committers are pleased to announce the release of Lift 3.1.0-M3 on May 18, 2017. This release continues our new release cadence of bimonthly milestone builds, and is the last milestone build of the 3.1.0 series. One more pre-release build will be made, 3.1.0-RC1, around June 15th, with an eye towards a 3.1.0 final release near the end of June (depending on how the RC cycle goes). These will lead up to the final 3.1.0 milestone at the start of June. 3.1.0-RC1 is currently targeted for June 15, and the final 3.1.0 release targeted for the end of June. After that we'll start the release cycle over for 3.2.0 for the latter part of the year. You can follow the milestone progress in the Github milestone view.

With that, 3.1.0-M3 contains a few delicious nuggets:

• (#1845) Custom rendering of special Double values. Prior to M3, lift-json always serialized NaN, PositiveInfinity, and NegativeInfinity as their respective string values (NaN, -Infinity, Infinity). This is actually not correct JSON, as these are not supported JSON numeric values. Many if not most JSON parsers will choke on this output, including browser parsers. One notable exception is if anyone is evaling JSON as JavaScript directly---but this is a very unsafe practice. As of M3, we default to rendering these as null instead, and provide a new RenderSettings customization that allows you to switch back to the old rendering approach, or to switch to an approach that throws an exception if these special values are found (which can be paired with tryo to produce a Failure in these cases).
• (#1839) Closer to jQuery independence. Lift 3.0.0 debuted a new liftVanilla provider of JavaScript functionality on the client with an eye towards removing the Lift jQuery dependency; unfortunately, that provider was somewhat incomplete. Amongst other things, loading it still required having jQuery loaded, or at least defined. We've removed this dependency now, and continue to work to make liftVanilla a fully functional replacement for the jquery-dependent functionality needed for core Lift operations.
• (#1841) Fixed event extraction for page fragments. When event extraction was introduced in Lift 3, it did not take into account the possibility that a page fragment might be processed---for example, as a response to an AJAX request. As a result, in these cases, the events were extracted… But they were not re-transmitted through a separate channel. Instead, they were lost entirely. We now fix that, and page fragments with extracted events will properly reference the detached event handler code that will set those handlers up properly on the client.
• (#1842) Disabled event extraction for fixHtmlFunc. JsExps that handle HTML go through fixHtmlFunc, which is charged with preprocessing any embedded JS so it can be served correctly for client interpretation. Unfortunately, the interaction between this preprocessing and event extraction led to some broken and unexpected behavior. We're reasoning through a deeper fix, but in the meantime even when LiftRules.extractInlineJavaScript is enabled, fixHtmlFunc will not do event extraction.
• (#1837, #1854) Removed FileInputStream and FileOutputStream usage. @eltimn moved much of Lift's internal usage of FileInputStream and FileOutputStream to their more GC-friendly java.nio equivalents. See this Cloudbees post for the GC impact of the old streams. This change should have no impact on your code. If you find yourself having to recompile your code to work with this change, please let us know on the mailing list, as this is meant to be a purely internal change.
• (#1832) Fixed snippet class cache. Resolved a bug in how we cache snippet class instances that caused a performance hit when using the same snippet multiple times.
• (#1768) Improved handling of tuples in lift-json. Tuples can now be serialized and deserialized as heterogenous arrays in JSON instead of as objects. This feature is disabled by default to ensure we're not changing default behavior in Lift 3.1, but can be enabled by providing a Formats object with tuplesAsArrays set to true. The one caveat with this functionality is that it doesn't consistently support Scala primitives, so if you're using tuples inside a larger, more complex structure you'll want to use the Java boxed types instead of Scala primitives where applicable (so, java.lang.Integer instead of Int). However, if the tuple contains case classes you should be able to use primitives inside those without issue: this caveat only affects primitives directly in the tuple. The README for lift-json documents all of this, and Matt Farmer wrote a blog post demonstrating it in a more narrative style if that's more your thing.
• (#1791) Event return normalization. If handlers to liftVanilla.onEvent returned false, we'd just return that value. Now, we now check for the existence of event.preventDefault and trigger it and stopPropagation if the handler returned false. We also return that return that false value for older browsers to work with.
• (#1838) Removed some deprecated rendering methods in lift-json.
• (#1853) Added Class caching for type hints in lift-json. This change should improve performance when the same type hint is seen multiple times by caching the Class instance we use for a particular type hint instead of invoking a class lookup each time.

The RC has a few more tidbits geared up to be included, and we're already planning for some good updates that will go into Lift 3.2 as well.

This release is immediately available on Maven Central (meaning it's actually been available since Thursday...) ;) Please let us know what you think on the mailing list!

Lift Framework 3.1.0-M2

The Lift Committers are pleased to announce the release of Lift 3.1.0-M2 on April 7, 2017. This release continues our new release cadence of bimonthly milestone builds. These will lead up to the final 3.1.0 milestone at the start of June. 3.1.0-RC1 is currently targeted for June 15, and the final 3.1.0 release targeted for the end of June. After that we'll start the release cycle over for 3.2.0 for the latter part of the year.

This milestone build brings a small set of improvements:

• The MongoDB Record module now supports the MongoDB Async API calls. (#1829) Now, there are a handful of *Async methods on the MongoDB record implementation that will return Futures to the calling code, meaning you can now easily compose Mongo Record operations with other non-blocking code. Hat tip to @eltimn and @marekzebrowski for their work on this.
• @n4to4 was kind enough to fix some broken links in our readme.

This release is immediately available on Maven Central.

This was a pretty small milestone, but we were focusing on producing a stable milestone at a predictable schedule, and we successfully accomplished that goal. We've got a lot of good work queued up for M3, so be on the lookout for that.

Lift Framework 3.1.0-M1

Lift 3.1.0-M1 marks a new release process. Now that Lift 3 is out the door
with most foreseeable breaking changes, Lift 3.1.0 will be developed on a
regular cycle, per the discussion @farmdawgnation initiated on the Lift ML
regarding our release cycles.

3.1.0-M1 is a little late by that account as we finalized the new cycle a little
after the planned date called for. In general, expect bimonthly milestone
builds, with 3 milestones before a final minor release. The first RC for a final
minor release will come about 2 weeks after the third milestone release for
that version, with an eye to having the final release out one month after the
last milestone, barring major bugs.

With that, 3.1.0-M1 contains a few things that were pent up during the Lift
3.0 release cycle:

• (#1812, #1815, #1823) Full compatibility with Scala 2.12. Lift 3.0.1 was
  released with Scala 2.12 support, but there were still some pieces to
  put in place for proper continuous integration and release building before
  we could consider that complete. This is now done. Thanks to @SethTisue
  and @farmdawgnation for putting in some contortions to get this all in order.
• (#1813, #1824) Session-aware Lift and Scala Futures. Especially with Lift 3's
  enhanced support for futures in CSS bindings and RestHelper, folks
  would find themselves firing off futures that needed to do i18n or something
  else that required session access, only to have that session context missing
  when the future actually executed. @pdyraga added a new helper,
  LAFutureWithSession.withCurrentSession, aliased as S.sessionFuture,
  which can be used to create an LAFuture task that has access to the
  session. There is a similar helper, FutureWithSession.withCurrentSession,
  that will spawn a task as a Scala Future with access to the session. The
  resulting futures can be chained and combined with other futures and will
  preserve their session access. This includes all APIs in Scala's Future in
  Scala 2.12, as well.
• (#1819) The mongo Java driver has been updated to version 3.4.0.
• (#1817, #1822) lift-json has gained significant parser performance
  improvements, and is now competitive with the jawn parser in most
  of jawn's microbenchmarks, making it one of the fastest Scala JSON
  parsers across a variety of parsing scenarios.

Lift Framework 3.0.1

This is a small point release to make Lift 3 available for Scala 2.12. The
Lift 3.0.1 release is built for both Scala 2.11.4 and Scala 2.12.1. As per
the usual Lift strategy of long-term support, we currently intend on
supporting Scala 2.11.x for some time.

Note that the bump to 3.0.1 brings with it bumps in several dependencies:

• Compile: Scalaz from 7.2.0 to 7.2.7.
• Test: Scalatest from 2.1.3 to 3.0.1. Specs2 from 3.7 to 3.8.6.

Please be aware of these dependency bumps when upgrading, and let
us know if you have any issues!

Lift Framework 3.0.0

The Big One

Lift 3 has been several years in the making, and includes a lot of stuff. Going
through it exhaustively would be very difficult, so some highlights will be listed
and then links will be provided to other places where a lot of the finer changes
have been announced, mentioned, and discussed.

Thanks for your patience waiting for the final release, and enjoy! More to come,
as always :)

Version Support

Currently Lift 3.0.0 is built for Scala 2.11.8. Scala 2.12.0 has a compiler bug that
prevents us from building Lift 3 for it; 2.12.1 has a fix for this bug, and we'll be
publishing a 2.12 build shortly after that is released.

Big Improvements

• Lift-json is a bit faster to serialize thanks to elimination of the intermediate scala.text.Document class,
  and hugely faster thanks to an optimization in the hot path of serialization by @chriswebster .

• Addition of LiftRules.securityRules, which allows configuring:

  • Content-Security-Policy support (first-class support for CSP Level 1, defaults
    to allowing only same-origin resources except for images, which are allowed from
    all domains, and JS, which allows unsafe eval).
  • Strict-Transport-Security settings (default to off).
  • Frame restrictions (same-origin by default)
  • Whether the above restrictions should be turned off for dev run mode vs other run modes.
  • Whether violations of the above restrictions should be logged in dev mode vs other run modes.

  See the API documentation for SecurityRules for more.

• Along with SecurityRules and supporting progressive enhancement, LiftRules.extractInlineJavaScript can be set to true to extract any onclick, onmouseover, and generally on* events, as well as javascript:-style URLs, into external event handlers. These are served on a per-page JS file and allow the CSP to be set to disallow unsafe inline JS while still permitting most classic server-side JS binding done in Lift using CSS selector transforms.

• Props allows lookup of properties in places other than Lift's .props files. In particular, any Map can be used to find properties by passing it to Props.appendProvider.

• Props also allows interpolation in property values, which values can be added as a Map using Props.appendInterpolationValues.

• Improved future and async support throughout, including:

  • Wrapping any right-hand value for a CSS selector transform in a Future or LAFuture (this will be rendered as a spinner to the client, until the future resolves at which point the content will be sent down). This is backed by the same infrastructure used for Lift's lazy snippet.
  • Wrapping any RestHelper response in a Future or LAFuture to have it handled asynchronously using container continuations, reusing all of the extensive support that Lift's comet actors use.
  • Including new comets in future values for CSS selector transforms or in AJAX responses or in lazy-loaded snippets without any additional plumbing or work. This also allows including lazy-loaded snippets in AJAX responses, or lazy-loaded snippets within lazy-loaded snippets (lazyception, as it were).

• Arbitrary parsers for Lift templates can be added using LiftRules.contentParsers. By default, HTML and Markdown parsers are provided, but this can be straightforwardly expanded to, for example, asciidoc, or any other template that can be parsed to NodeSeq in Scala. See the Scaladocs for ContentParser and @joescii's blog source code for more.

• Round-trips and streaming promises for even easier async support.

• Custom data- and element handling for better domain-specific templates.

In addition to these big features, following is a broader summary of changes with some duplicates.

Breaking Changes

All deprecated methods in Lift 2.6 have been removed. If you have deprecation warnings
in your 2.6 application, it will not compile for Lift 3.0.0. However, there are also other
aspects that have been changed that could not be deprecated properly in Lift 2.6.

• Box.get is no longer usable.
• JavaScript handling
  • liftAjax is no longer available on the client, as it has been significantly restructured.
  • There is now a semi-public API for Lift's few client-side functions; see lift.js. Note that this API is not yet documented and therefore not considered stable, so use it directly only with great care. That said, we also don't have any specific plans to change that API's behavior.
• Lift URIs
  • Lift AJAX calls are now routed under /lift/ajax
  • Lift comet calls are now routed under /lift/comet
  • Everything under /lift is reserved for Lift's use. That path can be customized via
    LiftRules.liftPath. Unlike before, when you could customize AJAX and comet paths
    separately, you can now only customize the top-level Lift path, and everything underneath
    it is reserved for Lift's use, both present and future.
• In #1584, lift-json's JField stopped being a JValue; it is now instead a type alias for (String, JValue). This is a cleaner representation, but it means that map, transform, find, and filter only operate on proper JValues, and using these on fields requires using mapField, transformField, findField, and filterField.
• In #1568, old binding strategy based on the bind function is now gone. CSS selector transforms should be used instead. Several built-in snippets have been migrated away from the old bind strategy; in general, elements and attributes that were prefixed by namespaces now correspond to classes without the prefixes. If you need any help migrating, please post to the Lift mailing list. The changed snippets are:
  • Paginator; see the Paginator binding migration guide for details here.
  • ProtoUser
  • Crudify
  • LiftScreen (now behaves like CssBoundLiftScreen); see the LiftScreen binding migration guide for details here.
  • CssBoundLiftScreen (now LiftScreen)
  • FormProcessor (removed)
  • TableEditor
  • Util in mapper.view
• (#1585) CometActor behavior—comets with no type specified are no longer supported
• (#1714) LocRewrite is now expected to return a (RewriteResponse, Box[T]) where T is the type of the menu item's param. Before it was a T rather than a Box[T].
• (#1710) lift-json no longer uses scala.text.Document as an intermediary when rendering to a string.

Improvements

• (#1585) Sending new comets to the client in AJAX callbacks
• (#1619) MessageCometActor/CometActor distinction allows partialUpdates with fewer bugs.

Deprecations

• (#1668) Much of TimeSpan's functionality has been deprecated. TimeSpan conflated
  several different concepts, including DateTime, Duration, and Period, which did not
  have the same semantics. As a result, there were corner cases where it could behave in
  very unexpected ways. In order to fix this, we've deprecated TimeSpan functionality for
  all uses that are not as a simple millisecond Duration. This deprecation takes effect for the
  final release of Lift 3.0.0, which means the functionality in question won't be removed until Lift
  3.1.0 at the earliest. Big big thanks to @arkadius for spotting this issue while trying to clean up
  specs, and taking point on adding the various deprecations.
• (#1710) In lift-json, compact and pretty (previously used in conjunction with
  render to serialize JSON to a String) are now deprecated in favor of compactRender
  and prettyRender. They will be removed in Lift 3.1.0.
• (#1742) FocusOnLoad is now deprecated in favor of S.appendJs(Focus(...))
  and/or using the HTML5 autofocus attribute.
• (#1749) Our mongo dependencies were upgraded to the latest driver that
  supports some of our older customization strategies. The older customization
  is now deprecated for removal in 3.1.0. In particular, these are defineDbAuth
  and useSession wrappers.

Prior Announcements

There have been lots of posts about the new functionality in Lift 3 over the years; following
are links to the release notes for all of the milestone and RC releases, followed by a set of
links to the Lift Weekly/Monthly Recap series that covered a lot of the early additions.

Release Notes

• Lift 3.0-M0
• Lift 3.0-M1
• Lift 3.0-M2
• Lift 3.0-M3
• Lift 3.0-M4
• Lift 3.0-M5
• Lift 3.0-M6
• Lift 3.0-M7
• Lift 3.0-M8
• Lift 3.0-RC1
• Lift 3.0-RC2
• [Lift 3.0-RC3](https://github.com/lift/framework/releases/tag/3.0-RC...

Lift Framework 3.0-RC4: Fourth Release Candidate

RC3 (and previous pre-release versions of Lift 3 that do event extraction for
content security policy purposes) had an issue where AJAX responses containing
HTML that in turn contained embedded event handlers could in certain cases turn
into attempts to attach events before the associated HTML elements were in
the DOM. This caused failures with existing apps.

Due to the lateness in the RC cycle of this bug, we've opted to allow for
disabling event extraction altogether, and disabled it by default. This
means that apps that have been using event extraction will want to enable it
explicitly by setting:

LiftRules.extractInlineJavaScript = true

We will enable it by default in a future Lift 3 point release once we're confident
of its correct behavior.

We expect this to be the last RC before Lift 3 goes final.

Breaking Changes

• (#1809) You must now explicitly enable event extraction (which turns on*-style
  event attributes in HTML and javascript:-style form submission and link URLs into
  out-of-band JavaScript that attaches event handlers, making HTML like this
  generated by Lift compatible with restrictive content security policies) in order for
  Lift to do this. This was done in response to noticing some issues with event extraction
  and HTML-appending AJAX responses, which could in some cases attempt to bind
  event handlers before the relevant nodes were in the DOM, and thus failed to bind
  those handlers. Users of Lift 3 before RC4 will want to explicitly enable
  LiftRules.extractInlineJavaScript to preserve prior behavior.

Lift Framework 3.0-RC3: Third Release Candidate

We found an annoying situation in RC2 that made the asJValue
method of Record and MetaRecord return JValue, which
didn't jive with the way these were being used in certain cases.

Fixes

• (#1787) Record and MetaRecord's asJValue methods were
  correctly converted to return JValues, but in certain cases this
  did not connect well with actual use. A new asJObject method
  was added to return the JSON as a JObject which could then be
  combined with other fields and objects.

Lift Framework 3.0-RC2: Second Release Candidate

We saw an issue in RC1 that could be worked around, but we
felt it was easy enough to come across it without intending to
that it was worth releasing a second RC.

Fixes

• (#1783) JsCmds that produced HTML with events and eagerly
  evaluated that HTML content (e.g. by declaring a val toJsCmd
  instead of def toJsCmd) would produce the event handler JS
  even if the JsCmd in question was never sent down to the client.
  We now tie the JS for event handling to the JsCmd's content
  directly, so this pitfall can't be triggered. Thanks to Riccardo Sirigu
  for reporting this issue on the mailing list.

Lift Framework 3.0-RC1: Release Candidate

This release features the last tidbits before 3.0 goes out the door. These
include some cleanup, a bunch of dependency bumps, and a couple of
fixes to bugs discovered during use of 3.0-M8. No feature work landed in
this release, and only bug fixes will be permitted before the next release.

If we don't see any bugs in the next 2-4 weeks, we'll be releasing Lift 3.0.
We're all super excited to be this close to a final release!

Breaking Changes

• (#1766) lift-json's \\ used to return a JValue. In cases where it matched
  a single field directly, it would return the field's value rather than a consistent
  container type. Matching multiple fields would return a JObject with the
  matched fields in it. Now, \\ always returns a JObject with the matching
  fields in it, even if there is only one such field. This may require adapting
  certain uses of \\, especially in for comprehensions. Code like
  for (JString(name) <- object \\ "name") will have to be changed to
  something more like for (JField(_, JString(name)) <- object \\ "name") to
  work correctly. Thanks to @eallik for reporting!
• (#1773, #1779) Lift was depending on outdated versions of many libraries.
  We've bumped those dependencies, so we now depend on specs2 3.7 and
  Java Servlet 3.1. All other version bumps were non-major, including
  lift-json-scalaz now depending on Scalaz 7.2. See the dependency file's diff for the full breakdown of dependency updates.

Improvements

• (#1772) When JsCmds including Noop were combined with &, you
  would get a lot of empty lines, since each Noop would emit some empty
  lines in those cases. Now, we ignore Noop when combining JsCmds,
  which should lead to reduced noise in serialized JS output. The most
  immediate impact is that page-specific JavaScript will be much more compact
  than it was before.

Fixes

• (#1779) Props.whereToLook works correctly again. In 3.0-M8, we expanded
  the abilities of Props to read from arbitrary sources. Unfortunately, in the
  process, we broke the whereToLook setting that allowed you to adjust the
  search paths for Props to look for named property files. This has been fixed
  in RC1. Thanks to @serioga for reporting!
• (#1769) Lift's JavaScript settings customization was set up such that you couldn't
  override things provided by Lift's liftVanilla or liftJQuery objects. This is now
  fixed, so custom JavaScript settings can build on and override those base functions.
  Thanks to @joescii for reporting… And fixing! ;)