Edoardo Panfili wrote:
Il 18/10/13 19:17, André Warnier ha scritto:
Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
André,
On 10/18/13 12:48 PM, André Warnier wrote:
Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Edoardo,
On 10/18/13 12:38 PM, Edoardo Panfili wrote:
Il 18/10/13 18:29, Martin Gainty ha scritto:
Date: Fri, 18 Oct 2013 18:04:19 +0200 From:
edoa...@aspix.it To: users@tomcat.apache.org Subject: Re:
can't connect to manager application
Il 18/10/13 16:40, André Warnier ha scritto:
Edoardo Panfili wrote:
Il 18/10/13 08:43, Ognjen Blagojevic ha scritto:
On 18.10.2013 7:34, Edoardo Panfili wrote:
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
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?
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>
the same for me.
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.
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!).
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
