Errai: The browser as a platform

Wednesday, May 21, 2014

What's new in Errai 3? Part 3: The Smaller (But No Less Powerful) Features

This is the third post in a series describing new features in Errai 3.0. This post is a summary of some of the smaller features and enhancements coming in 3.0.0.Final.

Improved HTML Form Support

Asynchronous form submission can make it difficult to trigger useful events in the web browser (such as prompting to remember a user's password). To help you overcome this issue, Errai UI now contains a base class for @Templated Widgets that provides better HTML form support.

By extending the AbstractForm class and invoking its submit method, Errai simulates native HTML form submission. Below is an example login form that causes modern browsers to prompt the user to remember a password when the "Login" button is clicked.

Test Generation with the Errai Forge Addon

If you haven't heard, there is an Errai Addon for JBoss Forge 2. This addon can set up Errai in an existing Java project for running in Dev Mode or compiling to production mode. But in the 3.0.0.Final release, you will be able to use the addon to generate unit and integration tests.

Unit tests are generated with GWT Mockito. Mockito is a test framework that allows you to inject mocks into classes and assert conditions on how these mocks are used. GWT Mockito adds extra GWT compatibility, allowing you to test classes with GWT.create calls or JSNI methods.

Integration tests extend the AbstractErraiCDITest (which in turn extends the GWTTestCase). In addition to the normal GWTTestCase functionality, the AbstractErraiCDITest initializes the Errai framework, including the Message Bus and IoC/CDI container.

WildFly 8.0 Support for Dev Mode

Previously we announced an improved Dev Mode setup using the JBossLauncher. This setup allowed the GWT Dev Mode to control a full JBoss 7 instance, making it easier to develop a GWT app using Java EE on the server.

It is now possible to use the this launcher with WildFly 8.0. If you haven't yet, give it a try since there have been many performance improvements to WildFly 8.0 that make a noticeable difference in startup time.

Asynchronous IOC with Fragment Control

Errai's @LoadAsync annotation allows for managed beans to be loaded asynchronously. That means the code for these beans will reside in a separate JavaScript file that will be downloaded the first time it is needed. In Errai 3.0.0.Final you have more control over these split points. A code fragment name can optionally be specified using a Java class literal (i.e. @LoadAsync(Admin.class) to group all beans related to admin functionality). GWT's code splitter will then put the code of all managed bean types with the same fragment name into the same code fragment (JavaScript file).

Error Detection for Common Pitfalls in Your IDE

By adding the following dependency to your project you will get automatic error detection for common Errai pitfalls directly in your IDE. While this covers an increasing amount of pitfalls, we are happy to accept your contributions. If you can think of more checks we should include please let us know or send us a pull request! Note that in Eclipse you will have to manually enable annotation processing: Go to Eclipse Workspace Preferences->Maven->Annotation Processing and select the "Automatically Configure JDT APT" radio button. In Eclipse you will also need to install the m2e-apt plugin.


That is all for today. Happy Coding!

Thursday, May 8, 2014

What's new in Errai 3? Part 2: Role-Based Access Control and PicketLink Integration

This is the second post in a series describing new features in Errai 3.0. This article is about Errai Security, which provides role-based access control with optional PicketLink integration.

Errai Security provides a declarative way of securing pages, UI elements, and remote services. Below we'll show how it is used, and how you can use it with PicketLink or another server-side security framework of your choice.

@RestrictedAccess

Role-based access control in Errai Security is focused around the @RestrictedAccess annotation. Whether you're securing a @Page, @Remote interface or UI element, you simply annotate the secured resource with @RestrictedAccess.

The annotation takes an optional array of role names (Strings). For a user to be able to access a resource, they must have all of these roles; if they do not have all of the required roles, we say that the user is unauthorized. @RestrictedAccess without roles blocks access to those not logged-in; if a user is denied access because they are not logged-in, we say that they are unauthenticated.

Restricting @Page

Here is an Errai Navigation @Page that restricts access to users lacking the admin role:


When a user is denied access to this page, one of two things will happen:
  • They will be redirected to the application's login page if unauthenticated.
  • They will be redirected to the application's security error page if unauthorized.
You can define any Errai Navigation page as login page or security error page with the @Page annotation role attribute. For example, here is a class that functions as both a login and security error page:

Restricting @DataFields

In @Templated widgets, Errai Security can be used to apply CSS styles to template-bound fields (for example for hiding UI elements from unauthorized users).


When a user lacks permissions for one of the @DataFields above, the element in the template will have the CSS class, errai-restricted-access-style, applied. The CSS definitions ensure that the admin anchor will not be displayed to unauthorized users while the logout anchor will only be seen by unauthenticated users.

Restricting Remote Services

Errai Security can be used to secure Errai Bus RPCs, JAX-RS Endpoints, and Errai Messaging Services. When access to a service is denied, a UnauthenticatedException or UnauthorizedException is thrown on the server, which can be handled on the client with an ErrorCallback.

The default error handling provides behaviour similar to @RestrictedAccess on @Pages: unauthorized access causes navigation to the security error page and unauthenticated access causes navigation to the login page.

Errai Bus RPC

Errai JAX-RS Endpoint

Authentication and Server-Side Integration

The single point of contact between Errai Security and your preferred server-side security framework is the AuthenticationService. This interface is used to log in and out, and obtain an instance of the current User. The AuthenticationService is an @Remote interface, so you can use Errai RPC to call it from the client. errai-security-picketlink.jar provides a default AuthenticationService implementation using PicketLink. Using this implementation requires no configuration: just have the jar on your classpath and you're good to go.

Here is a login page that uses an AuthenticationService caller for logging in.


Using a Custom AuthenticationService

Integrating Errai Security with a different security back-end is as simple as implementing the AuthenticationService, and making your implementation a valid CDI bean. You can even implement your own User and Role types: for example, the Errai JPA Demo AuthenticationService uses a custom User implementation that is a JPA entity.

See It In Action

If you'd like to see Errai Security in action, you should checkout the Errai Security Demo. If you have any feedback, we'd love to hear it!

Thursday, May 1, 2014

What's new in Errai 3? Part 1: RPC Enhancements

This is the first post in a series describing new features in Errai 3 that we haven't blogged about so far. We have recently published the first release candidate and plan to release 3.0.0.Final by the end of the month.

Today's focus is on enhancements made to Errai's RPC mechanism. You can find all details in our reference guide.

Global Exception Handlers

In your application you will likely find many remote procedure calls that potentially throw the same type of exception, usually related to some cross-cutting concern (i.e. authorization/authentication). Errai's new global exception handling feature supports handling these exceptions in a centralized way. It relieves you from having to provide error callbacks at each RPC invocation. Methods annotated with @UncaughtException are called when an exception occurs during a remote call that is not handled by an error callback. This feature is also used internally by Errai's new security module that we'll describe in detail in a future post.


Asynchronous handling of RPCs on the server

Sometimes computing the result of an RPC call can take a significant amount of time (i.e. because a slow database query needs to be executed or a third party service needs to be contacted). It then might be preferable to release the request-processing thread so it can perform other work and provide the RPC result from a different execution context farther in the future. Errai provides a special return type for this named CallableFuture which indicates to the RPC system that the result of the RPC will be provided asynchronously (after the remote method call has returned).

Here’s an example returning a future result of type String:

Enhancements to client-side remote call interceptors

In Errai 3, the new annotation @InterceptsRemoteCall can be used to define the interceptor target directly on the actual interceptor. This is useful in case you can't or don't want to annotate the remote interface with @InterceptedCall. Client-side interceptors can now also be IOC managed beans, which means you can now simply @Inject dependencies into it. Thanks to Eric Wittman for implementing these features!


Stay tuned for more new features in Errai 3 and as always, feedback is welcome and appreciated!