Replies: 1 comment
-
So what I'm currently thinking about would be something like this in the driver config:
We could have a TransportConfigProvider interface that defines a method that takes the code of a transport and returns a config instance for that. The parts I think that might be tricky, would be to implement the functionality for the two proposed annotations: ComplexConfigurationParameter and OverrideComplexConfigurationParameterDefault (Names are just a simple proposal ... if you have better names, happy to use them) |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
So I noticed even before the release, that it wasn't possible to override the settings for the serial port using the connection string. So having a deeper look, all of our configs implement the transport-config interfaces, however they don't really implement them, but rely on the default implementations instead. This is the reason, why there's currently no way to change the defaults.
Now in order to really support that, we'd need to implement the get methods for all of these interfaces and annotate them with the annotations so our configuration framework can inject them.
Problem is, that this way we'll have to add the same boilerplate code to every configuration for every transport that we expect the driver to support.
An alternative would be to change the TcpTransportConfig into a class (Or adding a DefaultTcpTransportConfig class that implements the interface) and to simply add one property per supported transport (And possibly add an additional TcpTransportConfigProvider interface).
The later version would be simpler and could possibly make us support a hierarchy of properties such as "tcp.keepalive". But it wouldn't allow us to provide defaults on a per-driver basis.
What do you folks think? I'm currently thinking that the long way, adding loads of properties to the config classes per driver, is the more flexible way, but I'm also not coming up with a situation, where I could imagine needing this type of flexibility. So far the "defaultPort" might be a good candidate. But for the rest ... don't think we need that.
If of course it would be possible to override the defaults in the tcpConfig field on a per-driver basis, that would be perfect.
Beta Was this translation helpful? Give feedback.
All reactions