[
https://issues.apache.org/jira/browse/KARAF-7773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17777095#comment-17777095
]
Grzegorz Grzybek commented on KARAF-7773:
-----------------------------------------
A little analysis (and sorry for a little mislead - if you enable TRACE you'll
get a lot more information. DEBUG just gives you a bit more ;))
Undeployment - I guess you touched the WAB in {{deploy/}}:
{noformat}
2023-10-19T08:53:01,657 | INFO | paxweb-config-1-thread-1 (undeploy /) |
ContextHandler | 409 - org.eclipse.jetty.util -
9.4.50.v20221201 | Stopped
o.o.p.w.s.j.i.PaxWebServletContextHandler@16870d95{Example Admin,/,null,STOPPED}
{noformat}
This is important and related to Whiteboard dynamism - every physical
"ServletContext" may be "managed" by the highest-ranked "OSGi Servlet Context"
and associated "OSGi Context Model". So if you undeploy one, another one takes
the charge. Here, OCM-1 "took over" - this is the default Whiteboard
ServletContextModel:
{noformat}
2023-10-19T08:53:01,657 | INFO | paxweb-config-1-thread-1 (undeploy /) |
JettyServerWrapper | 458 - org.ops4j.pax.web.pax-web-jetty -
8.0.15 | Changing default OSGi context model for
o.o.p.w.s.j.i.PaxWebServletContextHandler@16870d95{Example Admin,/,null,STOPPED}
2023-10-19T08:53:01,657 | INFO | paxweb-config-1-thread-1 (undeploy /) |
OsgiServletContext | 462 - org.ops4j.pax.web.pax-web-spi - 8.0.15
| Registering
OsgiServletContext{model=OsgiContextModel{WB,id=OCM-1,name='default',path='/',bundle=org.ops4j.pax.web.pax-web-extender-whiteboard,context=(supplier)}}
as OSGi service for "/" context path
{noformat}
Web elements are removed from "/" because it's being redeployed - OCM-77
stopped being the OSGi Context for "/" which will be replaced by OCM-1. OCM-1
comes from WB (Whiteboard), while OCM-77 was WAB.
{noformat}
2023-10-19T08:53:01,657 | DEBUG | paxweb-config-1-thread-1 (undeploy /) |
PaxWebServletHandler | 458 - org.ops4j.pax.web.pax-web-jetty -
8.0.15 | Stopping servlet holder
jsp==org.ops4j.pax.web.jsp.JspServlet@19c47{jsp=null,order=3,inst=false,async=false,src=EMBEDDED:null,STOPPED}
2023-10-19T08:53:01,657 | INFO | paxweb-config-1-thread-1 (undeploy /) |
JettyServerWrapper | 458 - org.ops4j.pax.web.pax-web-jetty -
8.0.15 | Removing servlet
ServletModel{id=ServletModel-79,name='jsp',urlPatterns=[*.jspx,
*.jsp],servletClass=class
org.ops4j.pax.web.jsp.JspServlet,contexts=[{WAB,OCM-77,/,/}]}
2023-10-19T08:53:01,657 | DEBUG | paxweb-config-1-thread-1 (undeploy /) |
JettyServerWrapper | 458 - org.ops4j.pax.web.pax-web-jetty -
8.0.15 | Removing servlet jsp from context /
2023-10-19T08:53:01,657 | DEBUG | paxweb-config-1-thread-1 (undeploy /) |
PaxWebServletHandler | 458 - org.ops4j.pax.web.pax-web-jetty -
8.0.15 | Stopping servlet holder
default==org.ops4j.pax.web.service.jetty.internal.web.JettyResourceServlet@5c13d641{jsp=null,order=1,inst=false,async=false,src=EMBEDDED:null,STOPPED}
2023-10-19T08:53:01,657 | INFO | paxweb-config-1-thread-1 (undeploy /) |
JettyServerWrapper | 458 - org.ops4j.pax.web.pax-web-jetty -
8.0.15 | Removing servlet
ServletModel{id=ServletModel-78,name='default',urlPatterns=[/],contexts=[{WAB,OCM-77,/,/}]}
2023-10-19T08:53:01,657 | DEBUG | paxweb-config-1-thread-1 (undeploy /) |
JettyServerWrapper | 458 - org.ops4j.pax.web.pax-web-jetty -
8.0.15 | Removing servlet default from context /
{noformat}
Now "/" servlet context is restarted - this time with OCM-1 being the
highest-ranked:
{noformat}
2023-10-19T08:53:01,657 | INFO | paxweb-config-1-thread-1 (undeploy /) |
JettyServerWrapper | 458 - org.ops4j.pax.web.pax-web-jetty -
8.0.15 | Starting Jetty context "/" with default Osgi Context
OsgiContextModel{WB,id=OCM-1,name='default',path='/',bundle=org.ops4j.pax.web.pax-web-extender-whiteboard,context=(supplier)}
{noformat}
This is what I was talking about - your filter added by listener is removed:
{noformat}
2023-10-19T08:53:01,658 | DEBUG | paxweb-config-1-thread-1 (undeploy /) |
JettyServerWrapper | 458 - org.ops4j.pax.web.pax-web-jetty -
8.0.15 | Removed 1 dynamically registered servlets/filters/listeners from
context /
{noformat}
The two listeners are called again - BaseWebSocketServer and
ServletContextInitializer from your com.example.web.core bundle
{noformat}
2023-10-19T08:53:01,658 | INFO | paxweb-config-1-thread-1 (undeploy /) |
BaseWebsocketServer | 82 - com.example.web.core - 0.1.0.SNAPSHOT |
context initialized
2023-10-19T08:53:01,658 | ERROR | paxweb-config-1-thread-1 (undeploy /) |
BaseWebsocketServer | 82 - com.example.web.core - 0.1.0.SNAPSHOT |
error registering websocket endpoint
2023-10-19T08:53:01,658 | INFO | paxweb-config-1-thread-1 (undeploy /) |
ServletContextInitializer | 82 - com.example.web.core - 0.1.0.SNAPSHOT |
context initialized
{noformat}
Your filter is added again - still to "/", but managed by OCM-1:
{noformat}
2023-10-19T08:53:01,658 | DEBUG | paxweb-config-1-thread-1 (undeploy /) |
HttpServiceEnabled | 461 - org.ops4j.pax.web.pax-web-runtime -
8.0.15 | Passing registration of
FilterModel{id=FilterModel-149,name='UrlRewriteFilter',filterClass=class
com.example.web.core.UrlRewriteFilter,contexts=[{WB,OCM-1,default,/}]} to
configuration thread
2023-10-19T08:53:01,658 | DEBUG | paxweb-config-1-thread-1 (undeploy /) |
WebElementEventDispatcher | 461 - org.ops4j.pax.web.pax-web-runtime -
8.0.15 | Sending web element event DEPLOYING
(com.example.web.core/0.1.0.SNAPSHOT):
org.ops4j.pax.web.service.spi.model.events.FilterEventData@fe0b3bf for bundle
com.example.web.core
2023-10-19T08:53:01,658 | INFO | paxweb-config-1-thread-1 (undeploy /) |
HttpServiceEnabled | 461 - org.ops4j.pax.web.pax-web-runtime -
8.0.15 | Registering
FilterModel{id=FilterModel-149,name='UrlRewriteFilter',filterClass=class
com.example.web.core.UrlRewriteFilter,contexts=[{WB,OCM-1,default,/}]}
{noformat}
Please comment on my analysis - I don't have a clear picture of all the bundles
you use and which are involved in "contribution to {{/}} context".
> WAB ServletContextListener.contextInitialized invoked multiple times during
> re-deploy (and 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
> Assignee: Grzegorz Grzybek
> Priority: Major
> Attachments: paxweb.log
>
>
> 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)
