Uploaded image for project: 'Errai'
  1. Errai
  2. ERRAI-485

Use Errai Magic to create "Registry" Objects


    • Type: Feature Request
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 3.0.0.M1
    • Fix Version/s: None
    • Component/s: ErraiIOC
    • Labels:


      There are certain use cases where there are certain classes of objects that would benefit from being added to a registry of some sort. Examples include Places, Data Providers, or Dashboard Widgets - In general, when there is a great deal of runtime configuration.

      To do this now, the developer must build a registry himself, a relatively tedious task. Trying to do so while using Errai-CDI is even more complex, especially with 3.0 moving to an Asynchronous interface.

      The errai framework could really provide a benefit by making the creation of such registries dead-simple. Here is an example of how it could go:

      Have an errai registry interface:

      public interface ErraiRegistry<O> {
        public O getRegistered( Object type );

      The developer would then create a registry as follows:

      public interface DashboardRegistry extends ErraiRegistry<DashboardWidget> {

      where DashboardWidget is an interface as well.

      Then, to have "DashboardWidgets" registered with the DashboardRegistry, we could do:

      @RegisterWith( registry=DashboardRegistry.class, type="weather")
      public class WeatherDashboardWidget implements DashboardWidget {

      where type is optional, defaulting to the class name. Finally, to use the registry, one would simply inject it:

      public class Dashboard {
        @Inject DashboardRegistry dashboardRegistry;
        public void loadDashboard( Object id ) {
          DashboardWidget dw = dashboardRegistry.getRegistered( id );

      To summarize, in my example implementation, I have one new errai interface, and one new errai annotation.

      There are a couple of benefits to this over using the IOC Bean manager directly,

      • it is more formalized by type
      • allows for the creation of beans from something other than the class (for example, a predefined string)
      • it actually allows for a synchronous call even when using the AsyncBeanManager.

      How this differs from Named Beans
      Named beans would allow you to access beans based on a name (provided by the @Named annotation). Using the AsyncBeanManager, these beans would still need to be created asyncronously once the AsyncBeanDef was returned. The idea with the registry is that the registry would be injected (or retried from the AsyncBeanManager asynchronously), but the call into the registry for a bean would be synchronous, regardless of the type of IocBeanManager that was being used.

      Conceptually, I am picturing code generated to the effect of:

      public class DashboardRegistryImpl implements DashboardRegistry {
         @Inject Provider<DashboardWidget1> dashboardWidget1;
         @Inject Provider<DashboardWidget2> dashboardWidget2;
         public DashboardWidget getRegistered( Object o ) {
            if( o.equals("w1")) {
               return dashboardWidget1.get();
            else if (o.equals("w2") ) {
               return dashboardWidget2.get();

        Gliffy Diagrams




              • Assignee:
                cbrock Mike Brock
                jblinick Josh B
              • Votes:
                0 Vote for this issue
                1 Start watching this issue


                • Created: