[Feature Request]: PlcConnectionManager implementations should provide a "tear down" / "destroy" / "dispose" mechanism

[in-fke]

What would you like to happen?

PlcConnectionManager interface and implementations should provide a "tear down" / "destroy" / "dispose" / "close" (choose your favorite wording) mechanism, in the sense of Spring's DisposableBean or Java's Closeable.
The implemenation should close all connections and dispose any resources.
This can be used for setUp / tearDown mechanisms in Unit Tests and Integration Tests, or for highly configurable frameworks that need to "restart everything".

Programming Languages

• plc4j
• plc4go
• plc4c
• plc4net

Protocols

• AB-Ethernet
• ADS /AMS
• BACnet/IP
• CANopen
• DeltaV
• DF1
• EtherNet/IP
• Firmata
• KNXnet/IP
• Modbus
• OPC-UA
• S7

[splatch]

PlcConnectionManager allows to establish connections which are tracked by user application, but it does not manage connection lifecycle beside attempting to open connection. We recently spoke about various aspects of connection management for 1.0.0 release and we decided to not chase all cases and focus on simplicity. This really means that we can't predict all use cases, and if you need to track connections - your application have to do it itself. Connection Manager is so far just a plain factory which can produce them on request.

[in-fke]

Hmm, if CachedPlcConnectionManager already holds all the connections, why should the caller manage the connections redundantly? I can somewhat understand if you are not willing to "blow" up the implementation, but some optional cleanup method would not hurt either?

Connection Manager is so far just a plain factory which can produce them on request.

Then the name "Manager" is kind of unlucky, and it should have been called "Factory" (again I would undertand if you do not want to change that).

[chrisdutz]

I think it was derived from us initially having only the DriverManager which also had a "getConnection" method and splitting that up into two interfaces in order to allow the connection cache to implement the one without having to implement the other. I do agree ... that considering this, renaming the Interface name could possibly be done as we're giving the API a polish before aiming for a 1.0.0 release (hopefully soon)