Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make ConnectionFactory easier to use #608

Open
acogoluegnes opened this issue Apr 3, 2019 · 3 comments
Open

Make ConnectionFactory easier to use #608

acogoluegnes opened this issue Apr 3, 2019 · 3 comments
Assignees
Milestone

Comments

@acogoluegnes
Copy link
Contributor

acogoluegnes commented Apr 3, 2019

Related to #330.

Many settings have been added to ConnectionFactory over the years, making it somewhat harder to configure. It's for instance easy to omit an important option when setting TLS, because the different TLS-related options are scattered: ConnectionFactory#useSslProtocol, ConnectionFactory#setSslContextFactory, ConnectionFactory#enableHostnameVerification. Same thing for NIO (mitigated by NioParams).

A more "use-case oriented", less JavaBeans-like way could improve the situation, e.g.:

cf.nio().executor(myNioExecutor).socketChannelConfigurator(configurator) // NIO configuration
  .connectionFactory() // going back to the connection factory (call may be avoided with syntax trick)
  .tls().context(sslContext).hostnameVerification(true); // TLS configuration

Not longer useful configuration methods would be deprecated and scheduled for removal in 7.0.0.

@acogoluegnes acogoluegnes added this to the 6.0.0 milestone Apr 3, 2019
@acogoluegnes acogoluegnes self-assigned this Apr 3, 2019
@mudit-saxena
Copy link

Hey,

I would like to contribute to this project. I was wondering if this issue is still actionable and can I take this up

@michaelklishin
Copy link
Member

@mudit-saxena you can take this up. We only have a single example but if you can run with it, feel free to submit a PR and we will discuss what you think such "fluent API" might look like. Thank you!

@acogoluegnes
Copy link
Contributor Author

This does not have to go into 6.0, as it could be introduced as a backward-compatible change. We could get rid of deprecated ("direct") configuration methods in 6.0 then.

acogoluegnes added a commit that referenced this issue Jan 29, 2024
The ConnectionFactory class has dozens of parameters.
It can be overwhelming to configure, especially
for tricky topics like TLS where the parameters are among
the other dozens, without clear way to find them.

This commit introduces an API to simplify the configuration
of ConnectionFactory. It is fluent, uses modern API (e.g. Duration
for timeout), and groups common settings in sub-API.

The configuration API will be introduced in 5.x, marked as experimental,
and refined in minor releases.

The traditional setter-based API will be marked deprecated 6.x and
removed in 7.x.

Benefits of the new configuration API:
* fluent, the method calls can be chained and formatted in a logical
way (it does not have to be 1 line = 1 parameter).
* the different timeout settings use the Duration type, instead of
int. It is no longer necessary to know the unit (seconds or
milliseconds).
* parameters for the same topic are grouped into dedicated configuration
API (TLS, NIO, OAuth2, recovery, etc). It makes it much easier to
configure those parts, as available settings will show up automatically
in the IDE auto-completion, and not among the other dozens of settings.
* more opinionated but easier configuration. OAuth2 is an example:
no need to use builder classes with very long names, the refresh service
part is also in the #oauth2() sub-configuration, whereas it's a
separate setter in ConnectionFactory.

References #608, #1139
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants