> If the JooqLogger is a particular type of listeners, then the cost of > logging is there all the time (wrapped result sets, event creation and > notification, parameter analysis, etc.). I would favor a no-cost API > when there are no listeners which is the most common case I think.
Setting the JooqLogger as a listener will be the default if no listener is configured. This will help new users to get started quickly. You will be able to override that explicitly, of course. On the other hand, loggers have cheap isDebugEnabled(), isTraceEnabled() methods. Such methods will still be part of the general API > Factory is not multi threaded, so a program does not have a single > factory. One of the strengths of the tool we have is that we can just > launch it and activate logging: it registers statically and listens to > everything. This is especially important because one thread may be > performing a call which can explain delays for another thread. > I don't deny that logging a particular factory is not useful, I am > just highlighting the fact that being able to listen to everything is > generally more desirable. jOOQ can be oblivious of the concrete static / threadsafe implementation. You'll just have to implement an API redirecting calls to your library. I'd prefer to keep such an API very general, not making assumptions about static-ness, thread-safety, or real-time behaviour-switching. So from a jOOQ-point-of-view, one interface instance per Factory might be the most general solution. What do you think?
