Errai: The browser as a platform

Friday, April 1, 2016

Errai 4.0.0.Beta1 released!

Greetings everyone!

As we write this, GWT and Errai are 10- and 6-years-old projects respectively. In those years, the web development community has progressed at an amazing speed, which has led some to ask the question: Is there still a place for these projects now and in the future?

We on the Errai Team continue to see huge value in our type-safe and declarative programming model for developing large projects. It is because of this value that we continue to actively develop Errai and it is because of this value that we continue to say this.

Today we're happy to announce the release of Errai 4.0.0.Beta1, targeting GWT 2.8.0-Beta1. This release brings exciting new features for working with native JavaScript and HTML, as well as improved refresh times in Super Dev Mode. In particular, 4.0.0.Beta1 includes:

  • A new Errai IoC container supporting partial code regeneration for improved refresh performance in Super Dev Mode
  • Greater compliance with CDI such as:
  • Support for injecting native JavaScript objects into IoC beans with JS interop
  • Support for injecting Errai IoC beans across separately compiled GWT scripts
  • Support for native DOM-based UI development with:
    • JS interop wrappers for common DOM elements
    • A declarative way of defining custom element wrappers available for injection in Errai IoC
    • Ability to use native DOM elements with Errai UI @DataFields, Errai Navigation @Pages, and Errai Data Binding @Bound fields

So what do all these changes mean for you?

Performance Improvements

When developing in Super Dev Mode, refreshing after modifying an IoC managed type requires generating significantly less code, decreasing the overall refresh time.
At runtime, applications with many @ApplicationScoped beans will notice decreased start-up times as @ApplicationScoped beans are now lazily instantiated by default.

Templated Beans with Native HTML Elements

In Errai 4 it's now possible to develop UI components without Widgets, and instead with thin-wrappers around native HTML elements. Here is a @Templated bean for a form using Errai UI and Data Binding.


How is this different from Errai 3?
  • Div, TextInput, and TextArea are not Widgets. Rather they are thin-wrappers around the div, input, and textarea elements respectively (using the GWT 2.8 JS Interop API)
  • The ContactForm does not extend Composite
  • The root element of the template is accessible as a @DataField. (This can be used to manually add this template to the DOM.)

Injecting Other DOM Elements

Errai 4 provides built-in thin-wrappers for most commonly used HTML elements, which you can you use in place of Widgets. The complete collection can be found in this package.
In case you wish to inject elements which do not have specific wrappers provided by Errai, you may use either of the following options.

Use the @Named Qualifier

Using the @Named qualifier, it is possible to inject an HTMLElement with any tag name. For example, here is how you could inject a nav element.

Create your own @Element

It's also very simple to declare your own thin DOM wrappers using the new @Element annotation. For example, here is a thin wrapper for the nav element that, if included in your project, can be available for injection in the IoC.

Next Steps

For those of you itching to learn more, our next blog post will take a deep dive into native JavaScript support in Errai 4, including how you can make arbitrary JavaScript objects injectable and how you can inject Errai IoC beans across separately compiled GWT scripts.
Until then you can check out our new and improved Errai Tutorial, which showcases all of the features mentioned here.

Happy coding!

Thursday, August 6, 2015

Errai 3.2.0.Final released and 4.0 in the making!

Hi everyone,

It's time for a quick update: Errai 3.2.0.Final has been released which contains a number of important fixes and quite a few new features, like runtime template support and an embedded WildFly launcher for Super Dev Mode (see the release notes for all details).

We've also just started work on Errai 4.0! In the short-term, we will be focusing on the following features and enhancements:

  • Errai IoC: Injection of types provided at runtime by dynamically loaded modules (external scripts)
  • Errai IoC: Incremental generation of our bootstrapping logic (to significantly improve refresh times)
  • Errai UI: Ease the integration of web components and allow the use of light-weight DOM wrappers instead of GWT widgets

Max Barkley is back in full force and will be leading most of this development.

What other features or enhancements would you like to see in Errai 4? We rely on your feedback so please join us on Freenode #errai, the errai-dev mailing list, or on our community forums.

Happy coding!

Thursday, February 5, 2015

Upcoming Errai talks

We're happy to announce that there will be three Errai talks this March!

Johannes Barop, a long-time Errai contributor and community member, will present at JavaLand on March, 25. You can find the details of his talk here. If you plan to attend JavaLand (and why wouldn't you? They have Java, beer, and roller coasters!) make sure to stop by and check out his talk!

Harald Pehl, core developer on Red Hat's WildFly team and long-time GWT developer, will present Errai at the Java Users Group in Frankfurt.

Finally, I am really excited and looking forward to presenting at QCon São Paulo on March, 26. The details of my talk can be found here.

Happy coding!

Monday, January 19, 2015

Errai 3.1.1.Final released!

Hi everyone,

Just a quick note that we released Errai 3.1.1.Final today. This is a maintenance release containing a few bug fixes (see the release notes for details). We have also switched master to 3.2.0-SNAPSHOT for future development. So far 3.2 contains a new feature that allows for server-side (dynamic) Errai UI templates. Please stay tuned for more information and an updated roadmap.

Everything is set for GWT.create now and I hope to see many of you in Mountain View and Munich in the coming days!

Happy coding!

Wednesday, January 14, 2015

SSO with Errai and Keycloak.js

The Artificer project (http://artificer.jboss.org) has been a long-time fan of Errai, relying on it for the majority of our powerful UI. We recently switched to using Keycloak, an out-of-the-box security solution, for authentication and authorization. Typically, you'd protect your Errai index.html page with a simple security-constraint in the WAR's web.xml.  However, due to various issues, we investigated the use of Keycloak's pure-Javascript adapter (keycloak.js). This post will quickly capture the approach and a few gotchas.

Note that Errai has a built-in Keycloak module, based on Errai Security. Although that may be the best way to go, we were interested in making keycloak.js work on its own with plain Errai.

index.html

So, first things first.  When you run Keycloak, either using its standalone appliance or within a container of your choice, it serves up the keycloak.js file.  Add it to your page's header:


Right off the bat, there's a few things to notice:

  • The keycloak variable is attached to the window object.  More on that later...
  • The init call includes the {onLoad: 'login-required'} option. This tells Keycloak to redirect users to the built-in login screen, if un-authenticated.  If left off, the user must be pre-authenticated by other means.
  • Keycloak revolves around the use of tokens. Server-side, those tokens expire after a configurable period.  For Javascript-based solutions, such as Errai, that may never refresh the page, manually refreshing the token is vital. However, Keycloak's updateToken is currently asynchronous and uses a promise. Rather than deal with a complicated callback setup, we're simply updating the token on a 10 second timer.  By default, Keycloak tokens expire after a minute, however this value is configurable.

REST

The back-end REST services are also protected by Keyloak.  In order to use them, without requiring basic authentication, the Errai app must provide a "bearer token" on each call.  To accomplish this, we created a RestClientInterceptor to intercept each call and add the token.


Here, we use a bit of JSNI to obtain the Keycloak token from index.html.  Here's where the window object necessity comes in.  Since this interceptor technically runs in a nested frame, simple global variables will not work.  Attaching the variable to window, then referring to it through JSNI's $wnd, allows the cross-frame sharing.

After obtaining the token, the interceptor adds it to the request.  Note that the header key is "Authorization" and the value is "Bearer [token]".  The "Bearer" bit is vital, but can be easily forgotten.

RPC

The above approach works similarly for RPC, but is instead based on RpcInterceptor.

Servlets

What about Servlets?  In our case, Servlets are used directly from GWT FormPanel for needs such as local file uploads.  The Servlets themselves are not protected by Keycloak, but they turn around and call the same REST services described above.  So, the bearer token is still needed, but in a proxied manner. Since there's not a request originating from Errai to intercept, we have to use this workaround.


We automatically add a Hidden input, called "Authorization", to the form.  When the form is submitted, we're re-using the JSNI in KeycloakBearerTokenInterceptor to set the input's value to "Bearer [token]". Then, in the Servlet's doPost, the "Authorization" parameter is pulled from the HttpServletRequest. The token is then used on the proceeding call to the REST services.

One caveat that's often overlooked: if your form sends multipart data, such as our file upload, the "Authorization" parameter is a part of the request's file/form items, not in request.getParameter("Authorization").

For GET, it's obviously easier. Simply add the "Authorization" parameter, identical to the above (if in a form) or by adding it to the URL query string. The Servlet grabs it through request.getParameter("Authorization").