How to get SecurityManager once Jakarta EE EnvironmentLoaderListener (@WebListener) triggered and Shiro environment initialized?

[AndrewG10i]

Hi,

When running a Jakarta EE application on Payara 6.x (latest), I observe that @WebListener org.apache.shiro.ee.listeners.EnvironmentLoaderListener is executed last. I need to trigger custom logic - specifically, to schedule a task and propagate a security context (Subject or SecurityManager) - once the Shiro environment has been fully initialized.

However, I do not see a straightforward way to do this, since the container invokes Shiro’s EnvironmentLoaderListener last in the startup sequence.

The task itself is scheduled via Hazelcast and therefore executes outside of the Jakarta EE context. As a result, I cannot @Inject the SecurityManager, and SecurityUtils.getSecurityManager() also fails, throwing an exception indicating that no SecurityManager is available.

What would be an appropriate solution for this scenario?

P.S. I have already tried multiple approaches and workarounds, but each has run into limitations that prevent achieving the desired behavior.

P.P.S. Thanks for enabling discussion here on GitHub - I was never able to make effective use of the mailing user groups. :)

[lprimak]

Hi,

If you look at https://shiro.apache.org/jakarta-ee.html, you will see a section
<!-- Enforce Filter Ordering (Optional) -->
<filter-mapping>
etc...

I am assuming you can write another filter to plug into initialization process that way.
Can you try that?

[AndrewG10i]

In my case it is rather about Listener @WebListener org.apache.shiro.ee.listeners.EnvironmentLoaderListener, not Filter.
EnvironmentLoaderListener initializes Shiro from INI-config, thus I need to hook to it. Here I am dealing with scheduled background task, not a Request context, thus Filter is bit not related.

What I have tried:

1. To preserve the functionality provided by shiro-jakarta-ee package - I am trying to make @WebListener org.apache.shiro.ee.listeners.EnvironmentLoaderListener starting first in chain of listeners by creating my own listener class (e.g. MyEnvironmentLoaderListener) which extends org.apache.shiro.ee.listeners.EnvironmentLoaderListener. And I defined it as the first <listener> in web.xml.
2. I added org.apache.shiro.ee.disabled=true to web.xml (to disable the original @WebListener EnvironmentLoaderListener) and overrided isShiroEEDisabled to always return false in my MyEnvironmentLoaderListener implementation.
3. The implementation of MyEnvironmentLoaderListener seems to work fine until it doesn't: 1) those timers triggered by hazelcast can successfully get SecMgr via SecurityUtils.getSecurityManager() but 2) login via web UI gets broken, it says java.lang.IllegalStateException: Configuration error: No realms have been configured! .... And that I could not resolve yet...

Any ideas? Thanks!

[lprimak]

What about using custom WebEnvironment class as described in Custom WebEnvironment class in the docs?
What you are describing doesn't seem right to me.

You can also specify listener ordering in web.xml if needed so you can get your custom listener invoked after Shiro's

[AndrewG10i]

I will take another look at the custom WebEnvironment tomorrow.

Regarding “custom listener invoked after Shiro’s”: that’s the issue. Currently, there is no deterministic way to control the invocation order of listeners annotated with @WebListener. And once a listener is annotated with @WebListener, I can’t also add it to web.xml as a <listener> - it throws an exception.

[lprimak]

Looks like you are right, @WebListeners are not orderable with <listener> in web.xml.
However, customer WebEnvironment should work. If not, there are other options as well we can explore.

[AndrewG10i]

After coming back to this with a fresh head (and better streamlining ChatGPT 😄 with the right questions), I finally found a clean solution.

The right place to hook in is after the Shiro environment is created by @WebListener org.apache.shiro.ee.listeners.EnvironmentLoaderListener.
Instead of trying to control listener order, the simplest approach is to wait until the WebEnvironment is stored in the ServletContext, and then initialize the VM-level singleton there.

This is mainly needed for background / timer jobs, since they’re not tied to any HTTP request or web context.

Code is simple and clear:

@WebListener
public class ShiroVMSecurityManagerBinder implements ServletContextAttributeListener {

    @Override
    public void attributeAdded(ServletContextAttributeEvent event) {
        bindIfShiroEnvironment(event);
    }

    @Override
    public void attributeReplaced(ServletContextAttributeEvent event) {
        bindIfShiroEnvironment(event);
    }

    private void bindIfShiroEnvironment(ServletContextAttributeEvent event) {
        if (!EnvironmentLoader.ENVIRONMENT_ATTRIBUTE_KEY.equals(event.getName())) {
            return;
        }

        Object value = event.getServletContext().getAttribute(EnvironmentLoader.ENVIRONMENT_ATTRIBUTE_KEY);
        if (value instanceof WebEnvironment env) {
            // Publish as VM-static singleton so SecurityUtils.getSecurityManager() works in timers/background threads
            SecurityUtils.setSecurityManager(env.getWebSecurityManager());
        }
    }
}

@lprimak, дякую за швидкі відповіді та чудовий проект! ;)

[lprimak]

Thank you for your kind words.
The rest of the Shiro team appreciates them as well.

This should work well. However, I would think custom WebEnvionment would work also, maybe even a bit cleaner, but I like this solution as well, it's well decoupled.