Amichai Rothman created KARAF-7773:
--------------------------------------
Summary: Servlet Filter init invoked (for 2nd time) during
undeploy with wrong context
Key: KARAF-7773
URL: https://issues.apache.org/jira/browse/KARAF-7773
Project: Karaf
Issue Type: Bug
Components: karaf
Affects Versions: 4.4.3
Reporter: Amichai Rothman
When touching a WAB bundle with a context listener as described belower, the
undeploy/deploy cycle, instead of just invoking destroy on the old context and
initialize on the new one, seems to destroy the old one, re-initialize the old
one (with the wrong "whiteboard extender" context), destroy it again,
initialize the new one (with correct context), and initialize the old one once
more (but without the filter init).
I'll describe my full scenario, even though it's possible the issue can be
reproduced with a simpler setup:
I have an application consisting of multiple bundles in the karaf deploy
folder. One of them is a WAB. It's web.xml only contains display-name and
listener-class with a ServletContextListener. The listener contextInitialized
implementation instantiates a custom Filter, whose class is imported from a
different app bundle:
{code:java}
Filter filter = new MyFilter();
context.addFilter("MyFilter", filter)
.addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST,
DispatcherType.FORWARD), true, "/*");
{code}
The filter's init method is invoked successfully and all is good.
Then, I update/touch the WAB bundle in the deploy folder.
This causes a thread named "paxweb-config-3-thread-1 (undeploy /)" to call the
listener's contextDestroyed method as expected, but then it also immediately
calls the contextInitialized method again (still from the undeploy thread, and
still the same old listener instance), this time with the servlet context of
the pax-web-extender-whiteboard rather than the WAB bundle. It creates another
filter instance, whose init method gets invoked with the
pax-web-extender-whiteboard context as well (my init implementation throws an
exception at this point when the context is wrong, resources aren't found etc.).
Then a thread named "paxweb-config-3-thread-1 (deploy /)" (notice undeploy
changed to deploy) calls contextDestroyed, still with the extender context.
Finally, a new listener instance is craeted, contextInitialized is invoked
again, this time with the correct WAB context, followed by the filter's init
method. In addition, the old listener instance (which should be dead by now)
contextInitialized also gets invoked again, but not followed by the filter init
(maybe because it previously threw an exception on it? just guessing).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
