Re: Question about Tomcat Rest Verbs initial settings allowed
On 09/08/2014 13:31, Christopher Schultz wrote: Rob, On 8/8/14, 7:50 PM, Rob Silver wrote: Is it true that by default on a Apache Tomcat 7.025 server RESTFUL verbs are enabled as part of the HTTP protocol Tomcat uses? Tomcat does not filter HTTP verbs other than TRACE out of the box. If you implement HttpServlet.service() then you can accept any verb you want. Anotherwards if I hade a restful web application - perhaps a spring mvc one would it work out of the box as far as security constraints go? Security constraints and HTTP verbs are not really related. Huh? Security constraints allow you to define the HTTP verbs they apply to. Note: It is generally a bad idea to do this (because of HTTP verb tampering) unless you are very careful and understand exactly what you are doing. Mark I have not yet seen any way to control a Tomcat server not to accept DELETE, PUT etc.. in addition to standard GET / POST http verbs. What have you tried? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to access tomcat manger user interface?
On 10/08/2014 03:52, Mohit Gupta wrote: i am using spring tcserver-2.9.5 (tomcat) as webserver. Pivotal tc Server != Apache Tomcat. tc Server is based on Tomcat and 99.9% of the code is the same. However, the configuration is very different: - tc Server uses separate CATALINA_HOME and CATALINA_BASE by default - tc Server uses different default settings in most (all? I'd need to check) of the configuration files - tc Server uses a different set of default web applications. I want to access tomcat manager UI. I tried to access it by http://local:8080/manager/html but i get blank page. I have done below entry under tomcat-users.xml user username=myadmin password=adminPassword roles=manager/ Any help what i am missing here? Is 8080 is not right port for admin. Because of the common code base, there are some tc Server support questions the members of this mailing list can answer. This might not be one of them. You will probably getting faster help if you contact Pivotal support. A few questions come to mind: 1. What version of Apache Tomcat is your instance using? 2. What is the full path to the Tomcat version your instance is using? 3. What is the full path to your instance? 4. Have you deployed the manager application? If so, where to (full path please)? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 7 to 8 Upgrade - Performance Degradation
On 8 August 2014 21:52:58 BST, Peter Rifel pri...@mixpo.com wrote: Yes I can build from svn to test changes. Great. Do you want me to file a BZ case? On one hand it isn't necessary since I'll fix any issues I find whether there is a bz entry or not. On the other hand it might help folks with a similar issue so if you don't mind... Thanks for looking into this, Not problem. Thanks for presenting this clearly with a simple test. It makes debugging much easier. Cheers, Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question about Tomcat Rest Verbs initial settings allowed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 8/10/14, 4:44 AM, Mark Thomas wrote: On 09/08/2014 13:31, Christopher Schultz wrote: Rob, On 8/8/14, 7:50 PM, Rob Silver wrote: Is it true that by default on a Apache Tomcat 7.025 server RESTFUL verbs are enabled as part of the HTTP protocol Tomcat uses? Tomcat does not filter HTTP verbs other than TRACE out of the box. If you implement HttpServlet.service() then you can accept any verb you want. Anotherwards if I hade a restful web application - perhaps a spring mvc one would it work out of the box as far as security constraints go? Security constraints and HTTP verbs are not really related. Huh? Security constraints allow you to define the HTTP verbs they apply to. The OP was asking about built-in Tomcat restrictions against any of this stuff. While security constraints can be applied to certain HTTP verbs, one has to do that kind of thing oneself, I would therefore expect that the OP would be aware of any self-imposed constraints. Note: It is generally a bad idea to do this (because of HTTP verb tampering) unless you are very careful and understand exactly what you are doing. +1 Apache httpd's LimitExcept is a great feature. It's too bad web.xml is not quite so explicit about that kind of thing. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJT51tIAAoJEBzwKT+lPKRY+mEP/05oXA80tUaaOL3bELheHQ1k QUy3czP8rsd2HVWi7T738ssBwu0W7zCt2xzXM+eIDRmi537FijfyCwEQTM+TZAC/ +MepJ6Mi7jTyI0sDo28xXfe9VN2aZaxqOdQmGX9zrJ+Wp1041KTFIxHohpXUdq1d vrXrX9I1IPCIPyoKtGPChJXbXh6No+XPzfCRLho/Q3YIkZoPK3yqkx0ZPAsBfWww o0Sb0bkd78uSwgXuuOod/hdatOXxF/BDR6DPoSSIRuQ+mvqdioFDA1vMYc16G73P Hd8DgwkYVCFndLpX8FsUHBA+uakIn9EmvuZS1ud4cM1aJoqi/hh/QQJO7Al8CzR2 CVeYlaV9cpI1SPheNCbDWK57ayrzpKriE/oaoJLbhSVtvT4iY/G5uIUHazSWl7Q1 0odEhKFSW/pR1HmO6aDsbYmZvede9i9hQBFgZSOhyaeWmvAXb8sp3S03ctiZAl5i NF+w6bq0KO7oMhqYlAfGQEffvHyH1+CRD+PRt4UK24m1UtnNLQqVg7lYh9tXnq9z I5KwVPmAamhH6WoLP28itOsN0ZasPFfHoWtDxV/Ws78z6kV0kVtd4ZOgbYquSpD+ lMHwJVpRqZxiqZDkBImrmFs6QztFBvZg3Swxp5grwdVFJLEutK09EDhDdPtWLEir 4kJWtpYx+1fg8kTg4Nwa =VQGe -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AJP connector is blocking JSON responses
Hi, I'm adding HTTPS access to my Java site. For that, I have chosen to leave the management of HTTPS to an Apache server. The Apache server is connecting to tomcat through mod_jk and AJP 1.3. I'm logging all my Tomcat request/responses, and I'm facing the following problem: - If I access my URL through the standard Tomcat connector on port 8080, I have a correct response (JSON) - If I access my URL through Apache HTTPS, I have an empty response(no JSON) From the Tomcat logs below, the last parameter is the number of bytes returned, and you can see that they are different. 41.227.87.197:443 - - [10/Aug/2014:15:24:32 +0200] 1688 GET /url?format=json HTTP/1.1 200 33 41.227.87.197:8080 - - [10/Aug/2014:15:24:46 +0200] 734 GET /url?format=json HTTP/1.1 200 44 Another test I have done is to use an XML response instead of JSON response, and I can't see any more the problem. Any idea what could it be ? Thanks !
Re: AJP connector is blocking JSON responses
Am 10.08.2014 um 15:41 schrieb Omar Belkhodja: Hi, I'm adding HTTPS access to my Java site. For that, I have chosen to leave the management of HTTPS to an Apache server. The Apache server is connecting to tomcat through mod_jk and AJP 1.3. I'm logging all my Tomcat request/responses, and I'm facing the following problem: - If I access my URL through the standard Tomcat connector on port 8080, I have a correct response (JSON) - If I access my URL through Apache HTTPS, I have an empty response(no JSON) From the Tomcat logs below, the last parameter is the number of bytes returned, and you can see that they are different. 41.227.87.197:443 - - [10/Aug/2014:15:24:32 +0200] 1688 GET /url?format=json HTTP/1.1 200 33 41.227.87.197:8080 - - [10/Aug/2014:15:24:46 +0200] 734 GET /url?format=json HTTP/1.1 200 44 Another test I have done is to use an XML response instead of JSON response, and I can't see any more the problem. Any idea what could it be ? Can you set JkLogLevel trace for mod_jk and post the complete log output for a single request? We can then check the headers etc. For a first try we don't need the startup messages, only the log lines related to receiving and forwarding the request and reponse. Are there any other Apache directives active that might change the URI or headers? RewriteRules etc.? Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP connector is blocking JSON responses
Thanks for your answer Rainer. Please find attached the logs you requested. Its is really strange, because it seems from the logs that jk_mod received the answer... Regards, Omar 2014-08-10 14:56 GMT+01:00 Rainer Jung rainer.j...@kippdata.de: Am 10.08.2014 um 15:41 schrieb Omar Belkhodja: Hi, I'm adding HTTPS access to my Java site. For that, I have chosen to leave the management of HTTPS to an Apache server. The Apache server is connecting to tomcat through mod_jk and AJP 1.3. I'm logging all my Tomcat request/responses, and I'm facing the following problem: - If I access my URL through the standard Tomcat connector on port 8080, I have a correct response (JSON) - If I access my URL through Apache HTTPS, I have an empty response(no JSON) From the Tomcat logs below, the last parameter is the number of bytes returned, and you can see that they are different. 41.227.87.197:443 - - [10/Aug/2014:15:24:32 +0200] 1688 GET /url?format=json HTTP/1.1 200 33 41.227.87.197:8080 - - [10/Aug/2014:15:24:46 +0200] 734 GET /url?format=json HTTP/1.1 200 44 Another test I have done is to use an XML response instead of JSON response, and I can't see any more the problem. Any idea what could it be ? Can you set JkLogLevel trace for mod_jk and post the complete log output for a single request? We can then check the headers etc. For a first try we don't need the startup messages, only the log lines related to receiving and forwarding the request and reponse. Are there any other Apache directives active that might change the URI or headers? RewriteRules etc.? Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP connector is blocking JSON responses
Sorry, I forgot to answer to the second part of your e-mail. Regarding Apache directives, I didn't add any specific directives. But, I'm not the one that have configured all the server, so I'm not sure at 100%. Regards, Omar 2014-08-10 14:56 GMT+01:00 Rainer Jung rainer.j...@kippdata.de: Am 10.08.2014 um 15:41 schrieb Omar Belkhodja: Hi, I'm adding HTTPS access to my Java site. For that, I have chosen to leave the management of HTTPS to an Apache server. The Apache server is connecting to tomcat through mod_jk and AJP 1.3. I'm logging all my Tomcat request/responses, and I'm facing the following problem: - If I access my URL through the standard Tomcat connector on port 8080, I have a correct response (JSON) - If I access my URL through Apache HTTPS, I have an empty response(no JSON) From the Tomcat logs below, the last parameter is the number of bytes returned, and you can see that they are different. 41.227.87.197:443 - - [10/Aug/2014:15:24:32 +0200] 1688 GET /url?format=json HTTP/1.1 200 33 41.227.87.197:8080 - - [10/Aug/2014:15:24:46 +0200] 734 GET /url?format=json HTTP/1.1 200 44 Another test I have done is to use an XML response instead of JSON response, and I can't see any more the problem. Any idea what could it be ? Can you set JkLogLevel trace for mod_jk and post the complete log output for a single request? We can then check the headers etc. For a first try we don't need the startup messages, only the log lines related to receiving and forwarding the request and reponse. Are there any other Apache directives active that might change the URI or headers? RewriteRules etc.? Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP connector is blocking JSON responses
I have compared JSON logs (NOK) with XML logs (OK). The main differences are here: JSON = ajp_unmarshal_response::jk_ajp_common.c (688): Number of headers is = 6 ajp_unmarshal_response::jk_ajp_common.c (744): Header[0] [Pragma] = [no-cache] ajp_unmarshal_response::jk_ajp_common.c (744): Header[1] [Cache-Control] = [no-cache, no-store, max-age=0] ajp_unmarshal_response::jk_ajp_common.c (744): Header[2] [Expires] = [Thu, 01 Jan 1970 00:00:00 GMT] ajp_unmarshal_response::jk_ajp_common.c (744): Header[3] [Content-Type] = [application/json;charset=UTF-8] ajp_unmarshal_response::jk_ajp_common.c (744): Header[4] [Content-Language] = [en-US] ajp_unmarshal_response::jk_ajp_common.c (744): Header[5] [Content-Length] = [0] XML = ajp_unmarshal_response::jk_ajp_common.c (688): Number of headers is = 3 ajp_unmarshal_response::jk_ajp_common.c (744): Header[0] [Content-Type] = [application/xml;charset=UTF-8] ajp_unmarshal_response::jk_ajp_common.c (744): Header[1] [Content-Language] = [en-US] ajp_unmarshal_response::jk_ajp_common.c (744): Header[2] [Content-Length] = [123] The content-length parameter shows a 0 length.I don't know if these headers are added by some framework, or if they are added by the AJP connector, based on the content. Do you know the answer ? Best regards, Omar 2014-08-10 15:30 GMT+01:00 Omar Belkhodja omar.belkho...@gmail.com: Sorry, I forgot to answer to the second part of your e-mail. Regarding Apache directives, I didn't add any specific directives. But, I'm not the one that have configured all the server, so I'm not sure at 100%. Regards, Omar 2014-08-10 14:56 GMT+01:00 Rainer Jung rainer.j...@kippdata.de: Am 10.08.2014 um 15:41 schrieb Omar Belkhodja: Hi, I'm adding HTTPS access to my Java site. For that, I have chosen to leave the management of HTTPS to an Apache server. The Apache server is connecting to tomcat through mod_jk and AJP 1.3. I'm logging all my Tomcat request/responses, and I'm facing the following problem: - If I access my URL through the standard Tomcat connector on port 8080, I have a correct response (JSON) - If I access my URL through Apache HTTPS, I have an empty response(no JSON) From the Tomcat logs below, the last parameter is the number of bytes returned, and you can see that they are different. 41.227.87.197:443 - - [10/Aug/2014:15:24:32 +0200] 1688 GET /url?format=json HTTP/1.1 200 33 41.227.87.197:8080 - - [10/Aug/2014:15:24:46 +0200] 734 GET /url?format=json HTTP/1.1 200 44 Another test I have done is to use an XML response instead of JSON response, and I can't see any more the problem. Any idea what could it be ? Can you set JkLogLevel trace for mod_jk and post the complete log output for a single request? We can then check the headers etc. For a first try we don't need the startup messages, only the log lines related to receiving and forwarding the request and reponse. Are there any other Apache directives active that might change the URI or headers? RewriteRules etc.? Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP connector is blocking JSON responses
Finally, I almost understood the problem. The framework was generating a response without a Content-Length header. The AJP connector seems to be adding it as a Content-Length=0, although if there are data. So, currenly I have forced the framework to add the Content-Length header. In fact, it is spring and I added property name=updateContentLength value =true/ In the following configuration bean class= org.springframework.web.servlet.view.json.MappingJackson2JsonView property name=objectMapper ref=jaxbJacksonObjectMapper/ property name=updateContentLength value=true/ /bean Thank you for having helped in locating where is the problem. For me, I have a workaround, but probably there is an issue on AJP (why adding the header with zero length ???) Regards, Omar 2014-08-10 15:50 GMT+01:00 Omar Belkhodja omar.belkho...@gmail.com: I have compared JSON logs (NOK) with XML logs (OK). The main differences are here: JSON = ajp_unmarshal_response::jk_ajp_common.c (688): Number of headers is = 6 ajp_unmarshal_response::jk_ajp_common.c (744): Header[0] [Pragma] = [no-cache] ajp_unmarshal_response::jk_ajp_common.c (744): Header[1] [Cache-Control] = [no-cache, no-store, max-age=0] ajp_unmarshal_response::jk_ajp_common.c (744): Header[2] [Expires] = [Thu, 01 Jan 1970 00:00:00 GMT] ajp_unmarshal_response::jk_ajp_common.c (744): Header[3] [Content-Type] = [application/json;charset=UTF-8] ajp_unmarshal_response::jk_ajp_common.c (744): Header[4] [Content-Language] = [en-US] ajp_unmarshal_response::jk_ajp_common.c (744): Header[5] [Content-Length] = [0] XML = ajp_unmarshal_response::jk_ajp_common.c (688): Number of headers is = 3 ajp_unmarshal_response::jk_ajp_common.c (744): Header[0] [Content-Type] = [application/xml;charset=UTF-8] ajp_unmarshal_response::jk_ajp_common.c (744): Header[1] [Content-Language] = [en-US] ajp_unmarshal_response::jk_ajp_common.c (744): Header[2] [Content-Length] = [123] The content-length parameter shows a 0 length.I don't know if these headers are added by some framework, or if they are added by the AJP connector, based on the content. Do you know the answer ? Best regards, Omar 2014-08-10 15:30 GMT+01:00 Omar Belkhodja omar.belkho...@gmail.com: Sorry, I forgot to answer to the second part of your e-mail. Regarding Apache directives, I didn't add any specific directives. But, I'm not the one that have configured all the server, so I'm not sure at 100%. Regards, Omar 2014-08-10 14:56 GMT+01:00 Rainer Jung rainer.j...@kippdata.de: Am 10.08.2014 um 15:41 schrieb Omar Belkhodja: Hi, I'm adding HTTPS access to my Java site. For that, I have chosen to leave the management of HTTPS to an Apache server. The Apache server is connecting to tomcat through mod_jk and AJP 1.3. I'm logging all my Tomcat request/responses, and I'm facing the following problem: - If I access my URL through the standard Tomcat connector on port 8080, I have a correct response (JSON) - If I access my URL through Apache HTTPS, I have an empty response(no JSON) From the Tomcat logs below, the last parameter is the number of bytes returned, and you can see that they are different. 41.227.87.197:443 - - [10/Aug/2014:15:24:32 +0200] 1688 GET /url?format=json HTTP/1.1 200 33 41.227.87.197:8080 - - [10/Aug/2014:15:24:46 +0200] 734 GET /url?format=json HTTP/1.1 200 44 Another test I have done is to use an XML response instead of JSON response, and I can't see any more the problem. Any idea what could it be ? Can you set JkLogLevel trace for mod_jk and post the complete log output for a single request? We can then check the headers etc. For a first try we don't need the startup messages, only the log lines related to receiving and forwarding the request and reponse. Are there any other Apache directives active that might change the URI or headers? RewriteRules etc.? Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: configuring tomcat 7, modify juli default configuration, doesn't work as expected
2014-08-08 23:18 GMT+04:00 Didier Wiroth dwir...@gmail.com:
Hi,
(using tomcat x64 7.0.55 java jvm 1.7.0_67-b01 on windows 8.1 x64)
I'm a tomcat amateur trying to setup tomcat with different service
containers and multihosting etc.
I would like to modify the default logging.properties to log the
appropriate files, but I doesn't work.
Here are the 2 service containers (serv1 serv2) of my server.xml:
Service name=serv1
Connector port=8080 protocol=HTTP/1.1
connectionTimeout=2
redirectPort=8443 /
Engine name=Catalina defaultHost=serv1 jvmRoute=jvm1
1. The usual convention is to use the same name in Service and Engine.
I mean you would better use Engine name=serv1 and in the same way
for the second Service/Engine pair.
Realm className=org.apache.
catalina.realm.LockOutRealm
Realm className=org.apache.catalina.realm.UserDatabaseRealm
resourceName=UserDatabase/
/Realm
Host name=serv1 appBase=webapps unpackWARs=true
autoDeploy=true
Valve className=org.apache.catalina.valves.AccessLogValve
directory=logs prefix=serv1_access. suffix=.log pattern=%h %l
%u %t quot;%rquot; %s %b /
/Host
/Engine
/Service
Service name=serv2
Connector port=8081 protocol=HTTP/1.1
connectionTimeout=2
redirectPort=8444 /
Engine name=Catalina defaultHost=serv2 jvmRoute=jvm2
Realm className=org.apache.catalina.realm.LockOutRealm
Realm className=org.apache.catalina.realm.UserDatabaseRealm
resourceName=UserDatabase/
/Realm
Host name=serv2 appBase=webapps.serv2 unpackWARs=true
autoDeploy=true
Valve className=org.apache.catalina.valves.AccessLogValve
directory=logs prefix=serv2_access. suffix=.log pattern=%h %l
%u %t quot;%rquot; %s %b /
/Host
/Engine
/Service
I kept all the original entries conf/logging.properties
I only added the following conf/logging properies.
a) added filehandlers (5serv1 6serv2)
handlers = 1catalina.org.apache.juli.FileHandler,
2localhost.org.apache.juli.FileHandler,
3manager.org.apache.juli.FileHandler,
4host-manager.org.apache.juli.FileHandler,
5serv1.org.apache.juli.FileHandler,
6serv2.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
.handlers = 1catalina.org.apache.juli.FileHandler,
java.util.logging.ConsoleHandler
b) Here are the handler properties:
5serv1.org.apache.juli.FileHandler.level = FINE
5serv1.apache.juli.FileHandler.directory = ${catalina.base}/logs
2. The above property name is mistyped. It misses org. before apache.
Effectively it is ignored. The default value of that property of
FileHandler is logs in the current working directory of the program.
3. I hope that all the properties (such as handlers property above)
are actually written in one line, and the above wrapping is performed
by e-mail editor.
I do not see any other apparent issues with your configuration.
4. Do you have any web applications deployed?
Best regards,
Konstantin Kolinko
5serv1.org.apache.juli.FileHandler.prefix = serv1.catalina.
6serv2.org.apache.juli.FileHandler.level = FINE
6serv2.apache.juli.FileHandler.directory = ${catalina.base}/logs
6serv2.org.apache.juli.FileHandler.prefix = serv2.catalina.
c) Here Facility specific properties:
org.apache.catalina.core.ContainerBase.[Catalina].[serv1].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].[serv1].handlers =
5serv1.org.apache.juli.FileHandler
org.apache.catalina.core.ContainerBase.[Catalina].[serv2].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].[serv2].handlers =
6serv2.org.apache.juli.FileHandler
Unfortunately the 5serv1.catalina.x 6serv2.catalina.y files are not
created, nothing is logged in these filehandlers.
Everything is still logged in the default filehandler:
1catalina.org.apache.juli.FileHandler
Why?
What am I doing wrong?
If you want, I can mail you my server.xml logging.properties.
Thank you very much!
--
Didier Wiroth
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Configuring a 'JarScanner' excluding classpath scanning, the 'VirtualWebappLoader' doesn't get scanned
2014-08-08 15:35 GMT+04:00 Luc useyour.m...@gmail.com: Hello, After a Tomcat 6.0.36 to 7.0.54 migration, I added to my global 'context.xml' the configuration: JarScanner scanClassPath=false / Which excluded (as I readed in the docs, http://tomcat.apache.org/tomcat-7.0-doc/config/jar-scanner.html#Standard_Implementation) the scaning of system classpath, and shared and common classloader, but not the webapp classloader (WEB-INF/lib). It worked, and was what I was looking for. Yesterday I discovered the 'VirtualWebappLoader' feature, which fit my needs: add .jar's to webapp classloading, and not to other classloader / classpath, but outside the WEB-INF/lib folder. Those .jar files contains some resources (facelets '.xhtml') which I though that ServletContext should find them, as they where found when the .jar's are located at WEB-INF/lib. But they are note being found when using ServletContext.getResource() method. Is this the expected behaviour? Yes, this is expected. I mean, 'JarScanner' docs says that webapp classloading will be scanned anyway. VirtualWebappLoader only adds the jars into Webapp's classpath They are not citizens of WEB-INF/lib. You have disabled classpath scanning so this is as expected And in the other hand the loader docs ( http://tomcat.apache.org/tomcat-7.0-doc/config/loader.html) says that resources loaded are considered as a webapp resources. But they are not being scanned. No, it does not say that. It says Java classes and resources. It does not say webapp resources. It is ClassLoader.getResource(). It is not ServletContext.getResource(). I'm using Tomcat 7.0.54, Java 6, on a Windows machine. I have an example webapp (deployable with Eclipse) which reproduces this issue, which I can upload later. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: ErrorReportValve(showReport,showServerInfo) at Engine-level working in 7.0.54, not anymore in 7.0.55
2014-08-08 13:54 GMT+04:00 Willem Fibbe - Realworks BV wil...@realworks.nl: Hi, When we upgraded our Tomcat-servers to 7.0.54, we used the new attributes of ErrorReportValve at the Engine-level. Our server.xml looked like this: Engine name=Catalina defaultHost=[fqdn.here] ... Valve className=org.apache.catalina.valves.ErrorReportValve showReport=false showServerInfo=false / Host name=[fqdn.here] /Host /Engine When we triggered an error, we saw that those attributes were working, because we didn't see a stacktrace or version. Last week we upgraded to 7.0.55 without modifying server.xml and now we see the stacktraces and version again. To confirm it was the upgraded Tomcat, I downgraded to 7.0.54 and indeed the ErrorReport was working again. With 7.0.55 we modified our server.xml like the following to get the desired behaviour again: Engine name=Catalina defaultHost=[fqdn.here] ... Valve className=org.apache.catalina.valves.ErrorReportValve showReport=false showServerInfo=false / !-- not necessary -- Host name=[fqdn.here] Valve className=org.apache.catalina.valves.ErrorReportValve showReport=false showServerInfo=false / !-- necessary -- /Host /Engine That is, we added the Valve at the Host-level. Could this be a bug or did I miss something in the changelog? Normally an ErrorReportValve belongs to Host and is created in o.a.catalina.core.StandardHost.startInternal(). I think that in your 7.0.54 configuration is wrong and essentially means that the same error was handled twice (at Host and then at Engine). The relevant change log entry in 7.0.55 is When an error occurs after the response has been committed close the connection immediately ... https://svn.apache.org/r1602443 Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP connector is blocking JSON responses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Omar, On 8/10/14, 1:18 PM, Omar Belkhodja wrote: Finally, I almost understood the problem. The framework was generating a response without a Content-Length header. The AJP connector seems to be adding it as a Content-Length=0, although if there are data. So, currenly I have forced the framework to add the Content-Length header. In fact, it is spring and I added property name=updateContentLength value =true/ In the following configuration bean class= org.springframework.web.servlet.view.json.MappingJackson2JsonView property name=objectMapper ref=jaxbJacksonObjectMapper/ property name=updateContentLength value=true/ /bean Thank you for having helped in locating where is the problem. For me, I have a workaround, but probably there is an issue on AJP (why adding the header with zero length ???) If you aren't explicitly setting the Content-Length and the response is not chunked, then some component is setting Content-Length to 0. mod_jk is not to blame here: the application server (Tomcat or your web application) is setting the Content-Length header to zero explicitly. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJT6BaCAAoJEBzwKT+lPKRYf1AP/Rhfrx1URnCxvP5b9cYcYEh2 M4TXhi+t648PyKWTyBkUtNn7/hfOTFAbidP8taC3kaat28l5PVT6RjK8F51PMrYo IWB59Wr5Z90D4ofl+QzPyrJ3HVGvhcvXkI2mAQnV6y138FG2tjwNtoySnstNXCvi SSOFVB1lib3EkJW5QsRpgsbtfFWDSWiQ1U72W5oMLQviU3KoBf2yDHoNWreCnLCf l9T2j45h3wF1OoMSN7aEZAUkZEv2eVn4Tf5YVvvVBS/t1kUgH2uAYbry5cWvovv1 jJy4wxhfvXIqJDuIz4nDDty4nw+NDcLL4VvhYrgbrwh4lwn/AZfi2UpamdGnWt6L /bL9ymvJ2GxndRfeUP3UuNTfgESpKpe/NU3ls/DW0N1pWlYnVIE/0nsBvph4mBVS dLllDKRcAria6pzIxQaciFVZFfi9kvS6Pux4OSB1oeSkpPvpaaphFeYFJQgVR4iw VW/iPC/SEgRlbVx0lBO6bf3tkG7rkinTY3FrMRv2GRxh1VKjFLUkLrc85igYYf9z J2oob0r1+jH/RxvABW03Ed2sWjLd/e8ZJ50eioJtYGAsoOWVkAr0WXHPM3dTFV1u 5yK7ZZvq8fwUFzLjEVRf2mznN4Tnnsy3SOBo62axcPXg4iZSscDn73EkivGal2rw AcHRwYuTXhnI+M967fwa =43hf -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
