Errai Developer Blog

Talking Errai in India and Brno

2012-01-17T11:54:00.000-08:00

If you're in Bangalore in India or Brno in Czech Republic over the next few weeks, you have an opportunity to see Errai getting talked up by myself (Mike Brock) and Christian Sadilek.

I'll be giving two talks at JUDCon India on January 24th. And if you come out for that, we've got a full schedule of other cool things for you to check out while you're there. See the JUDCon website for details and schedules.

On February 17th, Christian Sadilek will be giving a talk at the Fedora Developer Conference in Brno. Check out the details here.

Thoughts on HTML5 and Development Methodologies

2011-12-17T14:16:00.000-08:00

Over the past few months the Errai team has been busy at work preparing the next version of the Errai Framework, Errai 2.0.

It is a significant update that leverages all the best ideas that Errai 1.x had, while retiring some ideas and approaches that didn’t quite work out the way we’d planned.

Errai has developed a philosophy about rich application development in the browser. That philosophy might be summed up as: Your Application. Everywhere. Literally.

However, there’s been some people who’ve criticized this methodology. I’d like to respond to some of this now.

We have eschewed much of the conventional wisdom about how you should architect a web application by focusing on not just rich user experience, but rich developer experience. We believe that the latter ultimately leads to a better former.

We reject the need for polyglot applications as necessary -- the idea that the best way to build an application is to arrange a constellation of disparate languages and frameworks into a coherent single application is simply the “best approach” is something we don’t agree with.

You’re building your application in Java on the server. Why do you build the other part of it in JavaScript? The common response to this is, well, “that’s just the best way to do it”. But is it?

We don’t think it is. At the end of the day, the whole HTML5 group of technologies is just a specification that tells us how to make a browser do things.

Whether we write HTML and JavaScript directly or not, whether it’s translated from CoffeeScript, Dart, or in the case of Errai -- Java -- is immaterial. And it’s wrong to even suggest that Errai, with its use of the GWT compiler, sandboxes you into a world that proscribes any of these things. It doesn’t.

With Errai, your application can contain no JavaScript, or be almost all JavaScript.

The important part is how Errai helps you share not just model between the client and the server, but functionality. Without the need to write it twice, or write marshalling code, or worry about setting up your own comet or websockets. The communication model is central to the application development model.

Being able to share functionality, using the same code, with the same functionality is a good thing. You get all the benefits of type checking, code reuse, and productivity.

The implication that some make that, this sort of thing “hides the true nature of the web” is always one that puzzled me among those who advocate for a pure JavaScript approach.

I’ve always been of the opinion that such essentialist notions of pretty much anything are probably notions you should be suspicious of. I mean, the Java compiler hides bytecode. The C++ and C that the JVM is written in hides machine code.

It goes without saying that JavaScript itself is hiding all of this.

Moreover, JavaScript isn’t a terribly good language for large applications. And it surprises me that some of the very same people who trumpet the advantages of Java over other languages, will so willingly jettison their arguments in favor Java when it comes to JavaScript. There’s no immutability, side effects are hard to control, the object model is a mess, there’s nothing resembling a threading model, etc.

To which, counterarguments often include techniques about how JavaScript prototypes can be used in ways that simulate classes and inheritance, unit testing can guard against unintended side effects in large codebase, concurrency concerns do not apply in the world of the future, etc -- as if any of this somehow redeems JavaScript in any way in the eyes of someone who buys into these notions as being intrinsically good parts of a language.

JavaScript isn’t a bad language. Don’t get me wrong. It is mature and well understood. It does what its supposed to do. But the problem is, it was never designed with large application development in mind. Its designers did not envision a world where there’d be codebases of 100,000 lines of JavaScript code.

Yet, this is the world we’re quickly moving into. And the reality is, that technologies like GWT are extremely good solutions to manage these sorts of projects.

Over the next few weeks we’re going to show you why. Watch this space.

Setting the Record Straight on GWT

2011-11-23T10:31:00.001-08:00

Since joining the Errai team, I've been telling lots of people about our project. Every time I do this, I find myself dispelling some common misconceptions about what GWT is and how it can be used. I also find people are surprised that GWT code has easy access to the browser's native environment: although GWT smooths out implementation details between browsers, it is not a firewall that cuts you off from the underlying environment.

So what is GWT?

GWT, the Google Web Toolkit, is a project with many independent parts. Here's a partial list:

A Java-to-JavaScript compiler
A class library providing:

a subset of the Java SE 5 standard library (most notably java.lang and java.util)
A programmatic UI framework (somewhat like Swing)
Java wrappers for native browser functionality such as JSON and XML manipulation, XMLHttpRequest (AJAX and Comet), and HTML 5 features like Canvas, Local storage, Audio and Video.
An RPC mechanism you can use if your application's backend happens to be written in Java (GWT RPC can't easily be retrofitted on an existing object model, but you can use it to build a server-side RPC layer)

GWT Designer, a visual UI layout tool that generates code for the Swing-like UI framework

UiBinder, a system for declarative UI (you define layout in files that are essentially XHTML interspersed with GWT widgets, with named elements automatically bound to fields in a companion Java class)

Plugins for Eclipse, Maven, and Ant that help with creating, building, testing, and debugging GWT applications

The compiler itself is fundamental to any usage of GWT. Everything that follows is optional: you can take it or leave it, mix and match, use third-party alternatives, or invent your own replacements.

And what isn't GWT?

Now that we've listed off the highlights of what is included in GWT, it's important to address what it's not:

GWT doesn't mandate a single, prescribed way of creating user interfaces. In particular, you don't have to create UIs in a "Swing for the browser" mindset unless you want to.
GWT is not a server-centric system like JSF. Your GWT application compiles down to a collection of static files: HTML, CSS, images, and JavaScript. The application runs autonomously in the browser, communicating with the server only when it wants to. If you're not using GWT RPC, your apps need not be hosted on a Java web server.
GWT does not require any browser plugins. Your compiled app is just one or more standards-based web pages.
GWT does not prevent you from writing JavaScript directly. You can write inline JavaScript in your Java classes using JSNI, you can expose your Java APIs to JavaScript, and you can call JavaScript APIs from Java.
GWT is not a dead project. Rumours of its demise are greatly exaggerated.

If my GWT app just boils down to JavaScript and HTML, why bother with all this?

That's a great question. Thanks for asking. There are many compelling reasons to use GWT over raw HTML and JavaScript. I will address my favourite reasons in a future post, along with another question that I hope is burning in your mind: if GWT does all this, what does Errai add to the mix?

Errai 1.3.0.GA released!

2011-10-17T08:18:00.000-07:00

The Errai team is proud to announce the release of 1.3.0.GA. This is the final 1.3.0 release and includes improvements and fixes based on community feedback. We would like to thank the Errai community for raising questions, suggesting improvements and reporting problems. Please stay tuned, there's a lot more to come in the near future.

Furthermore, Mike Brock's hard work and epic late-night battle with the Maven Release Plugin (which he demonstrably won) deserves a big thank you from the rest of the Errai team (Jonathan Fuerth and myself).

JAX-RS in GWT with Errai

2011-10-04T15:43:00.000-07:00

The JAX-RS integration module is our latest extension to the Errai Framework. It brings another enterprise standard to the browser and simplifies the integration of REST-based services in GWT client applications.

How does it work?

To jump right in, let's assume we have the following JAX-RS interface which we want our clients to send requests to:

@Path("customers")

public interface CustomerService {

@GET

@Produces("application/json")

public List<Customer> listAllCustomers();

@POST

@Consumes("application/json")

@Produces("text/plain")

public long createCustomer(Customer customer);

@PUT

@Path("/{id}")

@Consumes("application/json")

@Produces("application/json")

public Customer updateCustomer(@PathParam("id") long id, Customer customer);

@DELETE

@Path("/{id}")

public void deleteCustomer(@PathParam("id") long id);

@GET

@Path("/{id}")

@Produces("application/json")

public Customer retrieveCustomerById(@PathParam("id") long id);

}

We simply put this interface somewhere in our client packages (e.g. client.shared) where the GWT compiler can find it. To create a request all that needs to be done is to invoke RestClient.create(), thereby providing the JAX-RS interface, a response callback and to invoke the corresponding interface method.

@EntryPoint

public class App {

...

final RemoteCallback<Long> callback = new RemoteCallback<Long>() {

public void callback(Long id) {

Window.alert("Customer created with ID: " + id);

}

};

@PostConstruct

public void init() {

final Button create = new Button("Create", new ClickHandler() {

public void onClick(ClickEvent clickEvent) {

Customer customer = new Customer(firstName, lastName, postalCode);

RestClient.create(CustomerService.class, callback).createCustomer(customer);

}

});

...

}

Error Handling

For handling errors, the existing error callback mechanism can be reused and the error callback can be passed to the RestClient.create() call. The ResponseException provides access to the Response object containing all details of the underlying HTTP response.

final ErrorCallback errorCallback = new ErrorCallback() {

public boolean error(Message message, Throwable throwable) {

try {

throw throwable;

}

catch (ResponseException e) {

Response response = e.getResponse();

// process unexpected response

response.getStatusCode();

}
catch (Throwable t) {

// process unexpected error (e.g. a network problem)

}

return false;

}

};

What does this buy you?

Errai will take care of generating the HTTP request logic for you and will automatically serialize/deserialize your method parameters. This helps alleviating boilerplate code for creating the URL, setting the HTTP headers, parsing the response, etc. By default, Errai's wire format will be used, but don't be dissuaded by that fact. Errai's wire format really is just simple JSON.

Future work

We are currently improving Errai's marshalling capabilities. One outcome of this will be a mechanism for pluggable custom serializers. So in the near future you will have the flexibility to choose your serialization format.

Interested and want to give it a try?

We have prepared a maven archetype, which generates a working JAX-RS CRUD application: https://docs.jboss.org/author/display/ERRAI/JAX-RS+Quickstart+Guide

This should help getting you started quickly.

As always, feedback is welcome and appreciated!

Welcome Jonathan Fuerth

2011-09-10T08:14:00.001-07:00

On behalf of the Errai team and the rest of Red Hat, and JBoss, I would like to extend my warm welcome to Jonathan Fuerth who joins the team, right here in Toronto.

Jonathan has an extensive background in software engineering, and has been actively involved in open source Java development for years, as well as being a community builder here in the Toronto area as a co-organizer of the Toronto Java User's Group.

Expect to here more from Jonathan in the coming weeks and months, right here in this space.

Speaking at FOSSLC: SC2011 Ottawa

2011-08-26T15:00:00.000-07:00

If you're in the Ottawa area, stop by and check out my Errai talk at FOSSCL's Software Developers' Haven on Saturday August 27th.

You can find details here: http://fosslc.org/drupal/sc2011

I'll also be hanging around for beers and talk afterwards.

Errai 1.3 CR1

2011-08-25T13:53:00.000-07:00

We're almost there. Today we have release Errai 1.3 Candidate Release 1. There's no new features to talk about since the beta release, of course. But the bug fixes are in, and we're excited to be closing in on the final!

Errai 1.3 Beta is Here!

2011-08-05T11:42:00.000-07:00

About four months of hardcore, heads down work, I am pleased to announce the first official beta release of Errai 1.3. Don’t be dissuaded by the relatively small increment to the version number -- this is a big release!

The number one philosophy of Errai is to erase boilerplate and bring the power of server-side programming to the browser. In 1.3, we’ve made great strides in this area.

The Enterprise

First and foremost, much of our efforts have been focused on our Errai enterprise integration around Java EE6 technologies. We wanted more than just dependency-injection in the browser, we wanted the full power of CDI in the browser. And while we still fall short of 100% of the CDI specification being implemented, we have managed to implement a significant footprint of the specification.

A big priority for 1.3 was making the CDI integration even more invisible. So, if you’re going to do CDI in the browser, than it should be against the standard APIs. So, gone if the old client Event interface, and in is use of the javax.enterprise.event.Event interface for CDI events.

Qualifiers for events and injection are now fully supported in Errai client code. And even for server-client events, in both directions!

We also now have support for CDI Producers and private-method PostConstructs.

The Framework

Implementing the aforementioned requires a lot of framework infrastructure. So we went back to the drawing board and revisited the way in which Errai generates code. And in so doing, we implemented a brand new class meta model, which completely abstracts away the GWT generator API, and we then implemented our core IOC engine on top of it. The end result is all the ridiculously awesome stuff we’re doing with CDI!

This new code generation framework, forms the basis for how we foresee going forward and implementing integration for more of the EE6 stack, as well as other great technologies like Infinispan, for instance.

Our latest team member to join, Christian Sadilek, has put a lot of effort into developing our test harness and getting our test coverage up to a respectable level, and I think that will pay dividends in the quality of this release as well as future releases.

The Docs

We are renovating our documentation. And we’ve already done a lot. But there’s more to do. For the latest docs -- which we’ll be updating frequently in the coming weeks -- please check out or Confluence Wiki here.

The Archetype

To get started with Errai SE, you can run this command right now:



mvn archetype:generate \

-DarchetypeGroupId=org.jboss.errai.archetypes \

-DarchetypeArtifactId=bus-quickstart \

-DarchetypeVersion=1.3.0-SNAPSHOT \

-DarchetypeRepository=https://repository.jboss.org/nexus/content/repositories/snapshots/

To get started with Errai EE, you can run this command right now:



mvn archetype:generate \

-DarchetypeGroupId=org.jboss.errai.archetypes \

-DarchetypeArtifactId=cdi-quickstart \

-DarchetypeVersion=1.3.0-SNAPSHOT \

-DarchetypeRepository=https://repository.jboss.org/nexus/content/repositories/snapshots/

….
The Downloads

If you’re allergic to Maven, our downloads page is here: http://www.jboss.org/errai/Downloads

Also, expect an awesome Forge plugin to be on the horizon -- especially considering that I co-founded that project (I know, I know… it’s embarrassing that i don’t have a plugin yet. But i’m a busy guy!)

The Future

We are only at the beginning. We expect to add a third team member in the next few weeks, and we are working closely with other JBoss projects, like Seam and RichFaces to expand the reach of the benefits which we bring to the JBoss web technology ecosystem.

Since we’re a framework which looks so heavily to the power of the browser, you can expect that over the next few months, our focus will shift intensely to leveraging the scope of capabilities that HTML5 brings to the table for developing rich applications.

Our ideas are vast, and we hope to share them with you going forward. So stay tuned.

The Gratitude

Thank you for everyone in the community who has given us feedback, reported bugs and supported us. Thanks to Heiko Braun for helping to get this project off the ground, and we’ll miss him as he moves on to work on other things. Thanks to Christian Sadilek for coming out of left-field and being incredibly awesome in every way. Thanks to Rodney Russ for being the world’s awesomest manager. Thanks to Mark Little for supporting all this from day one. Thanks to Dan Allen for his evangelization. Thanks to Pete Muir for his support. Thanks to Lincoln Baxter, Jay Balunas, and Shane Bryzak! And thanks to you for reading this.

Pervasive CDI: Errai at the JBoss World Keynote

2011-06-21T10:31:00.000-07:00

JBoss World kicked off with a real cool keynote presentation which represented a confluence of JBoss’s cutting-edge technology.

The demo brought together JBoss AS, Infinispan, HibernateOGM, CDI and Errai.

Of course, our little part of the presentation was the demonstration of Errai powering a real-time tag cloud which really brought home the concept of the "real-time web"; most certainly not something which hasn’t been done before, but it was how we did it that makes it interesting.

I'm not going to rehash too much of what has already been said in the aforementioned blog posts, and I highly recommend you click the hyperlinks and check them out. Instead, I'm going to talk about CDI and Errai.

CDI is a technology we’re pushing really aggressively at JBoss, and Errai is no exception. In fact, we’re relatively sure that we’re the one and only in-browser CDI engine.

It was only natural we’d want to show this off at JBoss World. And that we did.

The demo involved bringing in a live tweet stream from Twitter and then producing real-time information based on what hashtags were most popular. The key was to have a fully dynamic tag cloud which would be updated the instant that the information was available. And as such, we used Errai’s push technology to display the information to every browser simultaneously and in real time.

CDI in the Browser

So what does CDI in the browser look like? Well, this might come as a shock: it looks exactly as it does in your server-side code. Consider the following server code:

@ApplicationScoped public class MyService { @Inject @Updated private <>Event updatedTagEvent; ... }

And now consider the following client GWT code:

public void onTagUpdated(@Observes @Updated Tag tag) { System.out.println("Tag was updated: " + tag) }

In the former code snipped we setup a CDI event consumer, and in the latter, we setup a CDI event observer. Believe it or not, that’s pretty much everything you need to know about push messaging with Errai CDI.

In fact, this is exactly how our tag cloud was updated. Using our transparent push mechanism, serialization and bus framework, all of the boilerplate associated with doing “push” is eliminated.

Yes, it’s that cool. I’m not going to show you a bunch of XML , property or boilerplate class files because, well, there are none.

As a developer you simply want to think about your logic and your data. Utilizing Errai and CDI to build your rich web applications allows you to do just that.

How does it work?

Errai is very much a compile-time framework. In order to provide the runtime infrastructure to transparently communicate between browser code (written in GWT) and the server, we provide a significant amount of code generation to support functionality based on declarative configuration.

For instance, we provide a straight forward annotation, @ExposeEntity which effectively instructs Errai to produce marshaller and demarshaller wrappers -- ultimately compiled down to JavaScript -- for the entity.

The other aspect of Errai is a powerful messaging bus which, consistently with Errai’s “pervasive” theme, runs concurrently in the browser and on the server. As opposed to thinking about client vs server, we have aggressively pursued a flat architecture where the client and server APIs are common and shared. So there isn’t one way to write server code for Errai and another way to write client code.

This also provides the underlying application with transport agnosticism. That is to say, this only contract is between the bus APIs and the client code for all client-server communication. Or even more high-level in the case of Errai CDI, between the application and the CDI eventing system. This means the method of communication, be it WebSockets or COMET is invisible to the application. Developers no longer need to worry about the particularities of working with those technologies.

The future?

We think the future of the web is rich applications. But not only that pervasive applications. And the demo we showed at JBoss World which can be viewed here at about 35 minutes into the presentation is merely a taste of how powerful pervasive computing can be.

Latest enhancements to the Errai CDI integration module

2011-04-21T11:29:00.000-07:00

CDI event qualifiers

The Errai CDI integration module (see a previous blog post) has support for event qualifiers now, both for event producers and observers. Multiple qualifiers can be specified for an event and of course custom qualifiers can be used.

CDI conversations

The simple use of @Conversational allows a server to directly address a single client in response to an event.

BusReadyEvent

Clients can observe a BusReadyEvent to be notified when the CDI event system has been initialized and the message bus is ready to be used.

The example code below shows how to use these new features. Notice again the use of a uniform API on both the client and server. For more details on Errai's CDI support see the online documentation. Any feedback is appreciated!

@EntryPoint

public class SimpleDocumentClient extends LayoutPanel {

@Inject

private Event<DocumentSubscription> documentSubscriptionEvent;

@Inject @Published

private Event<Document> publishedDocumentEvent;

public void buildUI(@Observes BusReadyEvent busReadyEvent) {

documentSubscriptionEvent.fire(new DocumentSubscription());

// ...

new Button().addClickHandler(new ClickHandler() {

public void onClick(ClickEvent event) {

publishedDocumentEvent.fire(new Document());

}

});

}

public void onDocumentsReceived(@Observes Documents document) {

// this event is received as a direct response to the subscription event

// ...

}

public void onDocumentCreated(@Observes @New Document document) {

// ...

}

public void onDocumentUpdated(@Observes @Updated Document document) {

// ...

}

public void onDocumentDeleted(@Observes @Deleted Document document) {

// ...

}

@ApplicationScoped

public class SimpleDocumentService {

@Inject

private Event<Documents> subscriptionResponseEvent;

@Inject @New

private Event<Document> documentCreatedEvent;

@Inject @Updated

private Event<Document> documentUpdatedEvent;

@Inject @Deleted

private Event<Document> documentDeletedEvent;

@Conversational

public void onDocumentSubscription(@Observes DocumentSubscription subscription) {

Documents documents = new Documents();

//...

// respond to the client directly

subscriptionResponseEvent.fire(documents);

}

public void onDocumentPublished(@Observes @Published Document document) {

// receive document published events from the clients

//...

}

private void createDocument(Document document) {

// ...

documentCreatedEvent.fire(document);

}

private void updateDocument(Document document) {

// ...

documentUpdatedEvent.fire(document);

}

private void deleteDocument(Document document) {

// ...

documentDeletedEvent.fire(document);

}

Errai 1.2 released.

2011-03-24T11:32:00.000-07:00

I am pleased to announce the public release of Errai 1.2. This is a maintenance release on Errai, with big fixes, better support for CDI integration and so on.

Existing users of Errai 1.1 should be able to directly upgrade to 1.2.

We have recently expanded our team and we plan on aggressively pushing the project in new and exciting directions going forward. So please check this space often. There's a lot in the offing.

Community Asylum Podcast

2010-10-19T05:32:00.000-07:00

This time we got Heiko and Pete talking with us about JUDCon Berlin and Heiko's work on the Errai project.

As usual we also cover short news from the JBoss Community, but if you've wondered what Errai actually is and what it brings to the table then take a listen from about 30 minutes in, Heiko outlines it all in this episode.

Get it here

Slides from JUDCon Berlin

2010-10-16T04:21:00.001-07:00

"Errai offers a set of components for building rich web applications using The Google Web Toolkit. The framework provides a unified federation and RPC infrastructure with true, uniform, asynchronous messaging across the client and server.

It extends the Google Web Toolkit in two distinct areas:

- True asynchronous bi-directional communication between GWT clients and backend systems
- Integration with enterprise component models and technologies.

In this session we'll look at CDI integration module. It offers seamless integration of CDI backend components with GWT client applications. Build as an extension to the Errai core framework, it allows you to transparently access CDI beans while harnessing the power of the core framework.

Beans that are deployed to a CDI container (i.e. JBoss 6) will automatically be registered with Errai and exposed to your GWT client application. Communication between GWT client components and CDI beans can be done in several ways:

- RPC style invocations on beans through a typed interface
- Access beans in a publish/subscribe manner
- Wiring up your GWT application with the CDI event subsystem

After this session you should have a good idea about the core framework capabilities and CDI integration in particular."

Gwt cdi jud_con_berlin

View more presentations from hbraun.

Errai at JUDCon Berlin, October 2010

2010-09-23T01:35:00.000-07:00

We'll be presenting Errai at the JBoss Developer Conference in Berlin next month.
Besides the core framework features we'll take a particular look at the CDI integration capabilities.
Bring your laptops, because we'll wait for you at the hackfest Thursday night.

More information here

Enjoy the benefits of the Java EE 6 component model using GWT as an alternative view layer technology.

2010-08-19T03:11:00.000-07:00

The CDI integration module offers seamless integration of CDI backend components with GWT client applications. Build as an extension to the Errai core framework, it allows you to transparently access CDI beans while harnessing the power of the core framework.

Beans that are deployed to a CDI container (i.e. JBoss 6) will automatically be registered with Errai and exposed to your GWT client application. Communication between GWT client components and CDI beans can be done in several ways:

RPC style invocations on beans through a typed interface
Access beans in a publish/subscribe manner
Wiring up your GWT application with the CDI event subsystem

RPC Style Invocations
When chosing RPC style invocations on beans, you basically rely on a typed java interface the CDI managed bean needs to expose. A GWT client component can then create an invocation proxy based on this interface. For more information see chapter on RPC mechanism.

Publish/Subscribe with CDI managed components
If you chose publish/subscribe then your CDI bean needs to implement the MessageCallback interface, as described in chapter 'Messaging'. Any bean exposed in this way can be accessed through the MessageBuilder API.

Integration with the CDI event subsystem
Any CDI managed component may produce and consume events. This allows beans to interact in a completely decoupled fashion. Beans consume events by registering for a particular event type and qualifier. The Errai CDI extension simply extends this concept into the client tier. A GWT client application can simply register an Observer for a particular event type and thus receive events that are produced on the server side. Likewise GWT clients can produce events that are consumed by a server side component.

Let's take a look at an example GWT component:


public class FraudClient extends LayoutPanel {

@Inject
public Event event;                                    (1)

private HTML responsePanel;

public FraudClient() {
  super(new BoxLayout(BoxLayout.Orientation.VERTICAL));

  Button button = new Button("Create activity", new ClickHandler() {
    public void onClick(ClickEvent clickEvent) {
      event.fire(new AccountActivity());
    }
  });

  responsePanel = new HTML();

  add(button);
  add(responsePanel);
}


public void processFraud(@Observes Fraud fraudEvent) { (2)
  responsePanel.setText("Fraud detected: " + fraudEvent.getTimestamp());
}
}

Two things are notable in this example:

Injection of an event dispatcher proxy
Creation of an Oberserver method for a particular event type

Event dispatcher proxy

The event dispatcher is responsible to send events created on the client side to the server side event subsystem (CDI container). This means any event that is fired through a dispatcher will eventually be consumed by a CDI managed bean. If there is an Observer registered for it on the server side.

Client side observer methods
In order to consume events that are created on the server side you need to declare an Observer method for a particular event type. In case an event is fired on the server side this method will be invoked with an event instance of the type you declared.

To complete this exercise, let's look at the corresponding CDI managed bean as well:


@ApplicationScoped
public class AccountService {
  @Inject @Any
  Event event;

  public void watchActivity(@Observes @Inbound AccountActivity activity) {
      Fraud payload = new Fraud(System.currentTimeMillis());
      event.fire(new Outbound(payload));
  }
}

Whetting your appetite? Here are some links to get you going:

"Fueling the rocket" - Approaching 1.1-Final

2010-08-19T02:14:00.000-07:00

Ready for lift-off? The 1.1 Candidate Release has been released today. We got plenty of goodies baked into this one:

Serialization
Plenty of bugfixes and performance improvements.
Up to 40% performance gain and a much better memory footprint.
Deployment
Complete replacement for the meta data facilities and deployment hooks. This a fixes a lot of problems with nested deployment artifacts (i.e. WAR inside EAR)
Monitoring
Improvement activity monitoring tools. Added capabilities to query for certain message types/payload patterns.
CDI Integration
Seamless integration of CDI backend components with GWT client applications.
And much more ...
Check the Userguide for a complete reference of new features.

Download it now.
Browse the Userguide.
Get the sources.

Have fun,
the Errai Team

Image from "Fortress on a Skyhook" written and illustrated by Frank Tinsley, Mechanix Illustrated April, 1949

Dependency Injection in the Browser!

2010-07-19T09:56:00.000-07:00

One of the things that will be coming in Errai 1.1 is our new IOC module which provides a dependency injection framework, based on JSR-330 in the browser. Now, this is not just Gin packaged with Errai. Rather, it's an implementation which has been built specifically to intermix with Errai's code generation infrastructure and provide a boiler-plate free experience.

When we release 1.1, gone will be the days of having to access the bus or the dispatchers through static factories. Rather, your client-side code will look even more like your server-side code.

Check out our new HelloWorld example built atop our new DIfoundations.

@EntryPoint @Service public class HelloWorld extends VerticalPanel implements MessageCallback { private Button sayHello; private Label label; private MessageBus bus; @Inject public HelloWorld(MessageBus bus) { this.bus = bus; } public void callback(Message message) { label.setText(SimpleMessage.get(message)); } @PostConstruct public void init() { sayHello = new Button("Say Hello!"); /** * Register click handler. */ sayHello.addClickHandler(new ClickHandler() { public void onClick(ClickEvent event) { MessageBuilder.createMessage() .toSubject("HelloWorldService") .with(MessageParts.ReplyTo, "HelloWorld") .done().sendNowWith(bus); } }); label = new Label(); add(sayHello); add(label); RootPanel.get().add(this); } }

Notice use of the @EntryPoint annotation. When you use @EntryPoint you don't need to implement your own GWT EntryPoint class, we build that for you.

You're probably already wondering if you can provide your own arbitrary providers to inject custom services, widgets and other components. And the answer is yes. We've provided a simple Provider interface that you can annotate to be discovered by the container at compile time to provide an injectable dependency. In fact both MessageBus and RequestDispatcher plug-in using this mechanism. Here's the provider for MessageBus:

@Provider @Singleton public class MessageBusProvider implements TypeProvider<MessageBus> { public MessageBus provide() { return ErraiBus.get(); } }

Pretty cool, huh? Doing more sophisticated things requires tying into the code generator which is used to generate the wiring code, and there will be documentation on how to do that. But the code generation interfaces will be surprisingly easy to use if you want to do anything particularly advanced, such as provide custom annotations for the container to process during the bootstrap process.

This is just one of the many cool features coming to Errai 1.1. Stay tuned for more!

GWT, CDI and Errai at Jazoon

2010-05-30T08:47:00.000-07:00

If you happen to be at Jazoon this year and you are interested in GWT, CDI and Errai then these sessions may be interesting to you:

Patterns and Best Practices for building large GWT applications
Tuesday, 1 June 2010, 14:00-14:50, Arena 3

In this presentation we’ll see how to organize a nontrivial GWT application. We’ll go through the lessons learned in a real world project and take a look the complete development lifecycle and best practices that go beyond what GWT has to offer out-of-the-box. This talk does focus on modularity of GWT applications and how to overcome the burdens of compile-time linking. We’ll talk about client side patterns and server side implementation options and explore different approaches that allow for quick turn around times without sacrificing maintainability.

GWT, CDI and JAX-RS: A match made in heaven
Tuesday, 1 June 2010, 15:00-15:50, Arena 3

Every non-trivial GWT application requires integration with the server side. While GWT itself ships with the integration capabilities (i.e GWT RPC) it doesn't go beyond that. Developers have to decide how to build the backend to their GWT applications. While freedom of choice is a good thing, it doesn’t always lead to a good decision. In this session we’ll look at two options, JSR-299 [1] and JSR-311 [2], both part of the EE6 specification and see how they interplay with GWT. We'll discuss the use cases and justifications for each technology see how they are applied in practice by looking at some code examples.

[1] JSR-299: Java Contexts and Dependency Injection for the Java EE platform (CDI) is the new Java standard for dependency injection and contextual lifecycle management.

[2] JSR-311: A that specification defines a set of Java APIs for the development of Web services built according to the Representational State Transfer[1] (REST) architectural style.

Gwt cdi jaxrs_hbraun

View more presentations from hbraun.

The complete schedule can be found here.

Hello, 1.1 Milestone 1!

2010-05-12T11:59:00.000-07:00

Today, we’re pleased to announce our first step towards version 1.1, which sets us solidly on a course with 1.1 destiny.

This milestone release is a big step towards honing the concepts that we introduced in 1.0, driving someone them towards their logical conclusions, and smoothing out the rough edges. Community feedback was important to us, and we’ve worked diligently to respond to it.

This release brings a range of new features, including (but not limited to):

* Support for more servlet containers.
* New Async Task API
* A new bus monitor to make troubleshooting easier
* A new RPC API, that leverages the bus architecture, and provides an alternative to GWT-RPC.
* Better error handling.
* Better documentation.
* Bug fixes galore!

We think you should take a look. And we hope you have as much fun using it as we did building it.

Remember, Errai is always looking for community contributions. So if you’re interested in becoming a contributor, drop us a line. Download it before it gets cold.

Best Practices

2010-05-05T10:41:00.000-07:00

Fellow JBoss core developer, and lead engineer for JBoss's security initiatives, Anil Saldhana took a deep dive into Errai in recent weeks, and he's documented some best practices here.

He offers some valuable advice worth checking out.

Introducing new asynchronous task APIs

2010-04-25T18:33:00.000-07:00

One of the things that we've come to realize while developing Errai is that when you work with a framework such as Errai, where push messaging is basically free, easy and awesome -- you end up wanting to do things like stream live data across the wire. Stuff like stock quotes, news feeds, twitter feeds, clocks, weather patterns, and the migration activity of pigeons.

A lot of our demos have involved creating threads and pushing data across completely asynchronously. And it's always messy code. You need to worry about managing those threads, making sure they die when the session dies, or when the subject is unsubscribed, etc. Having to worry about all this creates security problems, resource management issues, and it makes your code messy.

Well, worry no longer! The latest commit into trunk introduces a new comprehensive (and simple) way of creating asynchronously running tasks -- as part of the the standard MessageBuilder API.

Take our TimeDisplay demo, where we stream a bunch of updates from the server to the client containing System.currentTimeMillis() results.

Up until now, the demo consisted of a thread that looped around and around and built new messages to send. Through the addition of a new API extensions, this demo is greatly simplified.

The first addition is some helper classes that help you create managed contexts to store stuff in the session. One is called SessionContext, and the other is called LocalContext. SessionContext allows you to create session scoped attributes, and LocalContext lets you create locally-scoped, as in, page-scoped. So if a user has multiple browser windows open, or multiple tabs, each window or tab is it's own LocalContext. This is a pretty powerful little tool.

The second addition is the implementation of what I'm calling provided message parts. Unlike regular message parts, these parts are resolved via providers at the time of transmission. This is a key aspect of what we're about to show below, as it creates message re-usability.

The third addition is the implementation of a repeating and delayed message transmission calls as part of the standard messaging API.

Let's take a look at the example:

AsyncTask task = MessageBuilder.createConversation(message) .toSubject("TimeChannel").signalling() .withProvided(TimeServerParts.TimeString, new <>ResourceProvider() { public String get() { return String.valueOf(System.currentTimeMillis()); } }).noErrorHandling().replyRepeating(TimeUnit.MILLISECONDS, 100);

In this example, we create a conversational message which replies not just once, but replies continuously. Once every 100 milliseconds as it would turn out. The replyRepeating() and replyDelayed(), sendRepeating() and sendDelayed() methods all return an instance of AsyncTask, which is a handle on the task being performed. You can use this object to cancel the task.

Doing so is pretty easy.

task.cancel(true)

Knowing all this, which isn't very much -- and that's the cool part -- let's put it all together:

@Service("TimeServer") @RequireAuthentication public class TimeDisplay implements MessageCallback { private MessageBus bus; @Inject public TimeDisplay(MessageBus bus) { this.bus = bus; } public void callback(final Message message) { if (message.getCommandType() == null) return; /** * Create a local context to store state that is unique to this client instance. (not session wide). */ final LocalContext context = LocalContext.get(message); /** * Switch on the TimeServerCommand type provided */ switch (TimeServerCommands.valueOf(message.getCommandType())) { case Start: /** * We want to start streaming. */ AsyncTask task = MessageBuilder.createConversation(message) .toSubject("TimeChannel").signalling() .withProvided(TimeServerParts.TimeString, new <>ResourceProvider() { public String get() { return String.valueOf(System.currentTimeMillis()); } }).noErrorHandling().replyRepeating(TimeUnit.MILLISECONDS, 100); /** * Store the task as an attribute uniquely identified by it's class type. */ context.setAttribute(AsyncTask.class, task); /** * Create a listener that will kill the task gracefully if the subject is unsubscribed. This * isn't 100% necessary, as the task will be auto-killed ungracefully. But this provides * and opportunity to clean up after ourselves. */ bus.addUnsubscribeListener(new UnsubscribeListener() { public void onUnsubscribe(SubscriptionEvent event) { if ("TimeChannel".equals(event.getSubject())) { /** * Delete this listener after this execution. */ event.setDisposeListener(true); /** * Stop the task from running. */ context.getAttribute(AsyncTask.class).cancel(true); /** * Destroy the local context. Sort of unnecessary, but helps reduce memory usage. */ context.destroy(); } } }); break; case Stop: /** * Access our stored AsyncTask from this instance and cancel it. */ context.getAttribute(AsyncTask.class).cancel(true); /** * Destroy the local context. Sort of unnecessary, but helps reduce memory usage. */ context.destroy(); break; } } }

That's all there is to it. It's pretty sweet. This API works on both the client and the server side. All the thread scheduling is all transparently managed by an executor service on the server, and by a simple Timer based implementation in the client. I'm hoping people will find this a welcome addition to Errai-land.

There will be more details coming as I iron out the bugs. This code is all new, so proceed at your own risk and all that stuff.

Errai goes Berlin, 27.04 FU-Berlin, Informatik Institut‎

2010-04-20T05:56:00.000-07:00

I will be speaking about Errai in Berlin next week:

http://www.xing.com/events/patterns-and-best-practices-for-building-large-gwt-applications-496953

If you are around, make sure to stop by.

Heiko

Visual Bus Monitor

2010-03-29T13:23:00.000-07:00

For the past few weeks, I've been focusing on seeing how we can improve the development / debugging experience with ErraiBus. The biggest component of this, is our new Swing-based ErraiBus Monitor application.

It's really straight-forward to get up and running.

You simply add it as a runtime dependency, and bootstrap GWT Development Mode with the -Derrai.tools.bus_monitor_attach=true VM flag, and this magical UI should automatically appear as ErraiBus bootstraps.

When the monitor is activated, it attaches probes in into the bus and records all activity accordingly. You can drill down into individual services and examine individual messages that have been received to debug any mysterious problems that arise.

There will be more details to come as I firm up the tool, but I thought I'd share my progress with the community since Heiko says I don't blog enough :)

What is Errai Workspaces and what can be used for?

2010-03-09T10:17:00.001-08:00

Errai Workspaces

View more presentations from hbraun.

Errai-Seam integration: Student projects

2010-03-05T01:41:00.000-08:00

The seam team is offering a range of student projects related that aim at improving the integration with Errai. I.e:

"Errai is a new project from JBoss.org, aiming to ease building GWT applications. Errai provides a bus which is used to communicate either from client to client or client to server. To build an Errai based application, you are likely to want to communicate with services on the server. CDI's services (and the integrations it offers with Java EE technologies as well as it's extension ecosystem) should be available for use here. A particular challenge here is to provide a mapping between the type safe injection facilities of CDI in pure Java code, and the compiled Java to Javascript that GWT produces."

More information can be found here

Errai 1.0!

2010-03-02T10:39:00.000-08:00

I am pleased to announce our 1.0 Release of the Errai Framework. It rounds out the first stepping stone in our journey towards building a truly innovative way to build next-generation web applications.

I would like to thank the entire team for their hard work on this: Heiko Braun, Lillian Angel, Rodney Russ, and myself for contributing to getting us to this goal.

We'd especially like to thank our early adopters who helped us work out the kinks, report bugs, and make us aware of what the community needs.

Some of the important highlights and milestone of this release include:

- Async IO support in ErraiBus for Apache Tomcat, JBoss AS, and Jetty. As well as standard synchronous IO support for all servlet containers.
- Easy to use homogeneous programming model that permeates both the server and client.
- Initial public release of our Workspaces RAD console/app framework.

Version 1.1, which will be released in the coming weeks will add support for Glassfish, WebLogic and WebSphere.

We encourage anybody interested in contributing to contact us on our mailing lists. For more information on Errai, check our main project website here: http://www.jboss.org/errai

Mission Control: Prepare for landing

2010-02-19T05:34:00.000-08:00

I am glad to announce that we've begun preparing the 1.0 release of Errai:
http://anonsvn.jboss.org/repos/errai/branches/errai-1.0.x/

(Image courtesey of CBSNEWS)

We will add another round of QA during the next week and polish our documentation. If you are an early adopter, this would be a good time to tell us what problems you experience. So make sure to file your bugs and let us now through the mailing list.

Errai at the JUG Toronto @ 18.0.2010

2010-02-17T07:13:00.000-08:00

Mike Brock will be presenting Errai at the Toronto Java User's Group on Thursday, February 18th at the Free Time Cafe (320 College St, Toronto). Details here.

Errai at the Java User Group Zurich, Switzerland

2010-02-17T07:08:00.000-08:00

Heiko will be talking about Errai in Zurich at the 2.3.2010:

Patterns and Best Practices for building large GWT applications

In this presentation weʼll see how to organize a nontrivial GWT application. Weʼll go through the lessons learned in a real world project and take a look the complete development lifecycle and best practices that go beyond what GWT has to offer out-of-the-box. This talk does focus on modularity of GWT applications and how to overcome the burdens of compile-time linking. Weʼll talk about client side patterns and server side implementation options and explore different approaches that allow for quick turn around times without sacriﬁcing maintainability.

Travel details can be found here:
http://www.jugs.ch/html/events.html

Jug Zurich Slides

View more presentations from hbraun.

Integrating Errai with Weld (CDI), Part 1

2009-12-08T04:37:00.000-08:00

While GWT is strong on the client side it doesn't provide any server side programming models. There is GWT RPC, but that's merely an integration layer. We've been discussing various options within the Errai team, looking for some best practice recommendations. In this article we'll look into CDI, which is part of the EE6 specification and offers a concise, easy to use programming model.

In the first part of this series, we'll focus on the CDI Event API and see how it integrates with Errai Bus.

Some knowledge about Errai Bus and GWT is recommended before reading any further. If you don't know about the Bus and it's purpose, then checkout the project page first.

Creating a CDI event consumer

To begin with, we'll create a simple CDI component that listens on paticular event types:


@ApplicationScoped
public class EchoService
{  
  @Inject
  BeanManager beanManager;

  public void echo(@Observes EchoRequest message)
  {
    String replyText = message.getMessageText() + " Response";
    
    beanManager.fireEvent(
        new EchoResponse(replyText),
        new ErraiBusQualifier()
    );
  }

}

In this example the echo(...) operation will be invoked on any occurance of an event type EchoRequest. It will create an EchoResponse event type and dispatch it through the BeanManager.

A simple GWT client

Now that we've got our server side component implementation, it's time to look at the GWT client. The client component basically needs to do two things:

Fire events that will ultimately invoke our server side component
Listen to events that are send in response

Create an event producer
We keep it simple and fire event when a button is clicked:


Button b = new Button("Send", new ClickHandler()
    {
      public void onClick(ClickEvent clickEvent)
      {
        CommandMessage.create(WeldCommands.WELD_EVENT)
            .toSubject("weldDispatcher")
            .set(WeldProtocol.TYPE, EchoRequest.class.getName())
            .set(WeldProtocol.OBJECT_REF, 
                    new EchoRequest("Message from client"))
            .sendNowWith(bus);
      }
    });

Register a listener for response messages:


 MessageBus.subscribe("echoClient",  // local endpoint
        new MessageCallback()
        {
          public void callback(CommandMessage message)
          {
                [...]
          }
        }
    );

In this case, we've create a listener that will receive messages that are send to the subject "echoClient".

Great, now we have a GWT event producer that sends messages through Errai Bus and we've created a CDI event consumer that listens on the internal CDI event subsystem. But how do we introduce them to each other?

Bridge between Errai Bus and the CDI Event Subsystem
If you carefully followed the example, you might have realized the event producer sends messages to a subject called "weldDispatcher". Actually this is an Errai server side service consuming messages send from a GWT client. That means any message put on the Bus that addresses this particular subject will be directed to a service that is registered to this subject:


@Service("weldDispatcher")
@ApplicationScoped
public class WeldDispatcher implements MessageCallback
{
  [...]
  
  // Invoked by Errai
  public void callback(CommandMessage message)
  {   
    try
    {
      switch (WeldCommands.valueOf(message.getCommandType()))
      {
        case WELD_EVENT:
          String type = 
               message.get(String.class, WeldProtocol.TYPE);
          Class clazz = 
               getClass().getClassLoader().loadClass(type);
          Object o = message.get(clazz, WeldProtocol.OBJECT_REF);
          beanManager.fireEvent(o);
          break;
        default:
          throw new IllegalArgumentException(
             "Unknown command type "+message.getCommandType()
          );
      }
    }
    catch (Exception e)
    {
      throw new RuntimeException(
            "Failed to dispatch Weld Event", e
      );
    }
  }

  // Invoked by Weld Event producer
  public void sendMessage(@Observes @ErraiBus Object message)
  {
      String subject = null;
      ErraiBus busAnnotation = 
          message.getClass().getAnnotation(ErraiBus.class);
      if(busAnnotation!=null)
        subject = busAnnotation.subject();

      assert subject!=null : "Missing subject declaration";

      // put on the bus
      CommandMessage.create(WeldCommands.WELD_EVENT)
          .toSubject(subject)
          .set(WeldProtocol.TYPE, message.getClass().getName())
          .set(WeldProtocol.OBJECT_REF, message)
          .sendNowWith(erraiBus);    
  }

  [...]
}

What's happening here?

The WeldDispatcher implementation acts a bridge between the Errai Bus and the CDI event subsystem. It does listen on messages in both directions and fowards the event message to the corresponding subsystem: either Errai Bus or CDI.

Receiving messages send from the client
When a messages is send to the "weldDispatcher" subject the callback(CommandMessage message) operation will be invoked. It umarshalls the the event type and forwards it to CDI using the BeanManager API:


String type = message.get(String.class, WeldProtocol.TYPE);
Class clazz = getClass().getClassLoader().loadClass(type);
Object o = message.get(clazz, WeldProtocol.OBJECT_REF);
beanManager.fireEvent(o);

Forwarding events produced on the server side
The CDI component that we've shown in the beginning of this article, fires EchoResponse events in response to it's invocation. These events are caught by a CDI ObserverMethod (sendMessage(@Observes @ErraiBus Object message)) that extracts the recipient subject, creates an Errai message and put's it on the bus:


CommandMessage.create(WeldCommands.WELD_EVENT)
          .toSubject(subject)
          .set(WeldProtocol.TYPE, message.getClass().getName())
          .set(WeldProtocol.OBJECT_REF, message)
          .sendNowWith(erraiBus);

Wrap up

That's it for today. To sum up, here's what we've shown in this example:

We've created a simple example that uses GWT on the client side.
It does leverage Errai Bus for integrating with the server side
We've used a CDI component on the server side to back our application
All communication is done asynchronously, using a bridge between Errai Bus and the CDI event subsystem

Stay tuned. More articles on Errai and CDI integration are following.

Update
More recent examples can be found here:
http://anonsvn.jboss.org/repos/errai/projects/weld-integration/trunk/

Community site launched

2009-10-14T00:13:00.000-07:00

We've just launched the Errai community site: http://www.jboss.org/errai

We are launching this community site early in the process to spark interest and engage the open source community.

For one, because we believe in what were doing, and we feel that the project is now at a point where it's time to branch out and join the greater OSS community and let our hard work finally see the light of day.

So, on behalf of the Errai Team, welcome!