Hi Chris,

thanks, I didn't know this (that it works that smooth).
And thinking about it I agree that Singletons are evil and also static init 
blocks are bad.

So it stays the same as with jdbc, simply add jar to cp and go?

Then it should be totally feasible for us to implement the DriverManager as 
interface for our pool as its kind of the equivalent of JDBCs Datasource as its 
non-static.

During a short research I stumbled across this https://github.com/google/auto 
which seems really cool (annotation based generation of service loader files), 
perhaps this is a cool way to keep "registration" code in the driver class.
I see no necessity right now as we have very few drivers, but wanted to share 
this with you.

Best
Julian

Am 18.09.18, 09:27 schrieb "Christofer Dutz" <[email protected]>:

    Hi Julian,
    
    1. Because that's what the ServiceLoader is made for ;-) and I think the 
JDBC way greatly sucks. And it's not a singleton as this way it is way simpler 
to test.
    2. You always could reference multiple files with the same name in the same 
package. Spring has been handling that quite nicely for many years. After all 
each resource has an URL of "mycool-lib.jar/package/package/resource.txt" ... 
no problem at all. 
    
    The ServiceLoader option was added in Java 7 and JDBC is way older and 
therefore can't rely on that.
    
    The static init block is the main reason why setting an Exception 
breakpoint for NullPointerException sucks so greatly (Cause it is always thrown 
in the JdbcOdbcBridge driver which is part of the JDK). ServiceLoader only 
initializes things that are explicitly requested.
    
    Chris
    
    Am 18.09.18, 09:16 schrieb "Julian Feinauer" <[email protected]>:
    
        Hi all,
        
        I have another question about another bit of the internals of the Plc4J 
core for you : )
        While implementing our Connection Pool I thought of the interface to 
use and observed that PlcDriverManager is no singleton and behaves quite a bit 
different than JDBCs.
        One notable difference is that it relies on Javas ServiceLoader to load 
drivers on the classpath.
        
        This leads me to two questions:
        
          1.  Why did you choose to do so and not use an approach like JDBC 
took with the singleton collection and each driver registering itself there 
during loading in a static init block?
          2.  How do the different service files interact (they have all equal 
name at equal path in the cp). Are they merged somehow during compile time with 
some kind of maven mabo-jumbo? Or how does this work that they don’t overwrite 
each other?
        
        Thanks!
        Julian
        
    
    

Reply via email to