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

[Caldarale, Charles R]

> 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

[Junqiang Zhang]

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

[Sean Dawson]

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 

Re: Question about your recent security (CVE-2015-5345) fix in 7.0.68 build

[Harish Krishnan]

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

[Sean Dawson]

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 

Re: Warning response header

[Mark Eggers]

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.

. . . 

Re: Warning response header

[Sean Dawson]

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 

Re: Warning response header

[David Kerber]

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

[Mark Eggers]

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

Re: Warning response header

[Sean Dawson]

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

[Chris Gamache]

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

[Joleen Barker]

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'
>>> 

Re: Question about your recent security (CVE-2015-5345) fix in 7.0.68 build

[Mark Thomas]

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

[Harish Krishnan]

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

[Joleen Barker]

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
>> 

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

[Caldarale, Charles R]

> 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

[Chris Gamache]

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

[Violeta Georgieva]

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

[Joleen Barker]

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 

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]

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

[Joleen Barker]

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.

RE: Tomcat 7 Web Service Shutdown Can't Stop Threads

[Chris Brown]

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

[Christopher Schultz]

-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

[Aurélien Terrestris]

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

[Chris Brown]

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 

Re: Tomcat 7 Web Service Shutdown Can't Stop Threads

[Christopher Schultz]

-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.
> 
> 
> 

RE: Performance regression from 7 to 8

[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

[Chris Brown]

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 

Re: Performance regression from 7 to 8

[Mark Thomas]

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

[tomcat]

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

[Rashmi R Katagall]

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

[Rashmi R Katagall]

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

[tomcat]

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