RE: Tomcat can not locate the folders of CSS files inside a web app, if the url-pattern of a servlet is set to / inside web.xml
> From: Junqiang Zhang [mailto:junqiangzh...@gmail.com] > Subject: Re: Tomcat can not locate the folders of CSS files inside a web app, > if the url-pattern of a servlet is set to / inside web.xml Don't top-post. See item 6 under http://tomcat.apache.org/lists.html#tomcat-users > I did map my servlet to the url-pattern "/". The point we're trying to make is that you must not use a servlet mapping of "/" unless your servlet can handle the duties of DefaultServlet, including delivering static content such as CSS files and images. Your mappings need to be more specific (as you appear to have already discovered, based on your first message). > Is there any setting could let web browsers find the static content inside > the webapp > directory? If I put the static content into some other places, can web > browsers find > the css file? Note that web browsers do not "find" the content inside the webapp directory; that's entirely up to the servlets of the webapp, including Tomcat's built-in DefaultServlet - if you haven't disabled it by mapping something else to "/". Correct your servlet mapping and things will work as desired. - 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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat can not locate the folders of CSS files inside a web app, if the url-pattern of a servlet is set to / inside web.xml
Thank all you guys very much for replying to my post. I did map my servlet to the url-pattern "/". Is there any setting could let web browsers find the static content inside the webapp directory? If I put the static content into some other places, can web browsers find the css file? Does Jetty work the same way as Tomcat regarding this problem? I have tried putting the webapp content in either ROOT directory or mywebapp directory inside Tomcat/webapps. Web browsers could not find the css file. I copied the content of web.xml below. http://xmlns.jcp.org/xml/ns/javaee"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"; version="3.1" metadata-complete="true"> search com.dealfar.mainpage search / On Tue, Mar 8, 2016 at 5:02 AM, Chris Gamache wrote: > Chuck, > > That's precisely the point I was trying to make. > > CG > > On Mon, Mar 7, 2016 at 2:05 PM, Caldarale, Charles R < > chuck.caldar...@unisys.com> wrote: > >> > From: Chris Gamache [mailto:cgama...@gmail.com] >> > Subject: Re: Tomcat can not locate the folders of CSS files inside a web >> app, >> > if the url-pattern of a servlet is set to / inside web.xml >> >> > /mywebapp/css/style.css is where that file should be located if exists in >> > the spot indicated in the tree diagram. >> >> > I don't think the default servlet plays in to this... >> >> Clearly it does, as Violeta stated. Since the webapp is overriding the >> mapping for "/", Tomcat's DefaultServlet will never get used, so there is >> _nothing_ available to deliver static content. >> >> - 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. >> >> >> - >> 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: Warning response header
On Mon, Mar 7, 2016 at 5:48 PM, Sean Dawson wrote: > > > On Mon, Mar 7, 2016 at 5:44 PM, David Kerber wrote: > >> On 3/7/2016 5:11 PM, Sean Dawson wrote: >> >>> On Sun, Mar 6, 2016 at 12:48 PM, Sean Dawson >>> wrote: >>> >>> Tomcat 8_32 Windows 7 Java 8_51 RestEasy 3.0.11.Final GWT 2.7.0 (Jetty jetty-9.3.5.v20151012) Servlet code makes a RestEasy call to another servlet (same container) - second servlet sets the 'Warning' HTTP header on response. Would like to access that in first servlet but when running in Tomcat, that header is not included. Code to get header in first servlet: Object headers = ((ClientResponseFailure) e).getResponse().getResponseHeaders().get("Warning"); Also tried: getHeaders(), getStringHeaders(), and getHeaderString(). When running GWT in superdev mode in IntelliJ (15.0.4) using Jetty, the above returns a List with one item that contains the warning string. When remote debugging Tomcat, that call returns null. Added this to web app xml, and also tried Tomcat conf/web.xml... CorsFilter org.apache.catalina.filters.CorsFilter cors.exposed.headers Warning CorsFilter /* Also tried cors.allowed.headers. Any pointers? Alright, lets try this again. Simple reproducible testcase... >>> >>> - download latest Tomcat 8 for Windows 64-bit zip >>> >>> http://mirrors.ocf.berkeley.edu/apache/tomcat/tomcat-8/v8.0.32/bin/apache-tomcat-8.0.32-windows-x64.zip >>> - extract somewhere >>> - delete everything in webapps folder >>> - build project below, put in webapps folder >>> - go to: http://localhost:8080/one >>> - check response headers... no Warning header >>> >>> ** pom.xml ** >>> >>> http://maven.apache.org/POM/4.0.0"; >>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 >>> http://maven.apache.org/maven-v4_0_0.xsd";> >>> 4.0.0 >>> >>> test >>> tcTest >>> war >>> 1.0-SNAPSHOT >>> >>> tcTest Maven Webapp >>> http://maven.apache.org >>> >>> >>> >>> org.glassfish >>> javax.servlet >>> 3.1.1 >>> >>> >>> org.jboss.resteasy >>> resteasy-client >>> 3.0.11.Final >>> >>> >>> >> >> If you're adding Maven, Glassfish and JBoss, you're adding a LOT of >> complexity to your "simple" reproducible! I've never used any of them, so >> would have no hope of reproducing your issue. And there's a fair chance >> that it has nothing to do with Tomcat anyway, given all the other stuff >> around it... >> >> > I could remove JBoss from the equation - and maven, although I'm pretty > sure that's not adding much complexity. If I run it on jetty instead of > tomcat, it works fine. So I'm leaning toward Tomcat (or something extra I > need to do for Tomcat) as the issue. > > Ok using httpclient instead of RestEasy shows the header. Strange that RestEasy passes headers in the Jetty case but not the Tomcat one. But I'll see if I can get help from them. Thanks. >> >> >>> >>> ROOT >>> >>> >>> >>> >>> ** web.xml ** >>> >>> >>> >> "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" >>> "http://java.sun.com/dtd/web-app_2_3.dtd"; > >>> >>> >>> Archetype Created Web Application >>> >>> >>> One >>> pkg.ServletOne >>> >>> >>> >>> One >>> /one/* >>> >>> >>> >>> Two >>> pkg.ServletTwo >>> >>> >>> >>> Two >>> /two/* >>> >>> >>> >>> >>> ** index.html ** >>> >>> >>> >>> >>> Hello World! >>> >>> >>> >>> >>> ** Caller interface ** >>> >>> >>> package pkg; >>> >>> import javax.ws.rs.GET; >>> import javax.ws.rs.Path; >>> >>> public interface Caller >>> { >>> @GET >>> @Path("two") >>> String makeCall(); >>> } >>> >>> >>> >>> ** Servlet one ** >>> >>> >>> package pkg; >>> >>> import java.io.IOException; >>> >>> import javax.servlet.ServletException; >>> import javax.servlet.http.HttpServlet; >>> import javax.servlet.http.HttpServletRequest; >>> import javax.servlet.http.HttpServletResponse; >>> import javax.ws.rs.core.MediaType; >>> >>> import org.jboss.resteasy.client.ProxyBuilder; >>> >>> public class ServletOne extends HttpServlet >>> { >>> Caller caller; >>> >>> @Override >>> public void init() throws ServletException >>> { >>> caller = ProxyBuilder.build(Caller.class, >>> "http://localhost:8080";).now(); >>> } >>> >>> @Override >>> protected void doGet(HttpServletRequest request, >>> HttpServletResponse response) throws ServletException, IOExcept
Re: Question about your recent security (CVE-2015-5345) fix in 7.0.68 build
Thanks for the reply, Mark. Unfortunately, i still could not verify this vulnerability as it still appears not fixed & my requests get redirected. Instead of using the manager webapp that comes default in tomcat, we created a sample webapp with the following security constraint - hello.html sercure-hello /* NONE Accessing http://localhost:8080/a (which exist) gets redirected to http://localhost:8080/a/ & then get 404. Accessing http://localhost:8080/b (does not exist) simply gets 404. I have set the context attribute (mapperContextRootRedirectEnabled) as well - My question simply boils down to, What additional setting i need to do for the above redirect to NOT happen. Thanks for your help. regards Harish Krishnan On Mon, Mar 7, 2016 at 12:42 PM, Mark Thomas wrote: > On 07/03/2016 20:23, Harish Krishnan wrote: > > Hi There, > > > > I am verifying the fix that you made for CVE-2015-5345 & it appears to > be > > not fixed. I might be doing something wrong & hence sending out this > email > > to you. > > All i did was, > > a) Downloaded & installed the latest tomcat build 7.0.68. > > b) Added the following context attribute to manager webapp just for > testing > > - > > File: $CATALINA_HOME\webapps\manager\META-INF\context.xml > >> antiResourceLocking="false" privileged="true"> > > c) When i access http://localhost/8080/manager/images, it still gets > > redirected to /images/ there by confirming the folder location. Same > thing > > happens when accessing /manager/index.jsp too. > > > > Am i missing anything here ? > > Yes. Look at the security constraints defined for the Manager application. > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Warning response header
On Mon, Mar 7, 2016 at 5:44 PM, David Kerber wrote: > On 3/7/2016 5:11 PM, Sean Dawson wrote: > >> On Sun, Mar 6, 2016 at 12:48 PM, Sean Dawson >> wrote: >> >> Tomcat 8_32 >>> Windows 7 >>> Java 8_51 >>> RestEasy 3.0.11.Final >>> GWT 2.7.0 (Jetty jetty-9.3.5.v20151012) >>> >>> Servlet code makes a RestEasy call to another servlet (same container) - >>> second servlet sets the 'Warning' HTTP header on response. Would like to >>> access that in first servlet but when running in Tomcat, that header is >>> not >>> included. >>> >>> Code to get header in first servlet: >>> >>> Object headers = ((ClientResponseFailure) >>> e).getResponse().getResponseHeaders().get("Warning"); >>> >>> Also tried: getHeaders(), getStringHeaders(), and getHeaderString(). >>> >>> When running GWT in superdev mode in IntelliJ (15.0.4) using Jetty, the >>> above returns a List with one item that contains the warning string. >>> When >>> remote debugging Tomcat, that call returns null. >>> >>> Added this to web app xml, and also tried Tomcat conf/web.xml... >>> >>> >>> CorsFilter >>> >>> org.apache.catalina.filters.CorsFilter >>> >>> cors.exposed.headers >>> Warning >>> >>> >>> >>> CorsFilter >>> /* >>> >>> >>> Also tried cors.allowed.headers. >>> >>> Any pointers? >>> >>> >>> Alright, lets try this again. Simple reproducible testcase... >> >> - download latest Tomcat 8 for Windows 64-bit zip >> >> http://mirrors.ocf.berkeley.edu/apache/tomcat/tomcat-8/v8.0.32/bin/apache-tomcat-8.0.32-windows-x64.zip >> - extract somewhere >> - delete everything in webapps folder >> - build project below, put in webapps folder >> - go to: http://localhost:8080/one >> - check response headers... no Warning header >> >> ** pom.xml ** >> >> http://maven.apache.org/POM/4.0.0"; >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 >> http://maven.apache.org/maven-v4_0_0.xsd";> >> 4.0.0 >> >> test >> tcTest >> war >> 1.0-SNAPSHOT >> >> tcTest Maven Webapp >> http://maven.apache.org >> >> >> >> org.glassfish >> javax.servlet >> 3.1.1 >> >> >> org.jboss.resteasy >> resteasy-client >> 3.0.11.Final >> >> >> > > If you're adding Maven, Glassfish and JBoss, you're adding a LOT of > complexity to your "simple" reproducible! I've never used any of them, so > would have no hope of reproducing your issue. And there's a fair chance > that it has nothing to do with Tomcat anyway, given all the other stuff > around it... > > I could remove JBoss from the equation - and maven, although I'm pretty sure that's not adding much complexity. If I run it on jetty instead of tomcat, it works fine. So I'm leaning toward Tomcat (or something extra I need to do for Tomcat) as the issue. > > >> >> ROOT >> >> >> >> >> ** web.xml ** >> >> >> > "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" >> "http://java.sun.com/dtd/web-app_2_3.dtd"; > >> >> >> Archetype Created Web Application >> >> >> One >> pkg.ServletOne >> >> >> >> One >> /one/* >> >> >> >> Two >> pkg.ServletTwo >> >> >> >> Two >> /two/* >> >> >> >> >> ** index.html ** >> >> >> >> >> Hello World! >> >> >> >> >> ** Caller interface ** >> >> >> package pkg; >> >> import javax.ws.rs.GET; >> import javax.ws.rs.Path; >> >> public interface Caller >> { >> @GET >> @Path("two") >> String makeCall(); >> } >> >> >> >> ** Servlet one ** >> >> >> package pkg; >> >> import java.io.IOException; >> >> import javax.servlet.ServletException; >> import javax.servlet.http.HttpServlet; >> import javax.servlet.http.HttpServletRequest; >> import javax.servlet.http.HttpServletResponse; >> import javax.ws.rs.core.MediaType; >> >> import org.jboss.resteasy.client.ProxyBuilder; >> >> public class ServletOne extends HttpServlet >> { >> Caller caller; >> >> @Override >> public void init() throws ServletException >> { >> caller = ProxyBuilder.build(Caller.class, >> "http://localhost:8080";).now(); >> } >> >> @Override >> protected void doGet(HttpServletRequest request, >> HttpServletResponse response) throws ServletException, IOException >> { >> String result = caller.makeCall(); >> response.getWriter().println(result); >> } >> } >> >> >> ** Servlet two ** >> >> >> package pkg; >> >> import java.io.IOException; >> >> import javax.servlet.ServletException; >> import javax.servlet.http.HttpServlet; >> import javax.servlet.http.HttpServletRequest; >> import javax.servlet.http.HttpServletResponse; >> >> public class ServletTwo extends HttpServlet >> { >> @
Re: Warning response header
Sean, I just noticed something else: On 3/7/2016 2:11 PM, Sean Dawson wrote: > On Sun, Mar 6, 2016 at 12:48 PM, Sean Dawson > wrote: > >> >> Tomcat 8_32 >> Windows 7 >> Java 8_51 >> RestEasy 3.0.11.Final >> GWT 2.7.0 (Jetty jetty-9.3.5.v20151012) >> >> Servlet code makes a RestEasy call to another servlet (same container) - >> second servlet sets the 'Warning' HTTP header on response. Would like to >> access that in first servlet but when running in Tomcat, that header is not >> included. >> >> Code to get header in first servlet: >> >> Object headers = ((ClientResponseFailure) >> e).getResponse().getResponseHeaders().get("Warning"); >> >> Also tried: getHeaders(), getStringHeaders(), and getHeaderString(). >> >> When running GWT in superdev mode in IntelliJ (15.0.4) using Jetty, the >> above returns a List with one item that contains the warning string. When >> remote debugging Tomcat, that call returns null. >> >> Added this to web app xml, and also tried Tomcat conf/web.xml... >> >> >> CorsFilter >> org.apache.catalina.filters.CorsFilter >> >> cors.exposed.headers >> Warning >> >> >> >> CorsFilter >> /* >> >> >> Also tried cors.allowed.headers. >> >> Any pointers? >> >> > > Alright, lets try this again. Simple reproducible testcase... > > - download latest Tomcat 8 for Windows 64-bit zip > http://mirrors.ocf.berkeley.edu/apache/tomcat/tomcat-8/v8.0.32/bin/apache-tomcat-8.0.32-windows-x64.zip > - extract somewhere > - delete everything in webapps folder > - build project below, put in webapps folder > - go to: http://localhost:8080/one > - check response headers... no Warning header > > ** pom.xml ** > > http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/maven-v4_0_0.xsd";> > 4.0.0 > > test > tcTest > war > 1.0-SNAPSHOT > > tcTest Maven Webapp > http://maven.apache.org > > > > org.glassfish > javax.servlet > 3.1.1 > > > org.jboss.resteasy > resteasy-client > 3.0.11.Final > > > > > ROOT > > > > > ** web.xml ** > > > "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" > "http://java.sun.com/dtd/web-app_2_3.dtd"; > > > > Archetype Created Web Application > > > One > pkg.ServletOne > > > > One > /one/* > > > > Two > pkg.ServletTwo > > > > Two > /two/* > > > > > ** index.html ** > > > > > Hello World! > > > > > ** Caller interface ** > > > package pkg; > > import javax.ws.rs.GET; > import javax.ws.rs.Path; > > public interface Caller > { > @GET > @Path("two") > String makeCall(); > } > > > > ** Servlet one ** > > > package pkg; > > import java.io.IOException; > > import javax.servlet.ServletException; > import javax.servlet.http.HttpServlet; > import javax.servlet.http.HttpServletRequest; > import javax.servlet.http.HttpServletResponse; > import javax.ws.rs.core.MediaType; > > import org.jboss.resteasy.client.ProxyBuilder; > > public class ServletOne extends HttpServlet > { > Caller caller; > > @Override > public void init() throws ServletException > { > caller = ProxyBuilder.build(Caller.class, > "http://localhost:8080";).now(); > } > > @Override > protected void doGet(HttpServletRequest request, > HttpServletResponse response) throws ServletException, IOException > { > String result = caller.makeCall(); > response.getWriter().println(result); > } > } > > > ** Servlet two ** > > > package pkg; > > import java.io.IOException; > > import javax.servlet.ServletException; > import javax.servlet.http.HttpServlet; > import javax.servlet.http.HttpServletRequest; > import javax.servlet.http.HttpServletResponse; > > public class ServletTwo extends HttpServlet > { > @Override > protected void doGet(HttpServletRequest request, > HttpServletResponse response) throws ServletException, IOException > { > addHeader(response); > response.getWriter().println("Ok"); > } > > void addHeader(HttpServletResponse response) > { > response.setHeader("Warning", "This is a warning"); // also > tried addHeader() > } > } > http://java.sun.com/dtd/web-app_2_3.dtd"; > Should probably be: http://xmlns.jcp.org/xml/ns/javaee"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"; version="3.1"> (sorry for the word wrapping). I normally don't use web.xml in my 3.1 applications. I end up using annotations instead. . . . just my two cents
Re: Warning response header
On Mon, Mar 7, 2016 at 5:36 PM, Mark Eggers wrote: > Sean, > > See comment at the end. > > On 3/7/2016 2:11 PM, Sean Dawson wrote: > > On Sun, Mar 6, 2016 at 12:48 PM, Sean Dawson > > wrote: > > > >> > >> Tomcat 8_32 > >> Windows 7 > >> Java 8_51 > >> RestEasy 3.0.11.Final > >> GWT 2.7.0 (Jetty jetty-9.3.5.v20151012) > >> > >> Servlet code makes a RestEasy call to another servlet (same container) - > >> second servlet sets the 'Warning' HTTP header on response. Would like > to > >> access that in first servlet but when running in Tomcat, that header is > not > >> included. > >> > >> Code to get header in first servlet: > >> > >> Object headers = ((ClientResponseFailure) > >> e).getResponse().getResponseHeaders().get("Warning"); > >> > >> Also tried: getHeaders(), getStringHeaders(), and getHeaderString(). > >> > >> When running GWT in superdev mode in IntelliJ (15.0.4) using Jetty, the > >> above returns a List with one item that contains the warning string. > When > >> remote debugging Tomcat, that call returns null. > >> > >> Added this to web app xml, and also tried Tomcat conf/web.xml... > >> > >> > >> CorsFilter > >> > org.apache.catalina.filters.CorsFilter > >> > >> cors.exposed.headers > >> Warning > >> > >> > >> > >> CorsFilter > >> /* > >> > >> > >> Also tried cors.allowed.headers. > >> > >> Any pointers? > >> > >> > > > > Alright, lets try this again. Simple reproducible testcase... > > > > - download latest Tomcat 8 for Windows 64-bit zip > > > http://mirrors.ocf.berkeley.edu/apache/tomcat/tomcat-8/v8.0.32/bin/apache-tomcat-8.0.32-windows-x64.zip > > - extract somewhere > > - delete everything in webapps folder > > - build project below, put in webapps folder > > - go to: http://localhost:8080/one > > - check response headers... no Warning header > > > > ** pom.xml ** > > > > http://maven.apache.org/POM/4.0.0"; > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > > http://maven.apache.org/maven-v4_0_0.xsd";> > > 4.0.0 > > > > test > > tcTest > > war > > 1.0-SNAPSHOT > > > > tcTest Maven Webapp > > http://maven.apache.org > > > > > > > > org.glassfish > > javax.servlet > > 3.1.1 > > > > > > org.jboss.resteasy > > resteasy-client > > 3.0.11.Final > > > > > > > > > > ROOT > > > > > > > > > > ** web.xml ** > > > > > > > "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" > > "http://java.sun.com/dtd/web-app_2_3.dtd"; > > > > > > > Archetype Created Web Application > > > > > > One > > pkg.ServletOne > > > > > > > > One > > /one/* > > > > > > > > Two > > pkg.ServletTwo > > > > > > > > Two > > /two/* > > > > > > > > > > ** index.html ** > > > > > > > > > > Hello World! > > > > > > > > > > ** Caller interface ** > > > > > > package pkg; > > > > import javax.ws.rs.GET; > > import javax.ws.rs.Path; > > > > public interface Caller > > { > > @GET > > @Path("two") > > String makeCall(); > > } > > > > > > > > ** Servlet one ** > > > > > > package pkg; > > > > import java.io.IOException; > > > > import javax.servlet.ServletException; > > import javax.servlet.http.HttpServlet; > > import javax.servlet.http.HttpServletRequest; > > import javax.servlet.http.HttpServletResponse; > > import javax.ws.rs.core.MediaType; > > > > import org.jboss.resteasy.client.ProxyBuilder; > > > > public class ServletOne extends HttpServlet > > { > > Caller caller; > > > > @Override > > public void init() throws ServletException > > { > > caller = ProxyBuilder.build(Caller.class, > > "http://localhost:8080";).now(); > > } > > > > @Override > > protected void doGet(HttpServletRequest request, > > HttpServletResponse response) throws ServletException, IOException > > { > > String result = caller.makeCall(); > > response.getWriter().println(result); > > } > > } > > > > > > ** Servlet two ** > > > > > > package pkg; > > > > import java.io.IOException; > > > > import javax.servlet.ServletException; > > import javax.servlet.http.HttpServlet; > > import javax.servlet.http.HttpServletRequest; > > import javax.servlet.http.HttpServletResponse; > > > > public class ServletTwo extends HttpServlet > > { > > @Override > > protected void doGet(HttpServletRequest request, > > HttpServletResponse response) throws ServletException, IOException > > { > > addHeader(response); > > response.getWriter().println("Ok"); > > } > > > > void addHeader(HttpServletResponse response) > > { > > response.setHeader("Warning", "This is a warning"); // also > > tried addHeader() > > } >
Re: Warning response header
On 3/7/2016 5:11 PM, Sean Dawson wrote: On Sun, Mar 6, 2016 at 12:48 PM, Sean Dawson wrote: Tomcat 8_32 Windows 7 Java 8_51 RestEasy 3.0.11.Final GWT 2.7.0 (Jetty jetty-9.3.5.v20151012) Servlet code makes a RestEasy call to another servlet (same container) - second servlet sets the 'Warning' HTTP header on response. Would like to access that in first servlet but when running in Tomcat, that header is not included. Code to get header in first servlet: Object headers = ((ClientResponseFailure) e).getResponse().getResponseHeaders().get("Warning"); Also tried: getHeaders(), getStringHeaders(), and getHeaderString(). When running GWT in superdev mode in IntelliJ (15.0.4) using Jetty, the above returns a List with one item that contains the warning string. When remote debugging Tomcat, that call returns null. Added this to web app xml, and also tried Tomcat conf/web.xml... CorsFilter org.apache.catalina.filters.CorsFilter cors.exposed.headers Warning CorsFilter /* Also tried cors.allowed.headers. Any pointers? Alright, lets try this again. Simple reproducible testcase... - download latest Tomcat 8 for Windows 64-bit zip http://mirrors.ocf.berkeley.edu/apache/tomcat/tomcat-8/v8.0.32/bin/apache-tomcat-8.0.32-windows-x64.zip - extract somewhere - delete everything in webapps folder - build project below, put in webapps folder - go to: http://localhost:8080/one - check response headers... no Warning header ** pom.xml ** http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 test tcTest war 1.0-SNAPSHOT tcTest Maven Webapp http://maven.apache.org org.glassfish javax.servlet 3.1.1 org.jboss.resteasy resteasy-client 3.0.11.Final If you're adding Maven, Glassfish and JBoss, you're adding a LOT of complexity to your "simple" reproducible! I've never used any of them, so would have no hope of reproducing your issue. And there's a fair chance that it has nothing to do with Tomcat anyway, given all the other stuff around it... ROOT ** web.xml ** http://java.sun.com/dtd/web-app_2_3.dtd"; > Archetype Created Web Application One pkg.ServletOne One /one/* Two pkg.ServletTwo Two /two/* ** index.html ** Hello World! ** Caller interface ** package pkg; import javax.ws.rs.GET; import javax.ws.rs.Path; public interface Caller { @GET @Path("two") String makeCall(); } ** Servlet one ** package pkg; import java.io.IOException; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import javax.ws.rs.core.MediaType; import org.jboss.resteasy.client.ProxyBuilder; public class ServletOne extends HttpServlet { Caller caller; @Override public void init() throws ServletException { caller = ProxyBuilder.build(Caller.class, "http://localhost:8080";).now(); } @Override protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { String result = caller.makeCall(); response.getWriter().println(result); } } ** Servlet two ** package pkg; import java.io.IOException; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; public class ServletTwo extends HttpServlet { @Override protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { addHeader(response); response.getWriter().println("Ok"); } void addHeader(HttpServletResponse response) { response.setHeader("Warning", "This is a warning"); // also tried addHeader() } } - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Warning response header
Sean, See comment at the end. On 3/7/2016 2:11 PM, Sean Dawson wrote: > On Sun, Mar 6, 2016 at 12:48 PM, Sean Dawson > wrote: > >> >> Tomcat 8_32 >> Windows 7 >> Java 8_51 >> RestEasy 3.0.11.Final >> GWT 2.7.0 (Jetty jetty-9.3.5.v20151012) >> >> Servlet code makes a RestEasy call to another servlet (same container) - >> second servlet sets the 'Warning' HTTP header on response. Would like to >> access that in first servlet but when running in Tomcat, that header is not >> included. >> >> Code to get header in first servlet: >> >> Object headers = ((ClientResponseFailure) >> e).getResponse().getResponseHeaders().get("Warning"); >> >> Also tried: getHeaders(), getStringHeaders(), and getHeaderString(). >> >> When running GWT in superdev mode in IntelliJ (15.0.4) using Jetty, the >> above returns a List with one item that contains the warning string. When >> remote debugging Tomcat, that call returns null. >> >> Added this to web app xml, and also tried Tomcat conf/web.xml... >> >> >> CorsFilter >> org.apache.catalina.filters.CorsFilter >> >> cors.exposed.headers >> Warning >> >> >> >> CorsFilter >> /* >> >> >> Also tried cors.allowed.headers. >> >> Any pointers? >> >> > > Alright, lets try this again. Simple reproducible testcase... > > - download latest Tomcat 8 for Windows 64-bit zip > http://mirrors.ocf.berkeley.edu/apache/tomcat/tomcat-8/v8.0.32/bin/apache-tomcat-8.0.32-windows-x64.zip > - extract somewhere > - delete everything in webapps folder > - build project below, put in webapps folder > - go to: http://localhost:8080/one > - check response headers... no Warning header > > ** pom.xml ** > > http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/maven-v4_0_0.xsd";> > 4.0.0 > > test > tcTest > war > 1.0-SNAPSHOT > > tcTest Maven Webapp > http://maven.apache.org > > > > org.glassfish > javax.servlet > 3.1.1 > > > org.jboss.resteasy > resteasy-client > 3.0.11.Final > > > > > ROOT > > > > > ** web.xml ** > > > "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" > "http://java.sun.com/dtd/web-app_2_3.dtd"; > > > > Archetype Created Web Application > > > One > pkg.ServletOne > > > > One > /one/* > > > > Two > pkg.ServletTwo > > > > Two > /two/* > > > > > ** index.html ** > > > > > Hello World! > > > > > ** Caller interface ** > > > package pkg; > > import javax.ws.rs.GET; > import javax.ws.rs.Path; > > public interface Caller > { > @GET > @Path("two") > String makeCall(); > } > > > > ** Servlet one ** > > > package pkg; > > import java.io.IOException; > > import javax.servlet.ServletException; > import javax.servlet.http.HttpServlet; > import javax.servlet.http.HttpServletRequest; > import javax.servlet.http.HttpServletResponse; > import javax.ws.rs.core.MediaType; > > import org.jboss.resteasy.client.ProxyBuilder; > > public class ServletOne extends HttpServlet > { > Caller caller; > > @Override > public void init() throws ServletException > { > caller = ProxyBuilder.build(Caller.class, > "http://localhost:8080";).now(); > } > > @Override > protected void doGet(HttpServletRequest request, > HttpServletResponse response) throws ServletException, IOException > { > String result = caller.makeCall(); > response.getWriter().println(result); > } > } > > > ** Servlet two ** > > > package pkg; > > import java.io.IOException; > > import javax.servlet.ServletException; > import javax.servlet.http.HttpServlet; > import javax.servlet.http.HttpServletRequest; > import javax.servlet.http.HttpServletResponse; > > public class ServletTwo extends HttpServlet > { > @Override > protected void doGet(HttpServletRequest request, > HttpServletResponse response) throws ServletException, IOException > { > addHeader(response); > response.getWriter().println("Ok"); > } > > void addHeader(HttpServletResponse response) > { > response.setHeader("Warning", "This is a warning"); // also > tried addHeader() > } > } > org.glassfish javax.servlet 3.1.1 This is wrong and will include the servlet API in your WAR file. You at least need: org.glassfish javax.servlet 3.1.1 provided I actually use the following in my Jersey applications: 2.22.1 1.7 3.1.0 UTF-8 javax.servlet javax.servlet-api ${version.servlet.api} provided javax.servlet.jsp
Re: Warning response header
On Sun, Mar 6, 2016 at 12:48 PM, Sean Dawson wrote: > > Tomcat 8_32 > Windows 7 > Java 8_51 > RestEasy 3.0.11.Final > GWT 2.7.0 (Jetty jetty-9.3.5.v20151012) > > Servlet code makes a RestEasy call to another servlet (same container) - > second servlet sets the 'Warning' HTTP header on response. Would like to > access that in first servlet but when running in Tomcat, that header is not > included. > > Code to get header in first servlet: > > Object headers = ((ClientResponseFailure) > e).getResponse().getResponseHeaders().get("Warning"); > > Also tried: getHeaders(), getStringHeaders(), and getHeaderString(). > > When running GWT in superdev mode in IntelliJ (15.0.4) using Jetty, the > above returns a List with one item that contains the warning string. When > remote debugging Tomcat, that call returns null. > > Added this to web app xml, and also tried Tomcat conf/web.xml... > > > CorsFilter > org.apache.catalina.filters.CorsFilter > > cors.exposed.headers > Warning > > > > CorsFilter > /* > > > Also tried cors.allowed.headers. > > Any pointers? > > Alright, lets try this again. Simple reproducible testcase... - download latest Tomcat 8 for Windows 64-bit zip http://mirrors.ocf.berkeley.edu/apache/tomcat/tomcat-8/v8.0.32/bin/apache-tomcat-8.0.32-windows-x64.zip - extract somewhere - delete everything in webapps folder - build project below, put in webapps folder - go to: http://localhost:8080/one - check response headers... no Warning header ** pom.xml ** http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 test tcTest war 1.0-SNAPSHOT tcTest Maven Webapp http://maven.apache.org org.glassfish javax.servlet 3.1.1 org.jboss.resteasy resteasy-client 3.0.11.Final ROOT ** web.xml ** http://java.sun.com/dtd/web-app_2_3.dtd"; > Archetype Created Web Application One pkg.ServletOne One /one/* Two pkg.ServletTwo Two /two/* ** index.html ** Hello World! ** Caller interface ** package pkg; import javax.ws.rs.GET; import javax.ws.rs.Path; public interface Caller { @GET @Path("two") String makeCall(); } ** Servlet one ** package pkg; import java.io.IOException; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import javax.ws.rs.core.MediaType; import org.jboss.resteasy.client.ProxyBuilder; public class ServletOne extends HttpServlet { Caller caller; @Override public void init() throws ServletException { caller = ProxyBuilder.build(Caller.class, "http://localhost:8080";).now(); } @Override protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { String result = caller.makeCall(); response.getWriter().println(result); } } ** Servlet two ** package pkg; import java.io.IOException; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; public class ServletTwo extends HttpServlet { @Override protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { addHeader(response); response.getWriter().println("Ok"); } void addHeader(HttpServletResponse response) { response.setHeader("Warning", "This is a warning"); // also tried addHeader() } }
Re: Tomcat can not locate the folders of CSS files inside a web app, if the url-pattern of a servlet is set to / inside web.xml
Chuck, That's precisely the point I was trying to make. CG On Mon, Mar 7, 2016 at 2:05 PM, Caldarale, Charles R < chuck.caldar...@unisys.com> wrote: > > From: Chris Gamache [mailto:cgama...@gmail.com] > > Subject: Re: Tomcat can not locate the folders of CSS files inside a web > app, > > if the url-pattern of a servlet is set to / inside web.xml > > > /mywebapp/css/style.css is where that file should be located if exists in > > the spot indicated in the tree diagram. > > > I don't think the default servlet plays in to this... > > Clearly it does, as Violeta stated. Since the webapp is overriding the > mapping for "/", Tomcat's DefaultServlet will never get used, so there is > _nothing_ available to deliver static content. > > - 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. > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Understanding how to controlling what data is written to log4j appenders
One more thing I tried was to change the parent for the rootlogger from CFCC to be CONSOLE to attempt to make it to where my log was not the parent and it still didn't change it. I am getting 0 messages in my cfcc log and everything still going to catalina.out. I know I'm so close to figuring out what little setting I am missing. On Mon, Mar 7, 2016 at 2:07 PM, Joleen Barker wrote: > There is a comment that says: > > #stdout is set to be a ConsoleAppender > > But I changed the "stdout" that was set as the parent to CFCC so I thought > then everything would go to the parent but I don't receive any of the logs. > My cfcc log is just about empty except for the startup details. So I went > ahead and changed the CATALINABASE/lib log4j.properties file name appender > CFCC to go to a file named tomcat instead so I could differentiate between > the application logs and the tomcat logs. > > Now I get the startup messages in a log called tomcat (this is fine) and > not one message in my cfcc log. Even with my updated log4j.properties file > sitting in the WEB-INF/classes directory so I must have something > configured wrong that they are all still going to the standard > Stdout/Stderr. > > > > On Mon, Mar 7, 2016 at 12:54 PM, Joleen Barker > wrote: > >> I forgot to tell Chuck that the swallowOutput parm is set to true in the >> context. When you see the vendor's log4j.properties you will see why there >> were so many messages still going to the catalina.out due to them using >> stdout. >> >> -Joleen >> >> On Mon, Mar 7, 2016 at 12:31 PM, Joleen Barker >> wrote: >> >>> Hello Christopher, Charles, and Cris, >>> >>> Thank you for all the responses. Thank you for the encouragement. I >>> dusted off my pants and went back at it. I made changes to the Vendors >>> log4j.properties file. When I really looked at it I was able to determine >>> they were things I was familiar with and the layout was just throwing me >>> off so I moved things around so the layout was similar to the default >>> log4j.properties I had. So I think I am getting this a lot more. However, >>> there are still some messages going to the catalina.out. I think this will >>> answer Chucks question as to if the product was really using log4j. >>> >>> The only thing I can think of to help you understand where I am at is to >>> post the different log4j.properties config files I have. So I will post the >>> one I have that went in for my default Tomcat messages and is working fine. >>> >>> Updated log4j.properties file I now use in my CATALINA/lib directory and >>> is my base of my understanding for the changes I made to the Vendor's >>> log4j.properties file. >>> >>> My appender that rolls daily is CFCC and is getting most of what was in >>> the catalina.out log originally (this one I was happy with): >>> >>> log4j.rootLogger = INFO, CATALINA >>> >>> # Define all the appenders >>> log4j.appender.CATALINA = org.apache.log4j.DailyRollingFileAppender >>> log4j.appender.CATALINA.File = ${catalina.base}/logs/catalina >>> log4j.appender.CATALINA.Append = true >>> log4j.appender.CATALINA.Encoding = UTF-8 >>> log4j.appender.CATALINA.DatePattern = '.'-MM-dd'.log' >>> log4j.appender.CATALINA.layout = org.apache.log4j.PatternLayout >>> log4j.appender.CATALINA.layout.ConversionPattern = %d [%t] %-5p %c- %m%n >>> >>> log4j.appender.CFCC = org.apache.log4j.DailyRollingFileAppender >>> log4j.appender.CFCC.File = ${catalina.base}/logs/cfcc >>> log4j.appender.CFCC.Append = true >>> log4j.appender.CFCC.Encoding = UTF-8 >>> log4j.appender.CFCC.DatePattern = '.'-MM-dd'.log' >>> log4j.appender.CFCC.layout = org.apache.log4j.PatternLayout >>> log4j.appender.CFCC.layout.ConversionPattern = %d [%t] %-5p %c- %m%n >>> >>> log4j.appender.LOCALHOST = org.apache.log4j.DailyRollingFileAppender >>> log4j.appender.LOCALHOST.File = ${catalina.base}/logs/localhost >>> log4j.appender.LOCALHOST.Append = true >>> log4j.appender.LOCALHOST.Encoding = UTF-8 >>> log4j.appender.LOCALHOST.DatePattern = '.'-MM-dd'.log' >>> log4j.appender.LOCALHOST.layout = org.apache.log4j.PatternLayout >>> log4j.appender.LOCALHOST.layout.ConversionPattern = %d [%t] %-5p %c- %m%n >>> >>> log4j.appender.MANAGER = org.apache.log4j.DailyRollingFileAppender >>> log4j.appender.MANAGER.File = ${catalina.base}/logs/manager >>> log4j.appender.MANAGER.Append = true >>> log4j.appender.MANAGER.Encoding = UTF-8 >>> log4j.appender.MANAGER.DatePattern = '.'-MM-dd'.log' >>> log4j.appender.MANAGER.layout = org.apache.log4j.PatternLayout >>> log4j.appender.MANAGER.layout.ConversionPattern = %d [%t] %-5p %c- %m%n >>> >>> log4j.appender.HOST-MANAGER = org.apache.log4j.DailyRollingFileAppender >>> log4j.appender.HOST-MANAGER.File = ${catalina.base}/logs/host-manager >>> log4j.appender.HOST-MANAGER.Append = true >>> log4j.appender.HOST-MANAGER.Encoding = UTF-8 >>> log4j.appender.HOST-MANAGER.DatePattern = '.'-MM-dd'.log' >>> log4j.appender.HOST-MANAGER.layout = org.apache.log4j.PatternLayout >>> log4j.appen
Re: Question about your recent security (CVE-2015-5345) fix in 7.0.68 build
On 07/03/2016 20:23, Harish Krishnan wrote: > Hi There, > > I am verifying the fix that you made for CVE-2015-5345 & it appears to be > not fixed. I might be doing something wrong & hence sending out this email > to you. > All i did was, > a) Downloaded & installed the latest tomcat build 7.0.68. > b) Added the following context attribute to manager webapp just for testing > - > File: $CATALINA_HOME\webapps\manager\META-INF\context.xml >antiResourceLocking="false" privileged="true"> > c) When i access http://localhost/8080/manager/images, it still gets > redirected to /images/ there by confirming the folder location. Same thing > happens when accessing /manager/index.jsp too. > > Am i missing anything here ? Yes. Look at the security constraints defined for the Manager application. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Question about your recent security (CVE-2015-5345) fix in 7.0.68 build
Hi There, I am verifying the fix that you made for CVE-2015-5345 & it appears to be not fixed. I might be doing something wrong & hence sending out this email to you. All i did was, a) Downloaded & installed the latest tomcat build 7.0.68. b) Added the following context attribute to manager webapp just for testing - File: $CATALINA_HOME\webapps\manager\META-INF\context.xml c) When i access http://localhost/8080/manager/images, it still gets redirected to /images/ there by confirming the folder location. Same thing happens when accessing /manager/index.jsp too. Am i missing anything here ? Please help me understand the exact fix for this issue. regards Harish Krishnan
Re: Understanding how to controlling what data is written to log4j appenders
There is a comment that says: #stdout is set to be a ConsoleAppender But I changed the "stdout" that was set as the parent to CFCC so I thought then everything would go to the parent but I don't receive any of the logs. My cfcc log is just about empty except for the startup details. So I went ahead and changed the CATALINABASE/lib log4j.properties file name appender CFCC to go to a file named tomcat instead so I could differentiate between the application logs and the tomcat logs. Now I get the startup messages in a log called tomcat (this is fine) and not one message in my cfcc log. Even with my updated log4j.properties file sitting in the WEB-INF/classes directory so I must have something configured wrong that they are all still going to the standard Stdout/Stderr. On Mon, Mar 7, 2016 at 12:54 PM, Joleen Barker wrote: > I forgot to tell Chuck that the swallowOutput parm is set to true in the > context. When you see the vendor's log4j.properties you will see why there > were so many messages still going to the catalina.out due to them using > stdout. > > -Joleen > > On Mon, Mar 7, 2016 at 12:31 PM, Joleen Barker > wrote: > >> Hello Christopher, Charles, and Cris, >> >> Thank you for all the responses. Thank you for the encouragement. I >> dusted off my pants and went back at it. I made changes to the Vendors >> log4j.properties file. When I really looked at it I was able to determine >> they were things I was familiar with and the layout was just throwing me >> off so I moved things around so the layout was similar to the default >> log4j.properties I had. So I think I am getting this a lot more. However, >> there are still some messages going to the catalina.out. I think this will >> answer Chucks question as to if the product was really using log4j. >> >> The only thing I can think of to help you understand where I am at is to >> post the different log4j.properties config files I have. So I will post the >> one I have that went in for my default Tomcat messages and is working fine. >> >> Updated log4j.properties file I now use in my CATALINA/lib directory and >> is my base of my understanding for the changes I made to the Vendor's >> log4j.properties file. >> >> My appender that rolls daily is CFCC and is getting most of what was in >> the catalina.out log originally (this one I was happy with): >> >> log4j.rootLogger = INFO, CATALINA >> >> # Define all the appenders >> log4j.appender.CATALINA = org.apache.log4j.DailyRollingFileAppender >> log4j.appender.CATALINA.File = ${catalina.base}/logs/catalina >> log4j.appender.CATALINA.Append = true >> log4j.appender.CATALINA.Encoding = UTF-8 >> log4j.appender.CATALINA.DatePattern = '.'-MM-dd'.log' >> log4j.appender.CATALINA.layout = org.apache.log4j.PatternLayout >> log4j.appender.CATALINA.layout.ConversionPattern = %d [%t] %-5p %c- %m%n >> >> log4j.appender.CFCC = org.apache.log4j.DailyRollingFileAppender >> log4j.appender.CFCC.File = ${catalina.base}/logs/cfcc >> log4j.appender.CFCC.Append = true >> log4j.appender.CFCC.Encoding = UTF-8 >> log4j.appender.CFCC.DatePattern = '.'-MM-dd'.log' >> log4j.appender.CFCC.layout = org.apache.log4j.PatternLayout >> log4j.appender.CFCC.layout.ConversionPattern = %d [%t] %-5p %c- %m%n >> >> log4j.appender.LOCALHOST = org.apache.log4j.DailyRollingFileAppender >> log4j.appender.LOCALHOST.File = ${catalina.base}/logs/localhost >> log4j.appender.LOCALHOST.Append = true >> log4j.appender.LOCALHOST.Encoding = UTF-8 >> log4j.appender.LOCALHOST.DatePattern = '.'-MM-dd'.log' >> log4j.appender.LOCALHOST.layout = org.apache.log4j.PatternLayout >> log4j.appender.LOCALHOST.layout.ConversionPattern = %d [%t] %-5p %c- %m%n >> >> log4j.appender.MANAGER = org.apache.log4j.DailyRollingFileAppender >> log4j.appender.MANAGER.File = ${catalina.base}/logs/manager >> log4j.appender.MANAGER.Append = true >> log4j.appender.MANAGER.Encoding = UTF-8 >> log4j.appender.MANAGER.DatePattern = '.'-MM-dd'.log' >> log4j.appender.MANAGER.layout = org.apache.log4j.PatternLayout >> log4j.appender.MANAGER.layout.ConversionPattern = %d [%t] %-5p %c- %m%n >> >> log4j.appender.HOST-MANAGER = org.apache.log4j.DailyRollingFileAppender >> log4j.appender.HOST-MANAGER.File = ${catalina.base}/logs/host-manager >> log4j.appender.HOST-MANAGER.Append = true >> log4j.appender.HOST-MANAGER.Encoding = UTF-8 >> log4j.appender.HOST-MANAGER.DatePattern = '.'-MM-dd'.log' >> log4j.appender.HOST-MANAGER.layout = org.apache.log4j.PatternLayout >> log4j.appender.HOST-MANAGER.layout.ConversionPattern = %d [%t] %-5p %c- >> %m%n >> >> log4j.appender.CONSOLE = org.apache.log4j.ConsoleAppender >> log4j.appender.CONSOLE.Encoding = UTF-8 >> log4j.appender.CONSOLE.layout = org.apache.log4j.PatternLayout >> log4j.appender.CONSOLE.layout.ConversionPattern = %d [%t] %-5p %c- %m%n >> >> # Configure which loggers log to which appenders >> log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/cfcc] >> = INFO, CFCC >> log4j.logger.org.apache.catal
RE: Tomcat can not locate the folders of CSS files inside a web app, if the url-pattern of a servlet is set to / inside web.xml
> From: Chris Gamache [mailto:cgama...@gmail.com] > Subject: Re: Tomcat can not locate the folders of CSS files inside a web app, > if the url-pattern of a servlet is set to / inside web.xml > /mywebapp/css/style.css is where that file should be located if exists in > the spot indicated in the tree diagram. > I don't think the default servlet plays in to this... Clearly it does, as Violeta stated. Since the webapp is overriding the mapping for "/", Tomcat's DefaultServlet will never get used, so there is _nothing_ available to deliver static content. - 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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat can not locate the folders of CSS files inside a web app, if the url-pattern of a servlet is set to / inside web.xml
Junqiang Zhang has the expectation of the paths to the files correct. /mywebapp/css/style.css is where that file should be located if exists in the spot indicated in the tree diagram. I don't think the default servlet plays in to this... Can you post your web.xml ? I think perhaps one of your mappings is sitting on "/*" which would keep tomcat from serving static resources. On Mon, Mar 7, 2016 at 1:52 PM, Violeta Georgieva wrote: > Hi, > > 2016-03-07 19:37 GMT+02:00 Junqiang Zhang : > > > > I have tested on Tomcat versions 8.0.30, 8.0.32, and 9.0.0.M3. > > > > A web app is put inside a folder (let's say the name of the foder is > > mywebapp) inside the Tomcat webapps directory. The folder for css > > files (let's say the name of folder is css) is located inside this web > > app folder. There is no index.html or index.jsp inside the web app > > folder. The structure is as the follows. > > > > Tomcat > > webapps > > ---mywebapp > > ---css > > ---styles.css > > ---images > > ---META-INF > > ---scripts > > ---WEB-INF > > ---classes > > ---someservlet.class > > ---lib > > ---src > > ---someservlet.java > >---web.xml > > > > > > If the url-pattern of someservlet.class is set to / inside web.xml, > > Tomcat's "default" servlet [1] is mapped to "/". > The "default" servlet is a servlet that serves static resources as well as > serves the directory listings (if enabled). > > You should know that when you map your servlet to "/" then you will > override the "default" servlet mapping. > So you should ensure that your servlet will do the same as "default" one in > order to serve the static resources. > > When you map your servlet to "/someclass" then the static resources will be > served by "default" servlet as expected. > > Regards, > Violeta > [1] http://tomcat.apache.org/tomcat-8.0-doc/default-servlet.html > > > someservlet.class can be access using > > http://www.somewebsite.com/mywebapp > > > > The problem is that web browsers cannot locate styles.css at > > http://www.somewebsite.com/mywebapp/css/styles.css. Therefor, > > styles.css cannot be applied on the html file generated by > > someservlet.class. Probably other folders or files inside mywebapp > > directory cannot be accessed by web browsers too. > > > > If the url-pattern of someservlet.class is set to /someclass inside > > web.xml, someservlet.class can be access using > > http://www.somewebsite.com/mywebapp/someclass . Web browsers can > > correctly locate styles.css at > > http://www.somewebsite.com/mywebapp/css/styles.css > > > > Any solution to this problem? Does it solve this problem if I use > > Jetty or Glassfish? > > > > Thanks. > > Junqiang > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > >
Re: Tomcat can not locate the folders of CSS files inside a web app, if the url-pattern of a servlet is set to / inside web.xml
Hi, 2016-03-07 19:37 GMT+02:00 Junqiang Zhang : > > I have tested on Tomcat versions 8.0.30, 8.0.32, and 9.0.0.M3. > > A web app is put inside a folder (let's say the name of the foder is > mywebapp) inside the Tomcat webapps directory. The folder for css > files (let's say the name of folder is css) is located inside this web > app folder. There is no index.html or index.jsp inside the web app > folder. The structure is as the follows. > > Tomcat > webapps > ---mywebapp > ---css > ---styles.css > ---images > ---META-INF > ---scripts > ---WEB-INF > ---classes > ---someservlet.class > ---lib > ---src > ---someservlet.java >---web.xml > > > If the url-pattern of someservlet.class is set to / inside web.xml, Tomcat's "default" servlet [1] is mapped to "/". The "default" servlet is a servlet that serves static resources as well as serves the directory listings (if enabled). You should know that when you map your servlet to "/" then you will override the "default" servlet mapping. So you should ensure that your servlet will do the same as "default" one in order to serve the static resources. When you map your servlet to "/someclass" then the static resources will be served by "default" servlet as expected. Regards, Violeta [1] http://tomcat.apache.org/tomcat-8.0-doc/default-servlet.html > someservlet.class can be access using > http://www.somewebsite.com/mywebapp > > The problem is that web browsers cannot locate styles.css at > http://www.somewebsite.com/mywebapp/css/styles.css. Therefor, > styles.css cannot be applied on the html file generated by > someservlet.class. Probably other folders or files inside mywebapp > directory cannot be accessed by web browsers too. > > If the url-pattern of someservlet.class is set to /someclass inside > web.xml, someservlet.class can be access using > http://www.somewebsite.com/mywebapp/someclass . Web browsers can > correctly locate styles.css at > http://www.somewebsite.com/mywebapp/css/styles.css > > Any solution to this problem? Does it solve this problem if I use > Jetty or Glassfish? > > Thanks. > Junqiang > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
Re: Understanding how to controlling what data is written to log4j appenders
I forgot to tell Chuck that the swallowOutput parm is set to true in the context. When you see the vendor's log4j.properties you will see why there were so many messages still going to the catalina.out due to them using stdout. -Joleen On Mon, Mar 7, 2016 at 12:31 PM, Joleen Barker wrote: > Hello Christopher, Charles, and Cris, > > Thank you for all the responses. Thank you for the encouragement. I dusted > off my pants and went back at it. I made changes to the Vendors > log4j.properties file. When I really looked at it I was able to determine > they were things I was familiar with and the layout was just throwing me > off so I moved things around so the layout was similar to the default > log4j.properties I had. So I think I am getting this a lot more. However, > there are still some messages going to the catalina.out. I think this will > answer Chucks question as to if the product was really using log4j. > > The only thing I can think of to help you understand where I am at is to > post the different log4j.properties config files I have. So I will post the > one I have that went in for my default Tomcat messages and is working fine. > > Updated log4j.properties file I now use in my CATALINA/lib directory and > is my base of my understanding for the changes I made to the Vendor's > log4j.properties file. > > My appender that rolls daily is CFCC and is getting most of what was in > the catalina.out log originally (this one I was happy with): > > log4j.rootLogger = INFO, CATALINA > > # Define all the appenders > log4j.appender.CATALINA = org.apache.log4j.DailyRollingFileAppender > log4j.appender.CATALINA.File = ${catalina.base}/logs/catalina > log4j.appender.CATALINA.Append = true > log4j.appender.CATALINA.Encoding = UTF-8 > log4j.appender.CATALINA.DatePattern = '.'-MM-dd'.log' > log4j.appender.CATALINA.layout = org.apache.log4j.PatternLayout > log4j.appender.CATALINA.layout.ConversionPattern = %d [%t] %-5p %c- %m%n > > log4j.appender.CFCC = org.apache.log4j.DailyRollingFileAppender > log4j.appender.CFCC.File = ${catalina.base}/logs/cfcc > log4j.appender.CFCC.Append = true > log4j.appender.CFCC.Encoding = UTF-8 > log4j.appender.CFCC.DatePattern = '.'-MM-dd'.log' > log4j.appender.CFCC.layout = org.apache.log4j.PatternLayout > log4j.appender.CFCC.layout.ConversionPattern = %d [%t] %-5p %c- %m%n > > log4j.appender.LOCALHOST = org.apache.log4j.DailyRollingFileAppender > log4j.appender.LOCALHOST.File = ${catalina.base}/logs/localhost > log4j.appender.LOCALHOST.Append = true > log4j.appender.LOCALHOST.Encoding = UTF-8 > log4j.appender.LOCALHOST.DatePattern = '.'-MM-dd'.log' > log4j.appender.LOCALHOST.layout = org.apache.log4j.PatternLayout > log4j.appender.LOCALHOST.layout.ConversionPattern = %d [%t] %-5p %c- %m%n > > log4j.appender.MANAGER = org.apache.log4j.DailyRollingFileAppender > log4j.appender.MANAGER.File = ${catalina.base}/logs/manager > log4j.appender.MANAGER.Append = true > log4j.appender.MANAGER.Encoding = UTF-8 > log4j.appender.MANAGER.DatePattern = '.'-MM-dd'.log' > log4j.appender.MANAGER.layout = org.apache.log4j.PatternLayout > log4j.appender.MANAGER.layout.ConversionPattern = %d [%t] %-5p %c- %m%n > > log4j.appender.HOST-MANAGER = org.apache.log4j.DailyRollingFileAppender > log4j.appender.HOST-MANAGER.File = ${catalina.base}/logs/host-manager > log4j.appender.HOST-MANAGER.Append = true > log4j.appender.HOST-MANAGER.Encoding = UTF-8 > log4j.appender.HOST-MANAGER.DatePattern = '.'-MM-dd'.log' > log4j.appender.HOST-MANAGER.layout = org.apache.log4j.PatternLayout > log4j.appender.HOST-MANAGER.layout.ConversionPattern = %d [%t] %-5p %c- > %m%n > > log4j.appender.CONSOLE = org.apache.log4j.ConsoleAppender > log4j.appender.CONSOLE.Encoding = UTF-8 > log4j.appender.CONSOLE.layout = org.apache.log4j.PatternLayout > log4j.appender.CONSOLE.layout.ConversionPattern = %d [%t] %-5p %c- %m%n > > # Configure which loggers log to which appenders > log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/cfcc] > = INFO, CFCC > log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost] > = INFO, LOCALHOST > log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager] > =\ > INFO, MANAGER > log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager] > =\ > INFO, HOST-MANAGER > > # In order to prevent messages from being duplicated in the appenders the > additivity flag is > # needed to be set. What this does is prevent the child appenders from > also sending their > # messages to the parent appender which in our case is the CATALINA log. > log4j.additivity.org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/cfcc] > = FALSE > log4j.additivity.org.apache.catalina.core.ContainerBase.[Catalina].[localhost] > = FALSE > > > Below this line is the Vendor's original one that was in the > /classes directory ( I also removed their log4j-1.2.8-1.jar that > was in the /lib directory folder as it w
Tomcat can not locate the folders of CSS files inside a web app, if the url-pattern of a servlet is set to / inside web.xml
I have tested on Tomcat versions 8.0.30, 8.0.32, and 9.0.0.M3. A web app is put inside a folder (let's say the name of the foder is mywebapp) inside the Tomcat webapps directory. The folder for css files (let's say the name of folder is css) is located inside this web app folder. There is no index.html or index.jsp inside the web app folder. The structure is as the follows. Tomcat webapps ---mywebapp ---css ---styles.css ---images ---META-INF ---scripts ---WEB-INF ---classes ---someservlet.class ---lib ---src ---someservlet.java ---web.xml If the url-pattern of someservlet.class is set to / inside web.xml, someservlet.class can be access using http://www.somewebsite.com/mywebapp The problem is that web browsers cannot locate styles.css at http://www.somewebsite.com/mywebapp/css/styles.css. Therefor, styles.css cannot be applied on the html file generated by someservlet.class. Probably other folders or files inside mywebapp directory cannot be accessed by web browsers too. If the url-pattern of someservlet.class is set to /someclass inside web.xml, someservlet.class can be access using http://www.somewebsite.com/mywebapp/someclass . Web browsers can correctly locate styles.css at http://www.somewebsite.com/mywebapp/css/styles.css Any solution to this problem? Does it solve this problem if I use Jetty or Glassfish? Thanks. Junqiang - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Understanding how to controlling what data is written to log4j appenders
Hello Christopher, Charles, and Cris, Thank you for all the responses. Thank you for the encouragement. I dusted off my pants and went back at it. I made changes to the Vendors log4j.properties file. When I really looked at it I was able to determine they were things I was familiar with and the layout was just throwing me off so I moved things around so the layout was similar to the default log4j.properties I had. So I think I am getting this a lot more. However, there are still some messages going to the catalina.out. I think this will answer Chucks question as to if the product was really using log4j. The only thing I can think of to help you understand where I am at is to post the different log4j.properties config files I have. So I will post the one I have that went in for my default Tomcat messages and is working fine. Updated log4j.properties file I now use in my CATALINA/lib directory and is my base of my understanding for the changes I made to the Vendor's log4j.properties file. My appender that rolls daily is CFCC and is getting most of what was in the catalina.out log originally (this one I was happy with): log4j.rootLogger = INFO, CATALINA # Define all the appenders log4j.appender.CATALINA = org.apache.log4j.DailyRollingFileAppender log4j.appender.CATALINA.File = ${catalina.base}/logs/catalina log4j.appender.CATALINA.Append = true log4j.appender.CATALINA.Encoding = UTF-8 log4j.appender.CATALINA.DatePattern = '.'-MM-dd'.log' log4j.appender.CATALINA.layout = org.apache.log4j.PatternLayout log4j.appender.CATALINA.layout.ConversionPattern = %d [%t] %-5p %c- %m%n log4j.appender.CFCC = org.apache.log4j.DailyRollingFileAppender log4j.appender.CFCC.File = ${catalina.base}/logs/cfcc log4j.appender.CFCC.Append = true log4j.appender.CFCC.Encoding = UTF-8 log4j.appender.CFCC.DatePattern = '.'-MM-dd'.log' log4j.appender.CFCC.layout = org.apache.log4j.PatternLayout log4j.appender.CFCC.layout.ConversionPattern = %d [%t] %-5p %c- %m%n log4j.appender.LOCALHOST = org.apache.log4j.DailyRollingFileAppender log4j.appender.LOCALHOST.File = ${catalina.base}/logs/localhost log4j.appender.LOCALHOST.Append = true log4j.appender.LOCALHOST.Encoding = UTF-8 log4j.appender.LOCALHOST.DatePattern = '.'-MM-dd'.log' log4j.appender.LOCALHOST.layout = org.apache.log4j.PatternLayout log4j.appender.LOCALHOST.layout.ConversionPattern = %d [%t] %-5p %c- %m%n log4j.appender.MANAGER = org.apache.log4j.DailyRollingFileAppender log4j.appender.MANAGER.File = ${catalina.base}/logs/manager log4j.appender.MANAGER.Append = true log4j.appender.MANAGER.Encoding = UTF-8 log4j.appender.MANAGER.DatePattern = '.'-MM-dd'.log' log4j.appender.MANAGER.layout = org.apache.log4j.PatternLayout log4j.appender.MANAGER.layout.ConversionPattern = %d [%t] %-5p %c- %m%n log4j.appender.HOST-MANAGER = org.apache.log4j.DailyRollingFileAppender log4j.appender.HOST-MANAGER.File = ${catalina.base}/logs/host-manager log4j.appender.HOST-MANAGER.Append = true log4j.appender.HOST-MANAGER.Encoding = UTF-8 log4j.appender.HOST-MANAGER.DatePattern = '.'-MM-dd'.log' log4j.appender.HOST-MANAGER.layout = org.apache.log4j.PatternLayout log4j.appender.HOST-MANAGER.layout.ConversionPattern = %d [%t] %-5p %c- %m%n log4j.appender.CONSOLE = org.apache.log4j.ConsoleAppender log4j.appender.CONSOLE.Encoding = UTF-8 log4j.appender.CONSOLE.layout = org.apache.log4j.PatternLayout log4j.appender.CONSOLE.layout.ConversionPattern = %d [%t] %-5p %c- %m%n # Configure which loggers log to which appenders log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/cfcc] = INFO, CFCC log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost] = INFO, LOCALHOST log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager] =\ INFO, MANAGER log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager] =\ INFO, HOST-MANAGER # In order to prevent messages from being duplicated in the appenders the additivity flag is # needed to be set. What this does is prevent the child appenders from also sending their # messages to the parent appender which in our case is the CATALINA log. log4j.additivity.org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/cfcc] = FALSE log4j.additivity.org.apache.catalina.core.ContainerBase.[Catalina].[localhost] = FALSE Below this line is the Vendor's original one that was in the /classes directory ( I also removed their log4j-1.2.8-1.jar that was in the /lib directory folder as it was older than the one I was using that is log4j-1.2.17.jar): cfi.trace.dir=/usr/opt/vendor/mft/IS/logs/trace # Crystal Reports variables crystal.logs.home=${user.home} # Tradelink variables tradelink.logging.level=ERROR # HCF variables hcf.logging.level=ERROR # Optus variables optus.logging.level=ERROR # SSO variables sso.logging.level=ERROR # CFI variables cfi.struts.logging.level=ERROR # Set root logger level to ERROR and its only appender to stdout. log4j.ro
RE: Tomcat 7 Web Service Shutdown Can't Stop Threads
Here is the code to shut down the pools. When I was running a single pool the issue did not occur. It's when I added the second pool that the issue started. Arrays.asList(universalConnectionPoolManager.getConnectionPoolNames()) .forEach(poolName -> { try { universalConnectionPoolManager .destroyConnectionPool(poolName); } catch (Exception e) { exceptionHandler.handleError( e, String.join( ":", "Destroy Connection Pool Error", poolName)); } }); The jdbc driver and connection pool .jar files are in the tomcat lib folder and not in the applications lib folder. I never tried Tomcat's version of connection pooling. Thank you, Chris Brown Systems Consultant National Council on Compensation Insurance 901 Peninsula Corporate Circle Boca Raton, FL 33487-1362 (P) 561-893-2324 chris_br...@ncci.com -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Monday, March 07, 2016 10:33 AM To: Tomcat Users List Subject: Re: Tomcat 7 Web Service Shutdown Can't Stop Threads -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris, On 3/7/16 9:51 AM, Chris Brown wrote: > Tomcat is shutting down the web service when I deploy a new .war file. Okay. You said you were closing the connection pool, though: On 3/4/16 2:13 PM, Chris Brown wrote: > I added a ServletContextListener to our web service. On the > contextDestroyed method we destroy the connection pools. Our web > service uses 2 connection pools. So, how, precisely, are you shutting those pools down? > There is no documentation on the threads and what they are for in > oracle or tomcats documentation. Tomcat would not contain information on a Vendor's product. A quick Google search for "oracle ojdbc7 ucp-worker-thread" yields the following very relevant result: http://stackoverflow.com/questions/9671270/oracle-ucp-driver-and-tomcat- threads-failing-to-stop Also, searching for the OJDBC manual has a FAQ which mentions threads and their lifetimes: http://www.oracleimg.com/technetwork/articles/sql/jdbc-faq-090281.html > The threads are not shutting down and they stay alive when the web > service is shut down. I know this because I count the number of > threads each time the web service context is destroyed and number > keeps growing for each deployment of the .war file. Oh, I believe you that they are piling up. Is there a particular reason you are using Oracle's connection pool rather than the one provided by the container (Tomcat)? Tomcat's pool won't leak like this one does. Then again, the Oracle driver itself might still leak, but it will be less leaky. It's possible that the driver needs to be loaded before the application in order to avoid pinning the ClassLoader into memory. That can be done with Tomcat's configuration, but I'd only recommend that you do this if nothing else is working. I'd still like to know that those other threads (e.g. Thread-0) are doin g. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlbdnygACgkQ9CaO5/Lv0PCClgCfUmDNGz68sT6beiMOwx2Pkewb UGcAoJNpSVJ8wagZRiGZMS9LxO3g0KY9 =qWGg -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message may be an attorney-client communication and/or work product and as such is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.
Re: Tomcat 7 Web Service Shutdown Can't Stop Threads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris, On 3/7/16 9:51 AM, Chris Brown wrote: > Tomcat is shutting down the web service when I deploy a new .war > file. Okay. You said you were closing the connection pool, though: On 3/4/16 2:13 PM, Chris Brown wrote: > I added a ServletContextListener to our web service. On the > contextDestroyed method we destroy the connection pools. Our web > service uses 2 connection pools. So, how, precisely, are you shutting those pools down? > There is no documentation on the threads and what they are for in > oracle or tomcats documentation. Tomcat would not contain information on a Vendor's product. A quick Google search for "oracle ojdbc7 ucp-worker-thread" yields the following very relevant result: http://stackoverflow.com/questions/9671270/oracle-ucp-driver-and-tomcat- threads-failing-to-stop Also, searching for the OJDBC manual has a FAQ which mentions threads and their lifetimes: http://www.oracleimg.com/technetwork/articles/sql/jdbc-faq-090281.html > The threads are not shutting down and they stay alive when the web > service is shut down. I know this because I count the number of > threads each time the web service context is destroyed and number > keeps growing for each deployment of the .war file. Oh, I believe you that they are piling up. Is there a particular reason you are using Oracle's connection pool rather than the one provided by the container (Tomcat)? Tomcat's pool won't leak like this one does. Then again, the Oracle driver itself might still leak, but it will be less leaky. It's possible that the driver needs to be loaded before the application in order to avoid pinning the ClassLoader into memory. That can be done with Tomcat's configuration, but I'd only recommend that you do this if nothing else is working. I'd still like to know that those other threads (e.g. Thread-0) are doin g. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlbdnygACgkQ9CaO5/Lv0PCClgCfUmDNGz68sT6beiMOwx2Pkewb UGcAoJNpSVJ8wagZRiGZMS9LxO3g0KY9 =qWGg -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance regression from 7 to 8
Tullio, as suggested before by Felix, maybe you should try different connector configurations (defaults for HTTP connector are different between T7 (blocking) and T8 (non-blocking)) and see if this changes anything. For example in the server.xml file : and Your code is simple, only buffering and writing to an OutputStream. Don't know how, but I believe that only the buffering can introduce some delay. best regards 2016-03-07 15:43 GMT+01:00 Tullio Bettinazzi : > As I already explained is not a reproductable problem. > I tested the testcase in my environment and I reproduced the problem on > some clients but not on all clients : the same clients where I noticed the > problem in the real application. > I'm not able to understand what's the relevant difference among them (not > OS version, not network, not browser). > The problem disappears using tomcat 7. > Tks > Tullio > > > Subject: Re: Performance regression from 7 to 8 > > To: users@tomcat.apache.org > > From: ma...@apache.org > > Date: Mon, 7 Mar 2016 11:52:40 + > > > > On 06/03/2016 08:45, Tullio Bettinazzi wrote: > > > I tested with 8.20 and 8.32 > > > With nothing changed I meant simply that results didn't change. > > > > I can't repeat the problem you are describing with your provided test > case. > > > > I ran: > > - ab -k -n 1000 -c 1 localhost:8080/user002/Test > > - latest 8.0.x code > > - your test case with and without setting the content length (as an > > HTTP/1.0 client ab needs the content length to use keep-alive with > > large response bodies > > > > I saw average response times of 6ms with a maximum of 9ms. > > The content length header made no difference (apart from keep-alive > > being used as expected). > > > > If the problem you are describing was widespread I'd expect to see other > > users reporting this on the mailing list. > > > > Given that: > > - I can't repeat this > > - Other users aren't reporting it > > - Only you are seeing the issue > > > > this looks like an issue with your environment rather than with Tomcat. > > I'd recommend using tools like Wireshark and YourKit to find out exactly > > what is going on. > > > > Mark > > > > > > > Tks > > > Tullio > > > > > >> Subject: Re: Performance regression from 7 to 8 > > >> To: users@tomcat.apache.org > > >> From: ma...@apache.org > > >> Date: Sat, 5 Mar 2016 18:40:36 + > > >> > > >> On 04/03/2016 13:19, Tullio Bettinazzi wrote: > > >>> Done and nothing changed. > > >> > > >> What has changed is that you have now provided a test case that > someone > > >> else can run easily and confirm, or not, your findings. > > >> > > >>> Any suggestion ? > > >> > > >> Before anyone spends time looking at this the other question I don't > see > > >> answered in this thread is "Exactly which Tomcat 8 version were you > > >> testing?". If it isn't the the latest then you'll need to retest to > > >> confirm the issue hasn't already been fixed. > > >> > > >> Mark > > >> > > >>> Here the code. > > >>> > > >>> package axioma.rubik.engine.web.servlet; > > >>> > > >>> import java.io.*; > > >>> import javax.servlet.ServletException; > > >>> import javax.servlet.annotation.WebServlet; > > >>> import javax.servlet.http.*; > > >>> > > >>> @WebServlet(name="Test8", description="Direct update of data", > urlPatterns={"/Test8"}) > > >>> public class Test8Servlet extends HttpServlet { > > >>> > > >>> private static final long serialVersionUID = 1L; > > >>> > > >>> @Override > > >>> protected void doGet(HttpServletRequest request, > HttpServletResponse response) throws ServletException, IOException { > > >>> try { > > >>> fai(response); > > >>> } catch (Exception ex) { > > >>> ex.printStackTrace(); > > >>> } > > >>> } > > >>> > > >>> public void fai(HttpServletResponse response) throws IOException > { > > >>> ByteArrayOutputStream bbs = new ByteArrayOutputStream(); > > >>> BufferedOutputStream bos = new BufferedOutputStream(bbs); > > >>> for(int i = 0; i < 40; i++) { > > >>> bos.write(96); > > >>> } > > >>> bos.flush(); > > >>> bbs.writeTo(response.getOutputStream()); > > >>> } > > >>> } > > >> > > >> > > >> - > > >> 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: Tomcat 7 Web Service Shutdown Can't Stop Threads
Tomcat is shutting down the web service when I deploy a new .war file. There is no documentation on the threads and what they are for in oracle or tomcats documentation. The threads are not shutting down and they stay alive when the web service is shut down. I know this because I count the number of threads each time the web service context is destroyed and number keeps growing for each deployment of the .war file. Thank you, Chris Brown Systems Consultant National Council on Compensation Insurance 901 Peninsula Corporate Circle Boca Raton, FL 33487-1362 (P) 561-893-2324 chris_br...@ncci.com -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Monday, March 07, 2016 9:47 AM To: Tomcat Users List Subject: Re: Tomcat 7 Web Service Shutdown Can't Stop Threads -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris, On 3/7/16 8:26 AM, Chris Brown wrote: > The .jar comes with the Oracle 12c client. Oracle JDBC Drivers > release 12.1.0.2.0 Thanks. > I upgraded to tomcat 8. The latest stable version. The issue still > occurred, but the messages in the logs were "Warnings" > instead of being "SEVERE" errors. You said that. How about taking a thread dump after your web application stops, to see a few things: 1. Whether this is a spurious notification, since Tomcat was just going down faster than the threads were able to (gracefully) shut down 2. What those threads are doing, especially the ones with the somewhat anonymous names You haven't said how you were shutting-down the thread pool. You also haven't said whether you read any or Oracle's documentation about what those threads are doing or how they should be terminated. - -chris > -Original Message- From: Christopher Schultz > [mailto:ch...@christopherschultz.net] Sent: Friday, March 04, 2016 > 4:33 PM To: Tomcat Users List Subject: Re: Tomcat 7 Web Service > Shutdown Can't Stop Threads > > Chris, > > On 3/4/16 2:13 PM, Chris Brown wrote: >> Tomcat version: 7.0.42 Server OS: Sun Solaris UCP Version: Oracle 12c >> Oracle Driver: ojdbc7 > > That doesn't look like an Oracle JDBC driver version I've seen before. > Can you clarify? > >> JDK version: 1.8.0_31 > > You might want to upgrade Tomcat and Java. Those are somewhat old. > >> Issue Description: When tomcat shuts down our web service during a >> hot deployment threads are left running that tomcat cannot shutdown. >> I believe the threads are from the universal connection pool. We use >> oracle's universal connection pool (ucp.jar). After multiple >> deployments the threads build up and cause high CPU usage from the 2 >> tomcat threads. > >> Log Error Examples: Feb 08, 2016 8:00:25 PM >> org.apache.catalina.loader.WebappClassLoader >> clearReferencesThreads SEVERE: The web application [/RatingService] >> appears to have started a thread named [UCP-worker-thread-3] but has >> failed to stop it. This is very likely to create a memory leak. Feb >> 08, 2016 8:00:25 PM org.apache.catalina.loader.WebappClassLoader >> clearReferencesThreads SEVERE: The web application [/RatingService] >> appears to have started a thread named [Thread-438] but has failed to >> stop it. This is very likely to create a memory leak. Feb 27, 2016 >> 6:15:14 PM org.apache.catalina.loader.WebappClassLoader >> clearReferencesThreads SEVERE: The web application [/RatingService] >> appears to have started a thread named >> [oracle.jdbc.driver.BlockSource.ThreadedCachingBlockSource.BlockRelea s > >> er] >> but has failed to stop it. This is very likely to create a >> memory leak. Feb 27, 2016 6:15:14 PM >> org.apache.catalina.loader.WebappClassLoader >> clearReferencesThreads SEVERE: The web application >> [/RatingService] appears to have started a thread named >> [ForkJoinPool.commonPool-worker-32] but has failed to stop it. >> This is very likely to create a memory leak. Feb 27, 2016 6:15:14 >> PM org.apache.catalina.loader.WebappClassLoader >> clearReferencesThreads SEVERE: The web application >> [/RatingService] appears to have started a thread named >> [Timer-121] but has failed to stop it. This is very likely to >> create a memory leak. > >> Correction made to code to try and fix issue: I added a >> ServletContextListener to our web service. On the >> contextDestroyed method we destroy the connection pools. Our web >> service uses 2 connection pools. > > How exactly are you destroying the connection pools? > >> I also upgraded to Tomcat 8 and the issue still occurred, but >> the messages are now warnings instead of SEVERE errors. > > That's just an effect of Tomcat downgrading the log level under > which it logs those issues. > >> I've searched the web and have tried many suggestions that have >> not helped except destroying the connection pools, but the issue >> still occurs. Please help!!! > > After you get those messages in the log, if you do a thread dump on > the JVM, do you still see those threads running? > > Generally speaking, Tomcat should be able to s
Re: Tomcat 7 Web Service Shutdown Can't Stop Threads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris, On 3/7/16 8:26 AM, Chris Brown wrote: > The .jar comes with the Oracle 12c client. Oracle JDBC Drivers > release 12.1.0.2.0 Thanks. > I upgraded to tomcat 8. The latest stable version. The issue > still occurred, but the messages in the logs were "Warnings" > instead of being "SEVERE" errors. You said that. How about taking a thread dump after your web application stops, to see a few things: 1. Whether this is a spurious notification, since Tomcat was just going down faster than the threads were able to (gracefully) shut down 2. What those threads are doing, especially the ones with the somewhat anonymous names You haven't said how you were shutting-down the thread pool. You also haven't said whether you read any or Oracle's documentation about what those threads are doing or how they should be terminated. - -chris > -Original Message- From: Christopher Schultz > [mailto:ch...@christopherschultz.net] Sent: Friday, March 04, 2016 > 4:33 PM To: Tomcat Users List Subject: Re: Tomcat 7 Web Service > Shutdown Can't Stop Threads > > Chris, > > On 3/4/16 2:13 PM, Chris Brown wrote: >> Tomcat version: 7.0.42 Server OS: Sun Solaris UCP Version: Oracle >> 12c Oracle Driver: ojdbc7 > > That doesn't look like an Oracle JDBC driver version I've seen > before. Can you clarify? > >> JDK version: 1.8.0_31 > > You might want to upgrade Tomcat and Java. Those are somewhat old. > >> Issue Description: When tomcat shuts down our web service during >> a hot deployment threads are left running that tomcat cannot >> shutdown. I believe the threads are from the universal connection >> pool. We use oracle's universal connection pool (ucp.jar). After >> multiple deployments the threads build up and cause high CPU >> usage from the 2 tomcat threads. > >> Log Error Examples: Feb 08, 2016 8:00:25 PM >> org.apache.catalina.loader.WebappClassLoader >> clearReferencesThreads SEVERE: The web application >> [/RatingService] appears to have started a thread named >> [UCP-worker-thread-3] but has failed to stop it. This is very >> likely to create a memory leak. Feb 08, 2016 8:00:25 PM >> org.apache.catalina.loader.WebappClassLoader >> clearReferencesThreads SEVERE: The web application >> [/RatingService] appears to have started a thread named >> [Thread-438] but has failed to stop it. This is very likely to >> create a memory leak. Feb 27, 2016 6:15:14 PM >> org.apache.catalina.loader.WebappClassLoader >> clearReferencesThreads SEVERE: The web application >> [/RatingService] appears to have started a thread named >> [oracle.jdbc.driver.BlockSource.ThreadedCachingBlockSource.BlockRelea s > >> er] >> but has failed to stop it. This is very likely to create a >> memory leak. Feb 27, 2016 6:15:14 PM >> org.apache.catalina.loader.WebappClassLoader >> clearReferencesThreads SEVERE: The web application >> [/RatingService] appears to have started a thread named >> [ForkJoinPool.commonPool-worker-32] but has failed to stop it. >> This is very likely to create a memory leak. Feb 27, 2016 6:15:14 >> PM org.apache.catalina.loader.WebappClassLoader >> clearReferencesThreads SEVERE: The web application >> [/RatingService] appears to have started a thread named >> [Timer-121] but has failed to stop it. This is very likely to >> create a memory leak. > >> Correction made to code to try and fix issue: I added a >> ServletContextListener to our web service. On the >> contextDestroyed method we destroy the connection pools. Our web >> service uses 2 connection pools. > > How exactly are you destroying the connection pools? > >> I also upgraded to Tomcat 8 and the issue still occurred, but >> the messages are now warnings instead of SEVERE errors. > > That's just an effect of Tomcat downgrading the log level under > which it logs those issues. > >> I've searched the web and have tried many suggestions that have >> not helped except destroying the connection pools, but the issue >> still occurs. Please help!!! > > After you get those messages in the log, if you do a thread dump on > the JVM, do you still see those threads running? > > Generally speaking, Tomcat should be able to shut down even with > the above errors. Hopefully, none of those threads are non-daemon > threads, meaning that they shouldn't stop the JVM from stopping > once the JVM's main thread terminates. If your web application > leaves those threads running after deployment, then multiple > re-deployments without a Tomcat/JVM restart will likely result in a > large memory leak. (Those threads will pin the web application's > ClassLoader in memory along with all the classes it ever loaded, > and these will pile-up until you have exhausted your permgen or > other heap spaces). > >> [UCP-worker-thread-3] > > This is almost certainly something form Oracle's UCP > >> [Thread-438] > > This could be anything. A thread dump could tell you what it might > be. > > > [oracle.jdbc.driver.BlockSource
RE: Performance regression from 7 to 8
As I already explained is not a reproductable problem. I tested the testcase in my environment and I reproduced the problem on some clients but not on all clients : the same clients where I noticed the problem in the real application. I'm not able to understand what's the relevant difference among them (not OS version, not network, not browser). The problem disappears using tomcat 7. Tks Tullio > Subject: Re: Performance regression from 7 to 8 > To: users@tomcat.apache.org > From: ma...@apache.org > Date: Mon, 7 Mar 2016 11:52:40 + > > On 06/03/2016 08:45, Tullio Bettinazzi wrote: > > I tested with 8.20 and 8.32 > > With nothing changed I meant simply that results didn't change. > > I can't repeat the problem you are describing with your provided test case. > > I ran: > - ab -k -n 1000 -c 1 localhost:8080/user002/Test > - latest 8.0.x code > - your test case with and without setting the content length (as an > HTTP/1.0 client ab needs the content length to use keep-alive with > large response bodies > > I saw average response times of 6ms with a maximum of 9ms. > The content length header made no difference (apart from keep-alive > being used as expected). > > If the problem you are describing was widespread I'd expect to see other > users reporting this on the mailing list. > > Given that: > - I can't repeat this > - Other users aren't reporting it > - Only you are seeing the issue > > this looks like an issue with your environment rather than with Tomcat. > I'd recommend using tools like Wireshark and YourKit to find out exactly > what is going on. > > Mark > > > > Tks > > Tullio > > > >> Subject: Re: Performance regression from 7 to 8 > >> To: users@tomcat.apache.org > >> From: ma...@apache.org > >> Date: Sat, 5 Mar 2016 18:40:36 + > >> > >> On 04/03/2016 13:19, Tullio Bettinazzi wrote: > >>> Done and nothing changed. > >> > >> What has changed is that you have now provided a test case that someone > >> else can run easily and confirm, or not, your findings. > >> > >>> Any suggestion ? > >> > >> Before anyone spends time looking at this the other question I don't see > >> answered in this thread is "Exactly which Tomcat 8 version were you > >> testing?". If it isn't the the latest then you'll need to retest to > >> confirm the issue hasn't already been fixed. > >> > >> Mark > >> > >>> Here the code. > >>> > >>> package axioma.rubik.engine.web.servlet; > >>> > >>> import java.io.*; > >>> import javax.servlet.ServletException; > >>> import javax.servlet.annotation.WebServlet; > >>> import javax.servlet.http.*; > >>> > >>> @WebServlet(name="Test8", description="Direct update of data", > >>> urlPatterns={"/Test8"}) > >>> public class Test8Servlet extends HttpServlet { > >>> > >>> private static final long serialVersionUID = 1L; > >>> > >>> @Override > >>> protected void doGet(HttpServletRequest request, HttpServletResponse > >>> response) throws ServletException, IOException { > >>> try { > >>> fai(response); > >>> } catch (Exception ex) { > >>> ex.printStackTrace(); > >>> } > >>> } > >>> > >>> public void fai(HttpServletResponse response) throws IOException { > >>> ByteArrayOutputStream bbs = new ByteArrayOutputStream(); > >>> BufferedOutputStream bos = new BufferedOutputStream(bbs); > >>> for(int i = 0; i < 40; i++) { > >>> bos.write(96); > >>> } > >>> bos.flush(); > >>> bbs.writeTo(response.getOutputStream()); > >>> } > >>> } > >> > >> > >> - > >> 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: Tomcat 7 Web Service Shutdown Can't Stop Threads
The .jar comes with the Oracle 12c client. Oracle JDBC Drivers release 12.1.0.2.0 I upgraded to tomcat 8. The latest stable version. The issue still occurred, but the messages in the logs were "Warnings" instead of being "SEVERE" errors. Thank you, Chris Brown Systems Consultant National Council on Compensation Insurance 901 Peninsula Corporate Circle Boca Raton, FL 33487-1362 (P) 561-893-2324 chris_br...@ncci.com -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Friday, March 04, 2016 4:33 PM To: Tomcat Users List Subject: Re: Tomcat 7 Web Service Shutdown Can't Stop Threads -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris, On 3/4/16 2:13 PM, Chris Brown wrote: > Tomcat version: 7.0.42 Server OS: Sun Solaris UCP Version: Oracle 12c > Oracle Driver: ojdbc7 That doesn't look like an Oracle JDBC driver version I've seen before. Can you clarify? > JDK version: 1.8.0_31 You might want to upgrade Tomcat and Java. Those are somewhat old. > Issue Description: When tomcat shuts down our web service during a hot > deployment threads are left running that tomcat cannot shutdown. I > believe the threads are from the universal connection pool. We use > oracle's universal connection pool (ucp.jar). After multiple > deployments the threads build up and cause high CPU usage from the 2 > tomcat threads. > > Log Error Examples: Feb 08, 2016 8:00:25 PM > org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads SEVERE: The web application [/RatingService] > appears to have started a thread named [UCP-worker-thread-3] but has > failed to stop it. This is very likely to create a memory leak. Feb > 08, 2016 8:00:25 PM org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads SEVERE: The web application [/RatingService] > appears to have started a thread named [Thread-438] but has failed to > stop it. This is very likely to create a memory leak. Feb 27, > 2016 6:15:14 PM org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads SEVERE: The web application [/RatingService] > appears to have started a thread named > [oracle.jdbc.driver.BlockSource.ThreadedCachingBlockSource.BlockReleas er] > but has failed to stop it. This is very likely to create a memory > leak. Feb 27, 2016 6:15:14 PM > org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads SEVERE: The web application [/RatingService] > appears to have started a thread named > [ForkJoinPool.commonPool-worker-32] but has failed to stop it. This is > very likely to create a memory leak. Feb 27, 2016 6:15:14 PM > org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads SEVERE: The web application [/RatingService] > appears to have started a thread named [Timer-121] but has failed to > stop it. This is very likely to create a memory leak. > > Correction made to code to try and fix issue: I added a > ServletContextListener to our web service. On the contextDestroyed > method we destroy the connection pools. Our web service uses 2 > connection pools. How exactly are you destroying the connection pools? > I also upgraded to Tomcat 8 and the issue still occurred, but the > messages are now warnings instead of SEVERE errors. That's just an effect of Tomcat downgrading the log level under which it logs those issues. > I've searched the web and have tried many suggestions that have not > helped except destroying the connection pools, but the issue still > occurs. Please help!!! After you get those messages in the log, if you do a thread dump on the JVM, do you still see those threads running? Generally speaking, Tomcat should be able to shut down even with the above errors. Hopefully, none of those threads are non-daemon threads, meaning that they shouldn't stop the JVM from stopping once the JVM's main thread terminates. If your web application leaves those threads running after deployment, then multiple re-deployments without a Tomcat/JVM restart will likely result in a large memory leak. (Those threads will pin the web application's ClassLoader in memory along with all the classes it ever loaded, and these will pile-up until you have exhausted your permgen or other heap spaces). > [UCP-worker-thread-3] This is almost certainly something form Oracle's UCP > [Thread-438] This could be anything. A thread dump could tell you what it might be. > [oracle.jdbc.driver.BlockSource.ThreadedCachingBlockSource.BlockReleaser ] Obviously, this is a thread from Oracle's JDBC driver. > [ForkJoinPool.commonPool-worker-32] Maybe something from UCP? Not sure. > [Timer-121] This is usually a thread started by TimerTask, a stock Java class. But any component may have created this thread. It might be worth searching your own code to see if a TimerTask is being launched and never shut-down when your web application is shutting down. Make arrangements to make sure that you shut these down when the application is going out of service. For the Oracle-s
Re: Performance regression from 7 to 8
On 06/03/2016 08:45, Tullio Bettinazzi wrote: > I tested with 8.20 and 8.32 > With nothing changed I meant simply that results didn't change. I can't repeat the problem you are describing with your provided test case. I ran: - ab -k -n 1000 -c 1 localhost:8080/user002/Test - latest 8.0.x code - your test case with and without setting the content length (as an HTTP/1.0 client ab needs the content length to use keep-alive with large response bodies I saw average response times of 6ms with a maximum of 9ms. The content length header made no difference (apart from keep-alive being used as expected). If the problem you are describing was widespread I'd expect to see other users reporting this on the mailing list. Given that: - I can't repeat this - Other users aren't reporting it - Only you are seeing the issue this looks like an issue with your environment rather than with Tomcat. I'd recommend using tools like Wireshark and YourKit to find out exactly what is going on. Mark > Tks > Tullio > >> Subject: Re: Performance regression from 7 to 8 >> To: users@tomcat.apache.org >> From: ma...@apache.org >> Date: Sat, 5 Mar 2016 18:40:36 + >> >> On 04/03/2016 13:19, Tullio Bettinazzi wrote: >>> Done and nothing changed. >> >> What has changed is that you have now provided a test case that someone >> else can run easily and confirm, or not, your findings. >> >>> Any suggestion ? >> >> Before anyone spends time looking at this the other question I don't see >> answered in this thread is "Exactly which Tomcat 8 version were you >> testing?". If it isn't the the latest then you'll need to retest to >> confirm the issue hasn't already been fixed. >> >> Mark >> >>> Here the code. >>> >>> package axioma.rubik.engine.web.servlet; >>> >>> import java.io.*; >>> import javax.servlet.ServletException; >>> import javax.servlet.annotation.WebServlet; >>> import javax.servlet.http.*; >>> >>> @WebServlet(name="Test8", description="Direct update of data", >>> urlPatterns={"/Test8"}) >>> public class Test8Servlet extends HttpServlet { >>> >>> private static final long serialVersionUID = 1L; >>> >>> @Override >>> protected void doGet(HttpServletRequest request, HttpServletResponse >>> response) throws ServletException, IOException { >>> try { >>> fai(response); >>> } catch (Exception ex) { >>> ex.printStackTrace(); >>> } >>> } >>> >>> public void fai(HttpServletResponse response) throws IOException { >>> ByteArrayOutputStream bbs = new ByteArrayOutputStream(); >>> BufferedOutputStream bos = new BufferedOutputStream(bbs); >>> for(int i = 0; i < 40; i++) { >>> bos.write(96); >>> } >>> bos.flush(); >>> bbs.writeTo(response.getOutputStream()); >>> } >>> } >> >> >> - >> 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: Windows Authentication
On 07.03.2016 11:39, André Warnier (tomcat) wrote: On 07.03.2016 06:10, Chanchal Kariwala wrote: The article which suggested that NTLM is being used by Winlogon instead of Kerberos : http://stackoverflow.com/questions/5597573/how-to-find-if-ntlm-or-kerberos-is-used-from-www-authenticate-negotiate-header So the token browser sends on first 401 starts from YHkG... And the second token begins with YIIK1QYG Check also this one : https://blogs.msdn.microsoft.com/friis/2009/12/31/things-to-check-when-kerberos-authentication-fails-using-iisie/ As you see, there are a lot of things to check, one by one. That is because WIA (and Kerberos) are very fiddly, and even one little setting or circumstance can result in the thing not working (as in your case). P.S. The mere volume of articles on this subject in Google (e.g. "kerberos and wia" or "kerberos and IE") 1) by itself makes it difficult to know which one to read and believe 2) indicates that this is a complex subject, with which a lot of people have problems This list here is about Tomcat issues. There is an SPNEGO authentication Valve in Tomcat, and there are certainly some people on this list with some knowledge of WIA/Kerberos, but such issues are probably not their main focus, or their main area of expertise. You may have a bit more luck (or at least find more people focused on Windows authentication) on the Samba list for example. Maybe try here : https://lists.samba.org/mailman/listinfo/samba and supply all your previous information again, including the captured headers. That would definitely increase your chances of receiving a helpful response. It is not that we don't /want/ to help, but there are just too many external factors and settings which can play a role, that it is a bit overwhelming to try this one step remote from the problem. If you do in the end identify a specific problem with the Tomcat SPNEGO Valve, don't hesitate to come back and ask for help here again. Also, if you do find the solution, please post a short message to this list, so that maybe other people here with a similar issue could in the future find the solution in the list archives. (I presume you have already searched these archives for similar issues ?) Another thing, at a different level : if your main aim is to solve this issue quickly, then have a look at Jespa (https://www.ioplex.com/). I can testify that Jespa works fautlessly in several installations which I did. And just reading the User Manual may already give you some useful tips. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 7.0.63 - socketBuffer "-1" - linux platform behaviour
Hi, I have implemented a service using Http11Protocol and I have disabled the socketBuffer for the object by setting its value to "-1". When the client disconnects before the server responds, then on windows I see the exception: SEVERE: Error processing request java.net.SocketException: Unrecognized Windows Sockets error: 0: socket write er ror at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:125) at java.net.SocketOutputStream.write(SocketOutputStream.java:171) at org.apache.coyote.http11.InternalOutputBuffer$OutputStreamOutputBuffe r.doWrite(InternalOutputBuffer.java:243) at org.apache.coyote.http11.filters.IdentityOutputFilter.doWrite(Identit yOutputFilter.java:84) at org.apache.coyote.http11.AbstractOutputBuffer.doWrite(AbstractOutputB uffer.java:192) at org.apache.coyote.Response.doWrite(Response.java:499) at dummyAdapter.service(dummyAdapter.java:49) But on linux, I don't see any exception raised. The source code and jar file - To execute the code run: java TomcatCipherTst This will start the listener on port 7677 and wait for client to connect. The server responds only after 60 seconds. So, to recreate the client needs to disconnect before 60 seconds. I am looking for help to understand why there is no exception raised on linux when the client disconnects before server responds unlike that on windows. Thanks, Rashmi - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Fw: Tomcat 7.0.63 - socketBuffer "-1" - linux platform behaviour
Hi, I have implemented a service using Http11Protocol and I have disabled the socketBuffer for the object by setting its value to "-1". When the client disconnects before the server responds, then on windows I see the exception: SEVERE: Error processing request java.net.SocketException: Unrecognized Windows Sockets error: 0: socket write er ror at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:125) at java.net.SocketOutputStream.write(SocketOutputStream.java:171) at org.apache.coyote.http11.InternalOutputBuffer$OutputStreamOutputBuffe r.doWrite(InternalOutputBuffer.java:243) at org.apache.coyote.http11.filters.IdentityOutputFilter.doWrite(Identit yOutputFilter.java:84) at org.apache.coyote.http11.AbstractOutputBuffer.doWrite(AbstractOutputB uffer.java:192) at org.apache.coyote.Response.doWrite(Response.java:499) at dummyAdapter.service(dummyAdapter.java:49) But on linux, I don't see any exception raised. The source code and jar file - To execute the code run: java TomcatCipherTst This will start the listener on port 7677 and wait for client to connect. The server responds only after 60 seconds. So, to recreate the client needs to disconnect before 60 seconds. I am looking for help to understand why there is no exception raised on linux when the client disconnects before server responds unlike that on windows. Thanks, Rashmi - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Authentication
On 07.03.2016 06:10, Chanchal Kariwala wrote: The article which suggested that NTLM is being used by Winlogon instead of Kerberos : http://stackoverflow.com/questions/5597573/how-to-find-if-ntlm-or-kerberos-is-used-from-www-authenticate-negotiate-header So the token browser sends on first 401 starts from YHkG... And the second token begins with YIIK1QYG Check also this one : https://blogs.msdn.microsoft.com/friis/2009/12/31/things-to-check-when-kerberos-authentication-fails-using-iisie/ Thanks, Chanchal R. Kariwala Product Engineer Seclore Technology chanchal.kariw...@seclore.com www.seclore.com On Mon, Mar 7, 2016 at 10:19 AM, Chanchal Kariwala < chanchal.kariw...@seclore.com> wrote: In response to *George Stanchev*, I tried with Chrome and IE 11, same behavior in both. And yes I tried waffle, but in another webapp. Waffle does not prompt for the credentials.. In response to *André Warnier*, I tired that to no avail :( In response to *Felix Schumacher*, It is not a problem with the webapp. I have tried both of what you asked. Tomcat Keytab is authenticated successfully. And KRB debug shows success for the keytab. So here are my additional findings over the weekend. Background - My test AD is virtual. My Domain Controller and client are VMS. 1. *Windows Logon was using NTLM instead of Kerberos* Some article led me to the following assumption : When the browser receives WWW-Authenticate: Negotiate, it asks for the token from the OS Cache. The OS Cache provides it a token that was obtained via NTLM. The Server does not accept that since it specifically wants Kerberos. And hence the browser asks for Credentials again and this time the user is authenticated via Kerberos. And this token is accepted by the Server. 2. *Windows Logon by IP Address uses NTLM* I access the client machine (with tomcat) using RDP via the IP Address. The following question on StackExchange indicates that in such a scenario NTLM is used to logon to the system. See : http://serverfault.com/questions/357975/is-it-possible-to-switch-to-kerberos-only-windows-domain 3. *Kerberos Event Logging* The next thing I was trying to figure was why Windows logon was using NTLM. The above link suggests that there was no way of forcing LSA to use Kerberos only. So now I am looking at the System events, which might suggest which protocol is being used. Also I enabled Kerberos event logging to see if there were any Kerberos Errors. See : https://support.microsoft.com/en-us/kb/262177 Thanks, Chanchal R. Kariwala Product Engineer Seclore Technology chanchal.kariw...@seclore.com www.seclore.com On Sat, Mar 5, 2016 at 3:57 PM, Felix Schumacher < felix.schumac...@internetallee.de> wrote: Am 04.03.2016 um 10:11 schrieb Chanchal Kariwala: I tries what you asked and I have observed the following 1. Browser sends a request for the resource Server replies with HTTP 401 and WWW-Authenticate: Negotiate in Response Headers 2. Browser sends a new request with the following in Request Headers Authorization: Negotiate YHkGBisGAQUFAqBvMG2gMDAuBgorBg Server replies again with HTTP 401 and WWW-Authenticate: Negotiate in Response Headers 3. At this point the browser shows HTTP Basic Auth form and sends the following in Headers Authorization: Negotiate YIIK1QYGKwYBBQUCoIIKyTCCCsWgMDAuBgkqhkiC9xIBAgIGCSqGS (*Really huge value, much much longer than the first one*) Now the Server replies with HTTP 200 and the following in headers WWW-Authenticate: Negotiate oYHzMIHwoAMKAQChCwYJKoZIhvcSAQICom0 Set-Cookie: JSESSIONID=541FE2EDD35690BBDE99..; Path=/webapp/; HttpOnly So yes WIA is failing.. Can you help me out with the next step in debugging? You can enable debugging for kerberos in the jvm and you can enable debug logs for the SpnegoAuthenticator in tomcat to get more information. To enable debug log messages in the jvm add -Dsun.security.krb5.debug=true to CATALINA_OPTS. The log messages will appear in catalina.out and are quite verbose. To enable debug log messages for SpnegoAuthenticator, add org.apache.catalina.authenticator.SpnegoAuthenticator.level = FINE to conf/logging.properties in your CATALINA_BASE directory. Regards, Felix Thanks, Chanchal R. Kariwala Product Engineer Seclore Technology chanchal.kariw...@seclore.com www.seclore.com On Fri, Mar 4, 2016 at 1:20 PM, André Warnier (tomcat) wrote: On 04.03.2016 07:16, Chanchal Kariwala wrote: I am using Tomcat 8.0.32 and I have followed the guide given at - https://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html#Tomcat_instance_(Windows_server) - https://dzone.com/articles/do-not-publish-configuring-tomcat-single-sign-on-w Windows AD Auth is working i.e. when I access the site, I am asked for credentials and when I enter the correct credentials, the restricted resource is displayed. However my question is why the browser is asking for credentials? Why isn't it accessing TGT Cache in the OS to fetch the user's