user384729
user384729

Reputation: 403

What's the benefit of having Jersey instantiating components

All of the code samples of Spring Boot and Jersey that I have seen register their components with Jersey by passing the component's class.

From here:

  public static class JerseyServletConfig extends ResourceConfig {
    public JerseyServletConfig() {
      register(RequestContextFilter.class);
      packages("com.github.cthiebault");
      register(LoggingFilter.class);
    }
  }

Or here:

register(ApiListingResource.class);

ResourceConfig's javadoc says:

Register an instance of a custom JAX-RS component (such as an extension provider or a feature meta-provider) to be instantiated and used in the scope of this configurable context.

My questions are:

  1. What is the benefit of letting those resources being instantiated by Jersey?

  2. If we should let Jersey manage those components, why does it still provides a register(Object component) method, why not keep it limited to register(Class<?> componentClass)?

  3. When should we send our own instances instead of letting Jersey instantiating our class?

Upvotes: 0

Views: 327

Answers (1)

sisyphus
sisyphus

Reputation: 6392

To start, Dependency Injection is a GoodThing(tm) in general - it allows for separating concerns and it can greatly simplify testing. In general separating object creation from object use gives benefits around separating business/application logic (i.e. object use) from implementation concerns (deciding what objects are wired together).

Allowing Jersey to manage your resources / components is also a GoodThing(tm). It's a part of what Jersey is for. If you allow Jersey to manage your resource lifecycle then you have less code to write / maintain and the code which you do end up writing / maintaining becomes more about what your application does and less about how your objects fit together.

Jersey provides a standard lifecycle, which gives you a convention that allows developers a mental framework to work in - making it easier for new developers to join and existing developers to switch between applications. The lifecycle can be configured if need be, which allows your special-snowflake application to have special-snowflake behaviour if necessary.

The register(Object) method is an example of how you can opt-out of Jersey controlling a component's lifecycle. You may want to do that for lots of reasons, but you should generally look to avoid doing it - let the library do its job. Examples of exceptional cases would be if you're integrating with some legacy code which, for obscure/arcane reasons of its own, means that some crucial class must be an application-level singleton. There may even be some non-legacy reasons why you only want a single instance of something in your application - object mappers were always a good example of this. Typically, you'd use JSR-330 support for that nowadays but there might be some cases where that's not possible.

By integrating with JSR-330, you can also provide custom named scopes for some objects - which allows you to control how Jersey creates and uses objects while also revealing what you're intending (via the scope name). This generally provides a clean structure which is intention-revealing rather than intention-hiding.

Upvotes: 1

Related Questions