Mark Thomas wrote:
Jess Holle wrote:
Stusynski, Dan wrote:
Tomcat devs,
Noticed a curiousity during 6.0.16 startup after migrating from 6.0.14.
Below is the startup logs for Tomcat 6.0.16 and am curious if this has
been seen before (the duplicate Listeners)? This was not encountered in
6.0.14.
Not only do we get these duplicate Listener messages for anything
defined in web.xml but we also get it for anything we might define
additionaly for our softwares Listeners.
In other words, we also get such duplicate listener messages any/all
<listener>'s in our web app's web.xml as well. [Our web.xml is a
perfectly valid 2.4 web.xml that worked fine with 6.0.14.]
These info messages were certainly not present in 6.0.14 and even if
they're bogus raise concerns and questions in 6.0.16.
They are a result of the fix for
http://issues.apache.org/bugzilla/show_bug.cgi?id=44268
It means that for some reason, Tomcat is trying to register the
listener more than once and subsequent attempts are ignored. This has
been the case for all of the 6.0.x series but now it is logged when it
happens.
Looking back at the original issue
http://issues.apache.org/bugzilla/show_bug.cgi?id=3770 it is probably
occurring because the TLD is being processed twice.
If this is generating a lot of noise then we probably need to look at
an alternative solution but one that addresses the noise and 44268
doesn't immediately jump out at me.
I'm unclear how <listener> elements in our web apps' web.xml are being
processed multiple times. I only declare a single <listener> element
for each listener class -- nothing odd. Processing them multiple times
would seem to be a bug. If Tomcat realizes its mistake and does not
actually do this twice, then from an external perspective there is no
bug (apart from a slight performance one possibly) -- but telling us
noisily about it makes it an externally noticeable bug and erodes
confidence in the overall server.
Given that our web app didn't mention anything about
"listeners.ContextListener" or "listeners.SessionListener" I have to
assume that this also is a bug -- in that our app never asked to define
these at all, much less twice.
I'd like to know (1) why this stuff is being attempted twice, (2)
whether it can be avoided from our end somehow, (3) whether there are
any side-effects [besides a minor delay in startup], (4) whether a
near-term fix is likely, and, lastly, (5) how we can shut up just this
message if there's no better fix in the short term offing.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
