Why is it not possible to register extensions by regular dependency injection mechanisms?

[akelsch]

Hi!

I was wondering why you are using java.util.ServiceLoader to detect extensions in Extensions:62 and not regular Spring dependency injection by means of @Component and the likes.

For example, we chose to register EnumCodec in our project using CodecRegistrar like this:

public class EnumCodecRegistrar implements CodecRegistrar {

    private final CodecRegistrar delegate;

    public EnumCodecRegistrar() {
        delegate = EnumCodec.builder().withEnum("my_enum", MyEnum.class).build();
    }

    @Override
    public Publisher<Void> register(PostgresqlConnection connection, ByteBufAllocator allocator, CodecRegistry registry) {
        return delegate.register(connection, allocator, registry);
    }
}

The reason behind this decision is that we do not want to implement AbstractR2dbcConfiguration#connectionFactory but rather let autoconfiguration take care of it using all the different configuration sources (properties etc). Also, it is confusing that you have to register the overridden method as a bean as it will not be considered otherwise (because of an early return). We also want to be able to switch between H2 and Postgres.

I ask because instead of just annotating our class with @Component, we had to create src/main/resources/META-INF/services/io.r2dbc.postgresql.extension.Extension and register the class using that file.

I am looking forward to your feedback. Maybe there is an even better approach to this.

[davecramer]

I suspect the answer is partly due to the fact that this needs to run independent of Spring
@mp911de ?

[mp911de]

@akelsch what is a regular dependency injection mechanism? There are Guice, Weld, OpenWebBeans, Spring, Micronaut, Pico Container and likely another dozen of libraries that provide dependency injection.

A database driver represents an infrastructure component that is typically designed with the least amount of dependencies so other, higher level libraries can building top of it. Building on top of one or more DI libs not only creates a cycle between these but also raises the question why DI library X isn’t supported.

That being said, such an integration should be built in the library, that you want to use with R2DBC Postgres and not within itself.

[akelsch]

I see, this specific repository is not a Spring project. Unfortunately, there is no Discussions tab in in spring-data-r2dbc to transfer this discussion to.

I know that extensions have to be registered before the ConnectionFactory is built. But something like this would have made life easier:

@Bean
public CodecRegistrar myEnumCodec() {
    return EnumCodec.builder().withEnum("my_enum", MyEnum.class).build();
}

Or if you simply could use the piece of code from the readme:

@Bean
public PostgresqlConnectionConfiguration.Builder myEnumCodec() {
   return PostgresqlConnectionConfiguration.builder()
           .codecRegistrar(EnumCodec.builder().withEnum("my_enum", MyEnum.class).build());
}

But Builder instances are not autowired anywhere and if you create a bean of type PostgresqlConnectionConfiguration it will effectively ignore auto-configuration saying "host or socket must not be null".

[mp911de]

All good. R2DBC isn't Spring, it's an independent effort that was kicked off by a few Pivotal engineers and transitioned to a community initiative.

Let's have a look on the arrangement from a JDBC perspective: PostgresqlConnectionFactory is in R2DBC what DataSource is for JDBC. PostgresqlConnectionConfiguration and PostgresqlConnectionConfiguration.Builder don't correspond with components in JDBC land. Also other mechanisms, such as MySQL's query/exception interceptors or custom types (PGConnection.addDataType(…)) do not get configured by Spring or any other application framework. It's the responsibility of the developer who wants to use this kind of functionality.

Clearly, R2DBC came late to the database driver party and had a chance to learn from the current state of things and make certain things different. For example, the Java ServiceLoader discovery mechanism and the configurable Extension mechanism in R2DBC Postgres are features that don't have counterparts in JDBC land (or maybe I'm not aware of these).

Historically it was always difficult to cater to vendor-specific features but I don't see a reason why the status quo should remain. One could easily come up with an extension library that wraps this driver and integrates with e.g. Spring to configure the ConnectionFactory by picking up easy-to-register beans. An alternative is Google's Auto Service that automatically registers classes as Service Loader extension (see https://github.com/google/auto/tree/master/service).