So I noticed, while doing this That the DriverManager has the two “getConnection” methods, but a load of others about listing drivers, accessing driver implementations etc. So for now I settled with introducing a “PlcConnectionManager” interface and having the PlcDriverManager implement that (well … it already did) This interface simply contains the two getConnection methods.
This way the CachedConnectionManager simply implements this interface and is exchangeable. Chris From: Łukasz Dywicki <l...@code-house.org> Date: Sunday, 8. January 2023 at 23:10 To: dev@plc4x.apache.org <dev@plc4x.apache.org> Subject: Re: [DISCUSS] Refactor the PlcDriverManager in Java? Hey Chris, I second approach with interfaces as it clearly cuts implementation and declaration of operations. It could also help people who use OSGi because making a PlcDriverManager valid osgi service will be easier (lighter) with interface. It boils down to runtime where proxy for interface type is built in JVM while proxy for class involves cglib/asm etc. Best, Łukasz On 8.01.2023 15:35, Christofer Dutz wrote: > Hi all, > > I’m currently working on a new Connection Cache for Java and have stumbled > over two things: > > The one is the fact, that the PlcDriverManager is a class and not an > interface. > This makes it problematic for me to have the PlcDriverManager implement the > same interface. > I could probably override every method, so this is not a big problem. > However, having a PlcDriverManager interface would be the cleaner solution. > This would require us to change the name of the current PlcDriverManager > class to something like DefaultPlcDriverManager… this would be a breaking > change. > > Another is that the getConnection doesn’t return a Future … the main reason > for this was the try-with-resources pattern, that automatically closes the > PlcConnection returned from getConnection. > However, returning a future might be the better option and it would be more > like in the other languages. > Especially when we’re working with cached connections. Here a client might be > waiting a while till it gets a connection handle. > This also would be a breaking change. > > > What do you folks think? > > Chris > > >
