Re: Adding a custom configurations file globally and at web-app level for Apache Tomcat

[Chiranga Alwis]

Hi Chris,

yeah as you said a decision was made to separate out properties which can
be defined only at global level in one file reminiscent to Tomcat's
server.xml and a web app descriptor file which can be defined at global
level and can also be overridden at context level reminiscent to web.xml of
Tomcat.

I am using LifeCycleListeners to load configurations and anyone using the
configurations in valves will be able to load them using
ValveBase.initInternal() method.

On Sat, Feb 20, 2016 at 8:23 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Chiranga,
>
> On 2/12/16 1:27 AM, Chiranga Alwis wrote:
> > There are some custom configurations which we intend to add to this
> config
> > file. We have a custom made single-sign-on valve based on SAML 2.0 which
> > has plenty of configuration properties plus there are some custom
> > classloading code which I am not that entirely proficient about.
> >
> > We intend to separate out these from default Tomcat configs in web.xml
> and
> > improve the users' usability.
>
> How does introducing a new type of global configuration file improve
> users' usability?
>
> -chris
>
> > On Thu, Feb 11, 2016 at 10:53 PM, Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Chiranga,
> >
> > On 2/11/16 6:45 AM, Chiranga Alwis wrote:
>  Hi,
> 
>  I have been working on adding a custom configurations file which
>  follow a pattern similar to the web.xml, i.e. the file can be
>  defined globally but several predefined configuration properties
>  can be overridden at web-app level.
> 
>  For this purpose, my initial plan was to load the content in global
>  level file by implementing the LifeCycleListener interface and in
>  the case of a web-app or context use a ServletContextListener.
> 
>  Is this the most appropriate procedure to achieve this or is it an
>  incorrect approach?
> >
> > Can you explain how this is different from what is possible using
> > conf/web.xml and conf/context.xml for site-wide defaults?
> >
> > -chris
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

RE: Tomcat memory

[Gokul . Baskaran]

Andre,

Thanks for getting granular. Let me explain to the items which could have 
sounded to be confusing..

The JVM in discussion is Oracle JVM.

OS is the 64bit Windows 2012. - OS has 6GB - OS should not impose a limit on 
memory (Only in this specific case, as OS is 64bit and total amount of memory 
available is 6GB) unless the memory consumption by other processes does not get 
impacted or grows near 5GB - 6GB limit.

>From my earlier posts ---

i. It is a Tomcat / Application question as well, as memory default can 
be configured in the application config. - Big typo error, it should have been 
Cannot be configured.
ii. Thanks again, to make things clear. When I meant default, what is 
the default min and max that is given to an application if there nothing 
defined in the JVM ? - I meant the JVM heap memory   given to the 
application, which is configured in the tomcat instance.
 
With respect to the Oracle documentation, if the -Xms and Xmx are not set. The 
max will be set to 1/4th which is around 1.5GB of 6 GB   .

To your point on "There is no Tomcat-Level configuration option" - If I have 2 
tomcat instance on the same OS (Tomcat 1 and Tomcat 2). I can define Xms and 
Xmx in catalina.sh or setenv.sh in each of the tomcat instances. For example, 
if Tomcat 1 is configured to have 1GB, JVM heap size for Tomcat 1 will have 1GB 
and if Tomcat 2 is configured to 2 GB, then JVM heap size for Tomcat 2 will get 
2GB.

Yes, it is clear and thanks for explaining.

-Gokul


-Original Message-
From: André Warnier (tomcat) [mailto:a...@ice-sa.com] 
Sent: Monday, February 22, 2016 8:37 AM
To: users@tomcat.apache.org
Subject: Re: Tomcat memory

On 22.02.2016 13:02, Gokul.Baskaran wrote:
> The answer I expected is the JVM grows as much as to the available system 
> memory of there are m min and max set.
>

Gokul,

Well, no.

And because these messages get archived and searched later by other people, 
they may get the wrong conclusion and therefore I will try again.

Re-read your last question.
And then re-read your question before that one.
And then re-read your question before that one.

The problem here is not that you are not being given the information that you 
want.
The problem is that each time you ask your question, you ask it in a different 
way, and each time somehow in a way that confuses people as to what exactly you 
want to know.
And the reason why it is confusing is that in your succesive questions you keep 
on talking about "application memory" in various ways, but it is not clear what 
you are referring to as "application".
For the OS, the JVM is an application.
For the JVM, Tomcat is the application.
And for Tomcat, the web applications (webapps) are the applications.

The JVM is one process that is running on a machine, under an OS.
That OS probably imposes limits on how much resources (including memory) a 
given process is allowed to use.  If a process tries to use more than this, it 
will be killed with an "out of memory" error.  It is unlikely that this 
per-process limit is "the available system memory". The OS will kill the 
process before it uses all of that.

The JVM itself (of which there are various models on the market) uses memory in 
various ways, for various purposes.  One of these purposes is to manage a Heap, 
which it makes available to Java applications which run inside the JVM.
But the JVM also uses memory for other reasons, such as a stack, and for the 
code of the JVM itself.

For any given JVM, there are (probably) parameters which tell the JVM how much 
memory it should set aside initially for the Heap, and then also for how big it 
should let the Heap grow as a maximum.  For the Oracle JVMs, these parameters 
are "-Xms" and "-Xmx".
By default (if these parameters are not set), the JVM uses some default values, 
which /vary/ depending on the specific JVM and on the circumstances under which 
it is running (the total available machine memory, for example).
For the Oracle JVM, someone already quoted to you the relevant documentation.
For other JVM's, you need to look at the relevant JVM documentation.
(You never indicated which JVM you are using).

The JVM runs java applications (of which Tomcat - the whole Tomcat - is one).  
These Java applications cannot set the amount of memory that they will use in 
the Heap of the JVM, other than indirectly (if they are well-written, the 
minimum necessary; if they are not well-written, who knows).  There is no 
Tomcat-level configuration option, that allows one to set how much Heap space 
Tomcat can use within the JVM Heap.

Then within Tomcat, there are "web applications" running.  Individual web 
applications also cannot set how much Heap they will use, because is not 
"their" Heap, it is the "Tomcat Heap", which itself is not really the Tomcat 
Heap, it is the JVM's Heap.
That Heap is used by /all/ web applications at the same time.
(That is a bit of an approximation, but ultimately it boils 

Re: tomcat7 installs to connect to ipv6:::8080 on Ubuntu 14.04

[Christoph P.U. Kukulies]

Being at the problem again since I would like to run haproxy against 
tomcat7.


Here are my connectors:








I added the address entry on each connector to no avail:

# netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address   Foreign Address State
tcp0  0 0.0.0.0:21 0.0.0.0:*   LISTEN
tcp0  0 0.0.0.0:22 0.0.0.0:*   LISTEN
tcp0  0 0.0.0.0:25 0.0.0.0:*   LISTEN
tcp0  0 0.0.0.0:36762 0.0.0.0:*   LISTEN
tcp0  0 127.0.0.1:6 0.0.0.0:*   LISTEN
tcp0  0 0.0.0.0:2049 0.0.0.0:*   LISTEN
tcp0  0 0.0.0.0:993 0.0.0.0:*   LISTEN
tcp0  0 127.0.0.1:10024 0.0.0.0:*   LISTEN
tcp0  0 127.0.0.1:10025 0.0.0.0:*   LISTEN
tcp0  0 127.0.0.1:3306 0.0.0.0:*   LISTEN
tcp0  0 0.0.0.0:587 0.0.0.0:*   LISTEN
tcp0  0 0.0.0.0:48397 0.0.0.0:*   LISTEN
tcp0  0 127.0.0.1:783 0.0.0.0:*   LISTEN
tcp0  0 0.0.0.0:143 0.0.0.0:*   LISTEN
tcp0  0 0.0.0.0:111 0.0.0.0:*   LISTEN
tcp0  0 0.0.0.0:53264 0.0.0.0:*   LISTEN
tcp0  0 0.0.0.0:80 0.0.0.0:*   LISTEN
tcp0  0 0.0.0.0:41584 0.0.0.0:*   LISTEN
tcp0  0 0.0.0.0:38836 0.0.0.0:*   LISTEN
tcp0  0 127.0.0.1:3306 127.0.0.1:39401 ESTABLISHED
tcp0  0 79.80.81.82:993 73.74.75.76:4849   ESTABLISHED
tcp0  0 79.80.81.82:993 73.74.75.76:4867   ESTABLISHED
tcp0  0 79.80.81.82:22 73.74.75.76:4491   ESTABLISHED
tcp0  0 79.80.81.82:993 73.74.75.76:4870   ESTABLISHED
tcp0  0 79.80.81.82:993 73.74.75.76:4854   ESTABLISHED
tcp0  0 79.80.81.82:993 73.74.75.76:4873   ESTABLISHED
tcp0  0 79.80.81.82:993 73.74.75.76:4869   ESTABLISHED
tcp0  0 79.80.81.82:993 73.74.75.76:4868   ESTABLISHED
tcp6   0  0 :::8085 :::*LISTEN
tcp6   0  0 :::8086 :::*LISTEN
tcp6   0  0 :::22 :::*LISTEN
tcp6   0  0 :::25 :::*LISTEN
tcp6   0  0 :::44001 :::*LISTEN
tcp6   0  0 :::2049 :::*LISTEN
tcp6   0  0 :::993 :::*LISTEN
tcp6   0  0 127.0.0.1:8005 :::*LISTEN
tcp6   0  0 :::42696 :::*LISTEN
tcp6   0  0 :::59018 :::*LISTEN
tcp6   0  0 :::587 :::*LISTEN
tcp6   0  0 :::57999 :::*LISTEN
tcp6   0  0 :::143 :::*LISTEN
tcp6   0  0 :::111 :::*LISTEN
tcp6   0  0 :::8080 :::*LISTEN
tcp6   0  0 :::8081 :::*LISTEN
tcp6   0  0 :::8082 :::*LISTEN
tcp6   0  0 :::8083 :::*LISTEN
tcp6   0  0 :::51795 :::*LISTEN
tcp6   0  0 127.0.0.1:39401 127.0.0.1:3306  ESTABLISHED

--
Christoph

Am 01.12.2015 um 20:12 schrieb Christopher Schultz:

Christoph,

On 12/1/15 12:49 PM, Christoph P.U. Kukulies wrote:

it is (was) in server.xml: (I now only have tomcat listening on port
8009 proxy_ajp)



I then did a
service tomcat7 restart
netstat -an | grep 8080


and saw tcp6 still listed and no tcp

Now it look like this: (after enabling ipv6 in sysctl.conf again):

tcp0  0 127.0.0.1:49393 127.0.0.1:8009  ESTABLISHED
tcp0  0 127.0.0.1:49395 127.0.0.1:8009  ESTABLISHED
tcp6   0  0 :::8009 :::*LISTEN
tcp6   0  0 127.0.0.1:8009 127.0.0.1:49395 ESTABLISHED
tcp6   0  0 127.0.0.1:8009 127.0.0.1:49393 ESTABLISHED

No port :8080 in that list.

-chris




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Update path of executeable of a tomcat windows service

[Daniel Küppers]

Am 22.02.2016 um 16:31 schrieb David kerber:

On 2/22/2016 10:12 AM, Fabian Birk wrote:

Hello,

I am using tomcat as a windows service and want to update the path of
executeable during my automated process via command line.
The Reason why I dont want to deinstall / install the service is, that I
want to keep the other informations like service user etc.

I have a tomcat 7 service (should work for all tomcat versions if 
possible)

and want to update it with the following command:

tomcat8 //US//TestService --DisplayName="TestService2" ^
--Install="..\Tomcat\x64\bin\tomcat8.exe"

The DisplayName is updated, install is not.

Is it even possible to change the path of executeable via tomcat?


I'm not sure about using a tomcat utility to do that, but I believe 
you can use the windows SC command to modify this setting.

You can actually change the binPath as suggested[1] like this:
sc config binPath=
Also you need administrative rights for the edit.

[1] http://stackoverflow.com/a/24877051/2614106


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Update path of executeable of a tomcat windows service

[David kerber]

On 2/22/2016 10:12 AM, Fabian Birk wrote:

Hello,

I am using tomcat as a windows service and want to update the path of
executeable during my automated process via command line.
The Reason why I dont want to deinstall / install the service is, that I
want to keep the other informations like service user etc.

I have a tomcat 7 service (should work for all tomcat versions if possible)
and want to update it with the following command:

tomcat8 //US//TestService --DisplayName="TestService2" ^
--Install="..\Tomcat\x64\bin\tomcat8.exe"

The DisplayName is updated, install is not.

Is it even possible to change the path of executeable via tomcat?


I'm not sure about using a tomcat utility to do that, but I believe you 
can use the windows SC command to modify this setting.




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Update path of executeable of a tomcat windows service

[Fabian Birk]

Hello,

I am using tomcat as a windows service and want to update the path of
executeable during my automated process via command line.
The Reason why I dont want to deinstall / install the service is, that I
want to keep the other informations like service user etc.

I have a tomcat 7 service (should work for all tomcat versions if possible)
and want to update it with the following command:

tomcat8 //US//TestService --DisplayName="TestService2" ^
--Install="..\Tomcat\x64\bin\tomcat8.exe"

The DisplayName is updated, install is not.

Is it even possible to change the path of executeable via tomcat?

Thanks for reading and your time.

Re: Tomcat memory

[tomcat]

On 22.02.2016 13:02, Gokul.Baskaran wrote:

The answer I expected is the JVM grows as much as to the available system 
memory of there are m min and max set.



Gokul,

Well, no.

And because these messages get archived and searched later by other people, they may get 
the wrong conclusion and therefore I will try again.


Re-read your last question.
And then re-read your question before that one.
And then re-read your question before that one.

The problem here is not that you are not being given the information that you 
want.
The problem is that each time you ask your question, you ask it in a different way, and 
each time somehow in a way that confuses people as to what exactly you want to know.
And the reason why it is confusing is that in your succesive questions you keep on talking 
about "application memory" in various ways, but it is not clear what you are referring to 
as "application".

For the OS, the JVM is an application.
For the JVM, Tomcat is the application.
And for Tomcat, the web applications (webapps) are the applications.

The JVM is one process that is running on a machine, under an OS.
That OS probably imposes limits on how much resources (including memory) a given process 
is allowed to use.  If a process tries to use more than this, it will be killed with an 
"out of memory" error.  It is unlikely that this per-process limit is "the available 
system memory". The OS will kill the process before it uses all of that.


The JVM itself (of which there are various models on the market) uses memory in various 
ways, for various purposes.  One of these purposes is to manage a Heap, which it makes 
available to Java applications which run inside the JVM.
But the JVM also uses memory for other reasons, such as a stack, and for the code of the 
JVM itself.


For any given JVM, there are (probably) parameters which tell the JVM how much memory it 
should set aside initially for the Heap, and then also for how big it should let the Heap 
grow as a maximum.  For the Oracle JVMs, these parameters are "-Xms" and "-Xmx".
By default (if these parameters are not set), the JVM uses some default values, which 
/vary/ depending on the specific JVM and on the circumstances under which it is running 
(the total available machine memory, for example).

For the Oracle JVM, someone already quoted to you the relevant documentation.
For other JVM's, you need to look at the relevant JVM documentation.
(You never indicated which JVM you are using).

The JVM runs java applications (of which Tomcat - the whole Tomcat - is one).  These Java 
applications cannot set the amount of memory that they will use in the Heap of the JVM, 
other than indirectly (if they are well-written, the minimum necessary; if they are not 
well-written, who knows).  There is no Tomcat-level configuration option, that allows one 
to set how much Heap space Tomcat can use within the JVM Heap.


Then within Tomcat, there are "web applications" running.  Individual web applications 
also cannot set how much Heap they will use, because is not "their" Heap, it is the 
"Tomcat Heap", which itself is not really the Tomcat Heap, it is the JVM's Heap.

That Heap is used by /all/ web applications at the same time.
(That is a bit of an approximation, but ultimately it boils down to that).

So if one of the web applications within Tomcat starts to do things which result in 
filling-up the Heap, and if the JVM cannot clean-up or increase the Heap anymore, there 
will be problems, not only with that web application, but for all web applications and for 
the whole Tomcat.


Is that clear, and does it answer your ultimate question ?





On Feb 22, 2016, at 2:43 AM, André Warnier (tomcat)  wrote:


On 22.02.2016 03:44, Gokul.Baskaran wrote:
Thanks again, to make things clear. When I meant default, what is the default 
min and max that is given to an application if there nothing defined in the JVM 
?


In how many different ways do you need to be told this ?
Re-read the previous answers that you already received.  All the information is 
there.


In my case, the Tomcat is running on windows and I don't have setenv.bat or 
sentenv.sh or even catalina.bat and catalina.conf does not have the OPT config 
for min and max. HTH

Thank you

-Gokul


-Original Message-
From: Olaf Kock [mailto:tom...@olafkock.de]
Sent: Sunday, February 21, 2016 3:04 PM
To: Tomcat Users List 
Subject: Re: Tomcat memory

grep mx bin/* found only settings in setenv.sh in my installation - this lets 
me state that there are no defaults: setenv.sh is not contained in the 
distribution but will be read in case it's found in the file system.
Thus there's no tomcat default that I'm aware of. Anybody who distributes 
tomcat with a setenv.sh might have a sensible default for their embedded 
application, but the raw distribution AFAIK has none.

Safe assumption should be: Whatever the JVM thinks is appropriate is the 
default.

Create a 

RE: Tomcat memory

[Gokul . Baskaran]

I meant the expectation as what I understood from the earlier posts.

The hyperlink url was not formed correct, hyperlink url helped as well. Earlier 
I read it as the 1/64th and 1/4th applied only to the JSE5.

Thanks to Olaf. 

-Gokul


-Original Message-
From: David kerber [mailto:dcker...@verizon.net] 
Sent: Monday, February 22, 2016 6:46 AM
To: Tomcat Users List 
Subject: Re: Tomcat memory

On 2/22/2016 7:02 AM, Gokul.Baskaran wrote:
> The answer I expected is the JVM grows as much as to the available system 
> memory of there are m min and max set.

But if you go back and read what others have posted, you will find that that is 
not the case.  Just because that's what you expect, does not mean that is what 
is actually going to happen.


>
> -Gokul
>
> Sent from iPhone
>
>> On Feb 22, 2016, at 2:43 AM, André Warnier (tomcat)  wrote:
>>
>>> On 22.02.2016 03:44, Gokul.Baskaran wrote:
>>> Thanks again, to make things clear. When I meant default, what is the 
>>> default min and max that is given to an application if there nothing 
>>> defined in the JVM ?
>>
>> In how many different ways do you need to be told this ?
>> Re-read the previous answers that you already received.  All the information 
>> is there.
>>
>>> In my case, the Tomcat is running on windows and I don't have 
>>> setenv.bat or sentenv.sh or even catalina.bat and catalina.conf does 
>>> not have the OPT config for min and max. HTH
>>>
>>> Thank you
>>>
>>> -Gokul
>>>
>>>
>>> -Original Message-
>>> From: Olaf Kock [mailto:tom...@olafkock.de]
>>> Sent: Sunday, February 21, 2016 3:04 PM
>>> To: Tomcat Users List 
>>> Subject: Re: Tomcat memory
>>>
>>> grep mx bin/* found only settings in setenv.sh in my installation - this 
>>> lets me state that there are no defaults: setenv.sh is not contained in the 
>>> distribution but will be read in case it's found in the file system.
>>> Thus there's no tomcat default that I'm aware of. Anybody who distributes 
>>> tomcat with a setenv.sh might have a sensible default for their embedded 
>>> application, but the raw distribution AFAIK has none.
>>>
>>> Safe assumption should be: Whatever the JVM thinks is appropriate is the 
>>> default.
>>>
>>> Create a setenv.sh or setenv.bat and set CATALINA_OPTS to the desired 
>>> value, e.g. "-Xms 2048m -Xmx2048m" (but there will probably be more 
>>> settings, e.g. for tuning the garbage collector...
>>>
>>> (apologies in case this goes out after the problem has long been solved:
>>> I'm in a hotel that blocks SMTP and have to find a way to send mail 
>>> from
>>> here)
>>>
>>> Olaf
>>>
 Am 21.02.2016 um 18:23 schrieb Gokul.Baskaran:
 Question was for Java 7

 It is a Tomcat / Application question as well, as memory default can be 
 configured in the application config.

 I totally agree that the best practice is to set the Xms and -Xmx. As am 
 going to change the config, I would curious to know if the tomcat ui or 
 the catalina does not have a Xms and -Xmx, would it default to 400MB? I 
 read this in another forum.

 -Gokul


 -Original Message-
 From: Olaf Kock [mailto:tom...@olafkock.de]
 Sent: Sunday, February 21, 2016 3:14 AM
 To: Tomcat Users List 
 Subject: Re: Tomcat memory

 This is rather a Java than a tomcat question:

 The JVM allocates memory based on whatever default your current JVM 
 version decides (you don't mention what version of Java you're on)

  From a text on
 http://docs.oracle.com/javase/7/docs/technotes/guides/vm/gc-ergonom
 ics
 .html
 that's linked from my Java's manpage:

  *initial heap size*

  Larger of 1/64th of the machine's physical memory on the machine
  or some reasonable minimum. Before J2SE 5.0, the default initial
  heap size was a reasonable minimum, which varies by platform.
  You can override this default using the |-Xms| command-line 
 option.

  *maximum heap size*

  Smaller of 1/4th of the physical memory or 1GB. Before J2SE 5.0,
  the default maximum heap size was 64MB. You can override this
  default using the |-Xmx| command-line option.

  *Note:* The boundaries and fractions given for the heap size are
  correct for J2SE 5.0. They are likely to be different in subsequent
  releases as computers get more powerful.

 Note that this is from JavaSE7 and even mentions 5 - with more power there 
 comes more initial and maximum memory defaults.

 I'm not aware of the actual development of the default memory - 
 mostly because I consider it good practice to know what an 
 application uses and provide it explicitly, rather than relying on 
 defaults. (and frankly, on the applications that I see, the 

Re: Tomcat memory

[David kerber]

On 2/22/2016 7:02 AM, Gokul.Baskaran wrote:

The answer I expected is the JVM grows as much as to the available system 
memory of there are m min and max set.


But if you go back and read what others have posted, you will find that 
that is not the case.  Just because that's what you expect, does not 
mean that is what is actually going to happen.





-Gokul

Sent from iPhone


On Feb 22, 2016, at 2:43 AM, André Warnier (tomcat)  wrote:


On 22.02.2016 03:44, Gokul.Baskaran wrote:
Thanks again, to make things clear. When I meant default, what is the default 
min and max that is given to an application if there nothing defined in the JVM 
?


In how many different ways do you need to be told this ?
Re-read the previous answers that you already received.  All the information is 
there.


In my case, the Tomcat is running on windows and I don't have setenv.bat or 
sentenv.sh or even catalina.bat and catalina.conf does not have the OPT config 
for min and max. HTH

Thank you

-Gokul


-Original Message-
From: Olaf Kock [mailto:tom...@olafkock.de]
Sent: Sunday, February 21, 2016 3:04 PM
To: Tomcat Users List 
Subject: Re: Tomcat memory

grep mx bin/* found only settings in setenv.sh in my installation - this lets 
me state that there are no defaults: setenv.sh is not contained in the 
distribution but will be read in case it's found in the file system.
Thus there's no tomcat default that I'm aware of. Anybody who distributes 
tomcat with a setenv.sh might have a sensible default for their embedded 
application, but the raw distribution AFAIK has none.

Safe assumption should be: Whatever the JVM thinks is appropriate is the 
default.

Create a setenv.sh or setenv.bat and set CATALINA_OPTS to the desired value, e.g. 
"-Xms 2048m -Xmx2048m" (but there will probably be more settings, e.g. for 
tuning the garbage collector...

(apologies in case this goes out after the problem has long been solved:
I'm in a hotel that blocks SMTP and have to find a way to send mail from
here)

Olaf


Am 21.02.2016 um 18:23 schrieb Gokul.Baskaran:
Question was for Java 7

It is a Tomcat / Application question as well, as memory default can be 
configured in the application config.

I totally agree that the best practice is to set the Xms and -Xmx. As am going 
to change the config, I would curious to know if the tomcat ui or the catalina 
does not have a Xms and -Xmx, would it default to 400MB? I read this in another 
forum.

-Gokul


-Original Message-
From: Olaf Kock [mailto:tom...@olafkock.de]
Sent: Sunday, February 21, 2016 3:14 AM
To: Tomcat Users List 
Subject: Re: Tomcat memory

This is rather a Java than a tomcat question:

The JVM allocates memory based on whatever default your current JVM
version decides (you don't mention what version of Java you're on)

 From a text on
http://docs.oracle.com/javase/7/docs/technotes/guides/vm/gc-ergonomics
.html
that's linked from my Java's manpage:

 *initial heap size*

 Larger of 1/64th of the machine's physical memory on the machine
 or some reasonable minimum. Before J2SE 5.0, the default initial
 heap size was a reasonable minimum, which varies by platform.
 You can override this default using the |-Xms| command-line option.

 *maximum heap size*

 Smaller of 1/4th of the physical memory or 1GB. Before J2SE 5.0,
 the default maximum heap size was 64MB. You can override this
 default using the |-Xmx| command-line option.

 *Note:* The boundaries and fractions given for the heap size are
 correct for J2SE 5.0. They are likely to be different in subsequent
 releases as computers get more powerful.

Note that this is from JavaSE7 and even mentions 5 - with more power there 
comes more initial and maximum memory defaults.

I'm not aware of the actual development of the default memory - mostly
because I consider it good practice to know what an application uses
and provide it explicitly, rather than relying on defaults. (and
frankly, on the applications that I see, the default typically is not
even enough - let alone a good basis for tuning)

While we're at it: For production systems I consider it good practice to set -Xms and 
-Xmx to the same value. Reason: If you don't have enough memory available, you want to 
know this when the process starts, not days later when it tries to allocate "the 
rest" - typically sunday night at 3am.

Olaf


Am 21.02.2016 um 03:39 schrieb Gokul.Baskaran:
Hi,

I am currently running tomcat 7 in Windows 2012.

The current JVM Heap memory parameters are set to empty, does the JVM Heap 
memory utilize the entire memory of the OS or does it default to a specific 
memory number?

Thank you
-Gokul


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat memory

[Gokul . Baskaran]

The answer I expected is the JVM grows as much as to the available system 
memory of there are m min and max set.

-Gokul

Sent from iPhone

> On Feb 22, 2016, at 2:43 AM, André Warnier (tomcat)  wrote:
> 
>> On 22.02.2016 03:44, Gokul.Baskaran wrote:
>> Thanks again, to make things clear. When I meant default, what is the 
>> default min and max that is given to an application if there nothing defined 
>> in the JVM ?
> 
> In how many different ways do you need to be told this ?
> Re-read the previous answers that you already received.  All the information 
> is there.
> 
>> In my case, the Tomcat is running on windows and I don't have setenv.bat or 
>> sentenv.sh or even catalina.bat and catalina.conf does not have the OPT 
>> config for min and max. HTH
>> 
>> Thank you
>> 
>> -Gokul
>> 
>> 
>> -Original Message-
>> From: Olaf Kock [mailto:tom...@olafkock.de]
>> Sent: Sunday, February 21, 2016 3:04 PM
>> To: Tomcat Users List 
>> Subject: Re: Tomcat memory
>> 
>> grep mx bin/* found only settings in setenv.sh in my installation - this 
>> lets me state that there are no defaults: setenv.sh is not contained in the 
>> distribution but will be read in case it's found in the file system.
>> Thus there's no tomcat default that I'm aware of. Anybody who distributes 
>> tomcat with a setenv.sh might have a sensible default for their embedded 
>> application, but the raw distribution AFAIK has none.
>> 
>> Safe assumption should be: Whatever the JVM thinks is appropriate is the 
>> default.
>> 
>> Create a setenv.sh or setenv.bat and set CATALINA_OPTS to the desired value, 
>> e.g. "-Xms 2048m -Xmx2048m" (but there will probably be more settings, e.g. 
>> for tuning the garbage collector...
>> 
>> (apologies in case this goes out after the problem has long been solved:
>> I'm in a hotel that blocks SMTP and have to find a way to send mail from
>> here)
>> 
>> Olaf
>> 
>>> Am 21.02.2016 um 18:23 schrieb Gokul.Baskaran:
>>> Question was for Java 7
>>> 
>>> It is a Tomcat / Application question as well, as memory default can be 
>>> configured in the application config.
>>> 
>>> I totally agree that the best practice is to set the Xms and -Xmx. As am 
>>> going to change the config, I would curious to know if the tomcat ui or the 
>>> catalina does not have a Xms and -Xmx, would it default to 400MB? I read 
>>> this in another forum.
>>> 
>>> -Gokul
>>> 
>>> 
>>> -Original Message-
>>> From: Olaf Kock [mailto:tom...@olafkock.de]
>>> Sent: Sunday, February 21, 2016 3:14 AM
>>> To: Tomcat Users List 
>>> Subject: Re: Tomcat memory
>>> 
>>> This is rather a Java than a tomcat question:
>>> 
>>> The JVM allocates memory based on whatever default your current JVM
>>> version decides (you don't mention what version of Java you're on)
>>> 
>>> From a text on
>>> http://docs.oracle.com/javase/7/docs/technotes/guides/vm/gc-ergonomics
>>> .html
>>> that's linked from my Java's manpage:
>>> 
>>> *initial heap size*
>>> 
>>> Larger of 1/64th of the machine's physical memory on the machine
>>> or some reasonable minimum. Before J2SE 5.0, the default initial
>>> heap size was a reasonable minimum, which varies by platform.
>>> You can override this default using the |-Xms| command-line option.
>>> 
>>> *maximum heap size*
>>> 
>>> Smaller of 1/4th of the physical memory or 1GB. Before J2SE 5.0,
>>> the default maximum heap size was 64MB. You can override this
>>> default using the |-Xmx| command-line option.
>>> 
>>> *Note:* The boundaries and fractions given for the heap size are
>>> correct for J2SE 5.0. They are likely to be different in subsequent
>>> releases as computers get more powerful.
>>> 
>>> Note that this is from JavaSE7 and even mentions 5 - with more power there 
>>> comes more initial and maximum memory defaults.
>>> 
>>> I'm not aware of the actual development of the default memory - mostly
>>> because I consider it good practice to know what an application uses
>>> and provide it explicitly, rather than relying on defaults. (and
>>> frankly, on the applications that I see, the default typically is not
>>> even enough - let alone a good basis for tuning)
>>> 
>>> While we're at it: For production systems I consider it good practice to 
>>> set -Xms and -Xmx to the same value. Reason: If you don't have enough 
>>> memory available, you want to know this when the process starts, not days 
>>> later when it tries to allocate "the rest" - typically sunday night at 3am.
>>> 
>>> Olaf
>>> 
 Am 21.02.2016 um 03:39 schrieb Gokul.Baskaran:
 Hi,
 
 I am currently running tomcat 7 in Windows 2012.
 
 The current JVM Heap memory parameters are set to empty, does the JVM Heap 
 memory utilize the entire memory of the OS or does it default to a 
 specific memory number?
 
 Thank you
 -Gokul
>>> 
>>> 

[SECURITY] CVE-2016-0706 Apache Tomcat Security Manager bypass

[Mark Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

CVE-2016-0706 Apache Tomcat Security Manager bypass

Severity: Low

Vendor: The Apache Software Foundation

Versions Affected:
- - Apache Tomcat 6.0.0 to 6.0.44
- - Apache Tomcat 7.0.0 to 7.0.67
- - Apache Tomcat 8.0.0.RC1 to 8.0.30
- - Apache Tomcat 9.0.0.M1
- - Earlier, unsupported Tomcat versions may be affected

Description:
The StatusManagerServlet could be loaded by a web application when a
security manager was configured. This servlet would then provide the web
application with a list of all deployed applications and a list of the
HTTP request lines for all requests currently being processed. This
could have exposed sensitive information from other web applications
such as session IDs to the web application.

Mitigation:
Users of affected versions should apply one of the following mitigations
- - Upgrade to Apache Tomcat 9.0.0.M3 or later
  (9.0.0.M2 has the fix but was not released)
- - Upgrade to Apache Tomcat 8.0.32 or later
  (8.0.31 has the fix but was not released)
- - Upgrade to Apache Tomcat 7.0.68 or later
- - Upgrade to Apache Tomcat 6.0.45 or later


Credit:
This issue was discovered by The Apache Tomcat Security Team.

References:
[1] http://tomcat.apache.org/security-9.html
[2] http://tomcat.apache.org/security-8.html
[3] http://tomcat.apache.org/security-7.html
[4] http://tomcat.apache.org/security-6.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWyu9qAAoJEBDAHFovYFnny/0P/0VtkiCt56FeS3I42BlvjAne
w/oqurmk/XoF/gof+VYxYuNOXMIwvgyGMjj21kZf+n2DjINXLHp9VFZ/APeSJ8kL
XcnTL1EBK1JBdxsieIhGAfLMeDO04wO3uuorJHwJIBbl4ymh7N4A2fgciKgCmNyB
y22TPT5Hz7iFCU8Ij6xsYJERpveUrenenAqbgjdcpILydbBoTqmZtZtWmPOFki90
cZo/2D0Av4H4SKh1PuCkzjk2DFXfyXcq+tDaX8dizPinQMQsbAX63BoYy5LrfWrJ
epgY9Q0QziOyp7b5Z72AjQ3RJR7yZS/iT3wb37jceI3Dq/mpkWFggqEGkSpFdGX7
AhoqVXjFw9eakjst0k5LZ29+dD8Fqz+2umXlRwelsxInLNgDk67Z2XehqkWWb85b
64PFh3ZYj/8CxxV6ErGq0bBhpCsNHZffEzOT/Ebldjn/afHajne3Yd9SZEbbZO3U
ejCSG2UziJ4t4mygnGyWaRCgKtjCrejzDZYicOICJEDE8enaPbNs0Ka8lR8fh21y
U3avzYIu7MosqvqoEAleMkjXySWSufqGF0ugbtsZx1lisl9Zax0LfXbq5sLmdNMS
fXhxu/1RfHfPS7NUP9YYs5OdWxCxecD/kiaxc3ArVVPdgAMSwlEyI59gSD/y7XPd
fitNMHbOMz6qG/uxVfH0
=6KO+
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[SECURITY] CVE-2015-5345 Apache Tomcat Directory disclosure

[Mark Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

CVE-2015-5345 Apache Tomcat Directory disclosure

Severity: Low

Vendor: The Apache Software Foundation

Versions Affected:
- - Apache Tomcat 6.0.0 to 6.0.44
- - Apache Tomcat 7.0.0 to 7.0.66
- - Apache Tomcat 8.0.0.RC1 to 8.0.29
- - Apache Tomcat 9.0.0.M1
- - Earlier, unsupported Tomcat versions may be affected

Description:
When accessing a directory protected by a security constraint with a URL
that did not end in a slash, Tomcat would redirect to the URL with the
trailing slash thereby confirming the presence of the directory before
processing the security constraint. It was therefore possible for a user
to determine if a directory existed or not, even if the user was not
permitted to view the directory. The issue also occurred at the root of
a web application in which case the presence of the web application was
confirmed, even if a user did not have access.

The solution was to implement the redirect in the DefaultServlet so that
any security constraints and/or security enforcing Filters were
processed before the redirect. The Tomcat team recognised that moving
the redirect could cause regressions to two new Context configuration
options (mapperContextRootRedirectEnabled and
mapperDirectoryRedirectEnabled) were introduced. The initial default was
false for both since this was more secure. However, due to regressions
such as Bug 58765 [1] the default for mapperContextRootRedirectEnabled
was later changed to true since it was viewed that the regression was
more serious than the security risk of associated with being able to
determine if a web application was deployed at a given path.

Mitigation:
Users of affected versions should apply one of the following mitigations
- - Upgrade to Apache Tomcat 9.0.0.M3 or later
  (9.0.0.M2 has the fix but was not released)
- - Upgrade to Apache Tomcat 8.0.30 or later
- - Upgrade to Apache Tomcat 7.0.67 or later
- - Upgrade to Apache Tomcat 6.0.45 or later


Credit:
This issue was discovered by Mark Koek of QCSec.

References:
[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=58765
[2] http://tomcat.apache.org/security-9.html
[3] http://tomcat.apache.org/security-8.html
[4] http://tomcat.apache.org/security-7.html
[5] http://tomcat.apache.org/security-6.html

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWyu+lAAoJEBDAHFovYFnnFrYP+wZwqPsP6vtAn4VrIslTxrkO
A31WCsXwnvggSIBLdITCwpJFywqPfpurFhce38Chgznli9E46Pr6dukTC56NhjmB
Cv7+PTdpJxM3vKFw+OlLrfIrxEFtHbYOTI6q7NgjfVjdbG9LbVgG3JRTmf3tT+GN
DU165VK7TxvBj68ll05gLECgAtrGFAEQl+51VlfWRZw8wXGFni2X43kEwUpihgHj
Ci4W1+sBUln0ww+aKa6sRpJTi/s3tKPWckjMY//bDIMfd4gdK7N6CJSrRMbj6Gsw
gfm1ixWlJJPKVvokH08NKvxcpwvRX4D1RD80WkaCrC7WMKzK8ohmhxxhIDXHmPE8
kibaJuy1WqQG+G/H00LTGpGkeevyg4/mH2hDxDbDJ5ye1RMA9GsKFC1YpDzugTxO
zr9lX9QRWpPNEJDXSipdjs27p8hcF+vgwI5eVd5R721wpv17IEg0Lsy4zvvswFik
t3rIj6wwVYHFoMNpwA/sojaRTGb62nqGREYiGMX4fPPd2OCtl1J4I8oZ3x4Q2gkJ
WRX98z6a04zMisiGNeTjl7ZkgEjNNW8/XG4J5sFmgSo5p2XwBCINLyWfnYiQporj
Ym0Ig9k8t5BHntgkP02a+CF9GScdkxNq8UC8Ad2oAHBqOEXd/9DHv80fA7ApvG7e
HnSzWGDdd63z0ixY0g2I
=6UrH
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[SECURITY] CVE-2015-5346 Apache Tomcat Session fixation

[Mark Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

CVE-2015-5346 Apache Tomcat Session fixation

Severity: Low

Vendor: The Apache Software Foundation

Versions Affected:
- - Apache Tomcat 7.0.5 to 7.0.65
- - Apache Tomcat 8.0.0.RC1 to 8.0.30
- - Apache Tomcat 9.0.0.M1

Description:
When recycling the Request object to use for a new request, the
requestedSessionSSL field was not recycled. This meant that a session ID
provided in the next request to be processed using the recycled Request
object could be used when it should not have been. This gave the client
the ability to control the session ID. In theory, this could have been
used as part of a session fixation attack but it would have been hard to
achieve as the attacker would not have been able to force the victim to
use the 'correct' Request object. It was also necessary for at least one
web application to be configured to use the SSL session ID as the HTTP
session ID. This is not a common configuration.

Mitigation:
Users of affected versions should apply one of the following mitigations
- - Upgrade to Apache Tomcat 9.0.0.M3 or later
  (9.0.0.M2 has the fix but was not released)
- - Upgrade to Apache Tomcat 8.0.30 or later
- - Upgrade to Apache Tomcat 7.0.67 or later
  (7.0.66 has the fix but was not released)


Credit:
This issue was discovered by the Apache Tomcat security team.

References:
[1] http://tomcat.apache.org/security-9.html
[2] http://tomcat.apache.org/security-8.html
[3] http://tomcat.apache.org/security-7.html





-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWyu+WAAoJEBDAHFovYFnnNasQANmHvs8L9RvbPSPvmR8sT9rc
nfoC64cVqVFx6G99+iskQ4SKL00zZk10gCNKvwu6aBW8Dv7U+sqoo09vtIVJ9qvD
9qBIaZMfnqMxMaHtonUj8E1/9GryquYNj7pWMf0tut2/RIvQq8/1tAtTgrzjVXG2
qtpB/ECBHQ53tJuPxRDakgav17Ok90DbAO4rsSdmCUwUg8NEYieNb6RG4eRSvuav
ffE2zaicXIHWLdnVEMpOWtum76+GMfS5B+zd03/OQmiJy+arVvGwyrn1ydKZI1JI
7gQT97SgLlI3iGtK3tc4S56tNQ9+K2oMp2B0qAceNG9MWimED9sC1aXoAARacoYI
c+cZdnhiRxsYycEdTXbNqhat+se6vKeXqgrsrr3CbNmaNl6siRZD/d+9PbmXh+0z
hHSC9tmG5ZAO3vS4wwHX+9qZlfdcQ2zAZnAnRZKtuRMgDphP+wszain4p+U82TV9
eshrfHzzN4R0kuBWXkl4Pf4KQd+ZCVmp8efXFcyXK2fV7FUmLRvwtZ43EPa77tRI
egiZcN/WEqGHODKNr/AGQYuiuEU7gm3hqnJlgDLpPzKF2ptkLcEh9/HYcW9yI1Kf
x+fKtcfr6jGjJRxFw5PRsHEO8ToE8w38mPmeLzQH3WRcoc+g5+BinbIe/fwMsVPM
cAK/Ln4UhXIcIM1f7h5M
=is2n
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[SECURITY] CVE-2016-0714 Apache Tomcat Security Manager Bypass

[Mark Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

CVE-2016-0714 Apache Tomcat Security Manager Bypass

Severity: Moderate

Vendor: The Apache Software Foundation

Versions Affected:
- - Apache Tomcat 6.0.0 to 6.0.44
- - Apache Tomcat 7.0.0 to 7.0.67
- - Apache Tomcat 8.0.0.RC1 to 8.0.30
- - Apache Tomcat 9.0.0.M1
- - Earlier, unsupported Tomcat versions may be affected

Description:
Tomcat provides several session persistence mechanisms. The
StandardManager persists session over a restart. The PersistentManager
is able to persist sessions to files, a database or a custom Store. The
Cluster implementation persists sessions to one or more additional nodes
in the cluster. All of these mechanisms could be exploited to bypass a
security manager. Session persistence is performed by Tomcat code with
the permissions assigned to Tomcat internal code. By placing a carefully
crafted object into a session, a malicious web application could trigger
the execution of arbitrary code.

Mitigation:
Users of affected versions should apply one of the following mitigations
- - Upgrade to Apache Tomcat 9.0.0.M3 or later
  (9.0.0.M2 has the fix but was not released)
- - Upgrade to Apache Tomcat 8.0.32 or later
  (8.0.31 has the fix but was not released)
- - Upgrade to Apache Tomcat 7.0.68 or later
- - Upgrade to Apache Tomcat 6.0.45 or later


Credit:
This issue was discovered by The Apache Tomcat Security Team.

References:
[1] http://tomcat.apache.org/security-9.html
[2] http://tomcat.apache.org/security-8.html
[3] http://tomcat.apache.org/security-7.html
[4] http://tomcat.apache.org/security-6.html

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWyu9PAAoJEBDAHFovYFnnllEQAMj38sm4FeeXJ2XOK/ODpj2J
SLK0VMib2gjRmMfuH15OPyYBIHPaWVD4E3ONiLz/2F9oqVAYfvswQnLfNrJ9k8oF
K+ETBoWfyODb8QddYQOd3JpDslrOLPscve6dgnkx/R8hZSPOvsmo8IIG4Bwh5VQM
rkAct8EFGpVuQ9ou59F8xSx7fhRMHhNKt8XwsuBIj43MwFv5P8rHhNJDbgC8hSP7
w8yKwrQ7alfeuzwQPegf11YEcauPog4TnD3JAuufcuPQefvDHRAIoKNRCwyvFbRC
rVHdsV5AehWaKKHj9Yu2IJB88s+0wXWlH01hG+wYl1jSVxs3CHhhP0FS55vwItWP
Igl26iz33esPlzQaVyWf5jOUOYfF0tZel4bDFcQrIQASJKS2vxCuOBgUhr+bReMD
I8W1A78EdGXm5IGqmPqHNXn+qAQKfs352eVFiS4vM+5n6wdVThxRzTIt/Op0iz8k
rOIm05kkZQedh7utUy4iW59MKHr9xGRQRI1r4/sdKHDIRSlzsfzJVrATqqLPxukg
QhG3LL0fO+kKLb526GZOlTaAcT7hM2wdYkLytiUItpMUR8ZfozqIS/nRUPmCfDgW
8QFRZEYIgETUYELbnj9chx0NJOkSH9OICV1U7EergsKsdpXN8uCDRy609ufSPn+W
M6wXyzp1l4aE2hnn22gZ
=OQbe
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[SECURITY] CVE-2016-0763 Apache Tomcat Security Manager Bypass

[Mark Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

CVE-2016-0763 Apache Tomcat Security Manager Bypass

Severity: Moderate

Vendor: The Apache Software Foundation

Versions Affected:
- - Apache Tomcat 7.0.0 to 7.0.67
- - Apache Tomcat 8.0.0.RC1 to 8.0.30
- - Apache Tomcat 9.0.0.M1 to 9.0.0.M2

Description:
ResourceLinkFactory.setGlobalContext() is a public method and was
accessible by web applications running under a security manager
without any checks. This allowed a malicious web application to inject
a malicious global context that could in turn be used to disrupt other
web applications and/or read and write data owned by other web
applications.

Mitigation:
Users of affected versions should apply one of the following mitigations
- - Upgrade to Apache Tomcat 9.0.0.M3 or later
- - Upgrade to Apache Tomcat 8.0.32 or later
  (8.0.31 has the fix but was not released)
- - Upgrade to Apache Tomcat 7.0.68 or later
- - Upgrade to Apache Tomcat 6.0.45 or later


Credit:
This issue was discovered by The Apache Tomcat Security Team.

References:
[1] http://tomcat.apache.org/security-9.html
[2] http://tomcat.apache.org/security-8.html
[3] http://tomcat.apache.org/security-7.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWyu+yAAoJEBDAHFovYFnnPIgP/j9nli2IrsZEyhDyJ6XqAcg9
AisYAv7iSQ63zLe27CERDdOS9BBFI9j+MwkabF0FzmTGxugLyRwpKLt8Y3BV/723
Jwgds8phJcOm5oouzblUBfx/HdFDRI8+J6q7CNoSh61yXatuKRe5upc51W9G8/Vd
YS6b5XNqavBgvkQZudITIsr4N9vqxb+QVS9iMJfrACikgeq6QR6rwkJWAEcUYHrn
RESKuCTPzw8yf1Q1C8Ar9BUdSx8MRFDHfV8stKmjQWslud0EOP5bObWXBsv9vrQ7
XNKVKA69Hp1Kk++ORHUPnv6B2bCRsD5mZmBwqcvi6jVMuVMKaiLgCqJqfXcJEb4+
D86kjsBCQchGWSsFEwzmoQI++wW60Mn5QRlibF90LHAJLfZLo+cCsOUZABqgv3+j
xwA6HpR5ToMepO5CNcL76wDoBJDEPRXjIuVY6RhWnS7UXi4kuqp/qxtWBifn07X/
Ncbm5TWhf4ESnS5YOPMNefA5aDQJKRclymyXB37VxMwHdJ/zkY8uV48SeG9ACHNt
KBaXiS7FiNKLWqbzZijsXM2a40benXn6ocxStyApF7h15k/8/pyyq4DC55TBMitK
/L+RHHp9RAS+wP98xyYpFnuVI8/LkHSJwnLvTURDQlr1Fi/AJ5YIB+Y9GPE2sigA
90lXXPnmrbSsQR10jD/j
=5LII
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[SECURITY] CVE-2015-5174 Apache Tomcat Limited Directory Traversal

[Mark Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

CVE-2015-5174 Apache Tomcat Limited Directory Traversal

Severity: Low

Vendor: The Apache Software Foundation

Versions Affected:
- - Apache Tomcat 6.0.0 to 6.0.44
- - Apache Tomcat 7.0.0 to 7.0.64
- - Apache Tomcat 8.0.0.RC1 to 8.0.26
- - Apache Tomcat 9 is not affected
- - Earlier, unsupported Tomcat versions may be affected

Description:
When accessing resources via the ServletContext methods getResource()
getResourceAsStream() and getResourcePaths() the paths should be limited
to the current web application. The validation was not correct and paths
of the form "/.." were not rejected. Note that paths starting with
"/../" were correctly rejected.
This bug allowed malicious web applications running under a security
manager to obtain a directory listing for the directory in which the web
application had been deployed. This should not be possible when running
under a security manager. Typically, the directory listing that would be
exposed would be for $CATALINA_BASE/webapps.

Mitigation:
Users of affected versions should apply one of the following mitigations
- - Upgrade to Apache Tomcat 8.0.27 or later
- - Upgrade to Apache Tomcat 7.0.65 or later
- - Upgrade to Apache Tomcat 6.0.45 or later


Credit:
This issue was discovered by the Apache Tomcat security team.

References:
[1] http://tomcat.apache.org/security-9.html
[2] http://tomcat.apache.org/security-8.html
[3] http://tomcat.apache.org/security-7.html
[4] http://tomcat.apache.org/security-6.html








-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWyu+JAAoJEBDAHFovYFnnubgQAICDB8mbxG4KbSDT1YAcqjJd
lToWRjRKVd0UzIaOZFUmqV0Ap7o181xMfQpSfGZSAAukF7+zTcX33O+cklTkZaw/
yjprJSI942enkWlGygiJxIH8DUadGa62iTMyhXmpqLqkD5ura5sSNEdzir7aEnUw
P8vLdpmfbdUqNn9Qv1L27btm5+lU6OU+I8nBTB5ESyDxjhVrpc1d8GVcRaXh0mU4
56oeIAJg7O9ozXrIQa692K4pAV+VqZFb52Vwk3XiNENn0VjwM2W7PAqy+vtAfkLt
wt5SDVjoXuCW1jBTjTU+hmxzDziN0WzgVMgFsSVZg0lyU/H837e/bOOmNVA1dfGD
F6Ln40a1eYkZQ6eXK9SPmz36OnU/akM3+rcDEz9e9spvbe/c4oH5T3/yZwmsONSO
4G+9JyMCg/YKWl2+YIJSGGxO1khaLbXZvyvVwkpq0IzJZ/ZhTp7BQY+DYb4axVY3
QLBx6/XzoIRfLxf1lpvUakGw8P/0y2BPHRa+3b0WDJSElD4H6KAQd+q5vb1eyK6+
0bNPLYd9AyxYwaIuZMk2WtT+pQO0R3Ao6mVBNFk8K/YJj7msMsS4feI76I2LYLT0
WCLKWb/noO8oPmjYk6a7AZKncT9nASN+rCfbXedw6F+COxfVjuddbttsGza2oH7o
NKmM5mCdDfQztF3uOTnu
=aYIY
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[SECURITY] CVE-2015-5351 Apache Tomcat CSRF token leak

[Mark Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

CVE-2015-5351 Apache Tomcat CSRF token leak

Severity: Moderate

Vendor: The Apache Software Foundation

Versions Affected:
- - Apache Tomcat 7.0.1 to 7.0.67
- - Apache Tomcat 8.0.0.RC1 to 8.0.31
- - Apache Tomcat 9.0.0.M1

Description:
The index page of the Manager and Host Manager applications included a
valid CSRF token when issuing a redirect as a result of an
unauthenticated request to the root of the web application. This token
could then be used by an attacker to construct a CSRF attack.

Mitigation:
Users of affected versions should apply one of the following mitigations
- - Upgrade to Apache Tomcat 9.0.0.M3 or later
  (9.0.0.M2 has the fix but was not released)
- - Upgrade to Apache Tomcat 8.0.32 or later
  (8.0.31 has the fix but was not released)
- - Upgrade to Apache Tomcat 7.0.68 or later

Credit:
This issue was discovered by the Apache Tomcat security team.

References:
[1] http://tomcat.apache.org/security-9.html
[2] http://tomcat.apache.org/security-8.html
[3] http://tomcat.apache.org/security-7.html



-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWyu97AAoJEBDAHFovYFnnkOkP/353AyMvuZvUHx7MJS6QmthF
ba5gOE0JprULz0VN9q6ilf1ZXE7myZiVxt0tWT9MvuQi+iMQUtarESxv/bnA1RSF
QsUoxgb4Wc6whrWIZUSXU9Vag5e7Ar/N3con0jzMLyopx0DBnOWNKQE/pp9Q6NPI
RRvOAWnq9nm3P9/D2x9AOl/LDaEFuPHW/GkfwuosNTLCRsWYqa1DN20cFnq/S8Iz
+jPpjkYsfIOoodLcX2t4B92alC3fRNPgG4Q8iuhwj3Umsw44D5/gdbmcEeEtqB4C
wYIQsyXdIA4JBSx44w8ihP+Z+pNt+MkxgXvhfGWu30JDELXRaXU0ItveeePTjRJR
u0jC09frTLKG7UnbVxitV7CgvMtEU6zGjaJsfEQcsES6q4s9qCzHCbp9alqQnW1i
5ZvabdyAkZVfdRsgurI6RAI1R/s2mWmXlIFjiKiYt3Qeyqkg5cFBNHctEw/DREiR
6GA6xmk06uKXUzv0SZUuvadWqkJ2JwVmd5Doe5IaoK4K069Ab5EJQSG1qQcXv6G2
LsYK4L9s+Zcp+m10unFX4v1CB8UnVPKw33intlvE7/6r0yBOaigtFHqV+ifuUdOO
bkENBx8Gp/HAx0VCpwhYP2AKkoSSqSOktsv/iBokWfIrsUG304uGoa3rWsAIcGCx
I/Yy6rJBLqfrQj4qFtc3
=bm3r
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat7/8 - Leap year compliant

[tomcat]

On 22.02.2016 11:40, Shree, Shubha wrote:

Hi ,

As 2016 is a Leap year,  can you please confirm is Tomcat7 and Tomcat8 leap 
year compliant so that there should not be any impact on the applications 
running on tomcat 7/8 .




Maybe you could define "leap year compliant" for us, so that we could determine what kind 
of answer is required here ?


But maybe first of all, navigate to the Apache Tomcat homepage on the web.
http://tomcat.apache.org/
You may want start by reading the first section, "Apache Tomcat", and try to reflect on 
what it means, in the context of your question.


Another useful read may be : http://www.catb.org/esr/faqs/smart-questions.html


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat7/8 - Leap year compliant

[Mark Thomas]

On 22/02/2016 10:40, Shree, Shubha wrote:
> Hi ,
> 
> As 2016 is a Leap year,  can you please confirm is Tomcat7 and Tomcat8 leap 
> year compliant so that there should not be any impact on the applications 
> running on tomcat 7/8 .

First of all, don't cross-post.

Tomcat does not do any direct processing of dates. All date processing
is performed via APIs provided by the JRE. If the JRE you are using does
not have any leap year bugs then Tomcat will be fine. If the JRE does
have leap year bugs the impact on Tomcat will depend on the nature of
the bug.

I am not aware of any known leap year bugs in any current JRE.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Tomcat7/8 - Leap year compliant

[Shree, Shubha]

Hi ,

As 2016 is a Leap year,  can you please confirm is Tomcat7 and Tomcat8 leap 
year compliant so that there should not be any impact on the applications 
running on tomcat 7/8 .


Regards,
Shubha Shree
Important : The information transmitted is intended for the person or entity to 
which it is addressed and may contain confidential, privileged or copyrighted 
material or attorney work product. If you receive this in error, please contact 
the sender and delete the material from any computer. Any comments or 
statements made are not necessarily those of FIL India Business Services 
Private Limited or any other Fidelity entity. All e-mails may be monitored or 
recorded.




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: context doesnt pick up

[Mark Thomas]

On 22/02/2016 08:53, Me Self wrote:
>>> Hi All
>>>
>>> When I put the context in server.xml it works fine, but if I put the same
>>> context tag in a xml file under /conf/Catalina/localhost/test.xml then
>>> tomcat doesn't pick it up. I would rather want to use the latter.
> 
>> You need to set deployOnStartup="true" for that to work.
> 
> And for that to work I would have to grant write access on the webapps
> folder for tomcat user?

Only if you want Tomcat to expand a WAR file in the appBase. There are
several ways you can avoid that:
- expand the WAR manually before Tomcat starts
- only place the expanded directory in the appBase
- set unpackWARs="false" on the host

Personally, I'd go with the second option.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: context doesnt pick up

[Me Self]

>> Hi All
>>
>> When I put the context in server.xml it works fine, but if I put the same
>> context tag in a xml file under /conf/Catalina/localhost/test.xml then
>> tomcat doesn't pick it up. I would rather want to use the latter.

>You need to set deployOnStartup="true" for that to work.

And for that to work I would have to grant write access on the webapps
folder for tomcat user?


On Sun, Feb 21, 2016 at 5:43 PM, Mark Thomas  wrote:

> On 20/02/2016 22:40, Me Self wrote:
> > Hi All
> >
> > When I put the context in server.xml it works fine, but if I put the same
> > context tag in a xml file under /conf/Catalina/localhost/test.xml then
> > tomcat doesn't pick it up. I would rather want to use the latter.
>
> You need to set deployOnStartup="true" for that to work.
>
> Mark
>
>
> >
> > The test.xml is
> > 
> > 
> >
> > Its a set up where the tomcat user has no write access to /webapps only
> > read. The war has been exploded to /webapps/test. Auto deployment is
> > disabled. In server.xml I have autoDeploy="false"
> deployOnStartup="false",
> > unpackWARS="false". The tomcat user only has read access to
> > /conf/Catalina/localhost/test.xml. Its tomcat 8 on linux.
> >
> > What Am I missing?
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat memory

[tomcat]

On 22.02.2016 03:44, Gokul.Baskaran wrote:

Thanks again, to make things clear. When I meant default, what is the default 
min and max that is given to an application if there nothing defined in the JVM 
?



In how many different ways do you need to be told this ?
Re-read the previous answers that you already received.  All the information is 
there.


In my case, the Tomcat is running on windows and I don't have setenv.bat or 
sentenv.sh or even catalina.bat and catalina.conf does not have the OPT config 
for min and max. HTH

Thank you

-Gokul


-Original Message-
From: Olaf Kock [mailto:tom...@olafkock.de]
Sent: Sunday, February 21, 2016 3:04 PM
To: Tomcat Users List 
Subject: Re: Tomcat memory

grep mx bin/* found only settings in setenv.sh in my installation - this lets 
me state that there are no defaults: setenv.sh is not contained in the 
distribution but will be read in case it's found in the file system.
Thus there's no tomcat default that I'm aware of. Anybody who distributes 
tomcat with a setenv.sh might have a sensible default for their embedded 
application, but the raw distribution AFAIK has none.

Safe assumption should be: Whatever the JVM thinks is appropriate is the 
default.

Create a setenv.sh or setenv.bat and set CATALINA_OPTS to the desired value, e.g. 
"-Xms 2048m -Xmx2048m" (but there will probably be more settings, e.g. for 
tuning the garbage collector...

(apologies in case this goes out after the problem has long been solved:
I'm in a hotel that blocks SMTP and have to find a way to send mail from
here)

Olaf

Am 21.02.2016 um 18:23 schrieb Gokul.Baskaran:

Question was for Java 7

It is a Tomcat / Application question as well, as memory default can be 
configured in the application config.

I totally agree that the best practice is to set the Xms and -Xmx. As am going 
to change the config, I would curious to know if the tomcat ui or the catalina 
does not have a Xms and -Xmx, would it default to 400MB? I read this in another 
forum.

-Gokul


-Original Message-
From: Olaf Kock [mailto:tom...@olafkock.de]
Sent: Sunday, February 21, 2016 3:14 AM
To: Tomcat Users List 
Subject: Re: Tomcat memory

This is rather a Java than a tomcat question:

The JVM allocates memory based on whatever default your current JVM
version decides (you don't mention what version of Java you're on)

 From a text on
http://docs.oracle.com/javase/7/docs/technotes/guides/vm/gc-ergonomics
.html
that's linked from my Java's manpage:

 *initial heap size*

 Larger of 1/64th of the machine's physical memory on the machine
 or some reasonable minimum. Before J2SE 5.0, the default initial
 heap size was a reasonable minimum, which varies by platform.
 You can override this default using the |-Xms| command-line option.

 *maximum heap size*

 Smaller of 1/4th of the physical memory or 1GB. Before J2SE 5.0,
 the default maximum heap size was 64MB. You can override this
 default using the |-Xmx| command-line option.

 *Note:* The boundaries and fractions given for the heap size are
 correct for J2SE 5.0. They are likely to be different in subsequent
 releases as computers get more powerful.

Note that this is from JavaSE7 and even mentions 5 - with more power there 
comes more initial and maximum memory defaults.

I'm not aware of the actual development of the default memory - mostly
because I consider it good practice to know what an application uses
and provide it explicitly, rather than relying on defaults. (and
frankly, on the applications that I see, the default typically is not
even enough - let alone a good basis for tuning)

While we're at it: For production systems I consider it good practice to set -Xms and 
-Xmx to the same value. Reason: If you don't have enough memory available, you want to 
know this when the process starts, not days later when it tries to allocate "the 
rest" - typically sunday night at 3am.

Olaf

Am 21.02.2016 um 03:39 schrieb Gokul.Baskaran:

Hi,

I am currently running tomcat 7 in Windows 2012.

The current JVM Heap memory parameters are set to empty, does the JVM Heap 
memory utilize the entire memory of the OS or does it default to a specific 
memory number?

Thank you
-Gokul




-
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



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To