LoggingApplicationListener calls loggingSystem.cleanUp() after nested context was destroyed

[toughpheeckouse]

Is it right way to cleanUp loggingSystem after nested context was destroyed?

I have next code:

migrationContext = new AnnotationConfigApplicationContext();

migrationContext.setParent(applicationContext);

.../*(some actions in migrationContext */

migrationContext.destroy(); // sends ContextClosedEvent to LoggingApplicationListener `

After that I can't get log messages from JUL.

What I'm doing wrong? Is it bug in LoggingApplicationListener or I use wrong way to create nested context?

As workaround - do not send ContextClosedEvent by nested context:

migrationContext = new AnnotationConfigApplicationContext()
{
    @Override
    public void publishEvent(ApplicationEvent event)
    {
        if (!(event instanceof ContextClosedEvent))
        {
            super.publishEvent(event);
        }
    }
};

[wilkinsona]

As described in the guidelines for contributing, we prefer to use GitHub issues only for bugs and enhancements. For general usage questions, please use StackOverflow

[toughpheeckouse]

But it seems to be a bug or not?

[wilkinsona]

Sorry, but I can tell from your description. For example, you haven't described the lifecycle of the nested context in relation to its parent or exactly what it is you're trying to do.

[toughpheeckouse]

lifecycle of the nested context is described in code block

it is just created and after some action (I think it's no matter what exact action) it is destroyed.
when nested context is destroyed it sends event ContextClosedEvent
which handled by LoggingApplicationListener.
and this listener does not look from what context this event has been sent and calls loggingSystem.cleanUp() where SLF4JBridgeHandler is uninstalled.

I think this is a bug - the SLF4JBridgeHandler is installed for parent context not for nested, but uninstalled when nested context is destroyed.

Sorry, for confused explanation

[wilkinsona]

That's much clearer now, thank you.