CDIExtensionPoints startupCallback vs RPC

[ruzkant]

Hi

I am working on having MessageBus objects injectable in a Spring context and have been looking at the CDIExtensionPoints class based on recommendation from Max.

I am trying to figure out why some services are subscribed in the StartupCallback in a scheduled execution where the bean instances are looked up as they become available, whereas the RPC remote interfaces are subscribed right away with a proxy class that looks up the bean:

  private void subscribeServices(final BeanManager beanManager, final MessageBus bus) {
    /**
     * Due to the lack of contract in CDI guaranteeing when beans will be available, we use an
     * executor to search for the beans every 100ms until it finds them. Or, after a 25 seconds,
     * blow up if they don't become available.
     */
    final ScheduledExecutorService startupScheduler = Executors.newScheduledThreadPool(1);
    startupScheduler.scheduleAtFixedRate(new StartupCallback(beanManager, bus, startupScheduler, 25), 0, 100,
            TimeUnit.MILLISECONDS);

    for (final Class<?> remoteInterfaceType : managedTypes.getRemoteInterfaces()) {
      if (!managedTypes.isRemoteInterfaceImplemented(remoteInterfaceType)) {
        log.warn("No @Service implementations found for " + remoteInterfaceType.getName());
      }
      createRPCScaffolding(remoteInterfaceType, bus, beanManager);
    }
  }

I have basic RPC integration working by reworking an example in this old post: Errai 2.2.0.Final + Spring (RCP service example). It does not however cater for plain MessageCallback implementations or the Command annotation and I'd like to cater for whatever is leading to the two different approaches above. Any insights would be appreciated...

[mbarkley]

Hi ruzkant,

I'm not sure what the original intent was, but the effective difference is that Errai looks up RPC services for every call, whereas plain message services are looked up once and reused.

For @ApplicationScoped beans this makes no difference, but for @Dependent beans this means that the plain services can still maintain internal state, whereas the RPC service instances will be different each time.

Hope that helps.

[ruzkant]

This does help, thanks. It's not immediately obvious to me why RPC classes should be different in this respect, any thoughts would be helpful. For now I will do the same in Spring, have singletons for MessageCallback and Services that use @Command, while supporting Spring's prototype scope which is similar to dependent for RPC.

[ruzkant]

I added a new post about a new spring errai github project from the results of looking into the CDI extension: github project for errai spring server side integration

I have basically just stuck to the same scope even though I don't yet know why it was implemented in this way. So plain services can be scoped as Singleton's in Spring, but RPC's can use other spring scopes, like prototype (dependent), session, request etc. So I'll just consider your answer as answer enough for now, thanks.