Discussion:
can't connect to manager application
Edoardo Panfili
2013-10-17 16:45:30 UTC
Permalink
My Tomcat (7.0.42) is listening on port 7080 and I have this
conf/tomcat-users.xml in (production server)

-------
<tomcat-users>
<role rolename="manager-script"/>
<user username="myname" password="pwd"
roles="manager-script,manager-gui,manager-jmx"/>
</tomcat-users>
----------
if I use

curl -u myname:pwd
http://localhost:7080/manager/text/reload?path=/myApplication

the response is--------------------------
<h1>404 Not found</h1>
<p>
The page you tried to access
(/manager/text/reload)
does not exist.
</p>
<p>
The Manager application has been re-structured for Tomcat 7 onwards
and some
of URLs have changed. All URLs used to access the Manager
application should
now start with one of the following options:
</p>
<ul>
<li>/manager/html for the HTML GUI</li>
<li>/manager/text for the text interface</li>
<li>/manager/jmxproxy for the JMX proxy</li>
<li>/manager/status for the status pages</li>
</ul>
<p>
Note that the URL for the text interface has changed from
&quot;/manager&quot; to
&quot;/manager/text&quot;.
</p>
<p>
You probably need to adjust the URL you are using to access the Manager
application. However, there is always a chance you have found a bug
in the
Manager application. If you are sure you have found a bug, and that
the bug
has not already been reported, please report it to the Apache
Tomcat team.
</p>
---------------------------------------------------------
on my local machine all goes well (same tomcat version but on port
8080), can't figure what is different on production server... where can
I take a look?

Some release ago (tomcat 7.0.x sorry, I can't be more precise) all was
well also on production server. Maybe i did something wrong during an
update.

thank you
Edoardo
Martin Gainty
2013-10-17 18:58:13 UTC
Permalink
<source>
http://localhost:8080/manager/text/reload?path=/examples
</source>



Signal an existing application to shut itself down and reload. This can
be useful when the web application context IS NOT RELOADABLE

and you have updated classes or property files in the

<code>/WEB-INF/classes</code>
directory or when you have added or updated jar files in the
<code>/WEB-INF/lib</code> directory.


Context reloadable attribute would need to reflect reloadable=false e.g.


<Context path="/petclinic" reloadable="false">


Buona Fortuna,
Martin
______________________________________________
Si prega di non alterare o interrompere questa trasmissione...Grazie
Date: Thu, 17 Oct 2013 18:45:30 +0200
Subject: can't connect to manager application
My Tomcat (7.0.42) is listening on port 7080 and I have this
conf/tomcat-users.xml in (production server)
-------
<tomcat-users>
<role rolename="manager-script"/>
<user username="myname" password="pwd"
roles="manager-script,manager-gui,manager-jmx"/>
</tomcat-users>
----------
if I use
curl -u myname:pwd
http://localhost:7080/manager/text/reload?path=/myApplication
the response is--------------------------
<h1>404 Not found</h1>
<p>
The page you tried to access
(/manager/text/reload)
does not exist.
</p>
<p>
The Manager application has been re-structured for Tomcat 7 onwards
and some
of URLs have changed. All URLs used to access the Manager
application should
</p>
<ul>
<li>/manager/html for the HTML GUI</li>
<li>/manager/text for the text interface</li>
<li>/manager/jmxproxy for the JMX proxy</li>
<li>/manager/status for the status pages</li>
</ul>
<p>
Note that the URL for the text interface has changed from
&quot;/manager&quot; to
&quot;/manager/text&quot;.
</p>
<p>
You probably need to adjust the URL you are using to access the Manager
application. However, there is always a chance you have found a bug
in the
Manager application. If you are sure you have found a bug, and that
the bug
has not already been reported, please report it to the Apache
Tomcat team.
</p>
---------------------------------------------------------
on my local machine all goes well (same tomcat version but on port
8080), can't figure what is different on production server... where can
I take a look?
Some release ago (tomcat 7.0.x sorry, I can't be more precise) all was
well also on production server. Maybe i did something wrong during an
update.
thank you
Edoardo
---------------------------------------------------------------------
Edoardo Panfili
2013-10-18 05:33:12 UTC
Permalink
Post by Martin Gainty
<source>
http://localhost:8080/manager/text/reload?path=/examples
</source>
Signal an existing application to shut itself down and reload. This can
be useful when the web application context IS NOT RELOADABLE
and you have updated classes or property files in the
<code>/WEB-INF/classes</code>
directory or when you have added or updated jar files in the
<code>/WEB-INF/lib</code> directory.
Context reloadable attribute would need to reflect reloadable=false e.g.
<Context path="/petclinic" reloadable="false">
the file $tomcat/conf/Catalina/localhost/myApplication.xml
starts with
<Context path="/myApplication" debug="100" reloadable="false">
Post by Martin Gainty
Buona Fortuna,
grazie!


Edoardo
Post by Martin Gainty
______________________________________________
Si prega di non alterare o interrompere questa trasmissione...Grazie
Date: Thu, 17 Oct 2013 18:45:30 +0200
Subject: can't connect to manager application
My Tomcat (7.0.42) is listening on port 7080 and I have this
conf/tomcat-users.xml in (production server)
-------
<tomcat-users>
<role rolename="manager-script"/>
<user username="myname" password="pwd"
roles="manager-script,manager-gui,manager-jmx"/>
</tomcat-users>
----------
if I use
curl -u myname:pwd
http://localhost:7080/manager/text/reload?path=/myApplication
the response is--------------------------
<h1>404 Not found</h1>
<p>
The page you tried to access
(/manager/text/reload)
does not exist.
</p>
<p>
The Manager application has been re-structured for Tomcat 7 onwards
and some
of URLs have changed. All URLs used to access the Manager
application should
</p>
<ul>
<li>/manager/html for the HTML GUI</li>
<li>/manager/text for the text interface</li>
<li>/manager/jmxproxy for the JMX proxy</li>
<li>/manager/status for the status pages</li>
</ul>
<p>
Note that the URL for the text interface has changed from
&quot;/manager&quot; to
&quot;/manager/text&quot;.
</p>
<p>
You probably need to adjust the URL you are using to access the Manager
application. However, there is always a chance you have found a bug
in the
Manager application. If you are sure you have found a bug, and that
the bug
has not already been reported, please report it to the Apache
Tomcat team.
</p>
---------------------------------------------------------
on my local machine all goes well (same tomcat version but on port
8080), can't figure what is different on production server... where can
I take a look?
Some release ago (tomcat 7.0.x sorry, I can't be more precise) all was
well also on production server. Maybe i did something wrong during an
update.
thank you
Edoardo
---------------------------------------------------------------------
Ognjen Blagojevic
2013-10-17 20:43:03 UTC
Permalink
Edoardo,
Post by Edoardo Panfili
Some release ago (tomcat 7.0.x sorry, I can't be more precise) all was
well also on production server. Maybe i did something wrong during an
update.
To rule out faulty upgrade, could you try to reproduce the problem on
clean Tomcat 7.0.42 install?

-Ognjen
Edoardo Panfili
2013-10-18 05:34:36 UTC
Permalink
Post by Ognjen Blagojevic
Edoardo,
Post by Edoardo Panfili
Some release ago (tomcat 7.0.x sorry, I can't be more precise) all was
well also on production server. Maybe i did something wrong during an
update.
To rule out faulty upgrade, could you try to reproduce the problem on
clean Tomcat 7.0.42 install?
the problem was surely present with 7.0.39, the 7.0.42 is a fresh
installation for me.

thank you
Edoardo
Ognjen Blagojevic
2013-10-18 06:43:33 UTC
Permalink
Post by Edoardo Panfili
Post by Ognjen Blagojevic
To rule out faulty upgrade, could you try to reproduce the problem on
clean Tomcat 7.0.42 install?
the problem was surely present with 7.0.39, the 7.0.42 is a fresh
installation for me.
Could you please clarify: does the problem exists on 7.0.42, 7.0.39 or both?

Could you provide steps to reproduce the problem on fresh 7.0.42
installation?

I tried to reproduce with the information you provided so far, but I was
unable. It works for me.

-Ognjen
Edoardo Panfili
2013-10-18 13:08:18 UTC
Permalink
Post by Ognjen Blagojevic
Post by Edoardo Panfili
Post by Ognjen Blagojevic
To rule out faulty upgrade, could you try to reproduce the problem on
clean Tomcat 7.0.42 install?
the problem was surely present with 7.0.39, the 7.0.42 is a fresh
installation for me.
Could you please clarify: does the problem exists on 7.0.42, 7.0.39 or both?
both
Post by Ognjen Blagojevic
Could you provide steps to reproduce the problem on fresh 7.0.42
installation?
- unpack tomcat
- modify listen port
- modify tomcat-users.xml
- copy jmxremote.access and jmxremote.password (setting permissions)
- build jsvc
- copy configuration files for applications (in
$tomcat/conf/Catalina/localhost)

thank you for you question: also jmx remote access is not working (in
both tomcat 7.0.39 and 7.0.42), maybe the two problems are related?
Post by Ognjen Blagojevic
I tried to reproduce with the information you provided so far, but I was
unable. It works for me.
Also on my local machine, where jmx is not configured.



thank you
Edoardo
André Warnier
2013-10-18 14:40:30 UTC
Permalink
Post by Edoardo Panfili
Post by Ognjen Blagojevic
Post by Edoardo Panfili
Post by Ognjen Blagojevic
To rule out faulty upgrade, could you try to reproduce the problem on
clean Tomcat 7.0.42 install?
the problem was surely present with 7.0.39, the 7.0.42 is a fresh
installation for me.
Could you please clarify: does the problem exists on 7.0.42, 7.0.39 or both?
both
Post by Ognjen Blagojevic
Could you provide steps to reproduce the problem on fresh 7.0.42
installation?
- unpack tomcat
- modify listen port
- modify tomcat-users.xml
- copy jmxremote.access and jmxremote.password (setting permissions)
- build jsvc
- copy configuration files for applications (in
$tomcat/conf/Catalina/localhost)
thank you for you question: also jmx remote access is not working (in
both tomcat 7.0.39 and 7.0.42), maybe the two problems are related?
Post by Ognjen Blagojevic
I tried to reproduce with the information you provided so far, but I was
unable. It works for me.
Also on my local machine, where jmx is not configured.
Usually, a good place to look first, are the Tomcat logfiles.
What do they say ?
Edoardo Panfili
2013-10-18 15:01:05 UTC
Permalink
Post by André Warnier
Post by Edoardo Panfili
Post by Ognjen Blagojevic
Post by Edoardo Panfili
Post by Ognjen Blagojevic
To rule out faulty upgrade, could you try to reproduce the problem on
clean Tomcat 7.0.42 install?
the problem was surely present with 7.0.39, the 7.0.42 is a fresh
installation for me.
Could you please clarify: does the problem exists on 7.0.42, 7.0.39 or both?
both
Post by Ognjen Blagojevic
Could you provide steps to reproduce the problem on fresh 7.0.42
installation?
- unpack tomcat
- modify listen port
- modify tomcat-users.xml
- copy jmxremote.access and jmxremote.password (setting permissions)
- build jsvc
- copy configuration files for applications (in
$tomcat/conf/Catalina/localhost)
thank you for you question: also jmx remote access is not working (in
both tomcat 7.0.39 and 7.0.42), maybe the two problems are related?
Post by Ognjen Blagojevic
I tried to reproduce with the information you provided so far, but I was
unable. It works for me.
Also on my local machine, where jmx is not configured.
Usually, a good place to look first, are the Tomcat logfiles.
What do they say ?
request at 4:48 PM -> reported an exception via curl
request at 4:50 PM -> reported usually problem via curl
request at 4:51 PM -> reported usually problem via curl
...


the only file modified seems to be manager.2013-10-18.log
-------------------------------------------------------------------------------
ott 18, 2013 4:48:17 PM org.apache.catalina.core.ApplicationContext log
Informazioni: Marking servlet Manager as unavailable
ott 18, 2013 4:48:17 PM org.apache.catalina.core.StandardWrapperValve invoke
Grave: Allocate exception for servlet Manager
java.lang.SecurityException: Restricted (ContainerServlet) class
org.apache.catalina.manager.ManagerServlet
at
org.apache.catalina.core.DefaultInstanceManager.checkAccess(DefaultInstanceManager.java:538)
at
org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:511)
at
org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:137)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1144)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:865)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:136)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:611)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)

----------------------------------------
André Warnier
2013-10-18 16:03:09 UTC
Permalink
Post by Edoardo Panfili
Post by André Warnier
Post by Edoardo Panfili
Post by Ognjen Blagojevic
Post by Edoardo Panfili
Post by Ognjen Blagojevic
To rule out faulty upgrade, could you try to reproduce the problem on
clean Tomcat 7.0.42 install?
the problem was surely present with 7.0.39, the 7.0.42 is a fresh
installation for me.
Could you please clarify: does the problem exists on 7.0.42, 7.0.39 or both?
both
Post by Ognjen Blagojevic
Could you provide steps to reproduce the problem on fresh 7.0.42
installation?
- unpack tomcat
- modify listen port
- modify tomcat-users.xml
- copy jmxremote.access and jmxremote.password (setting permissions)
- build jsvc
- copy configuration files for applications (in
$tomcat/conf/Catalina/localhost)
thank you for you question: also jmx remote access is not working (in
both tomcat 7.0.39 and 7.0.42), maybe the two problems are related?
Post by Ognjen Blagojevic
I tried to reproduce with the information you provided so far, but I was
unable. It works for me.
Also on my local machine, where jmx is not configured.
Usually, a good place to look first, are the Tomcat logfiles.
What do they say ?
request at 4:48 PM -> reported an exception via curl
request at 4:50 PM -> reported usually problem via curl
request at 4:51 PM -> reported usually problem via curl
...
the only file modified seems to be manager.2013-10-18.log
-------------------------------------------------------------------------------
ott 18, 2013 4:48:17 PM org.apache.catalina.core.ApplicationContext log
Informazioni: Marking servlet Manager as unavailable
ott 18, 2013 4:48:17 PM org.apache.catalina.core.StandardWrapperValve invoke
Grave: Allocate exception for servlet Manager
java.lang.SecurityException: Restricted (ContainerServlet) class
org.apache.catalina.manager.ManagerServlet
at
org.apache.catalina.core.DefaultInstanceManager.checkAccess(DefaultInstanceManager.java:538)
at
org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:511)
at
org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:137)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1144)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:865)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:136)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:611)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
----------------------------------------
There you go, probably.
You are starting Java with the Security Manager on, and the (tomcat)/conf/catalina.policy
contents somehow conflict with what the Manager app is trying to do.
Are you sure that file came from the Tomcat distribution which you are installing ?
Edoardo Panfili
2013-10-18 16:15:12 UTC
Permalink
Post by André Warnier
Post by Edoardo Panfili
Post by André Warnier
Post by Edoardo Panfili
Post by Ognjen Blagojevic
Post by Edoardo Panfili
Post by Ognjen Blagojevic
To rule out faulty upgrade, could you try to reproduce the problem on
clean Tomcat 7.0.42 install?
the problem was surely present with 7.0.39, the 7.0.42 is a fresh
installation for me.
Could you please clarify: does the problem exists on 7.0.42, 7.0.39 or both?
both
Post by Ognjen Blagojevic
Could you provide steps to reproduce the problem on fresh 7.0.42
installation?
- unpack tomcat
- modify listen port
- modify tomcat-users.xml
- copy jmxremote.access and jmxremote.password (setting permissions)
- build jsvc
- copy configuration files for applications (in
$tomcat/conf/Catalina/localhost)
thank you for you question: also jmx remote access is not working (in
both tomcat 7.0.39 and 7.0.42), maybe the two problems are related?
Post by Ognjen Blagojevic
I tried to reproduce with the information you provided so far, but I was
unable. It works for me.
Also on my local machine, where jmx is not configured.
Usually, a good place to look first, are the Tomcat logfiles.
What do they say ?
request at 4:48 PM -> reported an exception via curl
request at 4:50 PM -> reported usually problem via curl
request at 4:51 PM -> reported usually problem via curl
...
the only file modified seems to be manager.2013-10-18.log
-------------------------------------------------------------------------------
ott 18, 2013 4:48:17 PM org.apache.catalina.core.ApplicationContext log
Informazioni: Marking servlet Manager as unavailable
ott 18, 2013 4:48:17 PM org.apache.catalina.core.StandardWrapperValve invoke
Grave: Allocate exception for servlet Manager
java.lang.SecurityException: Restricted (ContainerServlet) class
org.apache.catalina.manager.ManagerServlet
at
org.apache.catalina.core.DefaultInstanceManager.checkAccess(DefaultInstanceManager.java:538)
at
org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:511)
at
org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:137)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1144)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:865)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:136)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:611)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
----------------------------------------
There you go, probably.
You are starting Java with the Security Manager on, and the
(tomcat)/conf/catalina.policy contents somehow conflict with what the
Manager app is trying to do.
Are you sure that file came from the Tomcat distribution which you are installing ?
catalina.policy is from the original distribution.

this is my setenv.sh

CATALINA_OPTS="-Xmx8192m -Xms2048m -Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=1707
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=true \

-Dcom.sun.management.jmxremote.password.file=/usr/local/tomcat7/conf/jmxremote.password
\

-Dcom.sun.management.jmxremote.access.file=/usr/local/tomcat7/conf/jmxremote.access"


(port 1707 is non accessible from internet)


Edoardo
Edoardo Panfili
2013-10-18 16:04:19 UTC
Permalink
Post by André Warnier
Post by Edoardo Panfili
Post by Ognjen Blagojevic
Post by Edoardo Panfili
Post by Ognjen Blagojevic
To rule out faulty upgrade, could you try to reproduce the problem on
clean Tomcat 7.0.42 install?
the problem was surely present with 7.0.39, the 7.0.42 is a fresh
installation for me.
Could you please clarify: does the problem exists on 7.0.42, 7.0.39 or both?
both
Post by Ognjen Blagojevic
Could you provide steps to reproduce the problem on fresh 7.0.42
installation?
- unpack tomcat
- modify listen port
- modify tomcat-users.xml
- copy jmxremote.access and jmxremote.password (setting permissions)
- build jsvc
- copy configuration files for applications (in
$tomcat/conf/Catalina/localhost)
thank you for you question: also jmx remote access is not working (in
both tomcat 7.0.39 and 7.0.42), maybe the two problems are related?
Post by Ognjen Blagojevic
I tried to reproduce with the information you provided so far, but I was
unable. It works for me.
Also on my local machine, where jmx is not configured.
Usually, a good place to look first, are the Tomcat logfiles.
What do they say ?
searching for "java.lang.SecurityException: Restricted
(ContainerServlet) class org.apache.catalina.manager.ManagerServlet"

seem that the solution is to add privileged="true" at
$tomcat/conf/context.xml... and the "reoload" command now works.

thank you
Edoardo
Caldarale, Charles R
2013-10-18 16:16:46 UTC
Permalink
Subject: Re: can't connect to manager application
seem that the solution is to add privileged="true" at
$tomcat/conf/context.xml... and the "reoload" command now works.
You really, really, really must not do that. Adding privileged="true" to conf/context.xml makes _all_ deployed webapps privileged. The <Context> element for the manager webapp already has privileged="true" in it - unless you took it out.

Note that if you're using a 3rd-party repackaged version of Tomcat, all bets are off. The repackagers frequently make a mess of things, such as the above. Best to use a Tomcat downloaded from tomcat.apache.org.

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Edoardo Panfili
2013-10-18 16:21:14 UTC
Permalink
Post by Caldarale, Charles R
Subject: Re: can't connect to manager application
seem that the solution is to add privileged="true" at
$tomcat/conf/context.xml... and the "reoload" command now works.
You really, really, really must not do that. Adding privileged="true" to conf/context.xml makes _all_ deployed webapps privileged. The <Context> element for the manager webapp already has privileged="true" in it - unless you took it out.
ok, it look not so good for me to change default privileges.
but.. what can I do?
Post by Caldarale, Charles R
Note that if you're using a 3rd-party repackaged version of Tomcat, all bets are off. The repackagers frequently make a mess of things, such as the above. Best to use a Tomcat downloaded from tomcat.apache.org.
I use the tar.gz from tomcat.apche.org.


Edoardo
André Warnier
2013-10-18 16:25:44 UTC
Permalink
Post by Edoardo Panfili
Post by Caldarale, Charles R
Subject: Re: can't connect to manager application
seem that the solution is to add privileged="true" at
$tomcat/conf/context.xml... and the "reoload" command now works.
You really, really, really must not do that. Adding privileged="true"
to conf/context.xml makes _all_ deployed webapps privileged. The
<Context> element for the manager webapp already has privileged="true"
in it - unless you took it out.
ok, it look not so good for me to change default privileges.
but.. what can I do?
Post by Caldarale, Charles R
Note that if you're using a 3rd-party repackaged version of Tomcat,
all bets are off. The repackagers frequently make a mess of things,
such as the above. Best to use a Tomcat downloaded from
tomcat.apache.org.
I use the tar.gz from tomcat.apche.org.
It could be that there is an error in the catalina.policy file of the standard distribution.
Many people do not run with the Java Security Manager enabled, so it may have been
unnoticed until now.
Or else, you are running a newer version of Tomcat with an older version of this file.
Edoardo Panfili
2013-10-18 16:32:50 UTC
Permalink
Post by André Warnier
Post by Edoardo Panfili
Post by Caldarale, Charles R
Subject: Re: can't connect to manager application
seem that the solution is to add privileged="true" at
$tomcat/conf/context.xml... and the "reoload" command now works.
You really, really, really must not do that. Adding
privileged="true" to conf/context.xml makes _all_ deployed webapps
privileged. The <Context> element for the manager webapp already has
privileged="true" in it - unless you took it out.
ok, it look not so good for me to change default privileges.
but.. what can I do?
Post by Caldarale, Charles R
Note that if you're using a 3rd-party repackaged version of Tomcat,
all bets are off. The repackagers frequently make a mess of things,
such as the above. Best to use a Tomcat downloaded from
tomcat.apache.org.
I use the tar.gz from tomcat.apche.org.
It could be that there is an error in the catalina.policy file of the
standard distribution.
maybe, but an error from my side is more probable!
Post by André Warnier
Many people do not run with the Java Security Manager enabled, so it may
have been unnoticed until now.
removing my setenv.sh this is the command that starts tomcat (from ps)
jsvc.exec -java-home /usr/lib/jvm/java-6-openjdk/ -user tomcat -pidfile
/usr/local/tomcat7/logs/catalina-daemon.pid -wait 10 -outfile
/usr/local/tomcat7/logs/catalina-daemon.out -errfile &1 -classpath
/usr/local/tomcat7/bin/bootstrap.jar:/usr/local/tomcat7/bin/commons-daemon.jar:/usr/local/tomcat7/bin/tomcat-juli.jar
-Djava.util.logging.config.file=/usr/local/tomcat7/conf/logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.endorsed.dirs= -Dcatalina.base=/usr/local/tomcat7
-Dcatalina.home=/usr/local/tomcat7
-Djava.io.tmpdir=/usr/local/tomcat7/temp
org.apache.catalina.startup.Bootstrap

using my setenv.sh
jsvc.exec -java-home /usr/local/jdk1.7.0_40 -user tomcat -pidfile
/usr/local/tomcat7/logs/catalina-daemon.pid -wait 10 -outfile
/usr/local/tomcat7/logs/catalina-daemon.out -errfile &1 -classpath
/usr/local/tomcat7/bin/bootstrap.jar:/usr/local/tomcat7/bin/commons-daemon.jar:/usr/local/tomcat7/bin/tomcat-juli.jar
-Djava.util.logging.config.file=/usr/local/tomcat7/conf/logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Xmx8192m -Xms2048m -Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=1707
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=true
-Dcom.sun.management.jmxremote.password.file=/usr/local/tomcat7/conf/jmxremote.password
-Dcom.sun.management.jmxremote.access.file=/usr/local/tomcat7/conf/jmxremote.access
-Djava.endorsed.dirs= -Dcatalina.base=/usr/local/tomcat7
-Dcatalina.home=/usr/local/tomcat7
-Djava.io.tmpdir=/usr/local/tomcat7/temp
org.apache.catalina.startup.Bootstrap


but in both the situations "reload" does not works.
Post by André Warnier
Or else, you are running a newer version of Tomcat with an older version of this file.
I recheck my "Tomcat update todo list", catalina.policy is not moved.


Edoardo
Christopher Schultz
2013-10-18 16:17:52 UTC
Permalink
Edoardo,
Post by Edoardo Panfili
Post by André Warnier
Post by Ognjen Blagojevic
Post by Edoardo Panfili
Post by Ognjen Blagojevic
To rule out faulty upgrade, could you try to reproduce
the problem on clean Tomcat 7.0.42 install?
the problem was surely present with 7.0.39, the 7.0.42 is a
fresh installation for me.
Could you please clarify: does the problem exists on 7.0.42, 7.0.39 or both?
both
Post by Ognjen Blagojevic
Could you provide steps to reproduce the problem on fresh
7.0.42 installation?
- unpack tomcat - modify listen port - modify tomcat-users.xml
- copy jmxremote.access and jmxremote.password (setting
permissions) - build jsvc - copy configuration files for
applications (in $tomcat/conf/Catalina/localhost)
thank you for you question: also jmx remote access is not
working (in both tomcat 7.0.39 and 7.0.42), maybe the two
problems are related?
Post by Ognjen Blagojevic
I tried to reproduce with the information you provided so
far, but I was unable. It works for me.
Also on my local machine, where jmx is not configured.
Usually, a good place to look first, are the Tomcat logfiles.
What do they say ?
searching for "java.lang.SecurityException: Restricted
(ContainerServlet) class
org.apache.catalina.manager.ManagerServlet"
seem that the solution is to add privileged="true" at
$tomcat/conf/context.xml... and the "reoload" command now works.
No no no no no no no no no do not do that: you will make every webapp
deployed on Tomcat privileged.

Tomcat's manager should already be set to privileged="true". Are you
sure you didn't change anything else?

- -chris
Edoardo Panfili
2013-10-18 16:28:26 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Edoardo,
Post by Edoardo Panfili
Post by André Warnier
Post by Ognjen Blagojevic
Post by Edoardo Panfili
Post by Ognjen Blagojevic
To rule out faulty upgrade, could you try to reproduce
the problem on clean Tomcat 7.0.42 install?
the problem was surely present with 7.0.39, the 7.0.42 is a
fresh installation for me.
Could you please clarify: does the problem exists on 7.0.42, 7.0.39 or both?
both
Post by Ognjen Blagojevic
Could you provide steps to reproduce the problem on fresh
7.0.42 installation?
- unpack tomcat - modify listen port - modify tomcat-users.xml
- copy jmxremote.access and jmxremote.password (setting
permissions) - build jsvc - copy configuration files for
applications (in $tomcat/conf/Catalina/localhost)
thank you for you question: also jmx remote access is not
working (in both tomcat 7.0.39 and 7.0.42), maybe the two
problems are related?
Post by Ognjen Blagojevic
I tried to reproduce with the information you provided so
far, but I was unable. It works for me.
Also on my local machine, where jmx is not configured.
Usually, a good place to look first, are the Tomcat logfiles.
What do they say ?
searching for "java.lang.SecurityException: Restricted
(ContainerServlet) class
org.apache.catalina.manager.ManagerServlet"
seem that the solution is to add privileged="true" at
$tomcat/conf/context.xml... and the "reoload" command now works.
No no no no no no no no no do not do that: you will make every webapp
deployed on Tomcat privileged.
ok, right, context.xml is back to the original.
Tomcat's manager should already be set to privileged="true". Are you
sure you didn't change anything else?
setenv.sh but... removing it nothing changes from this point of view.

Edoardo.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSYV8wAAoJEBzwKT+lPKRYnhIP/0ejZVnJcccOybCnqcE099fq
sFXhX7lspGM/3W3CwcRa6qDJGsuFxKr33I520Hw9JRku+HQRBrOLFjPpwHi4nLSF
gRt/tddEVNNDaTlojOCLgRyJNcRvnuBeJ12EOnTYmf5aQCNowm3ZR92nTCYFNsVM
jCFI8LXYpTl+VaiSA2dFPKL3FLlF8OcLujlnGmjg82IT0T34dLWpxSuHNV3Y87UY
8s0MJZIy1W5asrrpQLYG79VauZnwjTNnsfHV/KrsCBpP+Jw1xa9qKfRXeVlFJIg6
bWeJl4E8EIzx6nHHbuzF8cfb/OaxIkMxqC0CvM4gP1VVvljUllii0g1o2IBkZpnx
60Ad48NnqNaDjIfBzI19xCpoUOwttJSW6xyXRGET0kpIwJaSo984rSQWwcOWGXFH
XcJ4M/7uqh/cEJsGTTEtzOsHHAN3k02Rf1kRldoje8QOt8h35seJW9iRbCPEhcxT
DJOzMo+DDzZaBpdbNx1ukwOHWT6Hjf4S5q8Ft45atKmJGBjYQIvXECF8wdv52xxq
bOhDXx6G0uxnDiGxE7oboTVWYGt173reXidwKSy+FwtGv2dpB9jBL0doOStsggZE
slafDt1d1inumAtavC1TeJGX14aoLThaiLkJuj6KduroEWgI4UNQ/TnuDwuGFsdx
OZ0BksCbGVyrrjWxBAXf
=LzpS
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
André Warnier
2013-10-18 16:38:58 UTC
Permalink
Post by Edoardo Panfili
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Edoardo,
Post by Edoardo Panfili
Post by André Warnier
Post by Ognjen Blagojevic
Post by Edoardo Panfili
Post by Ognjen Blagojevic
To rule out faulty upgrade, could you try to reproduce
the problem on clean Tomcat 7.0.42 install?
the problem was surely present with 7.0.39, the 7.0.42 is a
fresh installation for me.
Could you please clarify: does the problem exists on 7.0.42, 7.0.39 or both?
both
Post by Ognjen Blagojevic
Could you provide steps to reproduce the problem on fresh
7.0.42 installation?
- unpack tomcat - modify listen port - modify tomcat-users.xml
- copy jmxremote.access and jmxremote.password (setting
permissions) - build jsvc - copy configuration files for
applications (in $tomcat/conf/Catalina/localhost)
thank you for you question: also jmx remote access is not
working (in both tomcat 7.0.39 and 7.0.42), maybe the two
problems are related?
Post by Ognjen Blagojevic
I tried to reproduce with the information you provided so
far, but I was unable. It works for me.
Also on my local machine, where jmx is not configured.
Usually, a good place to look first, are the Tomcat logfiles.
What do they say ?
searching for "java.lang.SecurityException: Restricted
(ContainerServlet) class
org.apache.catalina.manager.ManagerServlet"
seem that the solution is to add privileged="true" at
$tomcat/conf/context.xml... and the "reoload" command now works.
No no no no no no no no no do not do that: you will make every webapp
deployed on Tomcat privileged.
ok, right, context.xml is back to the original.
Tomcat's manager should already be set to privileged="true". Are you
sure you didn't change anything else?
setenv.sh but... removing it nothing changes from this point of view.
Do you need to run with the Java Security Manager enabled ?

As far as I know, it only really helps when you allow the installation of apps of which
you do not know if they are secure or not.
Edoardo Panfili
2013-10-18 16:45:18 UTC
Permalink
Post by André Warnier
Post by Edoardo Panfili
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Edoardo,
Post by Edoardo Panfili
Post by André Warnier
Post by Ognjen Blagojevic
Post by Edoardo Panfili
Post by Ognjen Blagojevic
To rule out faulty upgrade, could you try to reproduce
the problem on clean Tomcat 7.0.42 install?
the problem was surely present with 7.0.39, the 7.0.42 is a
fresh installation for me.
Could you please clarify: does the problem exists on 7.0.42, 7.0.39 or both?
both
Post by Ognjen Blagojevic
Could you provide steps to reproduce the problem on fresh
7.0.42 installation?
- unpack tomcat - modify listen port - modify tomcat-users.xml
- copy jmxremote.access and jmxremote.password (setting
permissions) - build jsvc - copy configuration files for
applications (in $tomcat/conf/Catalina/localhost)
thank you for you question: also jmx remote access is not
working (in both tomcat 7.0.39 and 7.0.42), maybe the two
problems are related?
Post by Ognjen Blagojevic
I tried to reproduce with the information you provided so
far, but I was unable. It works for me.
Also on my local machine, where jmx is not configured.
Usually, a good place to look first, are the Tomcat logfiles.
What do they say ?
searching for "java.lang.SecurityException: Restricted
(ContainerServlet) class
org.apache.catalina.manager.ManagerServlet"
seem that the solution is to add privileged="true" at
$tomcat/conf/context.xml... and the "reoload" command now works.
No no no no no no no no no do not do that: you will make every webapp
deployed on Tomcat privileged.
ok, right, context.xml is back to the original.
Tomcat's manager should already be set to privileged="true". Are you
sure you didn't change anything else?
setenv.sh but... removing it nothing changes from this point of view.
Do you need to run with the Java Security Manager enabled ?
no, there are only trusted applications.
Post by André Warnier
As far as I know, it only really helps when you allow the installation
of apps of which you do not know if they are secure or not.
but the only thing that I changed (for java security management) is
setenv.sh and removing it nothing changes. Am I missing something?

I will try a step by step install on another machine (can't do this on
production server)

Edoardo
André Warnier
2013-10-18 16:53:11 UTC
Permalink
Post by Edoardo Panfili
Post by André Warnier
Post by Edoardo Panfili
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Edoardo,
Post by Edoardo Panfili
Post by André Warnier
Post by Ognjen Blagojevic
Post by Edoardo Panfili
Post by Ognjen Blagojevic
To rule out faulty upgrade, could you try to reproduce
the problem on clean Tomcat 7.0.42 install?
the problem was surely present with 7.0.39, the 7.0.42 is a
fresh installation for me.
Could you please clarify: does the problem exists on 7.0.42, 7.0.39 or both?
both
Post by Ognjen Blagojevic
Could you provide steps to reproduce the problem on fresh
7.0.42 installation?
- unpack tomcat - modify listen port - modify tomcat-users.xml
- copy jmxremote.access and jmxremote.password (setting
permissions) - build jsvc - copy configuration files for
applications (in $tomcat/conf/Catalina/localhost)
thank you for you question: also jmx remote access is not
working (in both tomcat 7.0.39 and 7.0.42), maybe the two
problems are related?
Post by Ognjen Blagojevic
I tried to reproduce with the information you provided so
far, but I was unable. It works for me.
Also on my local machine, where jmx is not configured.
Usually, a good place to look first, are the Tomcat logfiles.
What do they say ?
searching for "java.lang.SecurityException: Restricted
(ContainerServlet) class
org.apache.catalina.manager.ManagerServlet"
seem that the solution is to add privileged="true" at
$tomcat/conf/context.xml... and the "reoload" command now works.
No no no no no no no no no do not do that: you will make every webapp
deployed on Tomcat privileged.
ok, right, context.xml is back to the original.
Tomcat's manager should already be set to privileged="true". Are you
sure you didn't change anything else?
setenv.sh but... removing it nothing changes from this point of view.
Do you need to run with the Java Security Manager enabled ?
no, there are only trusted applications.
Post by André Warnier
As far as I know, it only really helps when you allow the installation
of apps of which you do not know if they are secure or not.
but the only thing that I changed (for java security management) is
setenv.sh and removing it nothing changes. Am I missing something?
I will try a step by step install on another machine (can't do this on
production server)
By the way (and nothing to do with your current problem), I see the arguments :
-Xmx8192m -Xms2048m
It is usually recommended to set them at the same value, for a server. It gains some
efficiency, by stopping Java from resizing the Heap regularly.
Edoardo Panfili
2013-10-18 16:55:38 UTC
Permalink
Post by Edoardo Panfili
Post by Edoardo Panfili
Post by André Warnier
Post by Edoardo Panfili
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Edoardo,
Post by Edoardo Panfili
Post by André Warnier
Post by Ognjen Blagojevic
Post by Edoardo Panfili
Post by Ognjen Blagojevic
To rule out faulty upgrade, could you try to reproduce
the problem on clean Tomcat 7.0.42 install?
the problem was surely present with 7.0.39, the 7.0.42 is a
fresh installation for me.
Could you please clarify: does the problem exists on 7.0.42,
7.0.39 or both?
both
Post by Ognjen Blagojevic
Could you provide steps to reproduce the problem on fresh
7.0.42 installation?
- unpack tomcat - modify listen port - modify tomcat-users.xml
- copy jmxremote.access and jmxremote.password (setting
permissions) - build jsvc - copy configuration files for
applications (in $tomcat/conf/Catalina/localhost)
thank you for you question: also jmx remote access is not
working (in both tomcat 7.0.39 and 7.0.42), maybe the two
problems are related?
Post by Ognjen Blagojevic
I tried to reproduce with the information you provided so
far, but I was unable. It works for me.
Also on my local machine, where jmx is not configured.
Usually, a good place to look first, are the Tomcat logfiles.
What do they say ?
searching for "java.lang.SecurityException: Restricted
(ContainerServlet) class
org.apache.catalina.manager.ManagerServlet"
seem that the solution is to add privileged="true" at
$tomcat/conf/context.xml... and the "reoload" command now works.
No no no no no no no no no do not do that: you will make every webapp
deployed on Tomcat privileged.
ok, right, context.xml is back to the original.
Tomcat's manager should already be set to privileged="true". Are you
sure you didn't change anything else?
setenv.sh but... removing it nothing changes from this point of view.
Do you need to run with the Java Security Manager enabled ?
no, there are only trusted applications.
Post by André Warnier
As far as I know, it only really helps when you allow the installation
of apps of which you do not know if they are secure or not.
but the only thing that I changed (for java security management) is
setenv.sh and removing it nothing changes. Am I missing something?
I will try a step by step install on another machine (can't do this on
production server)
-Xmx8192m -Xms2048m
It is usually recommended to set them at the same value, for a server.
It gains some efficiency, by stopping Java from resizing the Heap
regularly.
maybe OT but appreciated,

thank you
Edoardo
Christopher Schultz
2013-10-18 16:55:49 UTC
Permalink
André,
Post by André Warnier
Post by Edoardo Panfili
Post by André Warnier
Post by Edoardo Panfili
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Edoardo,
Post by Edoardo Panfili
Post by André Warnier
Post by Ognjen Blagojevic
Post by Edoardo Panfili
Post by Ognjen Blagojevic
To rule out faulty upgrade, could you try to
reproduce the problem on clean Tomcat 7.0.42
install?
the problem was surely present with 7.0.39, the
7.0.42 is a fresh installation for me.
Could you please clarify: does the problem exists
on 7.0.42, 7.0.39 or both?
both
Post by Ognjen Blagojevic
Could you provide steps to reproduce the problem on
fresh 7.0.42 installation?
- unpack tomcat - modify listen port - modify
tomcat-users.xml - copy jmxremote.access and
jmxremote.password (setting permissions) - build jsvc
- copy configuration files for applications (in
$tomcat/conf/Catalina/localhost)
thank you for you question: also jmx remote access is
not working (in both tomcat 7.0.39 and 7.0.42), maybe
the two problems are related?
Post by Ognjen Blagojevic
I tried to reproduce with the information you
provided so far, but I was unable. It works for
me.
Also on my local machine, where jmx is not
configured.
Usually, a good place to look first, are the Tomcat
logfiles. What do they say ?
searching for "java.lang.SecurityException: Restricted
(ContainerServlet) class
org.apache.catalina.manager.ManagerServlet"
seem that the solution is to add privileged="true" at
$tomcat/conf/context.xml... and the "reoload" command now
works.
No no no no no no no no no do not do that: you will make
every webapp deployed on Tomcat privileged.
ok, right, context.xml is back to the original.
Tomcat's manager should already be set to
privileged="true". Are you sure you didn't change anything
else?
setenv.sh but... removing it nothing changes from this point of view.
Do you need to run with the Java Security Manager enabled ?
no, there are only trusted applications.
Post by André Warnier
As far as I know, it only really helps when you allow the
installation of apps of which you do not know if they are
secure or not.
but the only thing that I changed (for java security management)
is setenv.sh and removing it nothing changes. Am I missing
something?
I will try a step by step install on another machine (can't do
this on production server)
By the way (and nothing to do with your current problem), I see
the arguments : -Xmx8192m -Xms2048m It is usually recommended to
set them at the same value, for a server. It gains some efficiency,
by stopping Java from resizing the Heap regularly.
He's using jsvc anyway, so setenv.sh pretty much has no meaning.

I think there's a lot more going on than Edoardo is telling us. I
think lots of things are changing between reports and we cannot keep
up. A fresh install is the way to go and to see some up-to-date error
messages. It's clear that his current install is a shambles at this point.

- -chris
Martin Gainty
2013-10-18 16:29:51 UTC
Permalink
Date: Fri, 18 Oct 2013 18:04:19 +0200
Subject: Re: can't connect to manager application
Post by André Warnier
Post by Edoardo Panfili
Post by Ognjen Blagojevic
Post by Edoardo Panfili
Post by Ognjen Blagojevic
To rule out faulty upgrade, could you try to reproduce the problem on
clean Tomcat 7.0.42 install?
the problem was surely present with 7.0.39, the 7.0.42 is a fresh
installation for me.
Could you please clarify: does the problem exists on 7.0.42, 7.0.39 or both?
both
Post by Ognjen Blagojevic
Could you provide steps to reproduce the problem on fresh 7.0.42
installation?
- unpack tomcat
- modify listen port
- modify tomcat-users.xml
- copy jmxremote.access and jmxremote.password (setting permissions)
- build jsvc
- copy configuration files for applications (in
$tomcat/conf/Catalina/localhost)
thank you for you question: also jmx remote access is not working (in
both tomcat 7.0.39 and 7.0.42), maybe the two problems are related?
Post by Ognjen Blagojevic
I tried to reproduce with the information you provided so far, but I was
unable. It works for me.
Also on my local machine, where jmx is not configured.
Usually, a good place to look first, are the Tomcat logfiles.
What do they say ?
searching for "java.lang.SecurityException: Restricted
(ContainerServlet) class org.apache.catalina.manager.ManagerServlet"
<MG>my HostManagerServlet is defined in webapps/host-manager/WEB-INF/web.xml as:
<servlet>
<servlet-name>HostManager</servlet-name>
<servlet-class>org.apache.catalina.manager.host.HostManagerServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>2</param-value>
</init-param>
</servlet>
<servlet>
<servlet-name>HTMLHostManager</servlet-name>
<servlet-class>org.apache.catalina.manager.host.HTMLHostManagerServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>2</param-value>
</init-param>
</servlet>
</MG>
seem that the solution is to add privileged="true"
<MG>my privileged attr in Context is located at /webapps/host-manager/META-INF/context.xml as:
<Context antiResourceLocking="false" privileged="true" />
</MG>

at
$tomcat/conf/context.xml... and the "reoload" command now works.
thank you
Edoardo
MG>molte grazie Edoardo
MG>Martin
---------------------------------------------------------------------
Edoardo Panfili
2013-10-18 16:38:04 UTC
Permalink
Post by Martin Gainty
Date: Fri, 18 Oct 2013 18:04:19 +0200
Subject: Re: can't connect to manager application
Post by André Warnier
Post by Edoardo Panfili
Post by Ognjen Blagojevic
Post by Edoardo Panfili
Post by Ognjen Blagojevic
To rule out faulty upgrade, could you try to reproduce the problem on
clean Tomcat 7.0.42 install?
the problem was surely present with 7.0.39, the 7.0.42 is a fresh
installation for me.
Could you please clarify: does the problem exists on 7.0.42, 7.0.39 or both?
both
Post by Ognjen Blagojevic
Could you provide steps to reproduce the problem on fresh 7.0.42
installation?
- unpack tomcat
- modify listen port
- modify tomcat-users.xml
- copy jmxremote.access and jmxremote.password (setting permissions)
- build jsvc
- copy configuration files for applications (in
$tomcat/conf/Catalina/localhost)
thank you for you question: also jmx remote access is not working (in
both tomcat 7.0.39 and 7.0.42), maybe the two problems are related?
Post by Ognjen Blagojevic
I tried to reproduce with the information you provided so far, but I was
unable. It works for me.
Also on my local machine, where jmx is not configured.
Usually, a good place to look first, are the Tomcat logfiles.
What do they say ?
searching for "java.lang.SecurityException: Restricted
(ContainerServlet) class org.apache.catalina.manager.ManagerServlet"
<servlet>
<servlet-name>HostManager</servlet-name>
<servlet-class>org.apache.catalina.manager.host.HostManagerServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>2</param-value>
</init-param>
</servlet>
<servlet>
<servlet-name>HTMLHostManager</servlet-name>
<servlet-class>org.apache.catalina.manager.host.HTMLHostManagerServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>2</param-value>
</init-param>
</servlet>
</MG>
the same for me.
Post by Martin Gainty
seem that the solution is to add privileged="true"
<Context antiResourceLocking="false" privileged="true" />
also this, the same.

I can try with a new install (as suggested from Ognjen )

then try to use manager before install jsvc and befor setting the jmx
properties.

thank you to all
Edoardo
Christopher Schultz
2013-10-18 16:40:54 UTC
Permalink
Edoardo,
Post by Edoardo Panfili
Post by Martin Gainty
manager application
Post by André Warnier
Post by Ognjen Blagojevic
Post by Edoardo Panfili
Post by Ognjen Blagojevic
To rule out faulty upgrade, could you try to
reproduce the problem on clean Tomcat 7.0.42
install?
the problem was surely present with 7.0.39, the 7.0.42
is a fresh installation for me.
Could you please clarify: does the problem exists on
7.0.42, 7.0.39 or both?
both
Post by Ognjen Blagojevic
Could you provide steps to reproduce the problem on fresh
7.0.42 installation?
- unpack tomcat - modify listen port - modify
tomcat-users.xml - copy jmxremote.access and
jmxremote.password (setting permissions) - build jsvc -
copy configuration files for applications (in
$tomcat/conf/Catalina/localhost)
thank you for you question: also jmx remote access is not
working (in both tomcat 7.0.39 and 7.0.42), maybe the two
problems are related?
Post by Ognjen Blagojevic
I tried to reproduce with the information you provided so
far, but I was unable. It works for me.
Also on my local machine, where jmx is not configured.
Usually, a good place to look first, are the Tomcat
logfiles. What do they say ?
searching for "java.lang.SecurityException: Restricted
(ContainerServlet) class
org.apache.catalina.manager.ManagerServlet"
<MG>my HostManagerServlet is defined in
webapps/host-manager/WEB-INF/web.xml as: <servlet>
<servlet-name>HostManager</servlet-name>
<servlet-class>org.apache.catalina.manager.host.HostManagerServlet</servlet-class>
<init-param>
Post by Edoardo Panfili
Post by Martin Gainty
<param-name>debug</param-name> <param-value>2</param-value>
</init-param> </servlet> <servlet>
<servlet-name>HTMLHostManager</servlet-name>
<servlet-class>org.apache.catalina.manager.host.HTMLHostManagerServlet</servlet-class>
<init-param>
Post by Edoardo Panfili
Post by Martin Gainty
<param-name>debug</param-name> <param-value>2</param-value>
</init-param> </servlet> </MG>
the same for me.
Post by Martin Gainty
seem that the solution is to add privileged="true"
<MG>my privileged attr in Context is located at
/webapps/host-manager/META-INF/context.xml as: <Context
antiResourceLocking="false" privileged="true" />
also this, the same.
I can try with a new install (as suggested from Ognjen )
then try to use manager before install jsvc and befor setting the
jmx properties.
Neither jsvc nor jmx should have any effect on what you are seeing. I
would like to confirm that, however. Let us know what you discover.

The SecurityException is certainly going to be a problem. It's odd
that you saw the SecurityException which should fail to deploy the
Manager, yet you are seeing the Manager's 404-not-found page which
would require the Manager to be deployed.

Can you stop Tomcat, delete all log files, and then restart? If/when
you see that failure (should be easy to reproduce: just use curl,
right?) then post the entire catalina.out file.

- -chris
André Warnier
2013-10-18 16:48:08 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Edoardo,
Post by Edoardo Panfili
Post by Martin Gainty
manager application
Post by André Warnier
Post by Ognjen Blagojevic
Post by Edoardo Panfili
Post by Ognjen Blagojevic
To rule out faulty upgrade, could you try to
reproduce the problem on clean Tomcat 7.0.42
install?
the problem was surely present with 7.0.39, the 7.0.42
is a fresh installation for me.
Could you please clarify: does the problem exists on
7.0.42, 7.0.39 or both?
both
Post by Ognjen Blagojevic
Could you provide steps to reproduce the problem on fresh
7.0.42 installation?
- unpack tomcat - modify listen port - modify
tomcat-users.xml - copy jmxremote.access and
jmxremote.password (setting permissions) - build jsvc -
copy configuration files for applications (in
$tomcat/conf/Catalina/localhost)
thank you for you question: also jmx remote access is not
working (in both tomcat 7.0.39 and 7.0.42), maybe the two
problems are related?
Post by Ognjen Blagojevic
I tried to reproduce with the information you provided so
far, but I was unable. It works for me.
Also on my local machine, where jmx is not configured.
Usually, a good place to look first, are the Tomcat
logfiles. What do they say ?
searching for "java.lang.SecurityException: Restricted
(ContainerServlet) class
org.apache.catalina.manager.ManagerServlet"
<MG>my HostManagerServlet is defined in
webapps/host-manager/WEB-INF/web.xml as: <servlet>
<servlet-name>HostManager</servlet-name>
<servlet-class>org.apache.catalina.manager.host.HostManagerServlet</servlet-class>
<init-param>
Post by Edoardo Panfili
Post by Martin Gainty
<param-name>debug</param-name> <param-value>2</param-value>
</init-param> </servlet> <servlet>
<servlet-name>HTMLHostManager</servlet-name>
<servlet-class>org.apache.catalina.manager.host.HTMLHostManagerServlet</servlet-class>
<init-param>
Post by Edoardo Panfili
Post by Martin Gainty
<param-name>debug</param-name> <param-value>2</param-value>
</init-param> </servlet> </MG>
the same for me.
Post by Martin Gainty
seem that the solution is to add privileged="true"
<MG>my privileged attr in Context is located at
/webapps/host-manager/META-INF/context.xml as: <Context
antiResourceLocking="false" privileged="true" />
also this, the same.
I can try with a new install (as suggested from Ognjen )
then try to use manager before install jsvc and befor setting the
jmx properties.
Neither jsvc nor jmx should have any effect on what you are seeing. I
would like to confirm that, however. Let us know what you discover.
The SecurityException is certainly going to be a problem. It's odd
that you saw the SecurityException which should fail to deploy the
Manager, yet you are seeing the Manager's 404-not-found page which
would require the Manager to be deployed.
The logfile says :

Informazioni: Marking servlet Manager as unavailable
ott 18, 2013 4:48:17 PM org.apache.catalina.core.StandardWrapperValve
invoke
Grave: Allocate exception for servlet Manager
java.lang.SecurityException: Restricted (ContainerServlet) class
org.apache.catalina.manager.ManagerServlet

So to my (admittedly untrained) eyes, it may look like the Manager application (and its
static pages) is deployed, but it is when it's servlet is starting to run that the Java
Security Manager shoots it down..
It doesn't for that undeploy the whole app I guess.
Christopher Schultz
2013-10-18 16:56:33 UTC
Permalink
André,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Edoardo,
Post by Edoardo Panfili
Post by Martin Gainty
can't connect to manager application
Post by André Warnier
Post by Ognjen Blagojevic
Post by Edoardo Panfili
Post by Ognjen Blagojevic
To rule out faulty upgrade, could you try to
reproduce the problem on clean Tomcat 7.0.42
install?
the problem was surely present with 7.0.39, the
7.0.42 is a fresh installation for me.
Could you please clarify: does the problem exists on
7.0.42, 7.0.39 or both?
both
Post by Ognjen Blagojevic
Could you provide steps to reproduce the problem on
fresh 7.0.42 installation?
- unpack tomcat - modify listen port - modify
tomcat-users.xml - copy jmxremote.access and
jmxremote.password (setting permissions) - build jsvc
- copy configuration files for applications (in
$tomcat/conf/Catalina/localhost)
thank you for you question: also jmx remote access is
not working (in both tomcat 7.0.39 and 7.0.42), maybe
the two problems are related?
Post by Ognjen Blagojevic
I tried to reproduce with the information you
provided so far, but I was unable. It works for me.
Also on my local machine, where jmx is not configured.
Usually, a good place to look first, are the Tomcat
logfiles. What do they say ?
searching for "java.lang.SecurityException: Restricted
(ContainerServlet) class
org.apache.catalina.manager.ManagerServlet"
<MG>my HostManagerServlet is defined in
webapps/host-manager/WEB-INF/web.xml as: <servlet>
<servlet-name>HostManager</servlet-name>
<servlet-class>org.apache.catalina.manager.host.HostManagerServlet</servlet-class>
<init-param>
Post by Edoardo Panfili
Post by Martin Gainty
<param-name>debug</param-name> <param-value>2</param-value>
</init-param> </servlet> <servlet>
<servlet-name>HTMLHostManager</servlet-name>
<servlet-class>org.apache.catalina.manager.host.HTMLHostManagerServlet</servlet-class>
<init-param>
Post by Edoardo Panfili
Post by Martin Gainty
<param-name>debug</param-name> <param-value>2</param-value>
</init-param> </servlet> </MG>
the same for me.
Post by Martin Gainty
seem that the solution is to add privileged="true"
<MG>my privileged attr in Context is located at
/webapps/host-manager/META-INF/context.xml as: <Context
antiResourceLocking="false" privileged="true" />
also this, the same.
I can try with a new install (as suggested from Ognjen )
then try to use manager before install jsvc and befor setting
the jmx properties.
Neither jsvc nor jmx should have any effect on what you are
seeing. I would like to confirm that, however. Let us know what
you discover.
The SecurityException is certainly going to be a problem. It's
odd that you saw the SecurityException which should fail to
deploy the Manager, yet you are seeing the Manager's
404-not-found page which would require the Manager to be
deployed.
Informazioni: Marking servlet Manager as unavailable ott 18, 2013
4:48:17 PM org.apache.catalina.core.StandardWrapperValve invoke
Grave: Allocate exception for servlet Manager
java.lang.SecurityException: Restricted (ContainerServlet) class
org.apache.catalina.manager.ManagerServlet
So to my (admittedly untrained) eyes, it may look like the Manager
application (and its static pages) is deployed, but it is when
it's servlet is starting to run that the Java Security Manager
shoots it down.. It doesn't for that undeploy the whole app I
guess.
Thanks for pointing that out; it makes much more sense given that
explanation.

- -chris
André Warnier
2013-10-18 17:17:55 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
André,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Edoardo,
Post by Edoardo Panfili
Post by Martin Gainty
can't connect to manager application
Post by André Warnier
Post by Ognjen Blagojevic
Post by Edoardo Panfili
Post by Ognjen Blagojevic
To rule out faulty upgrade, could you try to
reproduce the problem on clean Tomcat 7.0.42
install?
the problem was surely present with 7.0.39, the
7.0.42 is a fresh installation for me.
Could you please clarify: does the problem exists on
7.0.42, 7.0.39 or both?
both
Post by Ognjen Blagojevic
Could you provide steps to reproduce the problem on
fresh 7.0.42 installation?
- unpack tomcat - modify listen port - modify
tomcat-users.xml - copy jmxremote.access and
jmxremote.password (setting permissions) - build jsvc
- copy configuration files for applications (in
$tomcat/conf/Catalina/localhost)
thank you for you question: also jmx remote access is
not working (in both tomcat 7.0.39 and 7.0.42), maybe
the two problems are related?
Post by Ognjen Blagojevic
I tried to reproduce with the information you
provided so far, but I was unable. It works for me.
Also on my local machine, where jmx is not configured.
Usually, a good place to look first, are the Tomcat
logfiles. What do they say ?
searching for "java.lang.SecurityException: Restricted
(ContainerServlet) class
org.apache.catalina.manager.ManagerServlet"
<MG>my HostManagerServlet is defined in
webapps/host-manager/WEB-INF/web.xml as: <servlet>
<servlet-name>HostManager</servlet-name>
<servlet-class>org.apache.catalina.manager.host.HostManagerServlet</servlet-class>
<init-param>
Post by Edoardo Panfili
Post by Martin Gainty
<param-name>debug</param-name> <param-value>2</param-value>
</init-param> </servlet> <servlet>
<servlet-name>HTMLHostManager</servlet-name>
<servlet-class>org.apache.catalina.manager.host.HTMLHostManagerServlet</servlet-class>
<init-param>
Post by Edoardo Panfili
Post by Martin Gainty
<param-name>debug</param-name> <param-value>2</param-value>
</init-param> </servlet> </MG>
the same for me.
Post by Martin Gainty
seem that the solution is to add privileged="true"
<MG>my privileged attr in Context is located at
/webapps/host-manager/META-INF/context.xml as: <Context
antiResourceLocking="false" privileged="true" />
also this, the same.
I can try with a new install (as suggested from Ognjen )
then try to use manager before install jsvc and befor setting
the jmx properties.
Neither jsvc nor jmx should have any effect on what you are
seeing. I would like to confirm that, however. Let us know what
you discover.
The SecurityException is certainly going to be a problem. It's
odd that you saw the SecurityException which should fail to
deploy the Manager, yet you are seeing the Manager's
404-not-found page which would require the Manager to be
deployed.
Informazioni: Marking servlet Manager as unavailable ott 18, 2013
4:48:17 PM org.apache.catalina.core.StandardWrapperValve invoke
Grave: Allocate exception for servlet Manager
java.lang.SecurityException: Restricted (ContainerServlet) class
org.apache.catalina.manager.ManagerServlet
So to my (admittedly untrained) eyes, it may look like the Manager
application (and its static pages) is deployed, but it is when
it's servlet is starting to run that the Java Security Manager
shoots it down.. It doesn't for that undeploy the whole app I
guess.
Thanks for pointing that out; it makes much more sense given that
explanation.
I think that there was a clue quite a few messages ago : some parameter in the Manager's
web.xml had a value that probably meant that it wasn't necesaarily initialised when Tomcat
starts up, only when it is first called.

That may also explain why the latest logfile did not show any problem.
It was probably copied before the first real call to the Manager happened.
Right now though, there is probably the same error message in the logs as before, because
Edoardo tried to call the Manager app, /after/ he sent us the startup logfile.
Edoardo Panfili
2013-10-18 18:09:12 UTC
Permalink
Post by André Warnier
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
André,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Edoardo,
Post by Edoardo Panfili
Post by Martin Gainty
can't connect to manager application
Post by André Warnier
Post by Ognjen Blagojevic
Post by Edoardo Panfili
Post by Ognjen Blagojevic
To rule out faulty upgrade, could you try to reproduce the
problem on clean Tomcat 7.0.42 install?
the problem was surely present with 7.0.39, the
7.0.42 is a fresh installation for me.
Could you please clarify: does the problem exists on 7.0.42,
7.0.39 or both?
both
Post by Ognjen Blagojevic
Could you provide steps to reproduce the problem on
fresh 7.0.42 installation?
- unpack tomcat - modify listen port - modify tomcat-users.xml
- copy jmxremote.access and jmxremote.password (setting
permissions) - build jsvc
- copy configuration files for applications (in
$tomcat/conf/Catalina/localhost)
thank you for you question: also jmx remote access is
not working (in both tomcat 7.0.39 and 7.0.42), maybe
the two problems are related?
Post by Ognjen Blagojevic
I tried to reproduce with the information you
provided so far, but I was unable. It works for me.
Also on my local machine, where jmx is not configured.
Usually, a good place to look first, are the Tomcat logfiles.
What do they say ?
searching for "java.lang.SecurityException: Restricted
(ContainerServlet) class org.apache.catalina.manager.ManagerServlet"
<MG>my HostManagerServlet is defined in
webapps/host-manager/WEB-INF/web.xml as: <servlet>
<servlet-name>HostManager</servlet-name>
<servlet-class>org.apache.catalina.manager.host.HostManagerServlet</servlet-class>
<init-param>
Post by Edoardo Panfili
Post by Martin Gainty
<param-name>debug</param-name> <param-value>2</param-value>
</init-param> </servlet> <servlet>
<servlet-name>HTMLHostManager</servlet-name>
<servlet-class>org.apache.catalina.manager.host.HTMLHostManagerServlet</servlet-class>
<init-param>
Post by Edoardo Panfili
Post by Martin Gainty
<param-name>debug</param-name> <param-value>2</param-value>
</init-param> </servlet> </MG>
the same for me.
Post by Martin Gainty
seem that the solution is to add privileged="true"
<MG>my privileged attr in Context is located at
/webapps/host-manager/META-INF/context.xml as: <Context
antiResourceLocking="false" privileged="true" />
also this, the same.
I can try with a new install (as suggested from Ognjen )
then try to use manager before install jsvc and befor setting
the jmx properties.
Neither jsvc nor jmx should have any effect on what you are
seeing. I would like to confirm that, however. Let us know what
you discover.
The SecurityException is certainly going to be a problem. It's
odd that you saw the SecurityException which should fail to
deploy the Manager, yet you are seeing the Manager's
404-not-found page which would require the Manager to be
deployed.
Informazioni: Marking servlet Manager as unavailable ott 18, 2013
4:48:17 PM org.apache.catalina.core.StandardWrapperValve invoke
Grave: Allocate exception for servlet Manager
java.lang.SecurityException: Restricted (ContainerServlet) class
org.apache.catalina.manager.ManagerServlet
So to my (admittedly untrained) eyes, it may look like the Manager
application (and its static pages) is deployed, but it is when
it's servlet is starting to run that the Java Security Manager
shoots it down.. It doesn't for that undeploy the whole app I
guess.
Thanks for pointing that out; it makes much more sense given that
explanation.
I think that there was a clue quite a few messages ago : some parameter
in the Manager's web.xml had a value that probably meant that it wasn't
necesaarily initialised when Tomcat starts up, only when it is first
called.
I didn't touch the manager application (at least not voluntarily!).
Post by André Warnier
That may also explain why the latest logfile did not show any problem.
It was probably copied before the first real call to the Manager happened.
Right now though, there is probably the same error message in the logs
as before, because Edoardo tried to call the Manager app, /after/ he
sent us the startup logfile.
Are we talking of catalina.out? if so: no. the problem is that the
exception log is not in catalina.out (or
catalina-daemon.out in my system) but in manager.2013-10-18.log

ott 18, 2013 6:44:14 PM org.apache.catalina.core.ApplicationContext log
Informazioni: Marking servlet Manager as unavailable
ott 18, 2013 6:44:14 PM org.apache.catalina.core.StandardWrapperValve invoke
Grave: Allocate exception for servlet Manager
java.lang.SecurityException: Restricted (ContainerServlet) class
org.apache.catalina.manager.ManagerServlet
at
org.apache.catalina.core.DefaultInstanceManager.checkAccess(DefaultInstanceManager.java:538)
at
org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:511)
at
org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:137)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1144)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:865)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:136)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:611)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)

(the same as before)

I am copying the whole Tomcat folder from the production server to my
local virtual machine.


I will post a detailed report (but it requests some time).

thank you again
Edoardo
Konstantin Kolinko
2013-10-18 18:37:56 UTC
Permalink
Post by Edoardo Panfili
I didn't touch the manager application (at least not voluntarily!).
Post by André Warnier
That may also explain why the latest logfile did not show any problem.
It was probably copied before the first real call to the Manager happened.
Right now though, there is probably the same error message in the logs
as before, because Edoardo tried to call the Manager app, /after/ he
sent us the startup logfile.
Are we talking of catalina.out? if so: no. the problem is that the exception
log is not in catalina.out (or
catalina-daemon.out in my system) but in manager.2013-10-18.log
ott 18, 2013 6:44:14 PM org.apache.catalina.core.ApplicationContext log
Informazioni: Marking servlet Manager as unavailable
ott 18, 2013 6:44:14 PM org.apache.catalina.core.StandardWrapperValve invoke
Grave: Allocate exception for servlet Manager
java.lang.SecurityException: Restricted (ContainerServlet) class
org.apache.catalina.manager.ManagerServlet
at
org.apache.catalina.core.DefaultInstanceManager.checkAccess(DefaultInstanceManager.java:538)
at
org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:511)
at
org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:137)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1144)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:865)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:136)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:611)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
(the same as before)
The code:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/tags/TOMCAT_7_0_40/java/org/apache/catalina/core/DefaultInstanceManager.java?view=markup#l538

To clarify: it is not related with Java SecurityManager. It is an
explicit check in Tomcat code that prohibits usage of special servlets
(such as the Manager one) in web applications that are not marked as
"privileged".

It means that OP's manager web application does not have
privileged="true" in its context xml file.

The default context.xml of the manager webapp in Tomcat 7 is in
$CATALINA_HOME/webapps/manager/META-INF/context.xml. It may be that
the file is missing, is not readable, or it is not effective (e.g. if
it is shadowed by another definition of the same context elsewhere.
There exist several ways on how a context can be configured). See [1].

As Martin Gainty noted, it seems that there is quite a number of
errors in how OP's web applications are deployed. All allowed
attributes are documented in [1].


[1] http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Defining_a_context


Best regards,
Konstantin Kolinko
Caldarale, Charles R
2013-10-18 18:49:48 UTC
Permalink
Subject: Re: can't connect to manager application
As Martin Gainty noted, it seems that there is quite a number of
errors in how OP's web applications are deployed. All allowed
attributes are documented in [1].
Martin G is not likely to ever be capable of such an analysis; it was Mark Eggers who did the extensive legwork.

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
André Warnier
2013-10-18 19:13:28 UTC
Permalink
Post by Edoardo Panfili
Post by André Warnier
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
André,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Edoardo,
Post by Edoardo Panfili
Post by Martin Gainty
can't connect to manager application
Post by André Warnier
Post by Ognjen Blagojevic
Post by Edoardo Panfili
Post by Ognjen Blagojevic
To rule out faulty upgrade, could you try to reproduce the
problem on clean Tomcat 7.0.42 install?
the problem was surely present with 7.0.39, the
7.0.42 is a fresh installation for me.
Could you please clarify: does the problem exists on 7.0.42,
7.0.39 or both?
both
Post by Ognjen Blagojevic
Could you provide steps to reproduce the problem on
fresh 7.0.42 installation?
- unpack tomcat - modify listen port - modify tomcat-users.xml
- copy jmxremote.access and jmxremote.password (setting
permissions) - build jsvc
- copy configuration files for applications (in
$tomcat/conf/Catalina/localhost)
thank you for you question: also jmx remote access is
not working (in both tomcat 7.0.39 and 7.0.42), maybe
the two problems are related?
Post by Ognjen Blagojevic
I tried to reproduce with the information you
provided so far, but I was unable. It works for me.
Also on my local machine, where jmx is not configured.
Usually, a good place to look first, are the Tomcat logfiles.
What do they say ?
searching for "java.lang.SecurityException: Restricted
(ContainerServlet) class
org.apache.catalina.manager.ManagerServlet"
<MG>my HostManagerServlet is defined in
webapps/host-manager/WEB-INF/web.xml as: <servlet>
<servlet-name>HostManager</servlet-name>
<servlet-class>org.apache.catalina.manager.host.HostManagerServlet</servlet-class>
<init-param>
Post by Edoardo Panfili
Post by Martin Gainty
<param-name>debug</param-name> <param-value>2</param-value>
</init-param> </servlet> <servlet>
<servlet-name>HTMLHostManager</servlet-name>
<servlet-class>org.apache.catalina.manager.host.HTMLHostManagerServlet</servlet-class>
<init-param>
Post by Edoardo Panfili
Post by Martin Gainty
<param-name>debug</param-name> <param-value>2</param-value>
</init-param> </servlet> </MG>
the same for me.
Post by Martin Gainty
seem that the solution is to add privileged="true"
<MG>my privileged attr in Context is located at
/webapps/host-manager/META-INF/context.xml as: <Context
antiResourceLocking="false" privileged="true" />
also this, the same.
I can try with a new install (as suggested from Ognjen )
then try to use manager before install jsvc and befor setting
the jmx properties.
Neither jsvc nor jmx should have any effect on what you are
seeing. I would like to confirm that, however. Let us know what
you discover.
The SecurityException is certainly going to be a problem. It's
odd that you saw the SecurityException which should fail to
deploy the Manager, yet you are seeing the Manager's
404-not-found page which would require the Manager to be
deployed.
Informazioni: Marking servlet Manager as unavailable ott 18, 2013
4:48:17 PM org.apache.catalina.core.StandardWrapperValve invoke
Grave: Allocate exception for servlet Manager
java.lang.SecurityException: Restricted (ContainerServlet) class
org.apache.catalina.manager.ManagerServlet
So to my (admittedly untrained) eyes, it may look like the Manager
application (and its static pages) is deployed, but it is when
it's servlet is starting to run that the Java Security Manager
shoots it down.. It doesn't for that undeploy the whole app I
guess.
Thanks for pointing that out; it makes much more sense given that
explanation.
I think that there was a clue quite a few messages ago : some parameter
in the Manager's web.xml had a value that probably meant that it wasn't
necesaarily initialised when Tomcat starts up, only when it is first
called.
I didn't touch the manager application (at least not voluntarily!).
Post by André Warnier
That may also explain why the latest logfile did not show any problem.
It was probably copied before the first real call to the Manager happened.
Right now though, there is probably the same error message in the logs
as before, because Edoardo tried to call the Manager app, /after/ he
sent us the startup logfile.
Are we talking of catalina.out? if so: no. the problem is that the
exception log is not in catalina.out (or
catalina-daemon.out in my system) but in manager.2013-10-18.log
ott 18, 2013 6:44:14 PM org.apache.catalina.core.ApplicationContext log
Informazioni: Marking servlet Manager as unavailable
ott 18, 2013 6:44:14 PM org.apache.catalina.core.StandardWrapperValve invoke
Grave: Allocate exception for servlet Manager
java.lang.SecurityException: Restricted (ContainerServlet) class
org.apache.catalina.manager.ManagerServlet
at
org.apache.catalina.core.DefaultInstanceManager.checkAccess(DefaultInstanceManager.java:538)
at
org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:511)
at
org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:137)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1144)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:865)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:136)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:611)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
(the same as before)
I am copying the whole Tomcat folder from the production server to my
local virtual machine.
I will post a detailed report (but it requests some time).
To further clarify what Konstantin points to in his latest post :

You should probably not do that (what you say above above "copying thw whole Tomcat folder
from the production server").
What you should do, is make a clean Tomcat install, to some directory where it was never
installed before.
Then test the Manager app and JMX.
Then, item by item, bring in the webapps from your production server into this clean
installation. Do not overwrite files from the clean installation by files from your
production server. Instead, *modify* the files of the clean installation to "bring in"
gradually what you need for your webapps.

The reason, as Konstantin and others pointed out, is that on your production server,
things are probably quite messy by now, and you may have several files which conflict with
one another, invalid attributes left over from older Tomcat versions etc. If you just copy
every file from the production server to your clean environment, you will copy the mess also.
So take your time, but do it nicely step by step, taking the opportunity to clean up all
that old stuff, and you'll get a squeaky clean Tomcat installation that you will be able
to use for a couple of years without having to cleanup again.

----------

About my wrong diagnosis of the Security Manager's implication : I also did not see the
parameters in the Java command-line which would have started the Security Manager. But,
being the occasional Java user which I am, I kind of assumed that maybe the Security
Manager might be started by default in recent Java versions.
That was apparently a wrong assumption.
So anyway, Edoardo, forget what I wrote about catalina.policy. It is not applicable here.

--------------

And about Martin's remarks being right : I don't know why, but my fingers have this
automatic reflex of hitting the delete button whenever my eyes see one of these posts. I
guess that this time, it was really unjustified. Apologies thus.
Caldarale, Charles R
2013-10-18 19:25:05 UTC
Permalink
Subject: Re: can't connect to manager application
And about Martin's remarks being right : I don't know why, but my fingers have this
automatic reflex of hitting the delete button whenever my eyes see one of these posts.
I guess that this time, it was really unjustified. Apologies thus.
No, your initial reaction was correct: Martin G's response was mostly noise, as usual. It was Mark E's response that contained the line-by-line analysis of the log.

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Edoardo Panfili
2013-10-18 20:16:26 UTC
Permalink
Post by André Warnier
Post by Edoardo Panfili
Post by André Warnier
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
André,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Edoardo,
Post by Edoardo Panfili
Post by Martin Gainty
can't connect to manager application
Post by André Warnier
Post by Ognjen Blagojevic
Post by Edoardo Panfili
Post by Ognjen Blagojevic
To rule out faulty upgrade, could you try to reproduce the
problem on clean Tomcat 7.0.42 install?
the problem was surely present with 7.0.39, the
7.0.42 is a fresh installation for me.
Could you please clarify: does the problem exists on 7.0.42,
7.0.39 or both?
both
Post by Ognjen Blagojevic
Could you provide steps to reproduce the problem on
fresh 7.0.42 installation?
- unpack tomcat - modify listen port - modify tomcat-users.xml
- copy jmxremote.access and jmxremote.password (setting
permissions) - build jsvc
- copy configuration files for applications (in
$tomcat/conf/Catalina/localhost)
thank you for you question: also jmx remote access is
not working (in both tomcat 7.0.39 and 7.0.42), maybe
the two problems are related?
Post by Ognjen Blagojevic
I tried to reproduce with the information you
provided so far, but I was unable. It works for me.
Also on my local machine, where jmx is not configured.
Usually, a good place to look first, are the Tomcat logfiles.
What do they say ?
searching for "java.lang.SecurityException: Restricted
(ContainerServlet) class
org.apache.catalina.manager.ManagerServlet"
<MG>my HostManagerServlet is defined in
webapps/host-manager/WEB-INF/web.xml as: <servlet>
<servlet-name>HostManager</servlet-name>
<servlet-class>org.apache.catalina.manager.host.HostManagerServlet</servlet-class>
<init-param>
Post by Edoardo Panfili
Post by Martin Gainty
<param-name>debug</param-name> <param-value>2</param-value>
</init-param> </servlet> <servlet>
<servlet-name>HTMLHostManager</servlet-name>
<servlet-class>org.apache.catalina.manager.host.HTMLHostManagerServlet</servlet-class>
<init-param>
Post by Edoardo Panfili
Post by Martin Gainty
<param-name>debug</param-name> <param-value>2</param-value>
</init-param> </servlet> </MG>
the same for me.
Post by Martin Gainty
seem that the solution is to add privileged="true"
<MG>my privileged attr in Context is located at
/webapps/host-manager/META-INF/context.xml as: <Context
antiResourceLocking="false" privileged="true" />
also this, the same.
I can try with a new install (as suggested from Ognjen )
then try to use manager before install jsvc and befor setting
the jmx properties.
Neither jsvc nor jmx should have any effect on what you are
seeing. I would like to confirm that, however. Let us know what
you discover.
The SecurityException is certainly going to be a problem. It's
odd that you saw the SecurityException which should fail to
deploy the Manager, yet you are seeing the Manager's
404-not-found page which would require the Manager to be
deployed.
Informazioni: Marking servlet Manager as unavailable ott 18, 2013
4:48:17 PM org.apache.catalina.core.StandardWrapperValve invoke
Grave: Allocate exception for servlet Manager
java.lang.SecurityException: Restricted (ContainerServlet) class
org.apache.catalina.manager.ManagerServlet
So to my (admittedly untrained) eyes, it may look like the Manager
application (and its static pages) is deployed, but it is when
it's servlet is starting to run that the Java Security Manager
shoots it down.. It doesn't for that undeploy the whole app I
guess.
Thanks for pointing that out; it makes much more sense given that
explanation.
I think that there was a clue quite a few messages ago : some parameter
in the Manager's web.xml had a value that probably meant that it wasn't
necesaarily initialised when Tomcat starts up, only when it is first
called.
I didn't touch the manager application (at least not voluntarily!).
Post by André Warnier
That may also explain why the latest logfile did not show any problem.
It was probably copied before the first real call to the Manager happened.
Right now though, there is probably the same error message in the logs
as before, because Edoardo tried to call the Manager app, /after/ he
sent us the startup logfile.
Are we talking of catalina.out? if so: no. the problem is that the
exception log is not in catalina.out (or
catalina-daemon.out in my system) but in manager.2013-10-18.log
ott 18, 2013 6:44:14 PM org.apache.catalina.core.ApplicationContext log
Informazioni: Marking servlet Manager as unavailable
ott 18, 2013 6:44:14 PM org.apache.catalina.core.StandardWrapperValve invoke
Grave: Allocate exception for servlet Manager
java.lang.SecurityException: Restricted (ContainerServlet) class
org.apache.catalina.manager.ManagerServlet
at
org.apache.catalina.core.DefaultInstanceManager.checkAccess(DefaultInstanceManager.java:538)
at
org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:511)
at
org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:137)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1144)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:865)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:136)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:611)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
(the same as before)
I am copying the whole Tomcat folder from the production server to my
local virtual machine.
I will post a detailed report (but it requests some time).
You should probably not do that (what you say above above "copying thw
whole Tomcat folder from the production server").
I copy the folder but I don't copy files from one installation to
another, I need to be sure that I can reproduce the problem using my
virtual linux installation.
Post by André Warnier
What you should do, is make a clean Tomcat install, to some directory
where it was never installed before.
Then test the Manager app and JMX.
Then, item by item, bring in the webapps from your production server
into this clean installation. Do not overwrite files from the clean
installation by files from your production server. Instead, *modify* the
files of the clean installation
this is my usual way! I use to copy only jmx files, and applications
configuration.
Post by André Warnier
The reason, as Konstantin and others pointed out, is that on your
production server, things are probably quite messy by now, and you may
have several files which conflict with one another, invalid attributes
left over from older Tomcat versions etc. If you just copy every file
from the production server to your clean environment, you will copy the
mess also.
believe me, surely there is something wrong but the modified files are
very few!
Post by André Warnier
So take your time, but do it nicely step by step,
this is what I want to do.
Post by André Warnier
About my wrong diagnosis of the Security Manager's implication : I also
did not see the parameters in the Java command-line which would have
started the Security Manager. But, being the occasional Java user which
I am, I kind of assumed that maybe the Security Manager might be started
by default in recent Java versions.
That was apparently a wrong assumption.
So anyway, Edoardo, forget what I wrote about catalina.policy. It is not applicable here.
I verified if some version ago (Tomcat 7.0.19) catalina.policy was
different in some significat way. seems not.


Edoardo
Edoardo Panfili
2013-10-18 16:55:32 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Edoardo,
Post by Edoardo Panfili
Post by Martin Gainty
manager application
Post by André Warnier
Post by Ognjen Blagojevic
Post by Edoardo Panfili
Post by Ognjen Blagojevic
To rule out faulty upgrade, could you try to
reproduce the problem on clean Tomcat 7.0.42
install?
the problem was surely present with 7.0.39, the 7.0.42
is a fresh installation for me.
Could you please clarify: does the problem exists on
7.0.42, 7.0.39 or both?
both
Post by Ognjen Blagojevic
Could you provide steps to reproduce the problem on fresh
7.0.42 installation?
- unpack tomcat - modify listen port - modify
tomcat-users.xml - copy jmxremote.access and
jmxremote.password (setting permissions) - build jsvc -
copy configuration files for applications (in
$tomcat/conf/Catalina/localhost)
thank you for you question: also jmx remote access is not
working (in both tomcat 7.0.39 and 7.0.42), maybe the two
problems are related?
Post by Ognjen Blagojevic
I tried to reproduce with the information you provided so
far, but I was unable. It works for me.
Also on my local machine, where jmx is not configured.
Usually, a good place to look first, are the Tomcat
logfiles. What do they say ?
searching for "java.lang.SecurityException: Restricted
(ContainerServlet) class
org.apache.catalina.manager.ManagerServlet"
<MG>my HostManagerServlet is defined in
webapps/host-manager/WEB-INF/web.xml as: <servlet>
<servlet-name>HostManager</servlet-name>
<servlet-class>org.apache.catalina.manager.host.HostManagerServlet</servlet-class>
<init-param>
Post by Edoardo Panfili
Post by Martin Gainty
<param-name>debug</param-name> <param-value>2</param-value>
</init-param> </servlet> <servlet>
<servlet-name>HTMLHostManager</servlet-name>
<servlet-class>org.apache.catalina.manager.host.HTMLHostManagerServlet</servlet-class>
<init-param>
Post by Edoardo Panfili
Post by Martin Gainty
<param-name>debug</param-name> <param-value>2</param-value>
</init-param> </servlet> </MG>
the same for me.
Post by Martin Gainty
seem that the solution is to add privileged="true"
<MG>my privileged attr in Context is located at
/webapps/host-manager/META-INF/context.xml as: <Context
antiResourceLocking="false" privileged="true" />
also this, the same.
I can try with a new install (as suggested from Ognjen )
then try to use manager before install jsvc and befor setting the
jmx properties.
Neither jsvc nor jmx should have any effect on what you are seeing. I
would like to confirm that, however. Let us know what you discover.
The SecurityException is certainly going to be a problem. It's odd
that you saw the SecurityException which should fail to deploy the
Manager, yet you are seeing the Manager's 404-not-found page which
would require the Manager to be deployed.
Can you stop Tomcat, delete all log files, and then restart? If/when
you see that failure (should be easy to reproduce: just use curl,
right?) then post the entire catalina.out file.
yes.

catalina-daemon.out

ott 18, 2013 6:43:57 PM org.apache.catalina.core.AprLifecycleListener init
Informazioni: The APR based Apache Tomcat Native library which allows
optimal performance in production environments was not found on the
java.library.path:
/usr/local/jdk1.7.0_40/jre/lib/amd64/server:/usr/local/jdk1.7.0_40/jre/lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
ott 18, 2013 6:43:57 PM org.apache.coyote.AbstractProtocol init
Informazioni: Initializing ProtocolHandler ["http-bio-9080"]
ott 18, 2013 6:43:57 PM org.apache.coyote.AbstractProtocol init
Informazioni: Initializing ProtocolHandler ["ajp-bio-9009"]
ott 18, 2013 6:43:57 PM org.apache.catalina.startup.Catalina load
Informazioni: Initialization processed in 528 ms
ott 18, 2013 6:43:57 PM org.apache.catalina.core.StandardService
startInternal
Informazioni: Starting service Catalina
ott 18, 2013 6:43:57 PM org.apache.catalina.core.StandardEngine
startInternal
Informazioni: Starting Servlet Engine: Apache Tomcat/7.0.42
ott 18, 2013 6:43:58 PM org.apache.catalina.startup.HostConfig
deployDescriptor
Informazioni: Deploying configuration descriptor
/usr/local/apache-tomcat-7.0.42/conf/Catalina/localhost/anotherApp.xml
ott 18, 2013 6:43:58 PM org.apache.catalina.startup.HostConfig
deployDescriptor
Avvertenza: A docBase /usr/local/apache-tomcat-7.0.42/webapps/sisv
inside the host appBase has been specified, and will be ignored
ott 18, 2013 6:43:59 PM org.apache.catalina.startup.HostConfig
deployDescriptor
Informazioni: Deploying configuration descriptor
/usr/local/apache-tomcat-7.0.42/conf/Catalina/localhost/myApplication.xml
ott 18, 2013 6:43:59 PM
org.apache.catalina.startup.SetContextPropertiesRule begin
Avvertenza: [SetContextPropertiesRule]{Context} Setting property 'debug'
to '100' did not find a matching property.
ott 18, 2013 6:44:01 PM org.apache.catalina.startup.HostConfig
deployDescriptor
Informazioni: Deploying configuration descriptor
/usr/local/apache-tomcat-7.0.42/conf/Catalina/localhost/app5.xml
ott 18, 2013 6:44:01 PM org.apache.catalina.startup.HostConfig
deployDescriptor
Avvertenza: A docBase /usr/local/apache-tomcat-7.0.42/webapps/app5
inside the host appBase has been specified, and will be ignored
ott 18, 2013 6:44:01 PM
org.apache.catalina.startup.SetContextPropertiesRule begin
Avvertenza: [SetContextPropertiesRule]{Context} Setting property 'debug'
to '100' did not find a matching property.
ott 18, 2013 6:44:01 PM org.apache.catalina.startup.HostConfig
deployDirectory
Informazioni: Deploying web application directory
/usr/local/apache-tomcat-7.0.42/webapps/ROOT
ott 18, 2013 6:44:01 PM org.apache.catalina.startup.HostConfig
deployDirectory
Informazioni: Deploying web application directory
/usr/local/apache-tomcat-7.0.42/webapps/manager
ott 18, 2013 6:44:01 PM org.apache.catalina.startup.HostConfig
deployDirectory
Informazioni: Deploying web application directory
/usr/local/apache-tomcat-7.0.42/webapps/app7
ott 18, 2013 6:44:03 PM org.apache.catalina.startup.HostConfig
deployDirectory
Informazioni: Deploying web application directory
/usr/local/apache-tomcat-7.0.42/webapps/host-manager
ott 18, 2013 6:44:03 PM org.apache.coyote.AbstractProtocol start
Informazioni: Starting ProtocolHandler ["http-bio-9080"]
ott 18, 2013 6:44:03 PM org.apache.coyote.AbstractProtocol start
Informazioni: Starting ProtocolHandler ["ajp-bio-9009"]
ott 18, 2013 6:44:03 PM org.apache.catalina.startup.Catalina start




Edoardo
Christopher Schultz
2013-10-18 16:57:02 UTC
Permalink
Edorado,
Post by Edoardo Panfili
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Edoardo,
Post by Edoardo Panfili
Post by Martin Gainty
can't connect to manager application
Post by André Warnier
Post by Ognjen Blagojevic
Post by Edoardo Panfili
Post by Ognjen Blagojevic
To rule out faulty upgrade, could you try to
reproduce the problem on clean Tomcat 7.0.42
install?
the problem was surely present with 7.0.39, the
7.0.42 is a fresh installation for me.
Could you please clarify: does the problem exists on
7.0.42, 7.0.39 or both?
both
Post by Ognjen Blagojevic
Could you provide steps to reproduce the problem on
fresh 7.0.42 installation?
- unpack tomcat - modify listen port - modify
tomcat-users.xml - copy jmxremote.access and
jmxremote.password (setting permissions) - build jsvc
- copy configuration files for applications (in
$tomcat/conf/Catalina/localhost)
thank you for you question: also jmx remote access is
not working (in both tomcat 7.0.39 and 7.0.42), maybe
the two problems are related?
Post by Ognjen Blagojevic
I tried to reproduce with the information you
provided so far, but I was unable. It works for me.
Also on my local machine, where jmx is not configured.
Usually, a good place to look first, are the Tomcat
logfiles. What do they say ?
searching for "java.lang.SecurityException: Restricted
(ContainerServlet) class
org.apache.catalina.manager.ManagerServlet"
<MG>my HostManagerServlet is defined in
webapps/host-manager/WEB-INF/web.xml as: <servlet>
<servlet-name>HostManager</servlet-name>
<servlet-class>org.apache.catalina.manager.host.HostManagerServlet</servlet-class>
<init-param>
Post by Edoardo Panfili
Post by Edoardo Panfili
Post by Martin Gainty
<param-name>debug</param-name> <param-value>2</param-value>
</init-param> </servlet> <servlet>
<servlet-name>HTMLHostManager</servlet-name>
<servlet-class>org.apache.catalina.manager.host.HTMLHostManagerServlet</servlet-class>
<init-param>
Post by Edoardo Panfili
Post by Edoardo Panfili
Post by Martin Gainty
<param-name>debug</param-name> <param-value>2</param-value>
</init-param> </servlet> </MG>
the same for me.
Post by Martin Gainty
seem that the solution is to add privileged="true"
<MG>my privileged attr in Context is located at
/webapps/host-manager/META-INF/context.xml as: <Context
antiResourceLocking="false" privileged="true" />
also this, the same.
I can try with a new install (as suggested from Ognjen )
then try to use manager before install jsvc and befor setting
the jmx properties.
Neither jsvc nor jmx should have any effect on what you are
seeing. I would like to confirm that, however. Let us know what
you discover.
The SecurityException is certainly going to be a problem. It's
odd that you saw the SecurityException which should fail to
deploy the Manager, yet you are seeing the Manager's
404-not-found page which would require the Manager to be
deployed.
Can you stop Tomcat, delete all log files, and then restart?
If/when you see that failure (should be easy to reproduce: just
use curl, right?) then post the entire catalina.out file.
yes.
catalina-daemon.out
ott 18, 2013 6:43:57 PM
The APR based Apache Tomcat Native library which allows optimal
performance in production environments was not found on the
/usr/local/jdk1.7.0_40/jre/lib/amd64/server:/usr/local/jdk1.7.0_40/jre/lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
ott 18, 2013 6:43:57 PM org.apache.coyote.AbstractProtocol init
Informazioni: Initializing ProtocolHandler ["http-bio-9080"] ott
18, 2013 6:43:57 PM org.apache.coyote.AbstractProtocol init
Informazioni: Initializing ProtocolHandler ["ajp-bio-9009"] ott 18,
2013 6:43:57 PM org.apache.catalina.startup.Catalina load
Informazioni: Initialization processed in 528 ms ott 18, 2013
6:43:57 PM org.apache.catalina.core.StandardService startInternal
Informazioni: Starting service Catalina ott 18, 2013 6:43:57 PM
Starting Servlet Engine: Apache Tomcat/7.0.42 ott 18, 2013 6:43:58
PM org.apache.catalina.startup.HostConfig deployDescriptor
Informazioni: Deploying configuration descriptor
/usr/local/apache-tomcat-7.0.42/conf/Catalina/localhost/anotherApp.xml
ott 18, 2013 6:43:58 PM org.apache.catalina.startup.HostConfig
Post by Edoardo Panfili
deployDescriptor Avvertenza: A docBase
/usr/local/apache-tomcat-7.0.42/webapps/sisv inside the host
appBase has been specified, and will be ignored ott 18, 2013
6:43:59 PM org.apache.catalina.startup.HostConfig deployDescriptor
Informazioni: Deploying configuration descriptor
/usr/local/apache-tomcat-7.0.42/conf/Catalina/localhost/myApplication.xml
ott 18, 2013 6:43:59 PM
Post by Edoardo Panfili
org.apache.catalina.startup.SetContextPropertiesRule begin
Avvertenza: [SetContextPropertiesRule]{Context} Setting property
'debug' to '100' did not find a matching property. ott 18, 2013
6:44:01 PM org.apache.catalina.startup.HostConfig deployDescriptor
Informazioni: Deploying configuration descriptor
/usr/local/apache-tomcat-7.0.42/conf/Catalina/localhost/app5.xml
ott 18, 2013 6:44:01 PM org.apache.catalina.startup.HostConfig
deployDescriptor Avvertenza: A docBase
/usr/local/apache-tomcat-7.0.42/webapps/app5 inside the host
appBase has been specified, and will be ignored ott 18, 2013
6:44:01 PM org.apache.catalina.startup.SetContextPropertiesRule
begin Avvertenza: [SetContextPropertiesRule]{Context} Setting
property 'debug' to '100' did not find a matching property. ott 18,
2013 6:44:01 PM org.apache.catalina.startup.HostConfig
deployDirectory Informazioni: Deploying web application directory
/usr/local/apache-tomcat-7.0.42/webapps/ROOT ott 18, 2013 6:44:01
PM org.apache.catalina.startup.HostConfig deployDirectory
Informazioni: Deploying web application directory
/usr/local/apache-tomcat-7.0.42/webapps/manager ott 18, 2013
6:44:01 PM org.apache.catalina.startup.HostConfig deployDirectory
Informazioni: Deploying web application directory
/usr/local/apache-tomcat-7.0.42/webapps/app7 ott 18, 2013 6:44:03
PM org.apache.catalina.startup.HostConfig deployDirectory
Informazioni: Deploying web application directory
/usr/local/apache-tomcat-7.0.42/webapps/host-manager ott 18, 2013
Starting ProtocolHandler ["http-bio-9080"] ott 18, 2013 6:44:03 PM
org.apache.coyote.AbstractProtocol start Informazioni: Starting
ProtocolHandler ["ajp-bio-9009"] ott 18, 2013 6:44:03 PM
org.apache.catalina.startup.Catalina start
Okay, did it fail this time? I see no problems in the above log file.

- -chris
Edoardo Panfili
2013-10-18 17:04:31 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Edorado,
Post by Edoardo Panfili
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Edoardo,
Post by Edoardo Panfili
Post by Martin Gainty
can't connect to manager application
Post by André Warnier
Post by Ognjen Blagojevic
Post by Edoardo Panfili
Post by Ognjen Blagojevic
To rule out faulty upgrade, could you try to
reproduce the problem on clean Tomcat 7.0.42
install?
the problem was surely present with 7.0.39, the
7.0.42 is a fresh installation for me.
Could you please clarify: does the problem exists on
7.0.42, 7.0.39 or both?
both
Post by Ognjen Blagojevic
Could you provide steps to reproduce the problem on
fresh 7.0.42 installation?
- unpack tomcat - modify listen port - modify
tomcat-users.xml - copy jmxremote.access and
jmxremote.password (setting permissions) - build jsvc
- copy configuration files for applications (in
$tomcat/conf/Catalina/localhost)
thank you for you question: also jmx remote access is
not working (in both tomcat 7.0.39 and 7.0.42), maybe
the two problems are related?
Post by Ognjen Blagojevic
I tried to reproduce with the information you
provided so far, but I was unable. It works for me.
Also on my local machine, where jmx is not configured.
Usually, a good place to look first, are the Tomcat
logfiles. What do they say ?
searching for "java.lang.SecurityException: Restricted
(ContainerServlet) class
org.apache.catalina.manager.ManagerServlet"
<MG>my HostManagerServlet is defined in
webapps/host-manager/WEB-INF/web.xml as: <servlet>
<servlet-name>HostManager</servlet-name>
<servlet-class>org.apache.catalina.manager.host.HostManagerServlet</servlet-class>
<init-param>
Post by Edoardo Panfili
Post by Edoardo Panfili
Post by Martin Gainty
<param-name>debug</param-name> <param-value>2</param-value>
</init-param> </servlet> <servlet>
<servlet-name>HTMLHostManager</servlet-name>
<servlet-class>org.apache.catalina.manager.host.HTMLHostManagerServlet</servlet-class>
<init-param>
Post by Edoardo Panfili
Post by Edoardo Panfili
Post by Martin Gainty
<param-name>debug</param-name> <param-value>2</param-value>
</init-param> </servlet> </MG>
the same for me.
Post by Martin Gainty
seem that the solution is to add privileged="true"
<MG>my privileged attr in Context is located at
/webapps/host-manager/META-INF/context.xml as: <Context
antiResourceLocking="false" privileged="true" />
also this, the same.
I can try with a new install (as suggested from Ognjen )
then try to use manager before install jsvc and befor setting
the jmx properties.
Neither jsvc nor jmx should have any effect on what you are
seeing. I would like to confirm that, however. Let us know what
you discover.
The SecurityException is certainly going to be a problem. It's
odd that you saw the SecurityException which should fail to
deploy the Manager, yet you are seeing the Manager's
404-not-found page which would require the Manager to be
deployed.
Can you stop Tomcat, delete all log files, and then restart?
If/when you see that failure (should be easy to reproduce: just
use curl, right?) then post the entire catalina.out file.
yes.
catalina-daemon.out
ott 18, 2013 6:43:57 PM
The APR based Apache Tomcat Native library which allows optimal
performance in production environments was not found on the
/usr/local/jdk1.7.0_40/jre/lib/amd64/server:/usr/local/jdk1.7.0_40/jre/lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
ott 18, 2013 6:43:57 PM org.apache.coyote.AbstractProtocol init
Informazioni: Initializing ProtocolHandler ["http-bio-9080"] ott
18, 2013 6:43:57 PM org.apache.coyote.AbstractProtocol init
Informazioni: Initializing ProtocolHandler ["ajp-bio-9009"] ott 18,
2013 6:43:57 PM org.apache.catalina.startup.Catalina load
Informazioni: Initialization processed in 528 ms ott 18, 2013
6:43:57 PM org.apache.catalina.core.StandardService startInternal
Informazioni: Starting service Catalina ott 18, 2013 6:43:57 PM
Starting Servlet Engine: Apache Tomcat/7.0.42 ott 18, 2013 6:43:58
PM org.apache.catalina.startup.HostConfig deployDescriptor
Informazioni: Deploying configuration descriptor
/usr/local/apache-tomcat-7.0.42/conf/Catalina/localhost/anotherApp.xml
ott 18, 2013 6:43:58 PM org.apache.catalina.startup.HostConfig
Post by Edoardo Panfili
deployDescriptor Avvertenza: A docBase
/usr/local/apache-tomcat-7.0.42/webapps/sisv inside the host
appBase has been specified, and will be ignored ott 18, 2013
6:43:59 PM org.apache.catalina.startup.HostConfig deployDescriptor
Informazioni: Deploying configuration descriptor
/usr/local/apache-tomcat-7.0.42/conf/Catalina/localhost/myApplication.xml
ott 18, 2013 6:43:59 PM
Post by Edoardo Panfili
org.apache.catalina.startup.SetContextPropertiesRule begin
Avvertenza: [SetContextPropertiesRule]{Context} Setting property
'debug' to '100' did not find a matching property. ott 18, 2013
6:44:01 PM org.apache.catalina.startup.HostConfig deployDescriptor
Informazioni: Deploying configuration descriptor
/usr/local/apache-tomcat-7.0.42/conf/Catalina/localhost/app5.xml
ott 18, 2013 6:44:01 PM org.apache.catalina.startup.HostConfig
deployDescriptor Avvertenza: A docBase
/usr/local/apache-tomcat-7.0.42/webapps/app5 inside the host
appBase has been specified, and will be ignored ott 18, 2013
6:44:01 PM org.apache.catalina.startup.SetContextPropertiesRule
begin Avvertenza: [SetContextPropertiesRule]{Context} Setting
property 'debug' to '100' did not find a matching property. ott 18,
2013 6:44:01 PM org.apache.catalina.startup.HostConfig
deployDirectory Informazioni: Deploying web application directory
/usr/local/apache-tomcat-7.0.42/webapps/ROOT ott 18, 2013 6:44:01
PM org.apache.catalina.startup.HostConfig deployDirectory
Informazioni: Deploying web application directory
/usr/local/apache-tomcat-7.0.42/webapps/manager ott 18, 2013
6:44:01 PM org.apache.catalina.startup.HostConfig deployDirectory
Informazioni: Deploying web application directory
/usr/local/apache-tomcat-7.0.42/webapps/app7 ott 18, 2013 6:44:03
PM org.apache.catalina.startup.HostConfig deployDirectory
Informazioni: Deploying web application directory
/usr/local/apache-tomcat-7.0.42/webapps/host-manager ott 18, 2013
Starting ProtocolHandler ["http-bio-9080"] ott 18, 2013 6:44:03 PM
org.apache.coyote.AbstractProtocol start Informazioni: Starting
ProtocolHandler ["ajp-bio-9009"] ott 18, 2013 6:44:03 PM
org.apache.catalina.startup.Catalina start
Okay, did it fail this time? I see no problems in the above log file.
it fails, I am pretty sure that I did something stupid during a past update!

I will use a virtual machine to copy this installation, download a new
Tomcat tar.gz one and move the applications step by step.

thank you to all
Edoardo
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSYWheAAoJEBzwKT+lPKRYl0kP/0eCTgo0LjGd0dHqcjktmWvV
il/1XJRyOcSm7vS/6l7m9yIjYzsyHeolXgdH6L3aMLIlab4a7q/x1JPrXee188S4
+ZY8vUH8kjfygpnvxBiFgm3zX/OYbDckYsEhF9EZfFNVPfGAQQBiN03OHZHuOjww
RwfjoGWJXFrSuBIghGMBoVc3tVEXTVR8xfEf/Wkt6RywScILA80brAh6VZ1lukJI
dzspOqrGgtVO+xJw67vOM0XQJyqw++Nz+Q9OeU2sDTyPm+ESV+CppB6w9AYeizvu
bqEwckFn9N8s2CPEhBa3dTUsQyX6BsE8JjUYUb4vl8blJWEPtcm0vxgd1vC1AcxF
JKiaavzMOuehJABWbq9ywPPL7pCUgZlGhT22iAz/0gAIdkJL7AnMfziBh3vMdraW
5b5Jdnyvct9Au4dMHAjhBE11c0zkiG+05fWvOkZ7NE2m4z8JNlvW+MF/AuXJ/GCu
HdNkJAtHeqD34P7dGlQ14vlTk+SWMF3BtJFucDCohVdsLnBlLzcYxq1+ZohWscjY
tOnkz93482Li1c0n1YEsF/9i0i7Rq17D+wCpVZkhrRiVTVP0h2u6yWWcbI/hkTi6
8I8C60sxoszdTq5effIx7woiLw7Li4HHlweOZG5kzvxsw/rvxzOd5p47De2hyA10
/A6MjKs4cw3jeK53jbHU
=4b7F
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
Mark Eggers
2013-10-18 17:43:49 UTC
Permalink
Lots of problems - see comments inline.

I don't know if these will impact application reloading, but cleaning up
the problems would be a good idea.
Post by Edoardo Panfili
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Edoardo,
Post by Edoardo Panfili
Post by Martin Gainty
manager application
Post by André Warnier
Post by Ognjen Blagojevic
Post by Edoardo Panfili
Post by Ognjen Blagojevic
To rule out faulty upgrade, could you try to
reproduce the problem on clean Tomcat 7.0.42
install?
the problem was surely present with 7.0.39, the 7.0.42
is a fresh installation for me.
Could you please clarify: does the problem exists on
7.0.42, 7.0.39 or both?
both
Post by Ognjen Blagojevic
Could you provide steps to reproduce the problem on fresh
7.0.42 installation?
- unpack tomcat - modify listen port - modify
tomcat-users.xml - copy jmxremote.access and
jmxremote.password (setting permissions) - build jsvc -
copy configuration files for applications (in
$tomcat/conf/Catalina/localhost)
thank you for you question: also jmx remote access is not
working (in both tomcat 7.0.39 and 7.0.42), maybe the two
problems are related?
Post by Ognjen Blagojevic
I tried to reproduce with the information you provided so
far, but I was unable. It works for me.
Also on my local machine, where jmx is not configured.
Usually, a good place to look first, are the Tomcat
logfiles. What do they say ?
searching for "java.lang.SecurityException: Restricted
(ContainerServlet) class
org.apache.catalina.manager.ManagerServlet"
<MG>my HostManagerServlet is defined in
webapps/host-manager/WEB-INF/web.xml as: <servlet>
<servlet-name>HostManager</servlet-name>
<servlet-class>org.apache.catalina.manager.host.HostManagerServlet</servlet-class>
<init-param>
Post by Edoardo Panfili
Post by Martin Gainty
<param-name>debug</param-name> <param-value>2</param-value>
</init-param> </servlet> <servlet>
<servlet-name>HTMLHostManager</servlet-name>
<servlet-class>org.apache.catalina.manager.host.HTMLHostManagerServlet</servlet-class>
<init-param>
Post by Edoardo Panfili
Post by Martin Gainty
<param-name>debug</param-name> <param-value>2</param-value>
</init-param> </servlet> </MG>
the same for me.
Post by Martin Gainty
seem that the solution is to add privileged="true"
<MG>my privileged attr in Context is located at
/webapps/host-manager/META-INF/context.xml as: <Context
antiResourceLocking="false" privileged="true" />
also this, the same.
I can try with a new install (as suggested from Ognjen )
then try to use manager before install jsvc and befor setting the
jmx properties.
Neither jsvc nor jmx should have any effect on what you are seeing. I
would like to confirm that, however. Let us know what you discover.
The SecurityException is certainly going to be a problem. It's odd
that you saw the SecurityException which should fail to deploy the
Manager, yet you are seeing the Manager's 404-not-found page which
would require the Manager to be deployed.
Can you stop Tomcat, delete all log files, and then restart? If/when
you see that failure (should be easy to reproduce: just use curl,
right?) then post the entire catalina.out file.
yes.
catalina-daemon.out
ott 18, 2013 6:43:57 PM org.apache.catalina.core.AprLifecycleListener init
Informazioni: The APR based Apache Tomcat Native library which allows
optimal performance in production environments was not found on the
/usr/local/jdk1.7.0_40/jre/lib/amd64/server:/usr/local/jdk1.7.0_40/jre/lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
ott 18, 2013 6:43:57 PM org.apache.coyote.AbstractProtocol init
Informazioni: Initializing ProtocolHandler ["http-bio-9080"]
ott 18, 2013 6:43:57 PM org.apache.coyote.AbstractProtocol init
Informazioni: Initializing ProtocolHandler ["ajp-bio-9009"]
ott 18, 2013 6:43:57 PM org.apache.catalina.startup.Catalina load
Informazioni: Initialization processed in 528 ms
ott 18, 2013 6:43:57 PM org.apache.catalina.core.StandardService
startInternal
Informazioni: Starting service Catalina
ott 18, 2013 6:43:57 PM org.apache.catalina.core.StandardEngine
startInternal
Informazioni: Starting Servlet Engine: Apache Tomcat/7.0.42
ott 18, 2013 6:43:58 PM org.apache.catalina.startup.HostConfig
deployDescriptor
Informazioni: Deploying configuration descriptor
/usr/local/apache-tomcat-7.0.42/conf/Catalina/localhost/anotherApp.xml
ott 18, 2013 6:43:58 PM org.apache.catalina.startup.HostConfig
deployDescriptor
========================

In general, don't specify docBase.
Post by Edoardo Panfili
Avvertenza: A docBase /usr/local/apache-tomcat-7.0.42/webapps/sisv
inside the host appBase has been specified, and will be ignored
A docBase should only be used when locating an application outside of
Tomcat's appBase (defaults to $CATALINA_BASE/webapps). Place that
information in $CATALINA_BASE/conf/Catalina/[hostname]/[appname].xml

=========================
Post by Edoardo Panfili
ott 18, 2013 6:43:59 PM org.apache.catalina.startup.HostConfig
deployDescriptor
Informazioni: Deploying configuration descriptor
/usr/local/apache-tomcat-7.0.42/conf/Catalina/localhost/myApplication.xml
ott 18, 2013 6:43:59 PM
=========================
Post by Edoardo Panfili
org.apache.catalina.startup.SetContextPropertiesRule begin
Avvertenza: [SetContextPropertiesRule]{Context} Setting property 'debug'
to '100' did not find a matching property.
There is no debug attribute for a context (not since Tomcat 5 (?)).

=========================
Post by Edoardo Panfili
ott 18, 2013 6:44:01 PM org.apache.catalina.startup.HostConfig
deployDescriptor
Informazioni: Deploying configuration descriptor
/usr/local/apache-tomcat-7.0.42/conf/Catalina/localhost/app5.xml
ott 18, 2013 6:44:01 PM org.apache.catalina.startup.HostConfig
deployDescriptor
=========================

In general, don't specify docBase.
Post by Edoardo Panfili
Avvertenza: A docBase /usr/local/apache-tomcat-7.0.42/webapps/app5
inside the host appBase has been specified, and will be ignored
ott 18, 2013 6:44:01 PM
A docBase should only be used when locating an application outside of
Tomcat's appBase (defaults to $CATALINA_BASE/webapps). Place that
information in $CATALINA_BASE/conf/Catalina/[hostname]/[appname].xml

=========================
Post by Edoardo Panfili
org.apache.catalina.startup.SetContextPropertiesRule begin
=========================
Post by Edoardo Panfili
Avvertenza: [SetContextPropertiesRule]{Context} Setting property 'debug'
to '100' did not find a matching property.
There is no debug attribute for a context (not since Tomcat 5 (?)).

=========================
Post by Edoardo Panfili
ott 18, 2013 6:44:01 PM org.apache.catalina.startup.HostConfig
deployDirectory
Informazioni: Deploying web application directory
/usr/local/apache-tomcat-7.0.42/webapps/ROOT
ott 18, 2013 6:44:01 PM org.apache.catalina.startup.HostConfig
deployDirectory
Informazioni: Deploying web application directory
/usr/local/apache-tomcat-7.0.42/webapps/manager
ott 18, 2013 6:44:01 PM org.apache.catalina.startup.HostConfig
deployDirectory
Informazioni: Deploying web application directory
/usr/local/apache-tomcat-7.0.42/webapps/app7
ott 18, 2013 6:44:03 PM org.apache.catalina.startup.HostConfig
deployDirectory
Informazioni: Deploying web application directory
/usr/local/apache-tomcat-7.0.42/webapps/host-manager
ott 18, 2013 6:44:03 PM org.apache.coyote.AbstractProtocol start
Informazioni: Starting ProtocolHandler ["http-bio-9080"]
ott 18, 2013 6:44:03 PM org.apache.coyote.AbstractProtocol start
Informazioni: Starting ProtocolHandler ["ajp-bio-9009"]
ott 18, 2013 6:44:03 PM org.apache.catalina.startup.Catalina start
Edoardo
Please read the following:

http://tomcat.apache.org/tomcat-7.0-doc/config/context.html

Clean up your applications, and try this again on a clean Tomcat.

. . . . just my two cents.
/mde/
Edoardo Panfili
2013-10-18 22:03:27 UTC
Permalink
Post by Edoardo Panfili
My Tomcat (7.0.42) is listening on port 7080 and I have this
conf/tomcat-users.xml in (production server)
-------
<tomcat-users>
<role rolename="manager-script"/>
<user username="myname" password="pwd"
roles="manager-script,manager-gui,manager-jmx"/>
</tomcat-users>
----------
if I use
curl -u myname:pwd
http://localhost:7080/manager/text/reload?path=/myApplication
the response is--------------------------
<h1>404 Not found</h1>
<p>
The page you tried to access
(/manager/text/reload)
does not exist.
</p>
<p>
The Manager application has been re-structured for Tomcat 7 onwards
and some
of URLs have changed. All URLs used to access the Manager
application should
</p>
<ul>
<li>/manager/html for the HTML GUI</li>
<li>/manager/text for the text interface</li>
<li>/manager/jmxproxy for the JMX proxy</li>
<li>/manager/status for the status pages</li>
</ul>
<p>
Note that the URL for the text interface has changed from
&quot;/manager&quot; to
&quot;/manager/text&quot;.
</p>
<p>
You probably need to adjust the URL you are using to access the Manager
application. However, there is always a chance you have found a bug
in the
Manager application. If you are sure you have found a bug, and that
the bug
has not already been reported, please report it to the Apache
Tomcat team.
</p>
---------------------------------------------------------
Installation step by step:

Unpack new download from tomcat.apache.org

1- set users
<tomcat-users>
<user username="edoardo" password="pwd"
roles="manager-script,manager-gui,manager-jmx,other"/>
</tomcat-users>

then reload tomcat
$curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/examples
OK - Reloaded application at context path /examples


2- copy myApplication from production server
copy configuration file ($tomcat/Catalina/localhost/myApplication.xml)
from production server
stop & start tomcat

$curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/myApplication
OK - Reloaded application at context path /myApplication


3- first modify to server.xml
shutdown tomcat
modify server.xml
<Connector port="8080" protocol="HTTP/1.1"
becomes
<Connector port="9080" protocol="HTTP/1.1"

start then curl again
all well


4- second modify to server.xml
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
becomes
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true" deployXML="false">

stop-start

$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
javax.servlet.ServletException: Error instantiating servlet class
org.apache.catalina.manager.ManagerServlet
[...]

$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
the same error reported in the initial post (above)



deployXML="false" is recommended at
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html and useful for me.


Edoardo
André Warnier
2013-10-18 22:18:31 UTC
Permalink
Post by Edoardo Panfili
Post by Edoardo Panfili
My Tomcat (7.0.42) is listening on port 7080 and I have this
conf/tomcat-users.xml in (production server)
-------
<tomcat-users>
<role rolename="manager-script"/>
<user username="myname" password="pwd"
roles="manager-script,manager-gui,manager-jmx"/>
</tomcat-users>
----------
if I use
curl -u myname:pwd
http://localhost:7080/manager/text/reload?path=/myApplication
the response is--------------------------
<h1>404 Not found</h1>
<p>
The page you tried to access
(/manager/text/reload)
does not exist.
</p>
<p>
The Manager application has been re-structured for Tomcat 7 onwards
and some
of URLs have changed. All URLs used to access the Manager
application should
</p>
<ul>
<li>/manager/html for the HTML GUI</li>
<li>/manager/text for the text interface</li>
<li>/manager/jmxproxy for the JMX proxy</li>
<li>/manager/status for the status pages</li>
</ul>
<p>
Note that the URL for the text interface has changed from
&quot;/manager&quot; to
&quot;/manager/text&quot;.
</p>
<p>
You probably need to adjust the URL you are using to access the Manager
application. However, there is always a chance you have found a bug
in the
Manager application. If you are sure you have found a bug, and that
the bug
has not already been reported, please report it to the Apache
Tomcat team.
</p>
---------------------------------------------------------
Unpack new download from tomcat.apache.org
1- set users
<tomcat-users>
<user username="edoardo" password="pwd"
roles="manager-script,manager-gui,manager-jmx,other"/>
</tomcat-users>
then reload tomcat
$curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/examples
OK - Reloaded application at context path /examples
2- copy myApplication from production server
copy configuration file ($tomcat/Catalina/localhost/myApplication.xml)
from production server
stop & start tomcat
$curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/myApplication
OK - Reloaded application at context path /myApplication
3- first modify to server.xml
shutdown tomcat
modify server.xml
<Connector port="8080" protocol="HTTP/1.1"
becomes
<Connector port="9080" protocol="HTTP/1.1"
start then curl again
all well
4- second modify to server.xml
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
becomes
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true" deployXML="false">
stop-start
$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
javax.servlet.ServletException: Error instantiating servlet class
org.apache.catalina.manager.ManagerServlet
[...]
$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
the same error reported in the initial post (above)
deployXML="false" is recommended at
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html and useful for me.
One big difference that I see when deployXML="false", is that this file :
(catalina_base)/webapps/myApplication/META-INF/context.xml
is no longer being parsed,
and instead this file is parsed :
$tomcat/Catalina/localhost/myApplication.xml
when you reload your app.
What is the content of that file ?
Mark Eggers
2013-10-18 22:24:25 UTC
Permalink
Post by André Warnier
Post by Edoardo Panfili
Post by Edoardo Panfili
My Tomcat (7.0.42) is listening on port 7080 and I have this
conf/tomcat-users.xml in (production server)
-------
<tomcat-users>
<role rolename="manager-script"/>
<user username="myname" password="pwd"
roles="manager-script,manager-gui,manager-jmx"/>
</tomcat-users>
----------
if I use
curl -u myname:pwd
http://localhost:7080/manager/text/reload?path=/myApplication
the response is--------------------------
<h1>404 Not found</h1>
<p>
The page you tried to access
(/manager/text/reload)
does not exist.
</p>
<p>
The Manager application has been re-structured for Tomcat 7 onwards
and some
of URLs have changed. All URLs used to access the Manager
application should
</p>
<ul>
<li>/manager/html for the HTML GUI</li>
<li>/manager/text for the text interface</li>
<li>/manager/jmxproxy for the JMX proxy</li>
<li>/manager/status for the status pages</li>
</ul>
<p>
Note that the URL for the text interface has changed from
&quot;/manager&quot; to
&quot;/manager/text&quot;.
</p>
<p>
You probably need to adjust the URL you are using to access the Manager
application. However, there is always a chance you have found a bug
in the
Manager application. If you are sure you have found a bug, and that
the bug
has not already been reported, please report it to the Apache
Tomcat team.
</p>
---------------------------------------------------------
Unpack new download from tomcat.apache.org
1- set users
<tomcat-users>
<user username="edoardo" password="pwd"
roles="manager-script,manager-gui,manager-jmx,other"/>
</tomcat-users>
then reload tomcat
$curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/examples
OK - Reloaded application at context path /examples
2- copy myApplication from production server
copy configuration file ($tomcat/Catalina/localhost/myApplication.xml)
from production server
stop & start tomcat
$curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/myApplication
OK - Reloaded application at context path /myApplication
3- first modify to server.xml
shutdown tomcat
modify server.xml
<Connector port="8080" protocol="HTTP/1.1"
becomes
<Connector port="9080" protocol="HTTP/1.1"
start then curl again
all well
4- second modify to server.xml
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
becomes
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true" deployXML="false">
stop-start
$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
javax.servlet.ServletException: Error instantiating servlet class
org.apache.catalina.manager.ManagerServlet
[...]
$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
the same error reported in the initial post (above)
deployXML="false" is recommended at
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html and useful for me.
(catalina_base)/webapps/myApplication/META-INF/context.xml
is no longer being parsed,
$tomcat/Catalina/localhost/myApplication.xml
when you reload your app.
What is the content of that file ?
From the last log file that was posted, these context files are pretty
broken (although myApplication.xml only had the magic debug attribute set).

/mde/
Edoardo Panfili
2013-10-19 07:28:10 UTC
Permalink
Post by Mark Eggers
Post by André Warnier
Post by Edoardo Panfili
Post by Edoardo Panfili
My Tomcat (7.0.42) is listening on port 7080 and I have this
conf/tomcat-users.xml in (production server)
-------
<tomcat-users>
<role rolename="manager-script"/>
<user username="myname" password="pwd"
roles="manager-script,manager-gui,manager-jmx"/>
</tomcat-users>
----------
if I use
curl -u myname:pwd
http://localhost:7080/manager/text/reload?path=/myApplication
the response is--------------------------
<h1>404 Not found</h1>
<p>
The page you tried to access
(/manager/text/reload)
does not exist.
</p>
<p>
The Manager application has been re-structured for Tomcat 7 onwards
and some
of URLs have changed. All URLs used to access the Manager
application should
</p>
<ul>
<li>/manager/html for the HTML GUI</li>
<li>/manager/text for the text interface</li>
<li>/manager/jmxproxy for the JMX proxy</li>
<li>/manager/status for the status pages</li>
</ul>
<p>
Note that the URL for the text interface has changed from
&quot;/manager&quot; to
&quot;/manager/text&quot;.
</p>
<p>
You probably need to adjust the URL you are using to access the Manager
application. However, there is always a chance you have found a bug
in the
Manager application. If you are sure you have found a bug, and that
the bug
has not already been reported, please report it to the Apache
Tomcat team.
</p>
---------------------------------------------------------
Unpack new download from tomcat.apache.org
1- set users
<tomcat-users>
<user username="edoardo" password="pwd"
roles="manager-script,manager-gui,manager-jmx,other"/>
</tomcat-users>
then reload tomcat
$curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/examples
OK - Reloaded application at context path /examples
2- copy myApplication from production server
copy configuration file ($tomcat/Catalina/localhost/myApplication.xml)
from production server
stop & start tomcat
$curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/myApplication
OK - Reloaded application at context path /myApplication
3- first modify to server.xml
shutdown tomcat
modify server.xml
<Connector port="8080" protocol="HTTP/1.1"
becomes
<Connector port="9080" protocol="HTTP/1.1"
start then curl again
all well
4- second modify to server.xml
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
becomes
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true" deployXML="false">
stop-start
$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
javax.servlet.ServletException: Error instantiating servlet class
org.apache.catalina.manager.ManagerServlet
[...]
$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
the same error reported in the initial post (above)
deployXML="false" is recommended at
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html and useful for me.
(catalina_base)/webapps/myApplication/META-INF/context.xml
is no longer being parsed,
$tomcat/Catalina/localhost/myApplication.xml
when you reload your app.
What is the content of that file ?
From the last log file that was posted, these context files are pretty
broken (although myApplication.xml only had the magic debug attribute set).
another try:

- remove deployXML="false" from server.xml
- cp $tomcat/conf/Catalina/localhost/myApplication.xml
$tomcat/webapps/myApplication/META-INF/context.xml
- stop then start tomcat

$curl -u name:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
OK - Reloaded application at context path /myApplication

Edoardo
André Warnier
2013-10-19 13:34:39 UTC
Permalink
Post by Edoardo Panfili
Post by Mark Eggers
Post by André Warnier
Post by Edoardo Panfili
Post by Edoardo Panfili
My Tomcat (7.0.42) is listening on port 7080 and I have this
conf/tomcat-users.xml in (production server)
-------
<tomcat-users>
<role rolename="manager-script"/>
<user username="myname" password="pwd"
roles="manager-script,manager-gui,manager-jmx"/>
</tomcat-users>
----------
if I use
curl -u myname:pwd
http://localhost:7080/manager/text/reload?path=/myApplication
the response is--------------------------
<h1>404 Not found</h1>
<p>
The page you tried to access
(/manager/text/reload)
does not exist.
</p>
<p>
The Manager application has been re-structured for Tomcat 7 onwards
and some
of URLs have changed. All URLs used to access the Manager
application should
</p>
<ul>
<li>/manager/html for the HTML GUI</li>
<li>/manager/text for the text interface</li>
<li>/manager/jmxproxy for the JMX proxy</li>
<li>/manager/status for the status pages</li>
</ul>
<p>
Note that the URL for the text interface has changed from
&quot;/manager&quot; to
&quot;/manager/text&quot;.
</p>
<p>
You probably need to adjust the URL you are using to access the Manager
application. However, there is always a chance you have found a bug
in the
Manager application. If you are sure you have found a bug, and that
the bug
has not already been reported, please report it to the Apache
Tomcat team.
</p>
---------------------------------------------------------
Unpack new download from tomcat.apache.org
1- set users
<tomcat-users>
<user username="edoardo" password="pwd"
roles="manager-script,manager-gui,manager-jmx,other"/>
</tomcat-users>
then reload tomcat
$curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/examples
OK - Reloaded application at context path /examples
2- copy myApplication from production server
copy configuration file ($tomcat/Catalina/localhost/myApplication.xml)
from production server
stop & start tomcat
$curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/myApplication
OK - Reloaded application at context path /myApplication
3- first modify to server.xml
shutdown tomcat
modify server.xml
<Connector port="8080" protocol="HTTP/1.1"
becomes
<Connector port="9080" protocol="HTTP/1.1"
start then curl again
all well
4- second modify to server.xml
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
becomes
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true" deployXML="false">
stop-start
$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
javax.servlet.ServletException: Error instantiating servlet class
org.apache.catalina.manager.ManagerServlet
[...]
$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
the same error reported in the initial post (above)
deployXML="false" is recommended at
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html and useful for me.
(catalina_base)/webapps/myApplication/META-INF/context.xml
is no longer being parsed,
$tomcat/Catalina/localhost/myApplication.xml
when you reload your app.
What is the content of that file ?
From the last log file that was posted, these context files are pretty
broken (although myApplication.xml only had the magic debug attribute set).
- remove deployXML="false" from server.xml
- cp $tomcat/conf/Catalina/localhost/myApplication.xml
$tomcat/webapps/myApplication/META-INF/context.xml
- stop then start tomcat
$curl -u name:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
OK - Reloaded application at context path /myApplication
That does look like a bug, doesn't it ?
Or at least, it doesn't look like it matches what is written in
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html
for "deployXML".

What happens if you set autoDeploy="false" ?
Edoardo Panfili
2013-10-19 21:57:52 UTC
Permalink
Post by André Warnier
Post by Edoardo Panfili
Post by Mark Eggers
Post by André Warnier
Post by Edoardo Panfili
Post by Edoardo Panfili
My Tomcat (7.0.42) is listening on port 7080 and I have this
conf/tomcat-users.xml in (production server)
-------
<tomcat-users>
<role rolename="manager-script"/>
<user username="myname" password="pwd"
roles="manager-script,manager-gui,manager-jmx"/>
</tomcat-users>
----------
if I use
curl -u myname:pwd
http://localhost:7080/manager/text/reload?path=/myApplication
the response is--------------------------
<h1>404 Not found</h1>
<p>
The page you tried to access
(/manager/text/reload)
does not exist.
</p>
<p>
The Manager application has been re-structured for Tomcat 7 onwards
and some
of URLs have changed. All URLs used to access the Manager
application should
</p>
<ul>
<li>/manager/html for the HTML GUI</li>
<li>/manager/text for the text interface</li>
<li>/manager/jmxproxy for the JMX proxy</li>
<li>/manager/status for the status pages</li>
</ul>
<p>
Note that the URL for the text interface has changed from
&quot;/manager&quot; to
&quot;/manager/text&quot;.
</p>
<p>
You probably need to adjust the URL you are using to access the Manager
application. However, there is always a chance you have found a bug
in the
Manager application. If you are sure you have found a bug, and that
the bug
has not already been reported, please report it to the Apache
Tomcat team.
</p>
---------------------------------------------------------
Unpack new download from tomcat.apache.org
1- set users
<tomcat-users>
<user username="edoardo" password="pwd"
roles="manager-script,manager-gui,manager-jmx,other"/>
</tomcat-users>
then reload tomcat
$curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/examples
OK - Reloaded application at context path /examples
2- copy myApplication from production server
copy configuration file ($tomcat/Catalina/localhost/myApplication.xml)
from production server
stop & start tomcat
$curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/myApplication
OK - Reloaded application at context path /myApplication
3- first modify to server.xml
shutdown tomcat
modify server.xml
<Connector port="8080" protocol="HTTP/1.1"
becomes
<Connector port="9080" protocol="HTTP/1.1"
start then curl again
all well
4- second modify to server.xml
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
becomes
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true" deployXML="false">
stop-start
$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
javax.servlet.ServletException: Error instantiating servlet class
org.apache.catalina.manager.ManagerServlet
[...]
$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
the same error reported in the initial post (above)
deployXML="false" is recommended at
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html and useful for me.
(catalina_base)/webapps/myApplication/META-INF/context.xml
is no longer being parsed,
$tomcat/Catalina/localhost/myApplication.xml
when you reload your app.
What is the content of that file ?
From the last log file that was posted, these context files are pretty
broken (although myApplication.xml only had the magic debug attribute set).
- remove deployXML="false" from server.xml
- cp $tomcat/conf/Catalina/localhost/myApplication.xml
$tomcat/webapps/myApplication/META-INF/context.xml
- stop then start tomcat
$curl -u name:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
OK - Reloaded application at context path /myApplication
That does look like a bug, doesn't it ?
Or at least, it doesn't look like it matches what is written in
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html
for "deployXML".
What happens if you set autoDeploy="false" ?
sorry for the late of the response but this mail (and another one) is
arrived in late.

autoDeploy="false" is the default setting and with default settings all
goes well.

using autoDeploy="true" I must move manager context file in
conf/Catalina/localhost (as explained in other post of this thread).

thank you
Edoardo
Edoardo Panfili
2013-10-19 08:23:11 UTC
Permalink
Post by Mark Eggers
Post by André Warnier
Post by Edoardo Panfili
Post by Edoardo Panfili
My Tomcat (7.0.42) is listening on port 7080 and I have this
conf/tomcat-users.xml in (production server)
-------
<tomcat-users>
<role rolename="manager-script"/>
<user username="myname" password="pwd"
roles="manager-script,manager-gui,manager-jmx"/>
</tomcat-users>
----------
if I use
curl -u myname:pwd
http://localhost:7080/manager/text/reload?path=/myApplication
the response is--------------------------
<h1>404 Not found</h1>
<p>
The page you tried to access
(/manager/text/reload)
does not exist.
</p>
<p>
The Manager application has been re-structured for Tomcat 7 onwards
and some
of URLs have changed. All URLs used to access the Manager
application should
</p>
<ul>
<li>/manager/html for the HTML GUI</li>
<li>/manager/text for the text interface</li>
<li>/manager/jmxproxy for the JMX proxy</li>
<li>/manager/status for the status pages</li>
</ul>
<p>
Note that the URL for the text interface has changed from
&quot;/manager&quot; to
&quot;/manager/text&quot;.
</p>
<p>
You probably need to adjust the URL you are using to access the Manager
application. However, there is always a chance you have found a bug
in the
Manager application. If you are sure you have found a bug, and that
the bug
has not already been reported, please report it to the Apache
Tomcat team.
</p>
---------------------------------------------------------
Unpack new download from tomcat.apache.org
1- set users
<tomcat-users>
<user username="edoardo" password="pwd"
roles="manager-script,manager-gui,manager-jmx,other"/>
</tomcat-users>
then reload tomcat
$curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/examples
OK - Reloaded application at context path /examples
2- copy myApplication from production server
copy configuration file ($tomcat/Catalina/localhost/myApplication.xml)
from production server
stop & start tomcat
$curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/myApplication
OK - Reloaded application at context path /myApplication
3- first modify to server.xml
shutdown tomcat
modify server.xml
<Connector port="8080" protocol="HTTP/1.1"
becomes
<Connector port="9080" protocol="HTTP/1.1"
start then curl again
all well
4- second modify to server.xml
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
becomes
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true" deployXML="false">
stop-start
$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
javax.servlet.ServletException: Error instantiating servlet class
org.apache.catalina.manager.ManagerServlet
[...]
$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
the same error reported in the initial post (above)
deployXML="false" is recommended at
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html and useful for me.
(catalina_base)/webapps/myApplication/META-INF/context.xml
is no longer being parsed,
$tomcat/Catalina/localhost/myApplication.xml
when you reload your app.
What is the content of that file ?
From the last log file that was posted, these context files are pretty
broken (although myApplication.xml only had the magic debug attribute set).
- unpack tomcat
- add an user in tomcat-users.xml
- modify server.xml adding deployXML="false" to Host
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true" deployXML="false">
- use manager application via curl
$ curl -u user:pwd http://localhost:8080/manager/text/reload?path=/example

error page.

# cat manager.2013-10-19.log
19-ott-2013 10.16.17 org.apache.catalina.core.ApplicationContext log
INFO: Marking servlet Manager as unavailable
19-ott-2013 10.16.17 org.apache.catalina.core.StandardWrapperValve invoke
GRAVE: Allocate exception for servlet Manager
java.lang.SecurityException: Restricted (ContainerServlet) class
org.apache.catalina.manager.ManagerServlet
at
org.apache.catalina.core.DefaultInstanceManager.checkAccess(DefaultInstanceManager.java:538)
at
org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:511)
at
org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:137)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1144)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:865)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:136)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:611)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)


my running environment is
OS: Debian 6.0.7
Tomcat: 7.042 from Apache site
java: OpenJDK Runtime Environment (IcedTea6 1.8.13) (6b18-1.8.13-0+squeeze2)


Edoardo
Martin Gainty
2013-10-19 12:21:44 UTC
Permalink
Date: Sat, 19 Oct 2013 10:23:11 +0200
Subject: Re: can't connect to manager application
Post by Mark Eggers
Post by André Warnier
Post by Edoardo Panfili
Post by Edoardo Panfili
My Tomcat (7.0.42) is listening on port 7080 and I have this
conf/tomcat-users.xml in (production server)
-------
<tomcat-users>
<role rolename="manager-script"/>
<user username="myname" password="pwd"
roles="manager-script,manager-gui,manager-jmx"/>
</tomcat-users>
----------
if I use
curl -u myname:pwd
http://localhost:7080/manager/text/reload?path=/myApplication
the response is--------------------------
<h1>404 Not found</h1>
<p>
The page you tried to access
(/manager/text/reload)
does not exist.
</p>
<p>
The Manager application has been re-structured for Tomcat 7 onwards
and some
of URLs have changed. All URLs used to access the Manager
application should
</p>
<ul>
<li>/manager/html for the HTML GUI</li>
<li>/manager/text for the text interface</li>
<li>/manager/jmxproxy for the JMX proxy</li>
<li>/manager/status for the status pages</li>
</ul>
<p>
Note that the URL for the text interface has changed from
&quot;/manager&quot; to
&quot;/manager/text&quot;.
</p>
<p>
You probably need to adjust the URL you are using to access the Manager
application. However, there is always a chance you have found a bug
in the
Manager application. If you are sure you have found a bug, and that
the bug
has not already been reported, please report it to the Apache
Tomcat team.
</p>
---------------------------------------------------------
Unpack new download from tomcat.apache.org
1- set users
<tomcat-users>
<user username="edoardo" password="pwd"
roles="manager-script,manager-gui,manager-jmx,other"/>
</tomcat-users>
then reload tomcat
$curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/examples
OK - Reloaded application at context path /examples
2- copy myApplication from production server
copy configuration file ($tomcat/Catalina/localhost/myApplication.xml)
from production server
stop & start tomcat
$curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/myApplication
OK - Reloaded application at context path /myApplication
3- first modify to server.xml
shutdown tomcat
modify server.xml
<Connector port="8080" protocol="HTTP/1.1"
becomes
<Connector port="9080" protocol="HTTP/1.1"
start then curl again
all well
4- second modify to server.xml
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
becomes
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true" deployXML="false">
stop-start
$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
javax.servlet.ServletException: Error instantiating servlet class
org.apache.catalina.manager.ManagerServlet
[...]
$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
the same error reported in the initial post (above)
deployXML="false" is recommended at
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html and useful for me.
(catalina_base)/webapps/myApplication/META-INF/context.xml
is no longer being parsed,
$tomcat/Catalina/localhost/myApplication.xml
when you reload your app.
What is the content of that file ?
From the last log file that was posted, these context files are pretty
broken (although myApplication.xml only had the magic debug attribute set).
- unpack tomcat
- add an user in tomcat-users.xml
- modify server.xml adding deployXML="false" to Host
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true" deployXML="false">
- use manager application via curl
$ curl -u user:pwd http://localhost:8080/manager/text/reload?path=/example
error page.
# cat manager.2013-10-19.log
19-ott-2013 10.16.17 org.apache.catalina.core.ApplicationContext log
INFO: Marking servlet Manager as unavailable
19-ott-2013 10.16.17 org.apache.catalina.core.StandardWrapperValve invoke
GRAVE: Allocate exception for servlet Manager
java.lang.SecurityException: Restricted (ContainerServlet) class
org.apache.catalina.manager.ManagerServlet
at
org.apache.catalina.core.DefaultInstanceManager.checkAccess(DefaultInstanceManager.java:538)
at
org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:511)
at
org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:137)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1144)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:865)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:136)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:611)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
MG>run catalina with debug AND securityManager enabled
MG>catalina<.bat/sh> debug -security //Debug Catalina with a security manager

MG>Ensure Security listener is enabled in server.xml
MG><Listener className="org.apache.catalina.security.SecurityListener" />

MG>check permissions setup for "securityManager" in /conf/catalina.policy
MG>// catalina.policy - Security Policy Permissions for Tomcat 7
//
// This file contains a default set of security policies to be enforced (by the
// JVM) when Catalina is executed with the "-security" option. In addition
// to the permissions granted here, the following additional permissions are
// granted to each web application:
//
// * Read access to the web application's document root directory
// * Read, write and delete access to the web application's working directory
// These permissions apply to javac
grant codeBase "file:${java.home}/lib/-" {
permission java.security.AllPermission;
};
// These permissions apply to all shared system extensions
grant codeBase "file:${java.home}/jre/lib/ext/-" {
permission java.security.AllPermission;
};
// These permissions apply to javac when ${java.home] points at $JAVA_HOME/jre
grant codeBase "file:${java.home}/../lib/-" {
permission java.security.AllPermission;
};
// These permissions apply to all shared system extensions when
// ${java.home} points at $JAVA_HOME/jre
grant codeBase "file:${java.home}/lib/ext/-" {
permission java.security.AllPermission;
};

MG>make sure ALL of these grants in catalina.policy are enabled (and not commented out or deleted)
MG>bounce TC and report back
my running environment is
OS: Debian 6.0.7
Tomcat: 7.042 from Apache site
java: OpenJDK Runtime Environment (IcedTea6 1.8.13) (6b18-1.8.13-0+squeeze2)
Edoardo
MG>MG
---------------------------------------------------------------------
Edoardo Panfili
2013-10-19 13:46:16 UTC
Permalink
Post by Martin Gainty
Date: Sat, 19 Oct 2013 10:23:11 +0200
Subject: Re: can't connect to manager application
Post by Mark Eggers
Post by André Warnier
Post by Edoardo Panfili
Post by Edoardo Panfili
My Tomcat (7.0.42) is listening on port 7080 and I have this
conf/tomcat-users.xml in (production server)
-------
<tomcat-users>
<role rolename="manager-script"/>
<user username="myname" password="pwd"
roles="manager-script,manager-gui,manager-jmx"/>
</tomcat-users>
----------
if I use
curl -u myname:pwd
http://localhost:7080/manager/text/reload?path=/myApplication
the response is--------------------------
<h1>404 Not found</h1>
<p>
The page you tried to access
(/manager/text/reload)
does not exist.
</p>
<p>
The Manager application has been re-structured for Tomcat 7 onwards
and some
of URLs have changed. All URLs used to access the Manager
application should
</p>
<ul>
<li>/manager/html for the HTML GUI</li>
<li>/manager/text for the text interface</li>
<li>/manager/jmxproxy for the JMX proxy</li>
<li>/manager/status for the status pages</li>
</ul>
<p>
Note that the URL for the text interface has changed from
&quot;/manager&quot; to
&quot;/manager/text&quot;.
</p>
<p>
You probably need to adjust the URL you are using to access the Manager
application. However, there is always a chance you have found a bug
in the
Manager application. If you are sure you have found a bug, and that
the bug
has not already been reported, please report it to the Apache
Tomcat team.
</p>
---------------------------------------------------------
Unpack new download from tomcat.apache.org
1- set users
<tomcat-users>
<user username="edoardo" password="pwd"
roles="manager-script,manager-gui,manager-jmx,other"/>
</tomcat-users>
then reload tomcat
$curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/examples
OK - Reloaded application at context path /examples
2- copy myApplication from production server
copy configuration file ($tomcat/Catalina/localhost/myApplication.xml)
from production server
stop & start tomcat
$curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/myApplication
OK - Reloaded application at context path /myApplication
3- first modify to server.xml
shutdown tomcat
modify server.xml
<Connector port="8080" protocol="HTTP/1.1"
becomes
<Connector port="9080" protocol="HTTP/1.1"
start then curl again
all well
4- second modify to server.xml
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
becomes
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true" deployXML="false">
stop-start
$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
javax.servlet.ServletException: Error instantiating servlet class
org.apache.catalina.manager.ManagerServlet
[...]
$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
the same error reported in the initial post (above)
deployXML="false" is recommended at
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html and useful for me.
(catalina_base)/webapps/myApplication/META-INF/context.xml
is no longer being parsed,
$tomcat/Catalina/localhost/myApplication.xml
when you reload your app.
What is the content of that file ?
From the last log file that was posted, these context files are pretty
broken (although myApplication.xml only had the magic debug attribute set).
- unpack tomcat
- add an user in tomcat-users.xml
- modify server.xml adding deployXML="false" to Host
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true" deployXML="false">
- use manager application via curl
$ curl -u user:pwd http://localhost:8080/manager/text/reload?path=/example
error page.
# cat manager.2013-10-19.log
19-ott-2013 10.16.17 org.apache.catalina.core.ApplicationContext log
INFO: Marking servlet Manager as unavailable
19-ott-2013 10.16.17 org.apache.catalina.core.StandardWrapperValve invoke
GRAVE: Allocate exception for servlet Manager
java.lang.SecurityException: Restricted (ContainerServlet) class
org.apache.catalina.manager.ManagerServlet
at
org.apache.catalina.core.DefaultInstanceManager.checkAccess(DefaultInstanceManager.java:538)
at
org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:511)
at
org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:137)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1144)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:865)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:136)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:611)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
MG>run catalina with debug AND securityManager enabled
MG>catalina<.bat/sh> debug -security //Debug Catalina with a security manager
MG>Ensure Security listener is enabled in server.xml
MG><Listener className="org.apache.catalina.security.SecurityListener" />
MG>check permissions setup for "securityManager" in /conf/catalina.policy
MG>// catalina.policy - Security Policy Permissions for Tomcat 7
//
// This file contains a default set of security policies to be enforced (by the
// JVM) when Catalina is executed with the "-security" option. In addition
// to the permissions granted here, the following additional permissions are
//
// * Read access to the web application's document root directory
// * Read, write and delete access to the web application's working directory
// These permissions apply to javac
grant codeBase "file:${java.home}/lib/-" {
permission java.security.AllPermission;
};
// These permissions apply to all shared system extensions
grant codeBase "file:${java.home}/jre/lib/ext/-" {
permission java.security.AllPermission;
};
// These permissions apply to javac when ${java.home] points at $JAVA_HOME/jre
grant codeBase "file:${java.home}/../lib/-" {
permission java.security.AllPermission;
};
// These permissions apply to all shared system extensions when
// ${java.home} points at $JAVA_HOME/jre
grant codeBase "file:${java.home}/lib/ext/-" {
permission java.security.AllPermission;
};
MG>make sure ALL of these grants in catalina.policy are enabled (and not commented out or deleted)
MG>bounce TC and report back
permissions OK.(none modified)
Security listener in server.xml in now enabled
$ export JAVA_HOME=/usr/lib/jvm/java-6-openjdk/


$tomcat/bin/catalina.sh debug -security
Using CATALINA_BASE: /usr/local/tomcat7
Using CATALINA_HOME: /usr/local/tomcat7
Using CATALINA_TMPDIR: /usr/local/tomcat7/temp
Using JAVA_HOME: /usr/lib/jvm/java-6-openjdk/
Using CLASSPATH:
/usr/local/tomcat7/bin/bootstrap.jar:/usr/local/tomcat7/bin/tomcat-juli.jar
Using Security Manager
Initializing jdb ...
Post by Martin Gainty
run
run org.apache.catalina.startup.Bootstrap start
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
VM Started: 19-ott-2013 15.33.07
org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal
performance in production environments was not found on the
java.library.path:
/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib/jni:/lib:/usr/lib
java.lang.Error: Start attempted while running as user [root]. Running
Tomcat as this user has been blocked by the Lifecycle listener
org.apache.catalina.security.SecurityListener (usually configured in
CATALINA_BASE/conf/server.xml)
at
org.apache.catalina.security.SecurityListener.checkOsUser(SecurityListener.java:154)
at
org.apache.catalina.security.SecurityListener.doChecks(SecurityListener.java:142)
at
org.apache.catalina.security.SecurityListener.lifecycleEvent(SecurityListener.java:63)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:402)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:99)
at org.apache.catalina.startup.Catalina.load(Catalina.java:640)
at org.apache.catalina.startup.Catalina.load(Catalina.java:665)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:281)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:455)

The application exited
***@virtual-vnr:/usr/local/tomcat7/logs#


the same using jdk1.7.0_45 from Oracle.


Edoardo
André Warnier
2013-10-19 14:19:29 UTC
Permalink
Post by Edoardo Panfili
Post by Martin Gainty
Date: Sat, 19 Oct 2013 10:23:11 +0200
Subject: Re: can't connect to manager application
Post by Mark Eggers
Post by André Warnier
Post by Edoardo Panfili
Post by Edoardo Panfili
My Tomcat (7.0.42) is listening on port 7080 and I have this
conf/tomcat-users.xml in (production server)
-------
<tomcat-users>
<role rolename="manager-script"/>
<user username="myname" password="pwd"
roles="manager-script,manager-gui,manager-jmx"/>
</tomcat-users>
----------
if I use
curl -u myname:pwd
http://localhost:7080/manager/text/reload?path=/myApplication
the response is--------------------------
<h1>404 Not found</h1>
<p>
The page you tried to access
(/manager/text/reload)
does not exist.
</p>
<p>
The Manager application has been re-structured for Tomcat 7 onwards
and some
of URLs have changed. All URLs used to access the Manager
application should
</p>
<ul>
<li>/manager/html for the HTML GUI</li>
<li>/manager/text for the text interface</li>
<li>/manager/jmxproxy for the JMX proxy</li>
<li>/manager/status for the status pages</li>
</ul>
<p>
Note that the URL for the text interface has changed from
&quot;/manager&quot; to
&quot;/manager/text&quot;.
</p>
<p>
You probably need to adjust the URL you are using to access the Manager
application. However, there is always a chance you have found a bug
in the
Manager application. If you are sure you have found a bug, and that
the bug
has not already been reported, please report it to the Apache
Tomcat team.
</p>
---------------------------------------------------------
Unpack new download from tomcat.apache.org
1- set users
<tomcat-users>
<user username="edoardo" password="pwd"
roles="manager-script,manager-gui,manager-jmx,other"/>
</tomcat-users>
then reload tomcat
$curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/examples
OK - Reloaded application at context path /examples
2- copy myApplication from production server
copy configuration file
($tomcat/Catalina/localhost/myApplication.xml)
from production server
stop & start tomcat
$curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/myApplication
OK - Reloaded application at context path /myApplication
3- first modify to server.xml
shutdown tomcat
modify server.xml
<Connector port="8080" protocol="HTTP/1.1"
becomes
<Connector port="9080" protocol="HTTP/1.1"
start then curl again
all well
4- second modify to server.xml
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
becomes
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true" deployXML="false">
stop-start
$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
javax.servlet.ServletException: Error instantiating servlet class
org.apache.catalina.manager.ManagerServlet
[...]
$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
the same error reported in the initial post (above)
deployXML="false" is recommended at
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html and useful for me.
(catalina_base)/webapps/myApplication/META-INF/context.xml
is no longer being parsed,
$tomcat/Catalina/localhost/myApplication.xml
when you reload your app.
What is the content of that file ?
From the last log file that was posted, these context files are pretty
broken (although myApplication.xml only had the magic debug
attribute set).
- unpack tomcat
- add an user in tomcat-users.xml
- modify server.xml adding deployXML="false" to Host
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true" deployXML="false">
- use manager application via curl
$ curl -u user:pwd
http://localhost:8080/manager/text/reload?path=/example
error page.
# cat manager.2013-10-19.log
19-ott-2013 10.16.17 org.apache.catalina.core.ApplicationContext log
INFO: Marking servlet Manager as unavailable
19-ott-2013 10.16.17 org.apache.catalina.core.StandardWrapperValve invoke
GRAVE: Allocate exception for servlet Manager
java.lang.SecurityException: Restricted (ContainerServlet) class
org.apache.catalina.manager.ManagerServlet
at
org.apache.catalina.core.DefaultInstanceManager.checkAccess(DefaultInstanceManager.java:538)
at
org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:511)
at
org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:137)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1144)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:865)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:136)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:611)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
MG>run catalina with debug AND securityManager enabled
MG>catalina<.bat/sh> debug -security //Debug Catalina with a security manager
MG>Ensure Security listener is enabled in server.xml
MG><Listener className="org.apache.catalina.security.SecurityListener" />
MG>check permissions setup for "securityManager" in /conf/catalina.policy
MG>// catalina.policy - Security Policy Permissions for Tomcat 7
//
// This file contains a default set of security policies to be enforced (by the
// JVM) when Catalina is executed with the "-security" option. In addition
// to the permissions granted here, the following additional
permissions are
//
// * Read access to the web application's document root directory
// * Read, write and delete access to the web application's working directory
// These permissions apply to javac
grant codeBase "file:${java.home}/lib/-" {
permission java.security.AllPermission;
};
// These permissions apply to all shared system extensions
grant codeBase "file:${java.home}/jre/lib/ext/-" {
permission java.security.AllPermission;
};
// These permissions apply to javac when ${java.home] points at $JAVA_HOME/jre
grant codeBase "file:${java.home}/../lib/-" {
permission java.security.AllPermission;
};
// These permissions apply to all shared system extensions when
// ${java.home} points at $JAVA_HOME/jre
grant codeBase "file:${java.home}/lib/ext/-" {
permission java.security.AllPermission;
};
MG>make sure ALL of these grants in catalina.policy are enabled (and
not commented out or deleted)
MG>bounce TC and report back
permissions OK.(none modified)
Security listener in server.xml in now enabled
$ export JAVA_HOME=/usr/lib/jvm/java-6-openjdk/
$tomcat/bin/catalina.sh debug -security
Using CATALINA_BASE: /usr/local/tomcat7
Using CATALINA_HOME: /usr/local/tomcat7
Using CATALINA_TMPDIR: /usr/local/tomcat7/temp
Using JAVA_HOME: /usr/lib/jvm/java-6-openjdk/
/usr/local/tomcat7/bin/bootstrap.jar:/usr/local/tomcat7/bin/tomcat-juli.jar
Using Security Manager
Initializing jdb ...
Post by Martin Gainty
run
run org.apache.catalina.startup.Bootstrap start
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
VM Started: 19-ott-2013 15.33.07
org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal
performance in production environments was not found on the
/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib/jni:/lib:/usr/lib
java.lang.Error: Start attempted while running as user [root]. Running
Tomcat as this user has been blocked by the Lifecycle listener
org.apache.catalina.security.SecurityListener (usually configured in
CATALINA_BASE/conf/server.xml)
at
org.apache.catalina.security.SecurityListener.checkOsUser(SecurityListener.java:154)
at
org.apache.catalina.security.SecurityListener.doChecks(SecurityListener.java:142)
at
org.apache.catalina.security.SecurityListener.lifecycleEvent(SecurityListener.java:63)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:402)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:99)
at org.apache.catalina.startup.Catalina.load(Catalina.java:640)
at org.apache.catalina.startup.Catalina.load(Catalina.java:665)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:281)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:455)
The application exited
the same using jdk1.7.0_45 from Oracle.
As posted by Konstantin before, your problem has nothing to do with the Java Security manager.
But the problem that ou are having here is because you run Tomcat as user root. The SM
doesn't like that.
That is why "jsvc" exists. It will allow the process to open a listening port < 1024, but
Tomcat itself will not run as root.
Running a webserver as root is dangerous : it has too many privileges; if it gets broken
in, your whole system is open to the attacker.
One thing at a time. For now, forget about the Security Manager.
Edoardo Panfili
2013-10-19 21:30:01 UTC
Permalink
Post by André Warnier
Post by Edoardo Panfili
Post by Martin Gainty
Date: Sat, 19 Oct 2013 10:23:11 +0200
Subject: Re: can't connect to manager application
Post by Mark Eggers
Post by André Warnier
Post by Edoardo Panfili
Post by Edoardo Panfili
My Tomcat (7.0.42) is listening on port 7080 and I have this
conf/tomcat-users.xml in (production server)
-------
<tomcat-users>
<role rolename="manager-script"/>
<user username="myname" password="pwd"
roles="manager-script,manager-gui,manager-jmx"/>
</tomcat-users>
----------
if I use
curl -u myname:pwd
http://localhost:7080/manager/text/reload?path=/myApplication
the response is--------------------------
<h1>404 Not found</h1>
<p>
The page you tried to access
(/manager/text/reload)
does not exist.
</p>
<p>
The Manager application has been re-structured for Tomcat 7 onwards
and some
of URLs have changed. All URLs used to access the Manager
application should
</p>
<ul>
<li>/manager/html for the HTML GUI</li>
<li>/manager/text for the text interface</li>
<li>/manager/jmxproxy for the JMX proxy</li>
<li>/manager/status for the status pages</li>
</ul>
<p>
Note that the URL for the text interface has changed from
&quot;/manager&quot; to
&quot;/manager/text&quot;.
</p>
<p>
You probably need to adjust the URL you are using to access the Manager
application. However, there is always a chance you have found a bug
in the
Manager application. If you are sure you have found a bug, and that
the bug
has not already been reported, please report it to the Apache
Tomcat team.
</p>
---------------------------------------------------------
Unpack new download from tomcat.apache.org
1- set users
<tomcat-users>
<user username="edoardo" password="pwd"
roles="manager-script,manager-gui,manager-jmx,other"/>
</tomcat-users>
then reload tomcat
$curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/examples
OK - Reloaded application at context path /examples
2- copy myApplication from production server
copy configuration file
($tomcat/Catalina/localhost/myApplication.xml)
from production server
stop & start tomcat
$curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/myApplication
OK - Reloaded application at context path /myApplication
3- first modify to server.xml
shutdown tomcat
modify server.xml
<Connector port="8080" protocol="HTTP/1.1"
becomes
<Connector port="9080" protocol="HTTP/1.1"
start then curl again
all well
4- second modify to server.xml
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
becomes
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true" deployXML="false">
stop-start
$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
javax.servlet.ServletException: Error instantiating servlet class
org.apache.catalina.manager.ManagerServlet
[...]
$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
the same error reported in the initial post (above)
deployXML="false" is recommended at
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html and useful for me.
(catalina_base)/webapps/myApplication/META-INF/context.xml
is no longer being parsed,
$tomcat/Catalina/localhost/myApplication.xml
when you reload your app.
What is the content of that file ?
From the last log file that was posted, these context files are pretty
broken (although myApplication.xml only had the magic debug attribute set).
- unpack tomcat
- add an user in tomcat-users.xml
- modify server.xml adding deployXML="false" to Host
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true" deployXML="false">
- use manager application via curl
$ curl -u user:pwd
http://localhost:8080/manager/text/reload?path=/example
error page.
# cat manager.2013-10-19.log
19-ott-2013 10.16.17 org.apache.catalina.core.ApplicationContext log
INFO: Marking servlet Manager as unavailable
19-ott-2013 10.16.17 org.apache.catalina.core.StandardWrapperValve invoke
GRAVE: Allocate exception for servlet Manager
java.lang.SecurityException: Restricted (ContainerServlet) class
org.apache.catalina.manager.ManagerServlet
at
org.apache.catalina.core.DefaultInstanceManager.checkAccess(DefaultInstanceManager.java:538)
at
org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:511)
at
org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:137)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1144)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:865)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:136)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:611)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
MG>run catalina with debug AND securityManager enabled
MG>catalina<.bat/sh> debug -security //Debug Catalina with a security manager
MG>Ensure Security listener is enabled in server.xml
MG><Listener
className="org.apache.catalina.security.SecurityListener" />
MG>check permissions setup for "securityManager" in
/conf/catalina.policy
MG>// catalina.policy - Security Policy Permissions for Tomcat 7
//
// This file contains a default set of security policies to be enforced (by the
// JVM) when Catalina is executed with the "-security" option. In addition
// to the permissions granted here, the following additional
permissions are
//
// * Read access to the web application's document root directory
// * Read, write and delete access to the web application's working directory
// These permissions apply to javac
grant codeBase "file:${java.home}/lib/-" {
permission java.security.AllPermission;
};
// These permissions apply to all shared system extensions
grant codeBase "file:${java.home}/jre/lib/ext/-" {
permission java.security.AllPermission;
};
// These permissions apply to javac when ${java.home] points at $JAVA_HOME/jre
grant codeBase "file:${java.home}/../lib/-" {
permission java.security.AllPermission;
};
// These permissions apply to all shared system extensions when
// ${java.home} points at $JAVA_HOME/jre
grant codeBase "file:${java.home}/lib/ext/-" {
permission java.security.AllPermission;
};
MG>make sure ALL of these grants in catalina.policy are enabled (and
not commented out or deleted)
MG>bounce TC and report back
permissions OK.(none modified)
Security listener in server.xml in now enabled
$ export JAVA_HOME=/usr/lib/jvm/java-6-openjdk/
$tomcat/bin/catalina.sh debug -security
Using CATALINA_BASE: /usr/local/tomcat7
Using CATALINA_HOME: /usr/local/tomcat7
Using CATALINA_TMPDIR: /usr/local/tomcat7/temp
Using JAVA_HOME: /usr/lib/jvm/java-6-openjdk/
/usr/local/tomcat7/bin/bootstrap.jar:/usr/local/tomcat7/bin/tomcat-juli.jar
Using Security Manager
Initializing jdb ...
Post by Martin Gainty
run
run org.apache.catalina.startup.Bootstrap start
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
VM Started: 19-ott-2013 15.33.07
org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal
performance in production environments was not found on the
/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib/jni:/lib:/usr/lib
java.lang.Error: Start attempted while running as user [root]. Running
Tomcat as this user has been blocked by the Lifecycle listener
org.apache.catalina.security.SecurityListener (usually configured in
CATALINA_BASE/conf/server.xml)
at
org.apache.catalina.security.SecurityListener.checkOsUser(SecurityListener.java:154)
at
org.apache.catalina.security.SecurityListener.doChecks(SecurityListener.java:142)
at
org.apache.catalina.security.SecurityListener.lifecycleEvent(SecurityListener.java:63)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:402)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:99)
at org.apache.catalina.startup.Catalina.load(Catalina.java:640)
at org.apache.catalina.startup.Catalina.load(Catalina.java:665)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:281)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:455)
The application exited
the same using jdk1.7.0_45 from Oracle.
As posted by Konstantin before, your problem has nothing to do with the
Java Security manager.
But the problem that ou are having here is because you run Tomcat as
user root. The SM doesn't like that.
That is why "jsvc" exists. It will allow the process to open a
listening port < 1024, but Tomcat itself will not run as root.
Running a webserver as root is dangerous : it has too many privileges;
if it gets broken in, your whole system is open to the attacker.
One thing at a time. For now, forget about the Security Manager.
I'm sorry but in production server I am using jsvc.

[from ps]

7369 ? Ss 0:00 jsvc.exec -java-home /usr/local/jdk1.7.0_40
-user tomcat -pidfile /usr/local/tomcat7/logs/cat

Edoardo
Edoardo Panfili
2013-10-19 07:12:18 UTC
Permalink
Post by André Warnier
Post by Edoardo Panfili
Post by Edoardo Panfili
My Tomcat (7.0.42) is listening on port 7080 and I have this
conf/tomcat-users.xml in (production server)
-------
<tomcat-users>
<role rolename="manager-script"/>
<user username="myname" password="pwd"
roles="manager-script,manager-gui,manager-jmx"/>
</tomcat-users>
----------
if I use
curl -u myname:pwd
http://localhost:7080/manager/text/reload?path=/myApplication
the response is--------------------------
<h1>404 Not found</h1>
<p>
The page you tried to access
(/manager/text/reload)
does not exist.
</p>
<p>
The Manager application has been re-structured for Tomcat 7 onwards
and some
of URLs have changed. All URLs used to access the Manager
application should
</p>
<ul>
<li>/manager/html for the HTML GUI</li>
<li>/manager/text for the text interface</li>
<li>/manager/jmxproxy for the JMX proxy</li>
<li>/manager/status for the status pages</li>
</ul>
<p>
Note that the URL for the text interface has changed from
&quot;/manager&quot; to
&quot;/manager/text&quot;.
</p>
<p>
You probably need to adjust the URL you are using to access the Manager
application. However, there is always a chance you have found a bug
in the
Manager application. If you are sure you have found a bug, and that
the bug
has not already been reported, please report it to the Apache
Tomcat team.
</p>
---------------------------------------------------------
Unpack new download from tomcat.apache.org
1- set users
<tomcat-users>
<user username="edoardo" password="pwd"
roles="manager-script,manager-gui,manager-jmx,other"/>
</tomcat-users>
then reload tomcat
$curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/examples
OK - Reloaded application at context path /examples
2- copy myApplication from production server
copy configuration file ($tomcat/Catalina/localhost/myApplication.xml)
from production server
stop & start tomcat
$curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/myApplication
OK - Reloaded application at context path /myApplication
3- first modify to server.xml
shutdown tomcat
modify server.xml
<Connector port="8080" protocol="HTTP/1.1"
becomes
<Connector port="9080" protocol="HTTP/1.1"
start then curl again
all well
4- second modify to server.xml
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
becomes
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true" deployXML="false">
stop-start
$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
javax.servlet.ServletException: Error instantiating servlet class
org.apache.catalina.manager.ManagerServlet
[...]
$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
the same error reported in the initial post (above)
deployXML="false" is recommended at
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html and useful for me.
(catalina_base)/webapps/myApplication/META-INF/context.xml
is no longer being parsed,
$tomcat/Catalina/localhost/myApplication.xml
when you reload your app.
yes, I know, is there for this reason, but also at the first start of
the application $tomcat/Catalina/localhost/myApplication.xml is used and
no error occurs.
Post by André Warnier
What is the content of that file ?
<!DOCTYPE Context>
<Context path="/myApplication" debug="100" reloadable="false">
<Resource name="jdbc/myApplication" auth="Container"
type="javax.sql.DataSource"
maxActive="8" maxIdle="5" minIdle="3" maxWait="30"
username="uname" password="pwd"
driverClassName="org.postgresql.Driver"
url="jdbc:postgresql://127.0.0.1:5432/myApplication"
removeAbandoned="true"
removeAbandonedTimeout="30"
logAbandoned="true" />

<Parameter name="javax.servlet.jsp.jstl.sql.dataSource"

value="jdbc:postgresql://localhost:5432/myApplication,org.postgresql.Driver,user,pwd"

override="false"/>
<Parameter name="email.uname" value="euser" override="false"/>
<Parameter name="email.pwd" value="epwd" override="false"/>
<Parameter name="logFolder" value="/var/log/myApplication"
override="false"/>
<Parameter name="blobsFolder"
value="/var/lib/myApplication/blobs" override="false"/>
<Parameter name="thumbnailsFolder"
value="/var/lib/myApplication/thumbnails"
override="false"/>
<Parameter name="usersPhotoFolder"
value="/var/lib/myApplication/utenti" override="false"/>
<Parameter name="tomcat.porta" value="9080" override="false"/>
</Context>

thank you
Edoardo
Ognjen Blagojevic
2013-10-19 14:44:17 UTC
Permalink
Edoardo,
Post by Edoardo Panfili
4- second modify to server.xml
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
becomes
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true" deployXML="false">
It is great that you took effort to pin-point the source of the problem.
Often users are not willing to do that.

Now, deployXML=false instructs Tomcat to ignore context descriptors in
directory webapps/, and to consider only those in directory conf/. That
means that context descriptor webapps/manager/META-INF/context.xml is
ignored, so manager application is not properly intialized.

If you want to keep parameter deployXML set to false, I believe you need
to copy webapps/manager/META-INF/context.xml to
conf/Catalina/localhost/manager.xml.

-Ognjen
Mark Eggers
2013-10-19 15:51:43 UTC
Permalink
Post by Ognjen Blagojevic
Edoardo,
Post by Edoardo Panfili
4- second modify to server.xml
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
becomes
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true" deployXML="false">
It is great that you took effort to pin-point the source of the problem.
Often users are not willing to do that.
Now, deployXML=false instructs Tomcat to ignore context descriptors in
directory webapps/, and to consider only those in directory conf/. That
means that context descriptor webapps/manager/META-INF/context.xml is
ignored, so manager application is not properly intialized.
If you want to keep parameter deployXML set to false, I believe you need
to copy webapps/manager/META-INF/context.xml to
conf/Catalina/localhost/manager.xml.
-Ognjen
Yep, reproducible on Windows 7.

Environment: Windows 7 Home Premium 64 bit
JRE 1.7.0_45 64 bit
Tomcat 7.0.42 (stock, edited tomcat-users.xml)
cygwin / curl

curl -u user:pass http://127.0.0.1:8080/manager/text/reload?
path=examples

1. As is - works as expected
This is good, since that's how NetBeans controls Tomcat

2. set deployXML="false" in host node
reload examples fails (stack trace)
probe also fails to run since it needs privileged="true"

3. copy context.xml to %CATALINA_BASE%\conf\Catalina\localhost
manager context.xml --> manager.xml
probe context.xml --> probe.xml

4. restart Tomcat
reloads work as expected
probe works as expected

/mde/
Ognjen Blagojevic
2013-10-19 16:54:35 UTC
Permalink
Mark,
Post by Mark Eggers
Post by Ognjen Blagojevic
If you want to keep parameter deployXML set to false, I believe you need
to copy webapps/manager/META-INF/context.xml to
conf/Catalina/localhost/manager.xml.
Yep, reproducible on Windows 7.
Thanks for verifying.

-Ognjen
André Warnier
2013-10-19 17:53:23 UTC
Permalink
Post by Ognjen Blagojevic
Mark,
Post by Mark Eggers
Post by Ognjen Blagojevic
If you want to keep parameter deployXML set to false, I believe you need
to copy webapps/manager/META-INF/context.xml to
conf/Catalina/localhost/manager.xml.
Yep, reproducible on Windows 7.
Thanks for verifying.
I think that Edoardo and I were being "blinded" by the MyApplication context.xml, and did
not click that the Manager too must have his context moved to conf/Catalina/localhost/
when deployXML="false".
Edoardo Panfili
2013-10-19 21:49:59 UTC
Permalink
Post by André Warnier
Post by Ognjen Blagojevic
Mark,
Post by Mark Eggers
Post by Ognjen Blagojevic
If you want to keep parameter deployXML set to false, I believe you need
to copy webapps/manager/META-INF/context.xml to
conf/Catalina/localhost/manager.xml.
Yep, reproducible on Windows 7.
Thanks for verifying.
I think that Edoardo and I were being "blinded" by the MyApplication
context.xml, and did not click that the Manager too must have his
context moved to conf/Catalina/localhost/ when deployXML="false".
I (unfortunately) never thought to move context.xml files for default
applications.

thank you again to all!
Edoardo
Edoardo Panfili
2013-10-19 21:45:25 UTC
Permalink
Post by Ognjen Blagojevic
Edoardo,
Post by Edoardo Panfili
4- second modify to server.xml
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
becomes
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true" deployXML="false">
It is great that you took effort to pin-point the source of the problem.
Often users are not willing to do that.
thanks to so many people ready to help!
Post by Ognjen Blagojevic
Now, deployXML=false instructs Tomcat to ignore context descriptors in
directory webapps/, and to consider only those in directory conf/. That
means that context descriptor webapps/manager/META-INF/context.xml is
ignored, so manager application is not properly intialized.
_sorry_ must read carefully documentation! as usual!

"deployXML: Set to false if you want to disable parsing the context XML
descriptor embedded inside the application (located at
/META-INF/context.xml)."


I thought that in any case if application.xml was not present in
conf/Catalina/localhost Tomcat would read that in applicatin/META-INF
I was wrong.
Post by Ognjen Blagojevic
If you want to keep parameter deployXML set to false, I believe you need
to copy webapps/manager/META-INF/context.xml to
conf/Catalina/localhost/manager.xml.
Great! right (and sounds also logic now)

it works in the virtual machine and also in production server.

thank you again to all
Edoardo
Christopher Schultz
2013-10-20 18:44:50 UTC
Permalink
Edoardo,
Post by Edoardo Panfili
Post by Edoardo Panfili
My Tomcat (7.0.42) is listening on port 7080 and I have this
conf/tomcat-users.xml in (production server)
------- <tomcat-users> <role rolename="manager-script"/> <user
username="myname" password="pwd"
roles="manager-script,manager-gui,manager-jmx"/> </tomcat-users>
---------- if I use
curl -u myname:pwd
http://localhost:7080/manager/text/reload?path=/myApplication
the response is-------------------------- <h1>404 Not found</h1>
<p> The page you tried to access (/manager/text/reload) does not
exist. </p> <p> The Manager application has been re-structured
for Tomcat 7 onwards and some of URLs have changed. All URLs used
to access the Manager application should now start with one of
the following options: </p> <ul> <li>/manager/html for the HTML
GUI</li> <li>/manager/text for the text interface</li>
<li>/manager/jmxproxy for the JMX proxy</li> <li>/manager/status
for the status pages</li> </ul> <p> Note that the URL for the
text interface has changed from &quot;/manager&quot; to
&quot;/manager/text&quot;. </p> <p> You probably need to adjust
the URL you are using to access the Manager application. However,
there is always a chance you have found a bug in the Manager
application. If you are sure you have found a bug, and that the
bug has not already been reported, please report it to the
Apache Tomcat team. </p>
---------------------------------------------------------
Unpack new download from tomcat.apache.org
1- set users <tomcat-users> <user username="edoardo"
password="pwd"
roles="manager-script,manager-gui,manager-jmx,other"/>
</tomcat-users>
then reload tomcat $curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/examples OK -
Reloaded application at context path /examples
2- copy myApplication from production server copy configuration
file ($tomcat/Catalina/localhost/myApplication.xml) from production
server stop & start tomcat
$curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/myApplication OK -
Reloaded application at context path /myApplication
3- first modify to server.xml shutdown tomcat modify server.xml
<Connector port="8080" protocol="HTTP/1.1" becomes <Connector
port="9080" protocol="HTTP/1.1"
start then curl again all well
4- second modify to server.xml <Host name="localhost"
appBase="webapps" unpackWARs="true" autoDeploy="true"> becomes
<Host name="localhost" appBase="webapps" unpackWARs="true"
autoDeploy="true" deployXML="false">
stop-start
$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
javax.servlet.ServletException: Error instantiating servlet class
org.apache.catalina.manager.ManagerServlet [...]
$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication the
same error reported in the initial post (above)
deployXML="false" is recommended at
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html and useful for me.
I'll bet the problem is that Tomcat doesn't like applications
declaring themselves to be privileged="true". The first time Tomcat is
started, META-INF/context.xml from the Manager is copied into
conf/Catalina/localhost/manager.xml where the privileged="true" is
preserved. With deployXML="false", this file is not copied and so
META-INF/context.xml is used instead. Tomcat maybe doesn't allow
META-INF/context.xml to contain privileged="true".

(Of course, Tomcat seems perfectly happy to copy META-INF/context.xml
into conf/Catalina/localhost/manager.xml and *then* permit
privileged="true" so my premise is a bit shaky).

- -chris
Christopher Schultz
2013-10-20 18:46:27 UTC
Permalink
All,
Post by Ognjen Blagojevic
Edoardo,
Post by Edoardo Panfili
Post by Edoardo Panfili
My Tomcat (7.0.42) is listening on port 7080 and I have this
conf/tomcat-users.xml in (production server)
------- <tomcat-users> <role rolename="manager-script"/> <user
username="myname" password="pwd"
roles="manager-script,manager-gui,manager-jmx"/>
</tomcat-users> ---------- if I use
curl -u myname:pwd
http://localhost:7080/manager/text/reload?path=/myApplication
the response is-------------------------- <h1>404 Not
found</h1> <p> The page you tried to access
(/manager/text/reload) does not exist. </p> <p> The Manager
application has been re-structured for Tomcat 7 onwards and
some of URLs have changed. All URLs used to access the Manager
</p> <ul> <li>/manager/html for the HTML GUI</li>
<li>/manager/text for the text interface</li>
<li>/manager/jmxproxy for the JMX proxy</li>
<li>/manager/status for the status pages</li> </ul> <p> Note
that the URL for the text interface has changed from
&quot;/manager&quot; to &quot;/manager/text&quot;. </p> <p> You
probably need to adjust the URL you are using to access the
Manager application. However, there is always a chance you have
found a bug in the Manager application. If you are sure you
have found a bug, and that the bug has not already been
reported, please report it to the Apache Tomcat team. </p>
---------------------------------------------------------
Unpack new download from tomcat.apache.org
1- set users <tomcat-users> <user username="edoardo"
password="pwd"
roles="manager-script,manager-gui,manager-jmx,other"/>
</tomcat-users>
then reload tomcat $curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/examples OK -
Reloaded application at context path /examples
2- copy myApplication from production server copy configuration
file ($tomcat/Catalina/localhost/myApplication.xml) from
production server stop & start tomcat
$curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/myApplication OK
- Reloaded application at context path /myApplication
3- first modify to server.xml shutdown tomcat modify server.xml
<Connector port="8080" protocol="HTTP/1.1" becomes <Connector
port="9080" protocol="HTTP/1.1"
start then curl again all well
4- second modify to server.xml <Host name="localhost"
appBase="webapps" unpackWARs="true" autoDeploy="true"> becomes
<Host name="localhost" appBase="webapps" unpackWARs="true"
autoDeploy="true" deployXML="false">
stop-start
$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
javax.servlet.ServletException: Error instantiating servlet class
org.apache.catalina.manager.ManagerServlet [...]
$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
the same error reported in the initial post (above)
deployXML="false" is recommended at
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html and
useful for me.
I'll bet the problem is that Tomcat doesn't like applications
declaring themselves to be privileged="true". The first time Tomcat
is started, META-INF/context.xml from the Manager is copied into
conf/Catalina/localhost/manager.xml where the privileged="true" is
preserved. With deployXML="false", this file is not copied and so
META-INF/context.xml is used instead. Tomcat maybe doesn't allow
META-INF/context.xml to contain privileged="true".
(Of course, Tomcat seems perfectly happy to copy
META-INF/context.xml into conf/Catalina/localhost/manager.xml and
*then* permit privileged="true" so my premise is a bit shaky).
Duh. I had this entirely backwards. Please ignore the noise.

- -chris
Konstantin Kolinko
2013-10-20 19:09:10 UTC
Permalink
Post by Ognjen Blagojevic
Edoardo,
I'll bet the problem is that Tomcat doesn't like applications
declaring themselves to be privileged="true". The first time Tomcat is
started, META-INF/context.xml from the Manager is copied into
conf/Catalina/localhost/manager.xml where the privileged="true" is
preserved. With deployXML="false", this file is not copied and so
META-INF/context.xml is used instead. Tomcat maybe doesn't allow
META-INF/context.xml to contain privileged="true".
(Of course, Tomcat seems perfectly happy to copy META-INF/context.xml
into conf/Catalina/localhost/manager.xml and *then* permit
privileged="true" so my premise is a bit shaky).
Copying is controlled by "copyXML" attribute.

The meaning of deployXML="false" is that Tomcat ignores
META-INF/context.xml files bundled with web applications and honors
only those there were explicitly (manually) configured by
Administrator in the conf directory of the server.

(Thus you have better control over deployed applications, but with
more work to configure them.)

deployXML="false" and running with SecurityManager are usually used together.

If you omit the latter, a rogue web application can reconfigure Tomcat
via reflection.

If you omit the former, an application can be configured via
context.xml so that it bypasses some crucial security restrictions.


Best regards,
Konstantin Kolinko

Loading...