Make it easier to configure a JOOQ Execution Listener Provider that runs after Boot's default

[aleksandar78]

Hi,

I'm using spring boot 2.0.4 to config JOOQ DSLContext as it uses JOOQAutoConfiguration class.
My problem is that provided translation to spring dao exceptions doesn't fit well with already created application error handling.
I need a custom ExecuteListener to translate JOOQ exception into application custom exceptions.

I've tried to expose default listener provider as bean:

@Bean
public DefaultExecuteListenerProvider applicationExceptionTranslatorExecuteListenerProvider() {
	return new DefaultExecuteListenerProvider(new ApplicationExceptionTranslator());
}

but JOOQ configuration doesn't pick up provider.

While searching around for other issues I've found in #13329 the solution that works.

@Bean
public static BeanPostProcessor jooqConfigurationPostProcessor() {
	return new BeanPostProcessor() {

		@Override
		public Object postProcessBeforeInitialization(Object bean, String beanName)
				throws BeansException {
			return bean;
		}

		@Override
		public Object postProcessAfterInitialization(Object bean, String beanName)
				throws BeansException {
			if (bean instanceof DefaultConfiguration) {
				((DefaultConfiguration) bean).set(new JOOQExceptionTranslator());
			}
			return bean;
		}

	};
}

I need to know if this is the right way of doing it or there is some other way to provide ExecuteListenerProvider with custom ExecuteListener?
Why exposing listenere provider as bean doesn't work, what am I missing?

Thanks

[wilkinsona]

I need to know if this is the right way of doing it or there is some other way to provide ExecuteListenerProvider with custom ExecuteListener?

Using a BeanPostProcessor should not be necessary. The auto-configuration should pick up any ExecuteListenerProvider beans that you define and configure jOOQ to use them in addition to the default one.

but JOOQ configuration doesn't pick up provider.
Why exposing listenere provider as bean doesn't work, what am I missing?

It's impossible to say as "doesn't pick up provider" doesn't tell us much. How have you identified that jOOQ hasn't picked up your provider? It would be useful to know what behaviour you are seeing and what behaviour you expected to see. The best way to show this is with a minimal sample that reproduces the problem. Can you please provide one? You may also want to consider the ordering of your provider and the default provider. You may want to use @Order on its @Bean method so that it's ordered to be called before the default.

[aleksandar78]

Thanks for reply.

It's impossible to say as "doesn't pick up provider"

You are right. I didn't use right words to describe what happened.
Listener is active but exception propagation, for some reason, doesn't work as I expected.

I can't provide a project sample, not now, but I'll try to show with code samples what is going on:

This is my execute listener:

@Slf4j
public class ApplicationExceptionTranslator extends DefaultExecuteListener {

	@Override
	public void exception(ExecuteContext ctx) {
		System.out.println("DEFAULT EXECUTION LISTENER ..............................");
		
		if (ctx.sqlException() != null) {
                        // PRINT SOME STAFF
			log.warn("SQL: {}", ctx.sql());
			log.warn("RUNTIME EXC MESSAGE: {}", ctx.exception().getMessage());
			log.warn("RUNTIME EXC CANNONICAL NAME: {}", ctx.exception().getClass().getCanonicalName());

			SQLDialect dialect = ctx.dialect();
			SQLExceptionTranslator translator = (dialect != null)
					? new SQLErrorCodeSQLExceptionTranslator(dialect.thirdParty().springDbName())
					: new SQLStateSQLExceptionTranslator();

			DataAccessException daoEx = translator.translate("jOOQ", ctx.sql(), ctx.sqlException());

			ApplicationRepositoryException appRepositoryException = // create EXCEPTION from ctx and daoEx
			ctx.exception(appRepositoryException);
		}
	}
}

This is my rest exception handler, with handler for application exceptions and spring dao exception ( spring exception added for debug purpose ):

@ControllerAdvice
@Slf4j
public class ApplicationRestResponseExceptionHandler extends ResponseEntityExceptionHandler {

	@ExceptionHandler(ApplicationRepositoryException.class)
	protected ResponseEntity<ApplicationRestError> handleApplicationRepositoryException(ApplicationRepositoryException ex, HttpServletRequest req) {
		HttpStatus status = HttpStatus.CONFLICT;
		ApplicationRestError body = MessageBuilder.buildApplicationRestError(ex, req, status);
		return new ResponseEntity<>(body, status);
	}

	@ExceptionHandler(DataAccessException.class)
	protected ResponseEntity<ApplicationRestError> handleSpringDataAccessException(DataAccessException ex, HttpServletRequest req) {
		HttpStatus status = HttpStatus.CONFLICT;
		ApplicationRestError body = MessageBuilder.buildApplicationRestError(ex, req, status);
		return new ResponseEntity<>(body, status);
	}
}

I've tried to set order to bean:

@Bean
@Order(Ordered.HIGHEST_PRECEDENCE)
public DefaultExecuteListenerProvider applicationExceptionTranslatorExecuteListenerProvider() {
	return new DefaultExecuteListenerProvider(new ApplicationExceptionTranslator());
}

and I disabled configuration with BeanPostProcessor.

The result of above configuration is that rest exception handler captures DataAccessException.class
and not ApplicationRepositoryException.class.

When I enable BeanPostProcessor ( as shown in my first post ) my rest exception handler captures ApplicationRepositoryException.class.
That is expected behavour for me, I simply want to handle application exceptions only.

One more thing: I see log statements in both cases. That confirms that listener is loaded.

Thanks

[wilkinsona]

Unfortunately, it's going to be difficult to diagnose exactly what's happening without a small sample that reproduces the problem. Hopefully you'll be able to provide one soon as we can't afford to spend the time that it would take to piece things together from a few code snippets. The risk of not reproducing the problem that you're actually seeing is too high for it to be worthwhile.

[aleksandar78]

Hi,

I've created the github project sample
with README and comments on how to reproduce the unexpected behavior.

Thanks again for your feedback.

[wilkinsona]

Thanks for the sample. I've reproduced the problem.

The cause is that Boot's JooqExceptionTranslator is running after your ApplicationExceptionTranslator and overwriting its translated exception with its own. This happens because the context's SQL exception is non-null and a non-null SQL exception is the trigger for exception translation being performed. Unfortunately, it doesn't appear to be possible for an exception translator to null out the context's SQL exception to prevent JooqExceptionTranslator from doing anything.

It looks as if Boot's DefaultExecuteListenerProvider for JooqExceptionTranslator should be ordered so that other providers can go after it (have lower precedence). This would allow their provided listener to overwrite Boot's translated exception with their own. That does come at the cost of exception translation being performed multiple times when only the last translation is of value. It would be interesting if there was a way to prevent further exception translation but that doesn't appear to be possible as calling sqlException(null) on ExecuteContext fails with an NPE. Perhaps I've missed something and there is a way to do it, @lukaseder?

[lukaseder]

I don't fully understand the idea behind calling sqlException(null). What exactly do you want to prevent?

[wilkinsona]

The hope was to prevent any subsequent exception translation from occurring. I wondered if this could be done by nulling out the SQL exception so that subsequent translation doesn’t happen as there’s nothing to translate any more.