Upgrade to Wicket 9

For v15 of brXM, we’ve upgraded Wicket from v7.18.0 to v9.7.0. The main reason for this is that Wicket v9 has built-in support for a Content Security Policy, which improves the security of our application.

This page describes the impact of these changes on all community plugins and custom Wicket code.

Upgrade to Wicket v8

First, upgrade your Wicket code to the latest release of Wicket v8 (v8.9.0).

The full migration guide can be found at https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+8.0.

The code changes with the most significant impact are:

• Wicket 6 deprecated the usage of JS event names like “onclick”, “onblur”, etc. in favor of their short version without ‘on’ prefix, i.e. “click”,“blur”, etc. Starting from this version, the old event names won’t work anymore.

• RequestCycle.find(Class<T>) now returns an Optional<T> value. Keep this in mind if you used the following code to get the current AjaxRequestTarget: 

  if (RequestCycle.get().find(AjaxRequestTarget.class) == null) {
      // executed for non-ajax-request in Wicket 7
      // never executed in Wicket 8
      ...
  }
  

• IModel is a @FunctionalInterface now which means that you can create a read-only IModel as follows:

  final IModel<String> nameModel = () -> "Bloomreach";
  

Upgrade to Wicket v9

Next, upgrade your Wicket code to the latest release of Wicket v9 (v9.7.0).

The full migration guide can be found at https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+9.0.

The code changes with the most significant impact are:

Deprecation of org.apache.wicket.util.time.** classes

Wicket used custom classes to handle and manipulate time entities such as “duration” or “current instant”. These classes have been replaced with standard Java 8 classes java.time.Duration and java.time.Instant. As such, we have updated the codebase to use the java.time.** classes as well.

One of the downsides of this change is that we no longer support creating a “duration” using the simple format of “1 second” or “2 days”. This was custom functionality from Wicket and has been replaced by the ISO-8601 standard.

For backwards compatibility we still allow the “old” format, but encourage anyone to upgrade to the new format by logging a WARNING.

Browser User Agent Detection

Another change that might impact application code, is the removal of Wicket’s built-in user-agent detection capabilities.

We have replaced it with the YAUAA library which can be accessed as follows:

final Main main = (Main) Main.get();
final WebClientInfo clientInfo = WebSession.get().getClientInfo();
final UserAgent.ImmutableUserAgent userAgent = main.getUserAgentAnalyzer().parse(clientInfo.getUserAgent());

As parsing of the user-agent String can be pretty expensive, we have limited the number of fields to the “agent-name” and the “agent-major-version”.

JUnit5

All the Test classes that ship with Wicket now depend on JUnit 5.x instead of 4.x. In most cases, this won’t impact application testing code, but in case your code extends any of these classes while you run your tests with JUnit4, you need to call super.commonBefore() manually from your @Before method.

@Before
public void beForeEach() {
    // We need to manually call the before methods that are annotated with JUnit5
    super.commonBefore();
}

Wicket Ajax debug window

Wicket has removed the custom “Ajax debug window” and instead logs all of its Javascript debug messages into the browser console. This is definitely an improvement (no more floating window), but it also clutters the browser console, which can make it pretty hard to work with custom debug messages. For this purpose, Wicket Javascript debug logging has been disabled by default and can be enabled when the CMS is started with a new CLI flag -Dwicket.js.debug=true. Note that this also requires the cargo.dev Maven profile, just like before.

Page serialization disabled for DEVELOPMENT mode

We’ve disabled page serialization for DEVELOPMENT mode. We already did this for PRODUCTION mode, and adopted the same practice when Wicket is running in DEVELOPMENT mode. This won’t affect any application code, athough it should theoretically improve performance for DEVELOPMENT mode.

Content Security Policy

By default, both the CMS and the NavApp application now have a Content Security Policy enabled. It is not very strict at the moment, as we depend on some legacy Javascript libraries that require “unsafe” features, but we will work on resolving those issues and locking down the CSP.

Probably the most impactful CSP rules relate to which domains are allowed to be used in elements such as <iframe>, <script> and <style>. This will affect OpenUI extensions in particular. In the future, we want to automate this, but for now, users will have to manually add such domains to the CSP configuration, which is located in the repository at /hippo:configuration/hippo:modules/application-settings/hippo:moduleconfig/content-security-policy. We currently support the following CSP directives to be configured:

• connect-src
• frame-ancestors
• frame-src
• img-src
• script-src
• style-src
• font-src