Hello Christopher,
I think there is a misunderstanding. I agree that for your use-case it
is very useful to have a single entity that can monitor all factories.
So your entity is probably static. But that doesn't mean that jOOQ's
objects need to be static (or synchronized) too. An example
These artefacts are implemented by you outside of jOOQ:
-------------------------------------------------------------------------------------
// This is your tool
class YourMonitoringTool {
static void event(Configuration c, Query query, Object... other params) {
}
}
// This is your bridge to jOOQ:
class YourJooqAdapter implements JooqLoggerPlugin {
static Object LOCK = new Object();
void event(Configuration c, Query query) {
// You can still handle the lifecycle and activation of your
// Listener yourself. Or you move all of that into your tool
if (isListening) {
synchonized (LOCK) {
YourMonitoringTool.event(c, query);
}
}
}
}
-------------------------------------------------------------------------------------
These would be the artefacts provided by jOOQ
-------------------------------------------------------------------------------------
// jOOQ only knows this interface. It maintains a list of
// such objects in every factory:
interface JooqLoggerPlugin {
void event(Configuration c, Query query);
}
// For instance:
class JooqLogger implements JooqLoggerPlugin {
void event(Configuration c, Query query) {
log.info("Query logged", query.getSQL());
}
}
-------------------------------------------------------------------------------------
I think all of your requirements could still be handled like this
while not imposing too many constraints on jOOQ? For instance, I
wouldn't want to synchronize on a static object, as I have no control
over productive deployments / class-loaders, etc. In a J2EE context,
it would be very hard to get this correctly within jOOQ. The way I see
it, a list of plugins in every Factory is the optimal solution for
everyone.
But maybe I'm still missing something?
Cheers
Lukas
