Il 18/10/13 21:13, André Warnier ha scritto:
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").
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.
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.
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!
So take your time, but do it nicely step by step,
this is what I want to do.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
