

Scopes¶

Reminder

By default, all guice beans are created in prototype scope. Guicey only force singleton scope for jersey extensions (resources and extensions))

Available scopes:

@Singleton - single instance per context
@RequestScoped - object per request (if guice filter support is not disabled)
@Prototype - prototype scope annotation (useful to override forced singleton scope for jersey services)

Session scope (@SessionScoped) is usually useless, because sessions are not enabled by default in dropwizard (but it is possible to enable them).

Tip

Scopes of registered beans could be checked in guice report

Prototype¶

Normally, prototype scope (new instance on each new injection) is the default - no need to explicitly specify it.

The only possible usage is overriding default forced singleton scope for jersey extensions. For example, resource declared like this:

@Path("/my")
public class MyResource {}

Will be singleton. Prototype scope must be explicitly declared (if required):

@Path("/my")
@Prototype
public class MyResource {}

Note

@Prototype scope annotation support is registered by guicey

Singleton¶

Both com.google.inject.Singleton and javax.inject.Singleton annotations could be used.

Tip

Prefer declaring @Singleton scope on all beans, except cases when different scope is required.

Request¶

By default, GuiceFilter is registered for both application and admin contexts. And so request (and session) scopes will be be available in both contexts.

@RequestScoped
public class MyRequestScopedBean { ... }

In order to access request scoped beans in other beans you'll need to use provider:

Provider<MyRequestScopedBean> myBeanProvider;

Some jersey objects are already bound in request scope

Context request and response objects are also available through request scope:

Provider<HttpServletRequest> requestProvider
Provider<HttpServletResponse> responseProvider

Request scope transition¶

This is guice feature, it is just mentioned here.

Guice could access request scoped bindings only in current thread. If you need to access request scoped binding in different thread, you need to transfer request scope into that thread:

@Singleton 
public class RequestBean {

    // provider will not work in other thread because of request scope
    @Inject
    Provider<UriInfo> uri;

    public void doSomethingInRequestScope() {
            // jersey object must be resolved inside hk request scope (to store it in guice request scope)
            // so guice could see its instance later in another thread
            uri.get();

            // wrap logic that require request scope 
            Callable<String> action = ServletScopes.transferRequest(() -> {
                // access request scoped binding in different thread 
                return uri.get().getQueryParameters().getFirst("q");
            });            
            CompletableFuture.runAsync(() -> {
                try {
                    // execute action in different thread
                    action.call();
                } catch (Exception e) {
                    e.printStackTrace();
                }
            });
    }
}

Warning

Pay attention that for jersey scope objects provider must be called first in the current thread! Guice would be able to propagate to another thread only objects already present in guice request scope. Without it, provider.get(), called under different thread would be delegated to jersey, which is not aware of this thread and so fail to provide its request scope object.

Such additional call is not required for pure guice-managed request scope objects.

Request scope simulation¶

Sometimes, request scoped beans may need to be used somewhere without request (for example, inside scheduled job). Of course, this is not correct situation, and the best way is to re-design services, but not always possible.

As a workaround, request scope could be simulated:

@Inject
Provider<RScopedService> service;
...
final RequestScoper scope = ServletScopes.scopeRequest(Collections.emptyMap());
try (final RequestScoper.CloseableScope ignored = scope.open()) {
  // work with request-scoped bean
  service.get().doSomething();
}

Eager singleton¶

By default, guicey create injector in PRODUCTION stage, so all registered singletons will be instantiated immediately.

But if you rely on guice JIT (instantiation by injection) it may defer bean creation (until it will be requested first time).

To always start beans (even in DEVELOPMENT stage) guice provide eager singleton option: bind(MyService.class).asEagerSingleton().

For cases when you don't want to manually declare bean, but require it to start with guice context you can either implement Managed or mark bean as @EagerSingleton (the latter will simply bind annotated bean as guice eager singleton instead of you).