Re: How to have relative paths refer to the context root

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jesse,

On 5/17/17 3:33 PM, Jesse Altman wrote:
> Hello,
> 
> I am running Tomcat 8.5.15 on Windows 10.
> 
> I have a folder called "myapp" with my web application files inside
> of it. Inside ${tomcat_base}/conf/Catalina/localhost I have my
> configuration file "other.xml" with the following entry:
> 
>  
> 
> The index.html file lives inside myapp/client with the following
> text:
> 
> text file 1 text file
> 2
> 
> file1.txt also lives inside myapp/client file2.txt lives inside
> myapp
> 
> The html file is then accessed by going to
> http://locahost:8080/other/client. When clicking the "text file 1"
> link it correctly finds the file under 
> http://localhost:8080/other/client/.  When clicking on the "text
> file 2" link unfortunately it looks for it under
> http://localhost:8080/, and it is not found.  I was hoping since
> the path to file2.txt starts with a '/' it would look for it under
> the context root http://localhost:8080/other/, but unfortunately it
> seems to look for it under the base webapps folder.  Is there a way
> to have a path refer to the context root of my application without
> specifically adding the context root in there?

This is not possible without a dynamic resource. So you can do it e.g.
with JSP:

text file 2

(You should really encode the above URL through response.encodeURL but
I wanted the example to be clean.)

But if you know that index.html lives at the root of the context path,
then simply:

text file 2

is all you need.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlkdLIwACgkQHPApP6U8
pFjktw//RzPReTkvXPEJPa9ciA7m/aP0pG5vXawJ6kWrhZvvbpFQ4xcDYdt9MyrO
Yre29U0fQY32fsHMp9q9qUVBPhtt2rq3l2a4UUwpqDV9lfw/znojuJeTZ/OWeLq3
cyjgfvpXgAODHwgiOPx6k7XDli7bUNkiMuz2V5tbDoq7lSBN0DAVL+zzlQ1APEo2
hH80pyDiUY0Y/fxbV2SHMsupmIc9y4wswlqgAUcI430KFtMz6svuUhja4kztCxa0
DWta6igFzr3hGu6U8q3AtPoF+I5VfZyQbjVdc15eh+iEPjKHYfq3yXeCtdknFlu0
CDUCty/G/crI6miwTsoUWtfHZ6rtHLRz2tRNRdraUMDtzZ8lb64295JjXky2Q4LN
3qcmEOE3fEmGJBJLdWSfSk/SEjyigmOtkTayxGbJUysfSUOojIBj8Wm7WNVEVu0e
EtKfXa3/Y4gxPtAfIl3/oibT8aGOuSMDtOxTXMa17cNnqaR4DxclpjBBV2s+SVRC
uH854X0QpiVFNCmAsrS1l0cIt7knsIL8n1JL1pkOyfrGT0RzY6igp7+on06ZDxaB
BxcoCRq59ayxtDTZIVrol2iSpMkZccBpGcDX2/R+KfMasMfYK3DHu4+vMSF7u1nX
i5dFNC7CgaAKwRllJvssAZBGHEhvMhL9g8ZlJ5PdpsJeQUUZ+m8=
=4k93
-END PGP SIGNATURE-

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

Re: Can't get over 100 client connections?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

John,

On 5/16/17 1:57 PM, john.e.gr...@wellsfargo.com.INVALID wrote:
> All,
> 
> I'm using Tomcat 7.0.75.
> 
> I cannot get my connection or thread count over 100 no matter how
> much load I throw at the server.  Currently I just have a dummy app
> deployed that doesn't do much except sleep for about 500ms and
> return a canned response.  Initially I had maxThreads=20 with no
> explicit maxConnections.  I could get the "current threads busy"
> metric to 20 easily.  Then I raised it to 100 and was able to reach
> that number easily.  Additionally, netstat told me I had 100
> incoming connections to port 5114.  However raising the maxThreads
> higher doesn't make any difference, nor does explicitly specifying
> maxConnections=200.  In either case, I can only get 100 busy
> threads and 100 active connections.  Once I reach that limit, the
> response times on the client start going up.  The Tomcat server
> itself isn't stressed at all.  CPU and GC are low.  The client is
> on a different server in the same data center.
> 
> I'm not going through a load balancer.  I'm going directly to the
> connector below:
> 
> 
>  maxConnections="200" maxThreads="200" maxKeepAliveRequests="100" 
> keepAliveTimeout="1" scheme="https" secure="true" 
> clientAuth="true" sslProtocol="TLS" 
> keystoreFile="/app/comp/myapp/certs/appcerttestkeystore" 
> keystorePass="${keystore.password}" keyAlias="test" 
> truststoreFile="/app/comp/myapp/certs/cacerts" 
> truststorePass="${truststore.password}" 
> allowUnsafeLegacyRenegotiation="false" ciphers="blah blah blah" />

What is the benchmark client and how do you invoke it?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlkdK6sACgkQHPApP6U8
pFh1zxAAlYXrL7LVfojOlVFfXizjNCC9ioE1ogn2557ga0lpU34D58FxtnSeP+DK
EywaYVNAcWzckFcoTc796GJJ9DVnmZN+rbGosT5jPR42pLYw9N2M6N3MVp0PQ/Tn
hud1X9giCDIqgC3YsuxtMqfwU4haVS7+qARrfpdVf9s+J0NMjTQK1AYmM78CSLeZ
RRe13eQDZFShl4cVrJhuRilu0Bf8vKSSMXFUCPpaZo1yU6Js6IVfS+YZwTpwjtfO
EYQQjQ6t5cplpv7fvGiiiOEf43/tTH+Cyii0M2VmdYnhDh3/WJUClbVtLE2zkVSY
7TG32sSGrjpUOS5/Zucbfjsc8G5E5y9AFdZctGK9A513yiLr+uB+YEG7TehwNelN
Z3wUGKZ6KXeAtjs2HMfg2tZ+6G2VMKUWAcn2+AC/vhEfq2DjdDn4KNmFma1WMVMW
k3J8khO7zbGyWFuzOyFrZ3dQyjGwWhLsmeiALphLkIKSVcUTD93rIidlvwEu2P3x
yUDeo+sNqwu0tr5j3b+CLPSFT8rClEIuG/yw3SFpeB/6XSOwJt5U5zspVVI7HRgd
7f0q9rVCy4mL9241CF0ntV9XN5EIpRi9EnPL2nXCz2eZTWBEGVjyo0CL+z8m5DZD
skw0vv6f6AlKjYrpk5Kt4c3zJFynUf8nP2B1xJ4NFggIYWQS6Ss=
=luv6
-END PGP SIGNATURE-

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

Re: TLS handshake performance

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 5/17/17 5:31 PM, Mark Thomas wrote:
> I got asked in the corridor at TomcatCon earlier today what the 
> relative performance of the TLS handshake was with 8.5.x, the NIO 
> connector and JSSE vs OpenSSL TLS implementation.
I'm curious about what exactly "TLS handshake" was intended to mean
(by the person who asked the question) in this context.

The handshake itself does not perform any bulk transfer of encrypted
data, so the negotiated cipher suite does not matter. However...

> Tested with: ab -n 1000 -c 2 -f TLS1.2 -Z
> ECDHE-RSA-AES128-GCM-SHA256 https://localhost:8443/test.txt

Here the cipher suite matters very much, since the client is not only
performing the TLS handshake but also transferring the client's
request to the server and the server's response back to the client.

Support for a particular algorithm may dominate the benchmark, here.

What happens if you negotiate a NULL cipher for instance? Or, perform
the TLS handshake but never make an HTTP request after connecting? I
don't know of a tool that can do that out of the box (e.g. ab makes
HTTP requests, not just TLS connections) but one could be written in
Java fairly easily.

> test.txt is a 3 byte text file.
> 
> The results were: JSSE:17 reqs/sec OpenSSL: 23 reqs/sec
> 
> So around a 35% increase.

I'd like to see a NULL or very low-overhead cipher under the same
circumstances.

> YMMV with different versions of TLS and associated ciphers, JREs, 
> OpenSSl versions etc.

Noted. ;)

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlkdK1IACgkQHPApP6U8
pFhfQw/+NGm1CNQcFZ2qVzlCZ36W+TXhaKaBcWeiSCKw60jf/utEFycONRldm5Q3
cRM7Nbrfx1GcPwAs8ufedOtHgsAfzp6JkpzqwVFqZjUX1GODbJhz1vaNgQgB3mL8
YlGBoLqQIRKvQNOcTYJx5bP+tbnqARu96uINH16rMT+GQUF9nIzk+ua7ec0Goe+e
6yO6euDrkV75uOMPArBWDDToSrQVZ9QKiliqlcYpnG2IPDMu1CGWDHZtwO1pxaLG
aMbtqea9gAj42rw3NpFjUNxqYdN4EJHhCFjIIdVCAbiqs5BZQQAjcWjaRPniq45M
ySsuBLNFqPj2sltlhZrdg7CEklvDbVvVgVIWZA21pw0wyfIofZnsiy+KsLo8q/wD
gHcOF/TkQ4pAYGVoP+wh5AnQHwze2SFTJq0RE7kE0s6cohtfXeNSH/Ga6lzbJW5d
B+vHpU8+U6X1Lpha8Hg0A1KxbP7hcANfdLTiRqZNIVMQES8p6Zh+fbIX+DlVYIFR
WLFNmFADdlZ5msxHwRjfdQ8dtL6McwyvM3kmDQeADU/YzN80bhXmr8ZHJJUevTUJ
cya5zcw5MmPrzdlavXhH0VKspbprPoJxrd9llRU0ra5aNfUmJ4xA79jD5VxQmNL/
Cglw5DT8QoxG3knjZEQ8YLRj0gq0NrQXQmzowxqekfMcyNc2EGg=
=+yjT
-END PGP SIGNATURE-

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

Tomcat on macOS

[Israel Timoteo]

Hi all,

My environment is Tomcat 8.5.12, Java 1.8.0_112 running on macOS 10.12 and 
planning to update Tomcat to 8.5.15.

I’m wondering if I can get comments from the community for my questions below?


1) What tools is the community using for simultaneous applications deployment 
on several servers, let’s say more than 20?

2) Would having the logs located outside of the Tomcat home directory, if 
possible, affect Tomcat operation?

3) Are there any recommendations/best practices for installing and running 
Tomcat 8.5.15 on macOS 10.12?

4) Is JAVA_OPTS required?



Thanks for your comments.

Israel

Re: TomcatCon Meetup (UPDATE)

[Coty Sutherland]

Sorry I had to run off, hopefully you guys had a productive meeting :)

On May 17, 2017 7:02 PM, "Coty Sutherland"  wrote:

> We're sitting next to the pool. The room is occupied :(
>
> On May 17, 2017 9:12 AM, "Christopher Schultz" <
> ch...@christopherschultz.net> wrote:
>
>> All,
>>
>> Let's move the Meetup to "immediately following the Lightning Talks",
>> since that is a popular event at the conference.
>>
>> -chris
>>
>> >
>> > All,
>> >
>> > For those of you at ApacheCon in Miami, here are the details for the
>> Tomcat Meetup. Come and meet fellow members of the community, committers,
>> and new friends.
>> >
>> > Time: 18:00 EDT
>> > Place: Escorial Conference Room (where all TomcatCon sessions are being
>> held)
>> >
>> > All are welcome to the meetup, and also the inevitable dinner and
>> drinks to follow.
>> >
>> > Thanks,
>> > -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: TomcatCon Meetup (UPDATE)

[Coty Sutherland]

We're sitting next to the pool. The room is occupied :(

On May 17, 2017 9:12 AM, "Christopher Schultz" 
wrote:

> All,
>
> Let's move the Meetup to "immediately following the Lightning Talks",
> since that is a popular event at the conference.
>
> -chris
>
> >
> > All,
> >
> > For those of you at ApacheCon in Miami, here are the details for the
> Tomcat Meetup. Come and meet fellow members of the community, committers,
> and new friends.
> >
> > Time: 18:00 EDT
> > Place: Escorial Conference Room (where all TomcatCon sessions are being
> held)
> >
> > All are welcome to the meetup, and also the inevitable dinner and drinks
> to follow.
> >
> > Thanks,
> > -chris
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: how to upgrade tomcat 8.5.x?

[Daniel Savard]

2017-05-17 12:58 GMT-04:00 Richard Huntrods :

> On 16/05/2017 17:18, Igal @ Lucee.org wrote:
>>
>>> On 5/16/2017 8:27 AM, Kreuser, Peter wrote:
>>>

 I'd say a more robust (and the documented way) is to use a Tomcat-Home
 directory and a Tomcat-Base Directory.

 $CATALINA_HOME holds the actual distributed Tomcat-"Binaries" (ZIP/TGZ),
 $CATALINA_BASE holds your adapted config, libs and webapps.

 This way you can just exchange the CATALINA_HOME with a new version
 (say 8.5.15) and restart Tomcat. In case there are differences in configs
 between versions, adapt your conf using https://tomcat.apache.org/migr
 ation-85.html#Tomcat_8.5.x_configuration_file_differences

>>>
>>> I agree that separating the CATALINA_HOME from CATALINA_BASE is a much
>>> better setup, but if Tomcat was not set up like that already then for a
>>> minor upgrade this complicates the process.
>>>
>>> The simplest way to upgrade is the one I documented.
>>>
>>
>> That simple approach is incomplete. It assumes that:
>> a) the JARs in $CATALINA_HOME/bin haven't changed
>> b) the names of the JARs in $CATALINA_HOME/lib haven't changed
>> c) no configuration changes are required.
>>
>> a) sometimes happens
>>
>> b) happens when the JDT compiler is updated
>>
>> c) can be checked via the migration guides
>>
>> Mark
>>
>>
> Well, I just upgraded my servers from Tomcat 8..5.12 to 8.5.14. The
> complex way is to create a new tomcat directory for the new version, then
> rename webapps to webapps.orig and create a new webapps directory to hold
> my war files. Then compare all the config files and make appropriate
> changes to the stock config files, then test. This takes a while.
>
> So for the minor change from 12 to 14, I decided to try a new way. On my
> windows devel box, I unzipped a new download of 12 and a new download of 14
> into their own new directories, then compared all the files in both (yay
> for the ancient program "windiff").  I then built a batch file to copy only
> the changed files and tested this. Once satisfied, I built a shell script
> to make the same changes on my devel unix server, and tested this. Once I
> was sure it worked without any problems, I ported the script (and virgin
> 8.5.14 directory) to my production servers. On scheduled maintenance I shut
> down each tomcat 12, ran the script and then restarted tomcat. All worked
> perfectly.
>
> Here's the file changes from 8.5.12 to 8.5.14, no including the changes to
> "webapps" which I don't use:
>
> #!/bin/sh
>> #
>> # update files in tomcat 8.5.12 to 8.5.14
>> #
>> # when done, rename apache-tomcat-8.5.12 to apache-tomcat-8.5.14
>> # then fix the symbolic link and restart tomcat
>> #
>>
>> cp ./apache-tomcat-8.5.14/RELEASE-NOTES ../apps/apache-tomcat-8.5.12
>> cp ./apache-tomcat-8.5.14/bin/bootstrap.jar
>> ../apps/apache-tomcat-8.5.12/bin
>> cp ./apache-tomcat-8.5.14/bin/tomcat-juli.jar
>> ../apps/apache-tomcat-8.5.12/bin
>> cp ./apache-tomcat-8.5.14/lib/annotations-api.jar
>> ../apps/apache-tomcat-8.5.12/lib
>> cp ./apache-tomcat-8.5.14/lib/catalina-ant.jar
>> ../apps/apache-tomcat-8.5.12/lib
>> cp ./apache-tomcat-8.5.14/lib/catalina-ha.jar
>> ../apps/apache-tomcat-8.5.12/lib
>> cp ./apache-tomcat-8.5.14/lib/catalina-storeconfig.jar
>> ../apps/apache-tomcat-8.5.12/lib
>> cp ./apache-tomcat-8.5.14/lib/catalina-tribes.jar
>> ../apps/apache-tomcat-8.5.12/lib
>> cp ./apache-tomcat-8.5.14/lib/catalina.jar ../apps/apache-tomcat-8.5.12/l
>> ib
>> cp ./apache-tomcat-8.5.14/lib/el-api.jar ../apps/apache-tomcat-8.5.12/lib
>> cp ./apache-tomcat-8.5.14/lib/jasper-el.jar
>> ../apps/apache-tomcat-8.5.12/lib
>> cp ./apache-tomcat-8.5.14/lib/jasper.jar ../apps/apache-tomcat-8.5.12/lib
>> cp ./apache-tomcat-8.5.14/lib/jaspic-api.jar
>> ../apps/apache-tomcat-8.5.12/lib
>> cp ./apache-tomcat-8.5.14/lib/jsp-api.jar ../apps/apache-tomcat-8.5.12/l
>> ib
>> cp ./apache-tomcat-8.5.14/lib/servlet-api.jar
>> ../apps/apache-tomcat-8.5.12/lib
>> cp ./apache-tomcat-8.5.14/lib/tomcat-api.jar
>> ../apps/apache-tomcat-8.5.12/lib
>> cp ./apache-tomcat-8.5.14/lib/tomcat-coyote.jar
>> ../apps/apache-tomcat-8.5.12/lib
>> cp ./apache-tomcat-8.5.14/lib/tomcat-dbcp.jar
>> ../apps/apache-tomcat-8.5.12/lib
>> cp ./apache-tomcat-8.5.14/lib/tomcat-i18n-es.jar
>> ../apps/apache-tomcat-8.5.12/lib
>> cp ./apache-tomcat-8.5.14/lib/tomcat-i18n-fr.jar
>> ../apps/apache-tomcat-8.5.12/lib
>> cp ./apache-tomcat-8.5.14/lib/tomcat-i18n-ja.jar
>> ../apps/apache-tomcat-8.5.12/lib
>> cp ./apache-tomcat-8.5.14/lib/tomcat-jdbc.jar
>> ../apps/apache-tomcat-8.5.12/lib
>> cp ./apache-tomcat-8.5.14/lib/tomcat-jni.jar
>> ../apps/apache-tomcat-8.5.12/lib
>> cp ./apache-tomcat-8.5.14/lib/tomcat-util-scan.jar
>> ../apps/apache-tomcat-8.5.12/lib
>> cp ./apache-tomcat-8.5.14/lib/tomcat-util.jar
>> ../apps/apache-tomcat-8.5.12/lib
>> cp ./apache-tomcat-8.5.14/lib/tomcat-websocket.jar
>> ../apps/apache-tomcat-8.5.12/lib
>> cp 

TLS handshake performance

[Mark Thomas]

Hi all,

I got asked in the corridor at TomcatCon earlier today what the relative 
performance of the TLS handshake was with 8.5.x, the NIO connector and 
JSSE vs OpenSSL TLS implementation.


This might be something that is of interest to a wider audience so here 
goes...


The following results are very rough and ready and generated with my 
(slightly aging now) laptop (4 cores).


I tested trunk but the code is close enough to 8.5.x for this purpose.

I used exacty the same config for each test. The only change was to 
add/remove the tc-native library to enable/disable OpenSSL.


Tested with:
ab -n 1000 -c 2 -f TLS1.2 -Z ECDHE-RSA-AES128-GCM-SHA256 
https://localhost:8443/test.txt


test.txt is a 3 byte text file.

The results were:
JSSE:17 reqs/sec
OpenSSL: 23 reqs/sec

So around a 35% increase.

JRE: Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
OpenSSL: 1.0.2k

YMMV with different versions of TLS and associated ciphers, JREs, 
OpenSSl versions etc.


HTH,

Mark

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

How to have relative paths refer to the context root

[Jesse Altman]

Hello,

I am running Tomcat 8.5.15 on Windows 10.

I have a folder called "myapp" with my web application files inside of it.
Inside ${tomcat_base}/conf/Catalina/localhost I have my configuration file
"other.xml" with the following entry:




The index.html file lives inside myapp/client with the following text:

text file 1
text file 2

file1.txt also lives inside myapp/client
file2.txt lives inside myapp

The html file is then accessed by going to http://locahost:8080/other/client.
When clicking the "text file 1" link it correctly finds the file under
http://localhost:8080/other/client/.  When clicking on the "text file 2"
link unfortunately it looks for it under http://localhost:8080/, and it is
not found.  I was hoping since the path to file2.txt starts with a '/' it
would look for it under the context root http://localhost:8080/other/, but
unfortunately it seems to look for it under the base webapps folder.  Is
there a way to have a path refer to the context root of my application
without specifically adding the context root in there?

Thank you,

Jesse

Re: how to upgrade tomcat 8.5.x?

[Richard Huntrods]

On 16/05/2017 17:18, Igal @ Lucee.org wrote:

On 5/16/2017 8:27 AM, Kreuser, Peter wrote:


I'd say a more robust (and the documented way) is to use a 
Tomcat-Home directory and a Tomcat-Base Directory.


$CATALINA_HOME holds the actual distributed Tomcat-"Binaries" 
(ZIP/TGZ),

$CATALINA_BASE holds your adapted config, libs and webapps.

This way you can just exchange the CATALINA_HOME with a new version 
(say 8.5.15) and restart Tomcat. In case there are differences in 
configs between versions, adapt your conf using 
https://tomcat.apache.org/migration-85.html#Tomcat_8.5.x_configuration_file_differences 



I agree that separating the CATALINA_HOME from CATALINA_BASE is a 
much better setup, but if Tomcat was not set up like that already 
then for a minor upgrade this complicates the process.


The simplest way to upgrade is the one I documented.


That simple approach is incomplete. It assumes that:
a) the JARs in $CATALINA_HOME/bin haven't changed
b) the names of the JARs in $CATALINA_HOME/lib haven't changed
c) no configuration changes are required.

a) sometimes happens

b) happens when the JDT compiler is updated

c) can be checked via the migration guides

Mark



Well, I just upgraded my servers from Tomcat 8..5.12 to 8.5.14. The 
complex way is to create a new tomcat directory for the new version, 
then rename webapps to webapps.orig and create a new webapps directory 
to hold my war files. Then compare all the config files and make 
appropriate changes to the stock config files, then test. This takes a 
while.


So for the minor change from 12 to 14, I decided to try a new way. On my 
windows devel box, I unzipped a new download of 12 and a new download of 
14 into their own new directories, then compared all the files in both 
(yay for the ancient program "windiff").  I then built a batch file to 
copy only the changed files and tested this. Once satisfied, I built a 
shell script to make the same changes on my devel unix server, and 
tested this. Once I was sure it worked without any problems, I ported 
the script (and virgin 8.5.14 directory) to my production servers. On 
scheduled maintenance I shut down each tomcat 12, ran the script and 
then restarted tomcat. All worked perfectly.


Here's the file changes from 8.5.12 to 8.5.14, no including the changes 
to "webapps" which I don't use:



#!/bin/sh
#
# update files in tomcat 8.5.12 to 8.5.14
#
# when done, rename apache-tomcat-8.5.12 to apache-tomcat-8.5.14
# then fix the symbolic link and restart tomcat
#

cp ./apache-tomcat-8.5.14/RELEASE-NOTES ../apps/apache-tomcat-8.5.12
cp ./apache-tomcat-8.5.14/bin/bootstrap.jar 
../apps/apache-tomcat-8.5.12/bin
cp ./apache-tomcat-8.5.14/bin/tomcat-juli.jar 
../apps/apache-tomcat-8.5.12/bin
cp ./apache-tomcat-8.5.14/lib/annotations-api.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/catalina-ant.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/catalina-ha.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/catalina-storeconfig.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/catalina-tribes.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/catalina.jar 
../apps/apache-tomcat-8.5.12/lib

cp ./apache-tomcat-8.5.14/lib/el-api.jar ../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/jasper-el.jar 
../apps/apache-tomcat-8.5.12/lib

cp ./apache-tomcat-8.5.14/lib/jasper.jar ../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/jaspic-api.jar 
../apps/apache-tomcat-8.5.12/lib

cp ./apache-tomcat-8.5.14/lib/jsp-api.jar ../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/servlet-api.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-api.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-coyote.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-dbcp.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-i18n-es.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-i18n-fr.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-i18n-ja.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-jdbc.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-jni.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-util-scan.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-util.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-websocket.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/websocket-api.jar 
../apps/apache-tomcat-8.5.12/lib




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[ANN] Apache Tomcat 8.0.44 released

[Violeta Georgieva]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.0.44.

Please note that Tomcat 8.x users should normally be using 8.5.x
releases in preference to 8.0.x releases.

Apache Tomcat 8.0 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language and Java
WebSocket technologies.

Apache Tomcat 8.0.44 includes fixes for issues identified in 8.0.43 as
well as other enhancements and changes. The notable changes since
8.0.43 include:


- Various improvements to the handling of static custom error pages

- Update to Eclipse JDT Compiler 4.6.3

- Review those places where Tomcat re-encodes a URI or URI component
  and ensure that the correct encoding is consistently applied.


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-8.0-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-80.cgi

Migration guides from Apache Tomcat 5.5.x, 6.0.x and 7.0.x:
http://tomcat.apache.org/migration.html

Enjoy

The Apache Tomcat team

[ANN] Apache Tomcat 7.0.78 released

[Violeta Georgieva]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 7.0.78.

Apache Tomcat is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Expression Language and Java
WebSocket technologies.

This release contains a number of bug fixes and improvements compared to
version 7.0.77. The notable changes since 7.0.77 include:


- Various improvements to the handling of static custom error pages

- Review those places where Tomcat re-encodes a URI or URI component
  and ensure that the correct encoding is consistently applied.


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-70.cgi

Migration guides from Apache Tomcat 5.5.x and 6.0.x:
http://tomcat.apache.org/migration.html

Enjoy

The Apache Tomcat team

Error connecting to the database with tomcat 7 on eclipse jave ee

[Yosef Fastow]

Hi, I am running a spring framework website on eclipse jave ee using tomcat
7. When I try to connect to do anything connected to the databse it raises
a HTTP 500:

Request processing failed; nested exception is
org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get
JDBC Connection; nested exception is
org.apache.commons.dbcp.SQLNestedException: Cannot create
PoolableConnectionFactory (The driver could not establish a secure
connection to SQL Server by using Secure Sockets Layer (SSL) encryption.
Error: "java.security.cert.CertificateException: Failed to validate the
server name in a certificate during Secure Sockets Layer (SSL)
initialization. The server name is *.database.windows.net, the name in
certificate is xxx.xxx.xxx.database.windows.net.".)

(the xxx is replacing the real information)

Anyways I was wondering what is causes this error and how to fix it. I'm
using sqljdbc.4-2.0.jar if that means anything. Thanks in advance.

Re: JSP compilation 65535 bytes limit

[Vidyadhar]

On Wed, May 17, 2017 at 7:36 PM, Mohammed Manna  wrote:

> You cannot blindly execute the snippet by copying it from Tomcat website.
> You have to adapt it to your project first. Try and remove the  file> line and try to build it. You probably need to set up your project
> for Ant build first if not done already.
>
Project is already setup and same set of build file is working fine with
different version of Tomcat. If we remove the import task for this
particular project we are seeing some different error which is regarding to
ANT and not related with Tomcat or JSP compilation.
Snippet of catalina-tasks.xml is as follows ( and this is the only file
included in import):


  Catalina Ant Manager, JMX and JSPC Tasks
  
  
  
  

  
  

  
  

  

  



> On 17 May 2017 at 15:03, Vidyadhar  wrote:
>
> > On Wed, May 17, 2017 at 7:30 PM, Mohammed Manna 
> > wrote:
> >
> > > Your ant Build File seems to be incorrect. Could you provide the
> snippet
> > of
> > > the Jspc Task and Javac task for this?
> > >
> > Following is the tomcat.xml which I am using for precompilation:
> > 
> >
> >
> >
> >
> >
> >  >  validateXml="false"
> >  uriroot="${webapp.path}"
> >  webXmlFragment="${webapp.path}/WEB-INF/generated_web.xml"
> >  outputDir="${webapp.path}/WEB-INF/src" />
> >
> >   
> >
> >   
> >
> > 
> > 
> >
> >  >optimize="off"
> >debug="on" failonerror="false"
> >srcdir="${webapp.path}/WEB-INF/src"
> >excludes="**/*.smap">
> >   
> > 
> > 
> >   
> > 
> > 
> > 
> >   
> > 
> > 
> >   
> > 
> >   
> >   
> >   
> > 
> >
> >   
> >
> >   
> >   
> >
> >   
> > 
> > 
> > 
> > 
> >   
> >
> > 
> >
> > >
> > > On 17 May 2017 at 14:58, Vidyadhar  wrote:
> > >
> > > > Hello KR,
> > > >
> > > > On Tue, May 16, 2017 at 8:43 PM, Mohammed Manna 
> > > > wrote:
> > > >
> > > > > Hi Vidyadhar,
> > > > >
> > > > > Some points to note here:
> > > > >
> > > > > 1) Setting those parameters in Web.xml file (CATALINA_HOME/conf)
> > > doesn't
> > > > > guarantee that it won't happen. Tomcat 8.0.43 onwards have got this
> > > > relaxed
> > > > > out by using a more efficient error handling code. But you will
> have
> > > this
> > > > > error if the code is truly hitting near the limit.
> > > > > 2) The issue occurs with Tomcat 8.0.39 onwards. Try to see if the
> > issue
> > > > > happens for tomcat 8.0.29. I can vouch for 8.0.29 where it didn't
> > > happen.
> > > > > 3) Did you try and follow my suggestion on point 3 (last email)
> about
> > > > > checking the method sizes of the precompiled JSPs using apache
> > commons
> > > > BCEL
> > > > > (bcel-5.4.1.jar) library? If yes, what did you find?
> > > > >
> > > >
> > > > I already tried to precompile the JSPs using ANT but it is giving
> > > following
> > > > error:
> > > > C:\apache-ant-1.9.4\tomcat.xml:11: org.apache.jasper.
> JasperException:
> > > > java.lang.IllegalArgumentException: Page directive: invalid value
> for
> > > > import
> > > > at org.apache.jasper.JspC.processFile(JspC.java:1296)
> > > > at org.apache.jasper.JspC.execute(JspC.java:1415)
> > > > at
> > > > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> > > > I guess I am hitting the bug # 57099 and there are multiple JSPs
> > wherein
> > > we
> > > > need to do these changes.
> > > >
> > > > >
> > > > >
> > > > > You also haven't mentioned what sort of JSPs you have that yields
> > into
> > > > such
> > > > > error. Are you having legacy scriptlets which are quite heavy and
> > uses
> > > > lots
> > > > > of custom tags? Try to use the following too:
> > > > >
> > > > > 
> > > > > trimSpaces
> > > > > true
> > > > > 
> > > > >
> > > > > The above is having some inconsistency reported in a different
> email
> > > > > thread, but I assume it should be fine in most of the cases. Try to
> > see
> > > > if
> > > > > you can provide some results on the above points.
> > > > >
> > > > >
> > > > > KR,
> > > > >
> > > > > On 16 May 2017 at 15:29, Vidyadhar 
> wrote:
> > > > >
> > > > > > Hello KR,
> > > > > >
> > > > > > On Fri, May 12, 2017 at 12:37 PM, Mohammed Manna <
> > manme...@gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > I have two things which you might want to try out:
> > > > > > >
> > > > > > > 1) You will lose your JSP debugging capability - but if that's
> > not
> > > > your
> > > > > > > concern, then in your CATALINA_HOME\conf folder append this for
> > > > > > > "JspServlet"
> > > > > > >
> > > > > > > 
> > > > > > > mappedfile
> > > > > 

Re: JSP compilation 65535 bytes limit

[Mohammed Manna]

You cannot blindly execute the snippet by copying it from Tomcat website.
You have to adapt it to your project first. Try and remove the  line and try to build it. You probably need to set up your project
for Ant build first if not done already.

On 17 May 2017 at 15:03, Vidyadhar  wrote:

> On Wed, May 17, 2017 at 7:30 PM, Mohammed Manna 
> wrote:
>
> > Your ant Build File seems to be incorrect. Could you provide the snippet
> of
> > the Jspc Task and Javac task for this?
> >
> Following is the tomcat.xml which I am using for precompilation:
> 
>
>
>
>
>
>   validateXml="false"
>  uriroot="${webapp.path}"
>  webXmlFragment="${webapp.path}/WEB-INF/generated_web.xml"
>  outputDir="${webapp.path}/WEB-INF/src" />
>
>   
>
>   
>
> 
> 
>
> optimize="off"
>debug="on" failonerror="false"
>srcdir="${webapp.path}/WEB-INF/src"
>excludes="**/*.smap">
>   
> 
> 
>   
> 
> 
> 
>   
> 
> 
>   
> 
>   
>   
>   
> 
>
>   
>
>   
>   
>
>   
> 
> 
> 
> 
>   
>
> 
>
> >
> > On 17 May 2017 at 14:58, Vidyadhar  wrote:
> >
> > > Hello KR,
> > >
> > > On Tue, May 16, 2017 at 8:43 PM, Mohammed Manna 
> > > wrote:
> > >
> > > > Hi Vidyadhar,
> > > >
> > > > Some points to note here:
> > > >
> > > > 1) Setting those parameters in Web.xml file (CATALINA_HOME/conf)
> > doesn't
> > > > guarantee that it won't happen. Tomcat 8.0.43 onwards have got this
> > > relaxed
> > > > out by using a more efficient error handling code. But you will have
> > this
> > > > error if the code is truly hitting near the limit.
> > > > 2) The issue occurs with Tomcat 8.0.39 onwards. Try to see if the
> issue
> > > > happens for tomcat 8.0.29. I can vouch for 8.0.29 where it didn't
> > happen.
> > > > 3) Did you try and follow my suggestion on point 3 (last email) about
> > > > checking the method sizes of the precompiled JSPs using apache
> commons
> > > BCEL
> > > > (bcel-5.4.1.jar) library? If yes, what did you find?
> > > >
> > >
> > > I already tried to precompile the JSPs using ANT but it is giving
> > following
> > > error:
> > > C:\apache-ant-1.9.4\tomcat.xml:11: org.apache.jasper.JasperException:
> > > java.lang.IllegalArgumentException: Page directive: invalid value for
> > > import
> > > at org.apache.jasper.JspC.processFile(JspC.java:1296)
> > > at org.apache.jasper.JspC.execute(JspC.java:1415)
> > > at
> > > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > I guess I am hitting the bug # 57099 and there are multiple JSPs
> wherein
> > we
> > > need to do these changes.
> > >
> > > >
> > > >
> > > > You also haven't mentioned what sort of JSPs you have that yields
> into
> > > such
> > > > error. Are you having legacy scriptlets which are quite heavy and
> uses
> > > lots
> > > > of custom tags? Try to use the following too:
> > > >
> > > > 
> > > > trimSpaces
> > > > true
> > > > 
> > > >
> > > > The above is having some inconsistency reported in a different email
> > > > thread, but I assume it should be fine in most of the cases. Try to
> see
> > > if
> > > > you can provide some results on the above points.
> > > >
> > > >
> > > > KR,
> > > >
> > > > On 16 May 2017 at 15:29, Vidyadhar  wrote:
> > > >
> > > > > Hello KR,
> > > > >
> > > > > On Fri, May 12, 2017 at 12:37 PM, Mohammed Manna <
> manme...@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > I have two things which you might want to try out:
> > > > > >
> > > > > > 1) You will lose your JSP debugging capability - but if that's
> not
> > > your
> > > > > > concern, then in your CATALINA_HOME\conf folder append this for
> > > > > > "JspServlet"
> > > > > >
> > > > > > 
> > > > > > mappedfile
> > > > > > false
> > > > > > 
> > > > > > 
> > > > > > suppressSmap
> > > > > > true
> > > > > > 
> > > > > >
> > > > > We already tried this option. We included these lines in tomcat's
> > > web.xml
> > > > > file and restarted the services, but still it is giving the same
> > error.
> > > > >
> > > > > >
> > > > > >  This will stop generating JSR45 debug info and Symbol Maps
> for
> > > JSP
> > > > > > pages ( I think I have said technical things right here,
> otherwise
> > > > please
> > > > > > correct me!).
> > > > > >
> > > > > > 2) I sincerely recommend moving scriptlet code out of your JSP
> and
> > > > remove
> > > > > > all unwanted/commented code, newline/carriages from your JSP.
> Even
> > > with
> > > > > the
> > > > > > config above, this might fail since the code is genuinely too
> large
> > > for
> > > 

Re: JSP compilation 65535 bytes limit

[Vidyadhar]

On Wed, May 17, 2017 at 7:30 PM, Mohammed Manna  wrote:

> Your ant Build File seems to be incorrect. Could you provide the snippet of
> the Jspc Task and Javac task for this?
>
Following is the tomcat.xml which I am using for precompilation:


   

   



  

  





  


  



  


  

  
  
  


  

  
  

  




  



>
> On 17 May 2017 at 14:58, Vidyadhar  wrote:
>
> > Hello KR,
> >
> > On Tue, May 16, 2017 at 8:43 PM, Mohammed Manna 
> > wrote:
> >
> > > Hi Vidyadhar,
> > >
> > > Some points to note here:
> > >
> > > 1) Setting those parameters in Web.xml file (CATALINA_HOME/conf)
> doesn't
> > > guarantee that it won't happen. Tomcat 8.0.43 onwards have got this
> > relaxed
> > > out by using a more efficient error handling code. But you will have
> this
> > > error if the code is truly hitting near the limit.
> > > 2) The issue occurs with Tomcat 8.0.39 onwards. Try to see if the issue
> > > happens for tomcat 8.0.29. I can vouch for 8.0.29 where it didn't
> happen.
> > > 3) Did you try and follow my suggestion on point 3 (last email) about
> > > checking the method sizes of the precompiled JSPs using apache commons
> > BCEL
> > > (bcel-5.4.1.jar) library? If yes, what did you find?
> > >
> >
> > I already tried to precompile the JSPs using ANT but it is giving
> following
> > error:
> > C:\apache-ant-1.9.4\tomcat.xml:11: org.apache.jasper.JasperException:
> > java.lang.IllegalArgumentException: Page directive: invalid value for
> > import
> > at org.apache.jasper.JspC.processFile(JspC.java:1296)
> > at org.apache.jasper.JspC.execute(JspC.java:1415)
> > at
> > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > I guess I am hitting the bug # 57099 and there are multiple JSPs wherein
> we
> > need to do these changes.
> >
> > >
> > >
> > > You also haven't mentioned what sort of JSPs you have that yields into
> > such
> > > error. Are you having legacy scriptlets which are quite heavy and uses
> > lots
> > > of custom tags? Try to use the following too:
> > >
> > > 
> > > trimSpaces
> > > true
> > > 
> > >
> > > The above is having some inconsistency reported in a different email
> > > thread, but I assume it should be fine in most of the cases. Try to see
> > if
> > > you can provide some results on the above points.
> > >
> > >
> > > KR,
> > >
> > > On 16 May 2017 at 15:29, Vidyadhar  wrote:
> > >
> > > > Hello KR,
> > > >
> > > > On Fri, May 12, 2017 at 12:37 PM, Mohammed Manna  >
> > > > wrote:
> > > >
> > > > > I have two things which you might want to try out:
> > > > >
> > > > > 1) You will lose your JSP debugging capability - but if that's not
> > your
> > > > > concern, then in your CATALINA_HOME\conf folder append this for
> > > > > "JspServlet"
> > > > >
> > > > > 
> > > > > mappedfile
> > > > > false
> > > > > 
> > > > > 
> > > > > suppressSmap
> > > > > true
> > > > > 
> > > > >
> > > > We already tried this option. We included these lines in tomcat's
> > web.xml
> > > > file and restarted the services, but still it is giving the same
> error.
> > > >
> > > > >
> > > > >  This will stop generating JSR45 debug info and Symbol Maps for
> > JSP
> > > > > pages ( I think I have said technical things right here, otherwise
> > > please
> > > > > correct me!).
> > > > >
> > > > > 2) I sincerely recommend moving scriptlet code out of your JSP and
> > > remove
> > > > > all unwanted/commented code, newline/carriages from your JSP. Even
> > with
> > > > the
> > > > > config above, this might fail since the code is genuinely too large
> > for
> > > > > __jspService().
> > > > >
> > > > > 3) If possible, try to use Ant and precompile your JSP and iterate
> > > > through
> > > > > the .class files to check which method size is larger or close to
> 90%
> > > or
> > > > > the 64k footprint. You can write a short program by leveraging
> > java.io
> > > > and
> > > > > Apache commons BCEL library. Ant has a strange behaviour which
> > doesn't
> > > > > throw any exceptions if the Jsp method size exceeds the limit. But
> > the
> > > > > compilation occurs anyway. So you can go through those compiled
> files
> > > > using
> > > > > your custom tool and print the size of the methods.
> > > > >
> > > > >
> > > > > I hope this helps you.
> > > > >
> > > > > Further to above we tried various tomcat version and as per our
> > > > observation we are not seeing this error on 8.0.29 version. Note that
> > the
> > > > same error is still there in latest version i.e. 8.5.15.
> > > >
> > > > > KR,
> > > > >
> > > > > On 12 May 2017 at 07:58, Vidyadhar 

Re: JSP compilation 65535 bytes limit

[Mohammed Manna]

Your ant Build File seems to be incorrect. Could you provide the snippet of
the Jspc Task and Javac task for this?

On 17 May 2017 at 14:58, Vidyadhar  wrote:

> Hello KR,
>
> On Tue, May 16, 2017 at 8:43 PM, Mohammed Manna 
> wrote:
>
> > Hi Vidyadhar,
> >
> > Some points to note here:
> >
> > 1) Setting those parameters in Web.xml file (CATALINA_HOME/conf) doesn't
> > guarantee that it won't happen. Tomcat 8.0.43 onwards have got this
> relaxed
> > out by using a more efficient error handling code. But you will have this
> > error if the code is truly hitting near the limit.
> > 2) The issue occurs with Tomcat 8.0.39 onwards. Try to see if the issue
> > happens for tomcat 8.0.29. I can vouch for 8.0.29 where it didn't happen.
> > 3) Did you try and follow my suggestion on point 3 (last email) about
> > checking the method sizes of the precompiled JSPs using apache commons
> BCEL
> > (bcel-5.4.1.jar) library? If yes, what did you find?
> >
>
> I already tried to precompile the JSPs using ANT but it is giving following
> error:
> C:\apache-ant-1.9.4\tomcat.xml:11: org.apache.jasper.JasperException:
> java.lang.IllegalArgumentException: Page directive: invalid value for
> import
> at org.apache.jasper.JspC.processFile(JspC.java:1296)
> at org.apache.jasper.JspC.execute(JspC.java:1415)
> at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> I guess I am hitting the bug # 57099 and there are multiple JSPs wherein we
> need to do these changes.
>
> >
> >
> > You also haven't mentioned what sort of JSPs you have that yields into
> such
> > error. Are you having legacy scriptlets which are quite heavy and uses
> lots
> > of custom tags? Try to use the following too:
> >
> > 
> > trimSpaces
> > true
> > 
> >
> > The above is having some inconsistency reported in a different email
> > thread, but I assume it should be fine in most of the cases. Try to see
> if
> > you can provide some results on the above points.
> >
> >
> > KR,
> >
> > On 16 May 2017 at 15:29, Vidyadhar  wrote:
> >
> > > Hello KR,
> > >
> > > On Fri, May 12, 2017 at 12:37 PM, Mohammed Manna 
> > > wrote:
> > >
> > > > I have two things which you might want to try out:
> > > >
> > > > 1) You will lose your JSP debugging capability - but if that's not
> your
> > > > concern, then in your CATALINA_HOME\conf folder append this for
> > > > "JspServlet"
> > > >
> > > > 
> > > > mappedfile
> > > > false
> > > > 
> > > > 
> > > > suppressSmap
> > > > true
> > > > 
> > > >
> > > We already tried this option. We included these lines in tomcat's
> web.xml
> > > file and restarted the services, but still it is giving the same error.
> > >
> > > >
> > > >  This will stop generating JSR45 debug info and Symbol Maps for
> JSP
> > > > pages ( I think I have said technical things right here, otherwise
> > please
> > > > correct me!).
> > > >
> > > > 2) I sincerely recommend moving scriptlet code out of your JSP and
> > remove
> > > > all unwanted/commented code, newline/carriages from your JSP. Even
> with
> > > the
> > > > config above, this might fail since the code is genuinely too large
> for
> > > > __jspService().
> > > >
> > > > 3) If possible, try to use Ant and precompile your JSP and iterate
> > > through
> > > > the .class files to check which method size is larger or close to 90%
> > or
> > > > the 64k footprint. You can write a short program by leveraging
> java.io
> > > and
> > > > Apache commons BCEL library. Ant has a strange behaviour which
> doesn't
> > > > throw any exceptions if the Jsp method size exceeds the limit. But
> the
> > > > compilation occurs anyway. So you can go through those compiled files
> > > using
> > > > your custom tool and print the size of the methods.
> > > >
> > > >
> > > > I hope this helps you.
> > > >
> > > > Further to above we tried various tomcat version and as per our
> > > observation we are not seeing this error on 8.0.29 version. Note that
> the
> > > same error is still there in latest version i.e. 8.5.15.
> > >
> > > > KR,
> > > >
> > > > On 12 May 2017 at 07:58, Vidyadhar  wrote:
> > > >
> > > > > Hello Sagar,
> > > > >
> > > > > On Fri, 12 May 2017 at 12:26 PM, sagar kohli <
> sagarkohl...@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Try adding following init parameter in /conf/web.xml
> > > > > >
> > > > > > 
> > > > > >  mappedfile
> > > > > >  false
> > > > > > 
> > > > >
> > > > >
> > > > > We already tried it but no success.
> > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, May 12, 2017 at 10:28 AM, Vidyadhar <
> > > techienote@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hello Team,
> > > > > > >
> > > > > > > Recently we did a upgrade existing 

Re: JSP compilation 65535 bytes limit

[Vidyadhar]

Hello KR,

On Tue, May 16, 2017 at 8:43 PM, Mohammed Manna  wrote:

> Hi Vidyadhar,
>
> Some points to note here:
>
> 1) Setting those parameters in Web.xml file (CATALINA_HOME/conf) doesn't
> guarantee that it won't happen. Tomcat 8.0.43 onwards have got this relaxed
> out by using a more efficient error handling code. But you will have this
> error if the code is truly hitting near the limit.
> 2) The issue occurs with Tomcat 8.0.39 onwards. Try to see if the issue
> happens for tomcat 8.0.29. I can vouch for 8.0.29 where it didn't happen.
> 3) Did you try and follow my suggestion on point 3 (last email) about
> checking the method sizes of the precompiled JSPs using apache commons BCEL
> (bcel-5.4.1.jar) library? If yes, what did you find?
>

I already tried to precompile the JSPs using ANT but it is giving following
error:
C:\apache-ant-1.9.4\tomcat.xml:11: org.apache.jasper.JasperException:
java.lang.IllegalArgumentException: Page directive: invalid value for import
at org.apache.jasper.JspC.processFile(JspC.java:1296)
at org.apache.jasper.JspC.execute(JspC.java:1415)
at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
I guess I am hitting the bug # 57099 and there are multiple JSPs wherein we
need to do these changes.

>
>
> You also haven't mentioned what sort of JSPs you have that yields into such
> error. Are you having legacy scriptlets which are quite heavy and uses lots
> of custom tags? Try to use the following too:
>
> 
> trimSpaces
> true
> 
>
> The above is having some inconsistency reported in a different email
> thread, but I assume it should be fine in most of the cases. Try to see if
> you can provide some results on the above points.
>
>
> KR,
>
> On 16 May 2017 at 15:29, Vidyadhar  wrote:
>
> > Hello KR,
> >
> > On Fri, May 12, 2017 at 12:37 PM, Mohammed Manna 
> > wrote:
> >
> > > I have two things which you might want to try out:
> > >
> > > 1) You will lose your JSP debugging capability - but if that's not your
> > > concern, then in your CATALINA_HOME\conf folder append this for
> > > "JspServlet"
> > >
> > > 
> > > mappedfile
> > > false
> > > 
> > > 
> > > suppressSmap
> > > true
> > > 
> > >
> > We already tried this option. We included these lines in tomcat's web.xml
> > file and restarted the services, but still it is giving the same error.
> >
> > >
> > >  This will stop generating JSR45 debug info and Symbol Maps for JSP
> > > pages ( I think I have said technical things right here, otherwise
> please
> > > correct me!).
> > >
> > > 2) I sincerely recommend moving scriptlet code out of your JSP and
> remove
> > > all unwanted/commented code, newline/carriages from your JSP. Even with
> > the
> > > config above, this might fail since the code is genuinely too large for
> > > __jspService().
> > >
> > > 3) If possible, try to use Ant and precompile your JSP and iterate
> > through
> > > the .class files to check which method size is larger or close to 90%
> or
> > > the 64k footprint. You can write a short program by leveraging java.io
> > and
> > > Apache commons BCEL library. Ant has a strange behaviour which doesn't
> > > throw any exceptions if the Jsp method size exceeds the limit. But the
> > > compilation occurs anyway. So you can go through those compiled files
> > using
> > > your custom tool and print the size of the methods.
> > >
> > >
> > > I hope this helps you.
> > >
> > > Further to above we tried various tomcat version and as per our
> > observation we are not seeing this error on 8.0.29 version. Note that the
> > same error is still there in latest version i.e. 8.5.15.
> >
> > > KR,
> > >
> > > On 12 May 2017 at 07:58, Vidyadhar  wrote:
> > >
> > > > Hello Sagar,
> > > >
> > > > On Fri, 12 May 2017 at 12:26 PM, sagar kohli  >
> > > > wrote:
> > > >
> > > > > Try adding following init parameter in /conf/web.xml
> > > > >
> > > > > 
> > > > >  mappedfile
> > > > >  false
> > > > > 
> > > >
> > > >
> > > > We already tried it but no success.
> > > >
> > > > >
> > > > >
> > > > > On Fri, May 12, 2017 at 10:28 AM, Vidyadhar <
> > techienote@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hello Team,
> > > > > >
> > > > > > Recently we did a upgrade existing tomcat from 7.0.42 to 7.0.76
> on
> > > > > windows
> > > > > > box. Post the up gradation we are seeing following error in
> couple
> > of
> > > > > JSPs
> > > > > >
> > > > > > org.apache.jasper.JasperException: Unable to compile class for
> > JSP:
> > > > > >
> > > > > > An error occurred at line: [231] in the generated java file:
> > > > [C:\Program
> > > > > > Files\Apache\Tomcat\work\Catalina\localhost\app\org\
> > apache\jsp\jsp\
> > > > > > 

Re: trimSpaces removing whitespace from html

[Mark Thomas]

On 15/05/2017 10:29, David Kavanagh wrote:

Ok cool, hopefully that will reproduce so you can see for yourself.
Thanks!


I've done the best I can to reproduce this without the access to the 
commerical tag library you appear to be using without success.


I've also checked the trimSpaces implementation and I can't see how an 
attribute value could be corrupted.


At this point I'm inclined to think this is not a Tomcat problem. If you 
can provide a simple test case (e.g JSP and tag file) that can be 
dropped into Tomcat to demonstrate this problem then I'd be happy to 
look at this further.


Mark





On 15 May 2017 at 10:39, Mark Thomas  wrote:


On 12/05/17 17:08, David Kavanagh wrote:

Yes, this is one of the .jsp files. I don't know how useful this is.


Hopefully this will reproduce this. Looking at this is on my TODO list
while I'm at ApacheCon.


Has anyone heard of a similar issue using trimSpaces before, or do you
think this might be something to do with the particular files being used?


This isn't anything I recall seeing before. The parsing is all handled
by the JRE. While historically the XML parsing provided by the JRE was
fairly buggy, these days it is much better. One thing on my TODO list is
to check the XML specs to make sure that any required escaping is not
missing or something along those lines.





Thanks

<%@taglib prefix="dali" uri="http://dev.marfeel.com/jsp/mrf/dali; %>
<%@taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core; %>

<%@page pageEncoding="UTF-8" %>




On 11 May 2017 at 18:35, Mark Thomas  wrote:


On 11 May 2017 15:34:32 BST, David Kavanagh  wrote:


Am Donnerstag, den 11.05.2017, 09:23 -0400 schrieb Christopher

Schultz:

So, removing the trailing space in the "class" attribute's value?


That too - but have a look at:

mrf-mmrf-image

it was before / should be:

mrf-m mrf-image

there are missing whitespaces in the actual class attributes content.

Torsten


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




Can you provide the simplest JSP that reproduces this issue?

Mark

-
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

RE: Can't get over 100 client connections?

[John.E.Gregg]

André,


> -Original Message-
> From: André Warnier (tomcat) [mailto:a...@ice-sa.com]
> Sent: Tuesday, May 16, 2017 2:00 PM
> To: users@tomcat.apache.org
> Subject: Re: Can't get over 100 client connections?
> 
> On 16.05.2017 19:57, john.e.gr...@wellsfargo.com.INVALID wrote:
> > All,
> >
> > I'm using Tomcat 7.0.75.
> >
> > I cannot get my connection or thread count over 100 no matter how much
> load I throw at the server.  Currently I just have a dummy app deployed that
> doesn't do much except sleep for about 500ms and return a canned
> response.  Initially I had maxThreads=20 with no explicit maxConnections.  I
> could get the "current threads busy" metric to 20 easily.  Then I raised it to
> 100 and was able to reach that number easily.  Additionally, netstat told me I
> had 100 incoming connections to port 5114.  However raising the maxThreads
> higher doesn't make any difference, nor does explicitly specifying
> maxConnections=200.  In either case, I can only get 100 busy threads and 100
> active connections.  Once I reach that limit, the response times on the client
> start going up.  The Tomcat server itself isn't stressed at all.  CPU and GC 
> are
> low.  The client is on a different server in the same data center.
> >
> > I'm not going through a load balancer.  I'm going directly to the connector
> below:
> >
> >
> >   >  protocol="HTTP/1.1"
> >  SSLEnabled="true"
> >  maxConnections="200"
> >  maxThreads="200"
> >  maxKeepAliveRequests="100"
> >  keepAliveTimeout="1"
> >  scheme="https"
> >  secure="true"
> >  clientAuth="true"
> >  sslProtocol="TLS"
> >  keystoreFile="/app/comp/myapp/certs/appcerttestkeystore"
> >  keystorePass="${keystore.password}"
> >  keyAlias="test"
> >  truststoreFile="/app/comp/myapp/certs/cacerts"
> >  truststorePass="${truststore.password}"
> >  allowUnsafeLegacyRenegotiation="false"
> >  ciphers="blah blah blah"
> >  />
> >
> 
> Hi.
> I do not know with what you are testing (as a client).
> But be aware of the following :
> 
> 1) >  keepAliveTimeout="1"
> means 10 seconds.
> It means that, after the last request which one particular client sends on its
> connection to Tomcat, and Tomcat has responded to it, Tomcat will keep that
> connection open for an additional 10 s., just waiting to see if that same 
> client
> has anything more to request.
> Since you are not using an Executor, keeping the connection open will also
> mean keeping the corresponding Tomcat thread alive, also waiting.
> Only once this time is over, will Tomcat close this connection, and "recycle"
> the thread to serve another client connection.
> 2) there may be a limit in the server OS, as to how many connections a
> process can have open at the same time. If that limit is reached at some
> point, that may either crash the process that wants an additional one, or put
> it in some wait queue until one is available again.
> 3) when a client opens a connection to a server (or tries to), and the server
> process does not immediately respond to the "open connection" request,
> the TCP/IP stack on the server will place the connection-open request in a
> wait queue. The size of that queue is an adjustable TCP/IP parameter.
>  From the client side, if its connection is not accepted immediately (but not
> rejected right away), the client will just wait, until it is accepted. There 
> is
> usually a timeout for this also, on the client side.
> 
> Some combination of the above may explain what you see.
> 

Thanks for the suggestions.  I don't know 100% the cause yet but it appears to 
be an issue on the client side.  When running multiple clients I can get the 
concurrent requests over 100 with no trouble.

Thanks


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

Tomcat 8.5: wrong classloader used during context startup?

[Michael Heinen]

I am currently migrating a web app from Tomcat 7.0.73 to 8.5.15. An 
embedded Tomcat is used on development systems.


The web-inf/lib folder of the application contains a jar with a 
SAXParserFactory implementation. This SAXParserFactory is now used with 
TC 8.5 by the WebXmlParser in order to parse the web.xml (and fails 
unfortunately). The ServiceLoader finds the jar because the 
ParallelWebappClassLoader is used for the lookup.


TC 7.0.73 uses the sun.misc.Launcher$AppClassLoader and does therefore 
not use the jar under web-inf\lib. It creates the webXml Digester in the 
init() phase of the stanrardContext. TC 8.5 does this in the 
startInternal() phase where the ParallelWebappClassLoader is 
instantiated and bound to the current thread.


Specifying "javax.xml.parsers.SAXParserFactory" as VM param solves the 
issue of course.


My question:
Is this behaviour expected?
Should Tomcat use libraries of the web app for the startup of a context, 
here for web-xml parsing?


Regards,
Michael

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

Re: TomcatCon Meetup (UPDATE)

[Christopher Schultz]

All,

Let's move the Meetup to "immediately following the Lightning Talks", since 
that is a popular event at the conference.

-chris

> 
> All,
> 
> For those of you at ApacheCon in Miami, here are the details for the Tomcat 
> Meetup. Come and meet fellow members of the community, committers, and new 
> friends.
> 
> Time: 18:00 EDT
> Place: Escorial Conference Room (where all TomcatCon sessions are being held)
> 
> All are welcome to the meetup, and also the inevitable dinner and drinks to 
> follow.
> 
> Thanks,
> -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: AW: how to upgrade tomcat 8.5.x?

[Mark Thomas]

On 16/05/2017 17:18, Igal @ Lucee.org wrote:

On 5/16/2017 8:27 AM, Kreuser, Peter wrote:


I'd say a more robust (and the documented way) is to use a Tomcat-Home 
directory and a Tomcat-Base Directory.


$CATALINA_HOME holds the actual distributed Tomcat-"Binaries" (ZIP/TGZ),
$CATALINA_BASE holds your adapted config, libs and webapps.

This way you can just exchange the CATALINA_HOME with a new version 
(say 8.5.15) and restart Tomcat. In case there are differences in 
configs between versions, adapt your conf using 
https://tomcat.apache.org/migration-85.html#Tomcat_8.5.x_configuration_file_differences 



I agree that separating the CATALINA_HOME from CATALINA_BASE is a much 
better setup, but if Tomcat was not set up like that already then for a 
minor upgrade this complicates the process.


The simplest way to upgrade is the one I documented.


That simple approach is incomplete. It assumes that:
a) the JARs in $CATALINA_HOME/bin haven't changed
b) the names of the JARs in $CATALINA_HOME/lib haven't changed
c) no configuration changes are required.

a) sometimes happens

b) happens when the JDT compiler is updated

c) can be checked via the migration guides

Mark

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