non-default TypeConverters aren't available in EventListeners

[nhoughto]

As per https://github.com/micronaut-projects/micronaut-core/blob/master/inject/src/main/java/io/micronaut/context/DefaultBeanContext.java#L2770

initializeEventListeners();
initializeContext(contextScopeBeans, processedBeans, parallelBeans);

Event listeners are always constructed before initializeTypeConverters is called, which means that non-default TypeConverters like TimeConverterRegistrar are not available/registered, which leads to strange errors like:

Message: Error resolving property value [app.smth.timeout]. Property doesn't exist

when using Duration values like 5s in YAML config, i couldn't see this limitation documented anywhere, my mental model of it was that I write EventListeners like I write all the other beans/singletons and i'd expect injecting config with Duration to work like it would anywhere else.

I can't find a good way to workaround it either, my first instinct was to create another EventListener to force the type converter registration, but @Order isn't honoured in EventListener construction, the ordering appears to be done after construction not before (which seems weird?)

https://github.com/micronaut-projects/micronaut-core/blob/master/inject/src/main/java/io/micronaut/context/DefaultBeanContext.java#L1467

So i've had to do various hacks to make typeconverters be registered in tests vs actual runtime, quite fragile. Is there a better way to solve for this?

[graemerocher]

Currently no, this is a known limitation. If we initialise type converters first we will have another issue report saying it is not possible to use BeanCreatedEventListeners for type converters. Also in particular type converters may be have transitives that pull in several beans which all would not be able to be listened for.

I agree it is an unfortunately limitation, but I don't have a solution

[nhoughto]

yep true, but specifically the treatment of @Order could help? The biggest problem for me was that there wasn't a good way to workaround it, by defining an EventListener i can get a hook to manually register the TypeConverter, but because there is no way to ensure the order of EventListener creation, I can't be sure my TypeConverter registration EventListener will run before other EventListeners.. if @Order worked as expected then this would be an OK workaround? At least i'd have one way to solve for runtime and when using @MicronautTest

[graemerocher]

I'm not sure how @Order would help, that would allow you to order the event listeners or order the type converters but not adjust the order of the combination of the 2

[nhoughto]

ah yeah, so just thinking about using an BeanCreatedEventListener as a way to execute logic early on in context creation, to ensure the TypeConverter has been registered, so if can ensure a BeanCreatedEventListener is created first, I can use that pattern, as it stands today can't ensure order of EventListener creation so can't use it as a way to execute logic early in context creation.

If there is another way to execute logic early in init that would work too, like a ApplicationEvent but way before StartupEvent

[graemerocher]

only thing I can think of which is a bit hacky is to use a PropertySourceLoader implementation and register converters in the passed Environment and return Optional.emtpy(). This would have to be registered via service loader with a META-INF/services