Errai Framework

Thank you for all the feedback and bug reports in the last month. We have just released Errai 2.2.0.Final! Check out the release notes for all the details!Now we're all looking forward to get back into R&D mode and work on some exciting new ... [More] features for Errai 3. Stay tuned for updates on client-server data synchronization and more upcoming mobile features.Here's a screencast demoing the biggest new features in Errai 2.2: HTML5 templating, data binding, client-side JPA persistence. Also make sure to check out the new page navigation module!  Errai To-Do List from JBoss Developer on Vimeo. [Less]

Errai 3.0 development continues to move forward unabated. One new feature that I worked on today is something I've being pining for recently.When you're developing rich web apps, one thing you often find yourself working with are timers. They enable ... [More] animations and timeout logic in your application logic. But since Errai manages beans inside your browser, it seemed like an elegant solution that fits in nicely with other beany features was in order. Enter, the @Timed annotation!This example shows a method that is part of a bean, which we have annotated with the @Timed annotation. In this case we have configured the timer to fire every one second.You get all the benefits of working in a managed bean environment. For instance, when the bean is destroyed, so to is the timer, implicitly.Anyways, this just went directly into the Errai 3.0 branch, and if you want to play with it, get forking! [Less]

One common problem that keeps catching people off guard using Errai UI and its hip companion framework, Errai UI Navigation, has been that @Templated and @Page beans have required explicit-scoping in order to work correctly.It turns out that you ... [More] almost always want such beans to be of the @Dependent scope. But if you know a little bit about CDI, you might be saying to yourself: well, all non-explicitly scoped beans are of the @Dependent scope! Well, yes. This is true. But Errai throws a bit of a curve-ball here. Because while Errai respects this semantic when it comes to static injection, it does not respect it when it comes to dynamic injection / dynamic lookup.The reason for this is straight-forward. When Errai compiles your CDI code magically down to JavaScript (via the GWT compiler), it prunes all the bean wiring code from non-explicitly scoped beans. It does this as a way of minimizing the amount of dead code that ends up being compiled. So, for example, if we respected the CDI specification strictly, we'd end up having to create bean wiring code for things like ArrayList, HashMap, LinkedList, StringBuilder, etc.  Instead, we allow you to @Inject those dependent beans directly as you might in a fully compliant CDI container. But we don't produce the code to allow them to be dynamically produced at runtime.  So, for Errai, implicit dependent beans are a compile-time feature. Not a runtime feature.But wait! It turns out there's a common need to dynamically lookup @Dependent beans in Errai applications. Widgets, for instance, are more often than not, of the @Dependent scope. And many widgets you want to instantiate many times, dynamically. Which is a perfect fit for the @Dependent scope. So to allow you to overcome the limitation we impose, you can annotate your bean with a @Dependent annotation. This explicit scoping is treated as signal that you want to interact with the bean via the bean manager. And that's why you've had to explicitly scope all your @Templated and @Page beans up until now.But as it turns out, we've changed the rules. In the absence of an explicit scope, Errai will now consider the use of either of these two annotations to mean the same thing as an explicitly-scoped @Dependent bean.The good news is that this improvement will be directly available in the next 2.2 release. And in final.Hopefully this improvement makes your coding experience a little bit more pleasant. It has for us. [Less]

Christian and myself burned some midnight oil the past few days in order to get ErraiBus's new native clustering support up and running.Some of our users have been looking for this for some time as ErraiBus has been somewhat limited in clustered ... [More] environments and required the creation of JMS Queues and such to handle global broadcasts in a cluster.People wanted something that would "just work" without having to worry about the topology of user sessions relative to whatever random server a load balancer might move a user to.As I just mentioned, really smart engineers have managed to work around the limitation that each bus is not aware of any other buses in a cluster. And even then, it's only a problem for a certain class of applications. But the whole point of ErraiBus was to be stupid easy to use.Therefore, tonight in the 3.0 branch we committed a new ClusteringProvider implementation that leverages the ever-so-awesome JGroups.It's pretty easy to use for basic clustering scenarios. Basically you add the following two lines to the ErraiService.properties file.Yeah, that's about it. JGroups will startup with the bus and use multicast to find other buses.So if you're interested in testing it yourself, hurry on over to the 3.0 branch, give it a clone and build it with Maven. If that's too much work, don't worry, we'll have a pre-release coming very shortly. [Less]

Creating an application for mobile is challenging and GWT is very good to use in this space, because it optimises for the browser and keeps the downloads small. But still there is this big initial download that users of your application need to do ... [More] (all the html and javascript). Also if you are going to create a mobile application you want to be able to use the additional features that a phone has, in a convenient way. This is where Errai-Cordova comes in. As you can get from the name it uses Cordova to create an application that can be installed easily on mobile devices. Cordova is like a little web server and a web browser bundled into a mobile app. So now, when your application gets installed, the user will already have all of your front-end. To be able to use your backend you'll have to do some configuration. In the class org.jboss.errai.example.client.local.Config you need to specify the address of your backend server like so: Now you can create some responsive html and have it behave nicely on differently sized devices. I'm not that good in designing something that looks very nice, but there are some really nice things that you can make. Take a look at 2012.inspireconf.com and make your browser window smaller to simulate looking at this site with a phone or a tablet. Finally using the capabilities of the phone, like the camera or accelerometer, you can inject them in a true errai fashion. Take a look at the demo project on github for a working example. This is the sneak peak of what's to come, hope you like it! [Less]

Thanks for all the feedback on Errai 2.2.0.CR1. Over the past few weeks, we fixed all the reported issues, and now Errai 2.2.0.CR2 is ready for your consideration.Please try this latest release candidate as soon as possible, and let us know what you ... [More] think through any of the usual channels! We expect to make the final release of 2.2.0 in January.For an overview of the major changes since Errai 2.1, see the earlier post about 2.2.0.CR1. [Less]

Today marks the first candidate release for Errai 2.2.0. With this release, we're delivering dozens of fixes and enhancements. If we had to choose the three most important changes, they would be: the new client-side Bus Lifecycle API, addition of ... [More] state parameters to the Page Navigation framework, and the ability to nest bindable properties.While you're reading this, why not kick off a compile of your existing Errai project against the new release?Do it now! It only takes a couple of minutes to switch the version number in your pom.xml to 2.2.0.CR1. If you're not using Maven, grab the release bits from our download page.Seriously! We'll wait right here for you!Client-side Bus LifecycleWe've had questions over the years about how to find out exactly what the client-side message bus is up to: is it connected to the server? Is it attempting to reconnect? Has it given up and gone offline? Although there were ways to infer some of this information in the past, we decided it was time to make all of this information available in one place, and to make some guarantees about the order that these state transitions will happen in.The best way to dive into the new bus lifecycle API would be to check out the BusStatusWidget that we added to the bus-stress-test demo, but here's a quick teaser:class BusStatusLogger implements BusLifecycleListener {  @Override  public void busAssociating(BusLifecycleEvent e) {    GWT.log("Errai Bus trying to connect...");  }  @Override  public void busOnline(BusLifecycleEvent e) {    GWT.log("Errai Bus connected!");  }  @Override  public void busOffline(BusLifecycleEvent e) {    GWT.log("Errai Bus trying to connect...");  }  @Override  public void busDisassociating(BusLifecycleEvent e) {    GWT.log("Errai Bus going into local-only mode.");  }}To attach such a listener to the bus, just do the following in client-side code:ClientMessageBus bus = (ClientMessageBus) ErraiBus.get();bus.addLifecycleListener(new BusStatusLogger());Nested Bindable PropertiesWe got good feedback about the data binding module that we added in Errai 2.1, which lets you bind properties from your model objects to GWT widgets (actually, to anything that implements HasValue). As a refresher, imagine you have an Item class with name and department properties, and a Department class with a name property of its own:@Bindablepublic class Item {  private String name;  private Department department;  public String getName() { return name; }  public void setName(String name) { this.name = name; }  public Department getDepartment() { return department; }  public void setDepartment(Department department) { this.department = department; }}@Bindablepublic class Department {  private String name;  public String getName() { return name; }  public void setName(String name) { this.name = name; }}Then you can link the value of item.name to a TextBox like this (this annotation-driven approach is provided by Errai UI):@Templated("#main")public class ItemWidget extends Composite {  @Inject private @AutoBound DataBinder<Item> itemBinder;  @Inject private @Bound @DataField TextBox name;}This is great, but what about the department name? We want a TextBox for that too! It became apparent pretty quickly that this feature would be way better if you could dig into the object graph and bind to nested properties, the data binding feature would cover a lot more use cases. Now you can:@Templatedpublic class ItemWidget extends Composite {  @Inject private @AutoBound DataBinder<Item> itemBinder;  @Inject private @Bound @DataField TextBox name;  @Inject private @Bound(property="department.name") @DataField TextBox department;}That's it! The name of the Department object nested inside item will be kept in sync with the contents of the department textbox.State Parameters in Page NavigationThe last big enhancement we want to call out is the addition of extra parameters to the page navigation framework. Following from the previous example, say your ItemWidget is also a @Page:@Templated @Page("item")public class ItemWidget extends Composite {  @Inject private @AutoBound DataBinder<Item> itemBinder;  @Inject private @Bound @DataField TextBox name;  @Inject private @Bound(property="department.name") @DataField TextBox department;}That's great: you can bookmark that you were at http://myapp.mycompany.com/#item. But which item were you looking at? That's important!Now you can do this:@Templated @Page("item")public class ItemWidget extends Composite {  @Inject private @AutoBound DataBinder<Item> itemBinder;  @Inject private @Bound @DataField TextBox name;  @Inject private @Bound(property="department.name") @DataField TextBox department;  @PageState private int itemId;  @PageShowing  private void setupItem() {    itemBinder.setModel(findItem(itemId));  }}And presto! Your bookmarkable URL is now http://myapp.mycompany.com/#item;itemId=42.We hope to enhance the navigation framework even more in Errai 3.0. Your input has been invaluable so far. Keep it coming!On top of the three headliners, 2.2.0 CR1 includes 17 bug fixes and 10 enhancements/features across virtually every part of the framework. See the release notes for full details.Once again, I urge you to try your project against Errai 2.2.0.CR1 today! We truly believe this is the best and most stable release to date, so you have nothing to lose. And in the unlikely event that you do find a new issue, you'll be able to tell us before 2.2.0 goes final.Happy coding,The Errai Team [Less]

For the last month or so, I've been hiding in a cave working on a big, upcoming feature in Errai 3.0. Which may sound crazy considering that we have yet to release 2.2 yet. But that's how I roll.Well, it's more that this is a big feature, and we've ... [More] feature-frozen Errai 2.2 on its path to productization as part of JBoss's WFK product, of which Errai will be a featured framework next year. So, big new features are bound for 3.0.So what is this new feature? It is nothing other than the new asynchronous bean manager for Errai IOC/CDI! If you follow me on Twitter (@JBossMike) or on Google+, then you might have stumbled upon the highs and lows of my gargantuan effort to implement this.First the big questions: what is asynchronous bean management, and why do we need it?Asynchronous bean management may be an unfortunate term. Perhaps a more accurate name would be asynchronously-loading bean management. But I don't like how that sounds, so... the former it is!The basic idea behind asynchronous bean management is the idea that the loading, construction and dependency-injectimification (yes, I made that word up) are done asynchronously. Obviously. But what does that mean?It means that bean loading happens in parallel to your application logic -- the reason why this is desirable will be answered in the 'why' part.In practice, you make a request to the bean manager for the instance of a bean, it goes and gets the bean (if it's already in existence) or it makes a new instance and gives it to you. But the way it gives the bean to you is through a callback mechanism.Let's take a look at this in practice: That's a bit different than what one might be use to if you've used the old bean manager API, where you would instead do this:The asynchronous version is quite a bit more code!The difference is, with the asynchronous lookup, the anonymous class we defined -- CreationalCallback  -- is used to receive the bean once its been created by the bean manager. When this happens, the callback() method is called, passing an instance of the bean. You then do something with that bean. In this case, we call it's show() method which, displays the popup widget.You could imagine this sort of thing getting really out of hand. But really, most direct calls to the bean manager in your app are probably quite rare, and probably something you may already be abstracting away behind say, an Activity and Places pattern -- in which case, this extra code overhead is negligible.But here's the real question: why?The answer is: code-splitting!One of the really cool features of GWT is its ability to partition your code behind runAsync() calls. This means, that as your app grows, you may find that the upfront loading time becomes undesirably long; wouldn't it be nice if the actual code needed was downloaded on-demand, based on the parts of the application which the user is actually using? Well, that's what GWT's code-splitting does!The problem with synchronous bean loading, is it short-circuits your ability to use GWT's code-splitting effectively if your app is built completely around CDI. This is because Errai emits synchronously executing bootstrapping code to wire you application.The asynchronous bean manager instead makes all the mechanics of the bean manager internally and externally (as shown above) based completely on a callback pattern. Meaning, quite simply, any aspect of bean management can now be contained in a GWT runAsync() callback. Yay!Taking our example above as a scenario to contemplate: it may be that we have indicated that the class Popup is a bean we'd like to code-split. Errai 3.0 will allow you to do this by annotating that bean with the @LoadAsync annotation. This means, that all of the code of Popup -- assuming it does not have code paths to and from parts of your app that are needed in the initial application download --  can be segmented into a separate JavaScript payload. So, when we make our asynchronous lookup of this bean for the first time, we are able to download the JavaScript code, create the bean, and pass the loaded bean to you when it's ready!You might decide, for the size of you app, that you don't need this functionality. Which is fine. We will be retaining both implementation of the bean manager -- the old one is not being deprecated. The caveat is only this: your app will be required to use one or the other. You cannot mix synchronous and asynchronous bean management within a single Errai app. Trust me: it's not possible or practical.In closing, this is just one of the new amazing features coming in 3.0 which will allow you to take maximum advantage of GWT's performance-optimizing capabilities when using Errai.I'm hoping to have something people can play with in the coming days. Stay tuned! [Less]

After a flurry of great feedback on our CR2 release, the Errai Team is proud to announce the release of Errai 2.1.0.Final.Errai 2.1 includes better Dev Mode reload support along with lots of stability enhancements over 2.0.x. Also we've introduced a ... [More] number of exciting new features, all of which are explored with code examples in our recent post announcing CR2.We'll be at JavaOne next week. If you're there too, drop us a note and we can meet up and chat about Errai!Until next time,The Errai Team [Less]

Are you looking to have your voice heard on the future direction of GWT as it moves beyond the 2.5 release?The guys over at Vaadin have collaborated with other members of the GWT Steering Committee to build a survey in order to poll the GWT ... [More] community, how they use GWT, what they use with GWT, and most importantly, what do they want from future GWT releases?We think this is a very useful exercise to help us determine priorities moving forward. If you have a few minutes of time, please go check out this post over at the Vaadin blog and fill out the survey.  [Less]