>Sent: Thursday, July 14, 2016 11:51 PM
>To: Tomcat Users List
>Cc: Rainer Jung
>Subject: Re: A complex issue concerning the application lifecycle, MBeans and
>Spring
>
>Dear Mark,
>
>thank you a lot for giving your time and knowledge to follow and confirm my
>thou
On 14.07.2016 22:09, Mark Thomas wrote:
> On 14/07/2016 21:14, Mark Thomas wrote:
>> On 14/07/2016 09:26, Jäkel, Guido wrote:
>
>
>
>>> So maybe there should be a special code path in case of an ongoing
>>> initialization on the top like the 'if(unloading)' clause. The note states,
>>> that
On 14/07/2016 21:14, Mark Thomas wrote:
> On 14/07/2016 09:26, Jäkel, Guido wrote:
>> So maybe there should be a special code path in case of an ongoing
>> initialization on the top like the 'if(unloading)' clause. The note states,
>> that one can't decide if a Servlet implements
On 14/07/2016 09:26, Jäkel, Guido wrote:
> Hi Mark,
>
> OK - as a newbie I read this from the stack trace: ...
>
>> 20160713-161427.340 ERROR [catalina-exec-64] [] [[/]]
>> StandardWrapper.Throwable
>> [...]
>>at
>>
Hi Mark,
OK - as a newbie I read this from the stack trace: ...
>20160713-161427.340 ERROR [catalina-exec-64] [] [[/]] StandardWrapper.Throwable
>[...]
>at
> org.springframework.web.servlet.HttpServletBean.init(HttpServletBean.java:136)
>at
Dear Mark,
> We need to find out what is triggering the second, unwanted
> initialization. You'll need to add some logging to your app to capture
> the relevant stack trace. When you have it, post it here.
taking remote access, I was able to extract a (hope so) relevant stack trace
from the
On 13.07.2016 22:41, Mark Thomas wrote:
> I've been through the MBean descriptor for a web application and as far
> as I can tell, reading of all of the attributes is passive. It might
> return a few unexpected nulls or maybe thrown an exception but it
> shouldn't trigger any additional
On 13/07/2016 15:20, Jäkel, Guido wrote:
> But if there is a certain request to some MBean while the App is
> starting, there will be a request to the application (via
> catalina-exec). And then, as a race condition, the initialization of
> the Spring framework, esp. the bean wiring will fail with
On 13.07.2016 16:33, Jäkel, Guido wrote:
Dear André,
thank you for quickly announcing your idea for an workaround. But you right see
the limits, and the more important
impact of disabling the connectors is that it will also disable the traffic to
all the other running applications (and we
>> Dear André,
>>
>> thank you for quickly announcing your idea for an workaround. But you right
>> see the limits, and the more important
>impact of disabling the connectors is that it will also disable the traffic to
>all the other running applications (and we have a
>bunch of it on each of
On 13.07.2016 15:51, Jäkel, Guido wrote:
So it would appear that if the Connectors are disabled, the monitoring system
is not able
to reach Tomcat, and the problem does not occur then.
So would it not be possible to create some little piece of software, which would
temporarily "suspend" or
>So it would appear that if the Connectors are disabled, the monitoring system
>is not able
>to reach Tomcat, and the problem does not occur then.
>
>So would it not be possible to create some little piece of software, which
>would
>temporarily "suspend" or "disable" the Connectors, while the
On 13.07.2016 15:20, Jäkel, Guido wrote:
Dear Developers,
I have an elaborate issue migrating from Tomcat 6.0.41 to 8.0.36 (currently
using java 8.0.66 on Gentoo Linux, but this is not of importance I think): It
is related to the build-in manager application used as a jmxproxy. And to
Dear Developers,
I have an elaborate issue migrating from Tomcat 6.0.41 to 8.0.36 (currently
using java 8.0.66 on Gentoo Linux, but this is not of importance I think): It
is related to the build-in manager application used as a jmxproxy. And to
initialization of the Spring framework during an
14 matches
Mail list logo
