Re: TLS 1.0 and "HTTP Security Header Not Detected" on Tomcat 7, running under Java 7

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

James,

On 2/6/19 12:21, James H. H. Lampert wrote:
> Thanks. I do have some follow up questions
> 
> On 2/6/19, 1:04 AM, Mark Thomas wrote:
>> On the TLS Connector:
>> 
>> sslEnabledProtocols="TLSv1.1,TLSv1.2"
> 
> Ok. So the active connector we currently have for this particular 
> installation (which has multiple IP addresses, hence the "address" 
> clause) is:
>> > protocol="org.apache.coyote.http11.Http11Protocol"
>> address="REDACTED" maxThreads="150" SSLEnabled="true"
>> scheme="https" secure="true" keystoreFile="REDACTED"
>> keyAlias="REDACTED"
>> 
>> ciphers="SSL_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_AES_128_CBC_SHA"
>>
>> 
clientAuth="false" sslProtocol="TLS" />
> 
> So I can just add the sslEnabledProtcols clause to the end of
> this?

Be careful: specifying a specific list of cipher suites limits what
the client+server will allow. You can handshake using TLSv1.2 but then
use a crappy cipher which then actually reduces your security. For
instance, the SSL_*CBC_SHA ciphers are all considered weak because of
the use of CBC.

https://crypto.stackexchange.com/a/52568

Unless you really need to be picky about the ciphers you support, you
shouldn't use a very short list like this one you have here.

When you upgrade from Tomcat 7, you should be able to use
OpenSSL-style configuration, which means you don't have to list every
single cipher suite you want to support -- you can say "anything that
has EDCHE is cool" and let Tomcat figure out what the environment will
support, for example. You can even say "anything but MD5" , etc. It's
quite expressive and much better than individually whitelisting ciphers.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxcZdgACgkQHPApP6U8
pFizZxAAsglgKwMO3aoLxqq+A4rWS8Qn7DKkBgfUGbU+2RXyl3vLhwclvtjoObsh
Llvce9LCmjmrZY1yKZcNe8sTU4dAbXQcjGr/Db7uEL8FWVZ8eF5jHZj5lQIt3FxZ
qQ7/aEsFgWTvAlRHM5nGv9mkYP0t7MyBSn3YI3xrIrtv5x0bn62jjJHEn9jg+pP9
BLPujVi3qEQMH6lQfd7PM9M3QfRyNyzPHmdt+7KIy53WTDWEYnMo2KuXX8lO3yY/
OUkSiCuSAl1KunHRkt2J70UrEwfgtcEsVi3ZTGgQiBv+GAmVCwPfdm4tsP+4Zxkk
Fs0eVKpcD0rcL1mCA6Twmrm0k7qbN07j9fuTsU9N+wyTlyLazGioLshb9TSx4Vws
aWtA9m/hfjjNgQXzzEDwrjod+RuN3cEDquHJVIdBh7fSqsz3uCrMYstb4aj36mFK
IIqjOfnyqel2TYsGVuSQFCIcDRrjdGEb1Ut4S4WCWtXAnKTHI8jT5X5AVxnS+CEy
4f6A/a3adQAGIc43gMP9kQAPxQOsUphkGk2ryYV5asCg/MBIg2MCk8OV8jxd7i8S
TXAe44jgrBQPeMiKARbqzzzdyzMiW1XM/a5YQA5KprndNJf+0/pHZjzXRAWY7c+s
dTcIp27HHz12Yi3uAlryidEKEe/rZ7pNFE5zLVWJyxfxSncvBDs=
=idYY
-END PGP SIGNATURE-

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

Re: TLS 1.0 and "HTTP Security Header Not Detected" on Tomcat 7, running under Java 7

[Mark Thomas]

On 06/02/2019 17:21, James H. H. Lampert wrote:
> Thanks. I do have some follow up questions
> 
> On 2/6/19, 1:04 AM, Mark Thomas wrote:
>> On the TLS Connector:
>>
>> sslEnabledProtocols="TLSv1.1,TLSv1.2"
> 
> Ok. So the active connector we currently have for this particular
> installation (which has multiple IP addresses, hence the "address"
> clause) is:
>> > protocol="org.apache.coyote.http11.Http11Protocol" address="REDACTED"
>>    maxThreads="150" SSLEnabled="true" scheme="https"
>> secure="true"
>>    keystoreFile="REDACTED" keyAlias="REDACTED"
>>   
>> ciphers="SSL_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_AES_128_CBC_SHA"
>>    clientAuth="false" sslProtocol="TLS" />
> 
> So I can just add the sslEnabledProtcols clause to the end of this?

Yes.

>>> 17369 - HTTP Security Header Not Detected.
>> It looks like this one:
>>
>> https://community.qualys.com/thread/17369-http-security-header-not-detected
>>
> 
> I concur on that, but how do I add the headers it's looking for?

Depending on what exactly what is missing, the built-in
HttpHeaderSecurityFilter may be able to help. If that can't met the
requirement you'll probably need to write a custom Filter - or get the
app devs to add one.

Mark

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

Re: TLS 1.0 and "HTTP Security Header Not Detected" on Tomcat 7, running under Java 7

[James H. H. Lampert]

Thanks. I do have some follow up questions

On 2/6/19, 1:04 AM, Mark Thomas wrote:

On the TLS Connector:

sslEnabledProtocols="TLSv1.1,TLSv1.2"


Ok. So the active connector we currently have for this particular 
installation (which has multiple IP addresses, hence the "address" 
clause) is:




So I can just add the sslEnabledProtcols clause to the end of this?


17369 - HTTP Security Header Not Detected.

It looks like this one:

https://community.qualys.com/thread/17369-http-security-header-not-detected


I concur on that, but how do I add the headers it's looking for?

--
JHHL


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

Re: TLS 1.0 and "HTTP Security Header Not Detected" on Tomcat 7, running under Java 7

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark and James,

On 2/6/19 04:04, Mark Thomas wrote:
> On 05/02/2019 23:49, James H. H. Lampert wrote:
>> We've just received word from a customer that they had two 
>> vulnerabilities flagged on a security scan of the box their
>> Tomcat server is running on.
>> 
>> 38628 - TLS 1.0 still supported. Ok, assuming that the box and
>> the JVM can go up to a more current TLS level, and a more current
>> cipher, what do I need to set? On other boxes, I've added a
>> "ciphers" clause to the Connector for port 443 in the server.xml,
>> but what about the TLS?
> 
> On the TLS Connector:
> 
> sslEnabledProtocols="TLSv1.1,TLSv1.2"

Unless you will *fail* your security evaluation, you might want to
keep TLSv1.0 enabled.

>> 17369 - HTTP Security Header Not Detected. This, I don't get:
>> what I've been able to find on this one talks about a security
>> header missing on port 80; the Tomcat server (at least the one 
>> we're responsible for) doesn't even have 80 (or 8080) open at
>> all. If I remember right, though, there are other HTTP(S) servers
>> running on that box; is it perhaps one of the others?
> 
> It looks like this one:
> 
> https://community.qualys.com/thread/17369-http-security-header-not-det
ected
>
>  While that page talks about port 80, it would apply equally to
> any HTTP[S] connection.

Yes, X-Frame-Options should be set regardless of the protocol.

Try running nikto[1] against your site. It points out all kinds of
little things and (!!) gives you better information than "header not
found".

- -chris

[1] https://cirt.net/Nikto2 (also comes pre-installed in a Kali Linux
livecd, which you can use easily from within a VM guest)
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxbAwQACgkQHPApP6U8
pFjgdxAAyKfl++O9kWtO9yYTcKtKotVMywF2tMCTcHNj3rGiVa/Jf++XtUv5Cxi1
mBcR8/FiaUUcKMbQncVD+MbcQpF1gDdw1v1pNpdHJz9opEGlNb9PFyJbh/x6BIiI
m8b2wqfpootbVZ14cczzyVFkbpF5Ydw/31IYOiSN0COHvuyPrc11S2qbedvYggOz
lX3h+G12jh3FFfl3SHMCeUAe0Hq5rg34K/4czsELGV0VpIzNfeacBBxrUUcsO6H5
esUPomQTGQYHsmSkF17aVxDw3Oa/Sth28CatdWGXMaOKkm7WeKbyM/UrugnJSeKE
5HnSgi5rQaRbyMGs1U3XZV0/EnndGKMdZctBWZipNzMeOxPRDA8eng0QEVZAm4QD
W+mqSyGkemmxCQGYhA7Ds4uWt1hfhEGGnTBw/pGqOf1x+1G560IrJNECvEF47Zre
boJoCoX9S4uY+hYprBP4ugmXgN1Ln07DxkxSxIjFRi6YaOlVzJ1P0f+rfIa0CAxO
8nxugMFHam1fJ9kvSevU5uTm/0bA4EhNKDNBRJzh0310zjfgquEw48Y+cIPQzeiy
T9icqVgXVJfvsoWTjmTvwwLmQC7JAPdYFxEwI+PiNJQkcp5n3MgTV5jonLr0DSZZ
uwqqxcrRs0LgQRLt1eVF7gPVOLHzGYEZNFaSUVlOpk/EQttHcWk=
=D5aV
-END PGP SIGNATURE-

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

Re: TLS 1.0 and "HTTP Security Header Not Detected" on Tomcat 7, running under Java 7

[Mark Thomas]

On 05/02/2019 23:49, James H. H. Lampert wrote:
> We've just received word from a customer that they had two
> vulnerabilities flagged on a security scan of the box their Tomcat
> server is running on.
> 
> 38628 - TLS 1.0 still supported.
> Ok, assuming that the box and the JVM can go up to a more current TLS
> level, and a more current cipher, what do I need to set? On other boxes,
> I've added a "ciphers" clause to the Connector for port 443 in the
> server.xml, but what about the TLS?

On the TLS Connector:

sslEnabledProtocols="TLSv1.1,TLSv1.2"

> 17369 - HTTP Security Header Not Detected.
> This, I don't get: what I've been able to find on this one talks about a
> security header missing on port 80; the Tomcat server (at least the one
> we're responsible for) doesn't even have 80 (or 8080) open at all. If I
> remember right, though, there are other HTTP(S) servers running on that
> box; is it perhaps one of the others?

It looks like this one:

https://community.qualys.com/thread/17369-http-security-header-not-detected

While that page talks about port 80, it would apply equally to any
HTTP[S] connection.

Mark

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

TLS 1.0 and "HTTP Security Header Not Detected" on Tomcat 7, running under Java 7

[James H. H. Lampert]

We've just received word from a customer that they had two 
vulnerabilities flagged on a security scan of the box their Tomcat 
server is running on.


38628 - TLS 1.0 still supported.
Ok, assuming that the box and the JVM can go up to a more current TLS 
level, and a more current cipher, what do I need to set? On other boxes, 
I've added a "ciphers" clause to the Connector for port 443 in the 
server.xml, but what about the TLS?


17369 - HTTP Security Header Not Detected.
This, I don't get: what I've been able to find on this one talks about a 
security header missing on port 80; the Tomcat server (at least the one 
we're responsible for) doesn't even have 80 (or 8080) open at all. If I 
remember right, though, there are other HTTP(S) servers running on that 
box; is it perhaps one of the others?


--
James H. H. Lampert

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

Re: Tomcat 8 runs under Java 7, but not Java 8

[James H. H. Lampert]

Fellow List members:

In the end, this morning, having been told that getting the development 
instance running under Java 8 had become a priority, and knowing that 
Tomcat was running under Apache (and also learning that Apache itself 
wasn't running under a service name containing recognizable words like 
"httpd" or "apache"), I ultimately just switched the setenv.sh to use 
Java 8, and stopped and restarted the instance (a course of action I'd 
regarded as a slightly risky last resort unless I was directed to do so 
by people who knew Tomcat and Apache better than I).


It came up quickly enough, and Manager showed Tomcat as running under 
Java 8.


--
JHHL

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

Re: Tomcat 8 runs under Java 7, but not Java 8

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

James,

On 12/18/18 17:34, James H. H. Lampert wrote:
> On the Debian List, "deloptes" brought up the subect of 
> "openjdk-8-jdk-headless"; could that be relevant?

The "headless" version has fewer package dependencies because it does
not provide all of the GUI support. You can still do things like image
manipulation without a "console", and that's called "headless".

The "headless" package would only be necessary if your application
were particularly poorly-written. It might be a good idea to replace
the "regular one" with the "headless" one simply to reduce the number
of installed packages that must be maintained. But it's unlikely to
cause any errors.

> Emmanuel Bourg asked about the other instances, that are running
> Tomcat 8 under Java 8; they are all derived from Google's Tomcat-8 
> pre-installed image.

No changes to Tomcat itself... just switching from Java 7 to Java 8?

Do you have anything in server.xml that mentions specific class names
that might be missing from Java 8? Maybe some custom
JreMemoryLeakPreventionListener config or something?

The "Address already in use (bind failed)" usually just means that
Tomcat is already running.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlwaX7IACgkQHPApP6U8
pFjafA//dkvyaizRBwtf9vwgjRYM54hmKNu1GAWW0A0fc6TxK7dWA7vi9pbsNXid
JFB6B5ulhOeagKvQBW1ukx7A46m2qBIk8fnU4SMLPmxgyL427L1vZcXXqSkom67Z
jX2sYKH1kxbF6yonTMY2XRgG+LjSxCD8pNt0vBqss6K4bjGQ4ndDExqWQTVd+dF0
UMQU9wkafTiLZ7bQKHHQvovwkMpn35SX4WVY2AyTlwfhKYJKoDciSZuxy0ab1AhA
kSp5D/PylV+utjTQG26+efGZan85bEIxpO4Lfi0v4eySu516cOiZIzGPEk663nN8
HBztzMleDfYjff5hzTmmCu2fZOS4VBDhZr0vkZvHC7OjL74be2azNJiXsvhZ7Obc
3qoYg0FrsKf/Kia/+BiwcOh8xU4qGxYylSXHLiXQVnrYLD9Bdr8JUT4eFkv1bMya
DLLLM+e+hrcmK05vshawYPSGWC3BHA+mMYQ+p49zneTRksSw9AgWsZdXcc+Anm8+
EHRF+kVUIjovaD0h6Xglofleft+9ORjDUQDFi5crSlYeGsTiuSpd4RoCwCdvjOak
gmBCWve4pxXCWBzDKVX+sSk3HYHUbWVwQ7tk3XaN/DuaCuWjQtEGmnGixQE0/67r
J6gyH3qmaJCpQ/GGYRIPI7E4m66JT4skAkY5TUzajNcLOOvcws0=
=Ij3J
-END PGP SIGNATURE-

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

Re: Tomcat 8 runs under Java 7, but not Java 8

[James H. H. Lampert]

On 12/18/18, 2:49 PM, Caldarale, Charles R wrote:

The above indicates you have a Tomcat (or something much like it) already
running...


You would think so, and yet if I switch the JAVA_HOME line in setenv.sh 
to Java 7, it launches just fine. . . .


WAIT A SECOND!

Port 443 is open, and the Tomcat server is responding on it, even after 
I do a "service tomcat8 stop"!


I suddenly remember how much reconfiguring I had to do on the production 
servers, with the pre-installed Tomcat, to get it to front-end itself, 
rather than the default of running through Apache. And I'm also starting 
to remember how hard it is to find where things are in Apache, which is 
WHY I switched to the Tomcat front-ending itself configuration I was 
already familiar with on AS/400s.


It looks like Tomcat isn't running independently on this box, but rather 
running behind/under Apache!


But that doesn't explain why, if I set the JAVA_HOME line in setenv.sh 
to Java 7, "service tomcat8 start" seems to work fine, but if I set it 
to Java 8, it produces error messages.


Can anybody point me in the right direction?

--
JHHL

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

RE: Tomcat 8 runs under Java 7, but not Java 8

[Caldarale, Charles R]

> From: James H. H. Lampert [mailto:jam...@touchtonecorp.com] 
> Subject: Re: Tomcat 8 runs under Java 7, but not Java 8

> Excerpt from the relevant time period, catalina.2018-12-18.log:

> > 18-Dec-2018 20:18:55.419 SEVERE [main]
org.apache.catalina.core.StandardServer.await 
> > StandardServer.await: create[localhost:8005]:
> >  java.net.BindException: Address already in use (Bind failed)

> > 18-Dec-2018 20:31:12.604 SEVERE [main]
org.apache.coyote.AbstractProtocol.init Failed 
> > to initialize end point associated with ProtocolHandler
["https-jsse-nio-443"]
> >  java.net.BindException: Address already in use

> > 18-Dec-2018 20:31:55.545 SEVERE [main]
org.apache.catalina.core.StandardServer.await 
> > StandardServer.await: create[localhost:8005]:
> >  java.net.BindException: Address already in use (Bind failed)

The above indicates you have a Tomcat (or something much like it) already
running...

  - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.



smime.p7s
Description: S/MIME cryptographic signature

Re: Tomcat 8 runs under Java 7, but not Java 8

[James H. H. Lampert]

On 12/18/18, 12:50 PM, Mark Thomas wrote:

They don't appear to be very helpful.

They certainly didn't suggest anything to me.


What do the Tomcat logs show? catalina.-mm-dd.log is likely to be
the most useful but check them all.


Dear Mr. Thomas, et al:

Excerpt from the relevant time period, catalina.2018-12-18.log:

18-Dec-2018 20:18:55.419 SEVERE [main] 
org.apache.catalina.core.StandardServer.await StandardServer.await: 
create[localhost:8005]:
 java.net.BindException: Address already in use (Bind failed)
at java.net.PlainSocketImpl.socketBind(Native Method)
at 
java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:376)
at java.net.ServerSocket.bind(ServerSocket.java:375)
at java.net.ServerSocket.(ServerSocket.java:237)
at 
org.apache.catalina.core.StandardServer.await(StandardServer.java:440)
at org.apache.catalina.startup.Catalina.await(Catalina.java:744)
at org.apache.catalina.startup.Catalina.start(Catalina.java:690)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:355)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:495)

18-Dec-2018 20:18:55.420 INFO [main] org.apache.coyote.AbstractProtocol.pause Pausing 
ProtocolHandler ["https-jsse-nio-443"]
18-Dec-2018 20:18:55.426 INFO [main] 
org.apache.catalina.core.StandardService.stopInternal Stopping service Catalina
18-Dec-2018 20:18:55.590 INFO [main] org.apache.coyote.AbstractProtocol.stop Stopping 
ProtocolHandler ["https-jsse-nio-443"]
18-Dec-2018 20:18:55.590 INFO [main] org.apache.coyote.AbstractProtocol.destroy 
Destroying ProtocolHandler ["https-jsse-nio-443"]
18-Dec-2018 20:31:11.502 WARNING [main] 
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with 
directory [/var/lib/tomcat8/common/classes], exists: [false], isDirectory: 
[false], canRead: [false]
18-Dec-2018 20:31:11.509 WARNING [main] 
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with 
directory [/var/lib/tomcat8/common], exists: [false], isDirectory: [false], 
canRead: [false]
18-Dec-2018 20:31:11.509 WARNING [main] 
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with 
directory [/usr/share/tomcat8/common/classes], exists: [false], isDirectory: 
[false], canRead: [false]
18-Dec-2018 20:31:11.510 WARNING [main] 
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with 
directory [/usr/share/tomcat8/common], exists: [false], isDirectory: [false], 
canRead: [false]
18-Dec-2018 20:31:11.513 WARNING [main] 
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with 
directory [/var/lib/tomcat8/server/classes], exists: [false], isDirectory: 
[false], canRead: [false]
18-Dec-2018 20:31:11.515 WARNING [main] 
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with 
directory [/var/lib/tomcat8/server], exists: [false], isDirectory: [false], 
canRead: [false]
18-Dec-2018 20:31:11.515 WARNING [main] 
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with 
directory [/usr/share/tomcat8/server/classes], exists: [false], isDirectory: 
[false], canRead: [false]
18-Dec-2018 20:31:11.515 WARNING [main] 
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with 
directory [/usr/share/tomcat8/server], exists: [false], isDirectory: [false], 
canRead: [false]
18-Dec-2018 20:31:11.516 WARNING [main] 
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with 
directory [/var/lib/tomcat8/shared/classes], exists: [false], isDirectory: 
[false], canRead: [false]
18-Dec-2018 20:31:11.516 WARNING [main] 
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with 
directory [/var/lib/tomcat8/shared], exists: [false], isDirectory: [false], 
canRead: [false]
18-Dec-2018 20:31:11.516 WARNING [main] 
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with 
directory [/usr/share/tomcat8/shared/classes], exists: [false], isDirectory: 
[false], canRead: [false]
18-Dec-2018 20:31:11.517 WARNING [main] 
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with 
directory [/usr/share/tomcat8/shared], exists: [false], isDirectory: [false], 
canRead: [false]
18-Dec-2018 20:31:12.212 WARNING [main] 
org.apache.catalina.startup.SetAllPropertiesRule.begin 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 'bufferSize' 
to '1024' did not find a matching property.
18-Dec-2018 20:31:12.360 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Server version:
Apache Tomcat/8.5.14 (Debian)
18-Dec-2018 20:31:12.361 INFO [main] 

Re: Tomcat 8 runs under Java 7, but not Java 8

[Emmanuel Bourg]

Hi James,

Le 18/12/2018 à 21:40, James H. H. Lampert a écrit :
> I just installed Java 8 (not as the default JRE) on a Google Compute
> Debian 8 instance that has been running Tomcat 8 under Java 7.

I assume you are using the tomcat8 package from the distribution. Tomcat
on Debian 8 Jessie is a bit old (but still receives security fixes), I
recommend upgrading to Debian 9 where you'll be able to use the latest
8.5 version from the stretch-backports repository (and soon tomcat9 too).


> If I change setenv.sh to add
>> JAVA_HOME="/usr/lib/jvm/java-8-openjdk-amd64/"

Note that on Debian the JAVA_HOME variable is typically set in the
/etc/defaut/tomcat8 file.


> and I try to "service tomcat8 start," I get
> 
>> Job for tomcat8.service failed because the control process exited with
>> error code.
>> See "systemctl status tomcat8.service" and "journalctl -xe" for details.

This version of the Tomcat package doesn't have really useful
information in the systemd log unfortunately. This changed with the
version 8.5.32-2 of the package which now provides a proper systemd
service file. So in your case you should look into
/var/log/tomcat8/catalina.out instead.


> If I leave the JAVA_HOME in there, but change it to refer to the Java 7
> directory, it works fine.
> 
> What am I doing wrong? Tomcat 8 runs just fine on our other Google
> Compute instances, and they *only* have Java 8.

How did you install Java 8? From the jessie-backports repository?

Emmanuel Bourg

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

Re: Tomcat 8 runs under Java 7, but not Java 8

[Mark Thomas]

On 18/12/2018 20:40, James H. H. Lampert wrote:
> I just installed Java 8 (not as the default JRE) on a Google Compute
> Debian 8 instance that has been running Tomcat 8 under Java 7.
> 
> If I change setenv.sh to add
>> JAVA_HOME="/usr/lib/jvm/java-8-openjdk-amd64/"
> 
> and I try to "service tomcat8 start," I get
> 
>> Job for tomcat8.service failed because the control process exited with
>> error code.
>> See "systemctl status tomcat8.service" and "journalctl -xe" for details.

They don't appear to be very helpful.

What do the Tomcat logs show? catalina.-mm-dd.log is likely to be
the most useful but check them all.

Mark

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

Tomcat 8 runs under Java 7, but not Java 8

[James H. H. Lampert]

I just installed Java 8 (not as the default JRE) on a Google Compute 
Debian 8 instance that has been running Tomcat 8 under Java 7.


If I change setenv.sh to add

JAVA_HOME="/usr/lib/jvm/java-8-openjdk-amd64/"


and I try to "service tomcat8 start," I get


Job for tomcat8.service failed because the control process exited with error 
code.
See "systemctl status tomcat8.service" and "journalctl -xe" for details.


and then

# systemctl status tomcat8.service
● tomcat8.service - LSB: Start Tomcat.
   Loaded: loaded (/etc/init.d/tomcat8; generated; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2018-12-18 20:31:16 UTC; 13s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 32227 ExecStop=/etc/init.d/tomcat8 stop (code=exited, 
status=0/SUCCESS)
  Process: 32259 ExecStart=/etc/init.d/tomcat8 start (code=exited, 
status=1/FAILURE)
   CGroup: /system.slice/tomcat8.service
   ├─30767 /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java 
-Djava.util.logging.config.file=/var/lib/tomcat8/conf/logging.properties
   └─32285 /usr/lib/jvm/java-8-openjdk-amd64//bin/java 
-Djava.util.logging.config.file=/var/lib/tomcat8/conf/logging.properties -D

Dec 18 20:31:11 bitnami-trac-dm-87ea systemd[1]: Starting LSB: Start Tomcat
Dec 18 20:31:16 bitnami-trac-dm-87ea tomcat8[32259]: Starting Tomcat servlet 
engine: tomcat8 failed!
Dec 18 20:31:16 bitnami-trac-dm-87ea systemd[1]: tomcat8.service: Control 
process exited, code=exited status=1
Dec 18 20:31:16 bitnami-trac-dm-87ea systemd[1]: Failed to start LSB: Start 
Tomcat..
Dec 18 20:31:16 bitnami-trac-dm-87ea systemd[1]: tomcat8.service: Unit entered 
failed state.
Dec 18 20:31:16 bitnami-trac-dm-87ea systemd[1]: tomcat8.service: Failed with 
result 'exit-code'.

# journalctl -xe
Dec 18 20:29:26 bitnami-trac-dm-87ea sshd[32138]: lastlog_openseek: Couldn't 
stat /var/log/lastlog: No such file or directory
Dec 18 20:29:26 bitnami-trac-dm-87ea sshd[32138]: lastlog_openseek: Couldn't 
stat /var/log/lastlog: No such file or directory
Dec 18 20:29:36 bitnami-trac-dm-87ea sudo[32174]: jamesl : TTY=pts/2 ; 
PWD=/home/jamesl ; USER=root ; COMMAND=/bin/bash
Dec 18 20:29:36 bitnami-trac-dm-87ea sudo[32174]: pam_unix(sudo:session): 
session opened for user root by jamesl(uid=0)
Dec 18 20:29:45 bitnami-trac-dm-87ea sshd[32194]: Disconnecting: Too many 
authentication failures for root from 162.156.168.156 port 42965
Dec 18 20:29:52 bitnami-trac-dm-87ea sshd[32197]: Invalid user jzapata from 
186.15.24.34
Dec 18 20:29:52 bitnami-trac-dm-87ea sshd[32197]: input_userauth_request: 
invalid user jzapata [preauth]
Dec 18 20:29:52 bitnami-trac-dm-87ea sshd[32197]: Received disconnect from 
186.15.24.34: 11: Bye Bye [preauth]
Dec 18 20:30:21 bitnami-trac-dm-87ea sshd[32202]: reverse mapping checking 
getaddrinfo for static.201.20.36.4.datacenter1.com.br [201.20.3
Dec 18 20:30:21 bitnami-trac-dm-87ea sshd[32202]: Invalid user ftp from 
201.20.36.4
Dec 18 20:30:21 bitnami-trac-dm-87ea sshd[32202]: input_userauth_request: 
invalid user ftp [preauth]
Dec 18 20:30:21 bitnami-trac-dm-87ea sshd[32202]: Received disconnect from 
201.20.36.4: 11: Bye Bye [preauth]
Dec 18 20:30:35 bitnami-trac-dm-87ea systemd[1]: Stopping LSB: Start Tomcat
-- Subject: Unit tomcat8.service has begun shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit tomcat8.service has begun shutting down.
Dec 18 20:30:35 bitnami-trac-dm-87ea tomcat8[32227]: Stopping Tomcat servlet 
engine: tomcat8 Tomcat servlet engine is not running but pid
Dec 18 20:30:35 bitnami-trac-dm-87ea systemd[1]: Stopped LSB: Start Tomcat..
-- Subject: Unit tomcat8.service has finished shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit tomcat8.service has finished shutting down.
Dec 18 20:31:11 bitnami-trac-dm-87ea systemd[1]: Starting LSB: Start Tomcat
-- Subject: Unit tomcat8.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit tomcat8.service has begun starting up.
Dec 18 20:31:16 bitnami-trac-dm-87ea tomcat8[32259]: Starting Tomcat servlet 
engine: tomcat8 failed!
Dec 18 20:31:16 bitnami-trac-dm-87ea systemd[1]: tomcat8.service: Control 
process exited, code=exited status=1
Dec 18 20:31:16 bitnami-trac-dm-87ea systemd[1]: Failed to start LSB: Start 
Tomcat..
-- Subject: Unit tomcat8.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit tomcat8.service has failed.
--
-- The result is failed.
Dec 18 20:31:16 bitnami-trac-dm-87ea systemd[1]: tomcat8.service: Unit entered 
failed state.
Dec 18 20:31:16 bitnami-trac-dm-87ea systemd[1]: tomcat8.service: Failed with 
result 'exit-code'.
Dec 18 20:31:50 bitnami-trac-dm-87ea sshd[32355]: Invalid user webmaster from 
78.36.7.170
Dec 18 

Re: Apache Tomcat 4.1.30 - not working with OS400 after upgrading the OS to V7R3 which uses Java 7/Java 8

[Greg Huber]

> "taglib",
> > > must match DOCTYPE root "null".
> > > org.xml.sax.SAXParseException: Document root element "taglib", must
> match
> > > DOCTYPE root "null".
> > >
> > > Aug 23, 2017 9:36:49 AM org.apache.commons.digester.Digester
> > > error
> > > SEVERE: Parse Error at line 6 column 19: Document is invalid: no
> grammar
> > > found.
> > > org.xml.sax.SAXParseException: Document is invalid: no grammar
> > > found.
> > >
> > > Aug 23, 2017 9:36:49 AM org.apache.commons.digester.Digester
> > > error
> > > SEVERE: Parse Error at line 6 column 17: Document root element
> "taglib",
> > > must match DOCTYPE root "null".
> > > org.xml.sax.SAXParseException: Document root element "taglib", must
> match
> > > DOCTYPE root "null".
> > >
> > > Aug 23, 2017 9:36:49 AM org.apache.commons.digester.Digester
> > > error
> > > SEVERE: Parse Error at line 6 column 17: Document is invalid: no
> grammar
> > > found.
> > > org.xml.sax.SAXParseException: Document is invalid: no grammar
> > > found.
> > >
> > > Aug 23, 2017 9:36:49 AM org.apache.commons.digester.Digester
> > > error
> > > SEVERE: Parse Error at line 7 column 19: Document root element
> "taglib",
> > > must match DOCTYPE root "null".
> > > org.xml.sax.SAXParseException: Document root element "taglib", must
> match
> > > DOCTYPE root "null".
> > >
> > > Aug 23, 2017 9:36:49 AM org.apache.commons.digester.Digester
> > > error
> > > SEVERE: Parse Error at line 7 column 19: Document is invalid: no
> grammar
> > > found.
> > > org.xml.sax.SAXParseException: Document is invalid: no grammar
> > > found.
> > >
> > > Aug 23, 2017 9:36:49 AM org.apache.commons.digester.Digester
> > > error
> > > SEVERE: Parse Error at line 7 column 19: Document root element
> "taglib",
> > > must match DOCTYPE root "null".
> > > org.xml.sax.SAXParseException: Document root element "taglib", must
> match
> > > DOCTYPE root "null".
> > >
> > > Aug 23, 2017 9:36:49 AM org.apache.commons.digester.Digester
> > > error
> > > SEVERE: Parse Error at line 7 column 19: Document is invalid: no
> grammar
> > > found.
> > > org.xml.sax.SAXParseException: Document is invalid: no grammar
> > > found.
> > >
> > > Aug 23, 2017 9:36:49 AM org.apache.commons.digester.Digester
> > > error
> > > SEVERE: Parse Error at line 6 column 19: Document root element
> "taglib",
> > > must match DOCTYPE root "null".
> > > org.xml.sax.SAXParseException: Document root element "taglib", must
> match
> > > DOCTYPE root "null".
> > >
> > > Aug 23, 2017 9:36:49 AM org.apache.commons.digester.Digester
> > > error
> > > SEVERE: Parse Error at line 6 column 19: Document is invalid: no
> grammar
> > > found.
> > > org.xml.sax.SAXParseException: Document is invalid: no grammar
> > > found.
> > >
> > > Aug 23, 2017 9:36:49 AM org.apache.commons.digester.Digester
> > > error
> > > SEVERE: Parse Error at line 6 column 19: Document root element
> "taglib",
> > > must match DOCTYPE root "null".
> > > org.xml.sax.SAXParseException: Document root element "taglib", must
> match
> > > DOCTYPE root "null".
> > >
> > > Aug 23, 2017 9:36:49 AM org.apache.commons.digester.Digester
> > > error
> > > SEVERE: Parse Error at line 6 column 19: Document is invalid: no
> grammar
> > > found.
> > > org.xml.sax.SAXParseException: Document is invalid: no grammar
> > > found.
> > >
> > > Aug 23, 2017 9:36:50 AM org.apache.struts.util.
> PropertyMessageResources
> > > 
> > > INFO: Initializing, config='org.apache.struts.util.LocalStrings',
> > > returnNull=true
> > > Aug 23, 2017 9:36:50 AM org.apache.struts.util.
> PropertyMessageResources
> > > 
> > > INFO: Initializing, config='org.apache.struts.action.ActionResources',
> > > returnNull=true
> > > Aug 23, 2017 9:36:51 AM org.apache.struts.util.
> PropertyMessageResources
> > > 
> > > INFO: Initializing, config='org.apache.webapp.
> > admin.ApplicationResources',
> > > returnNull=true
>

Re: Apache Tomcat 4.1.30 - not working with OS400 after upgrading the OS to V7R3 which uses Java 7/Java 8

[Vinay A S]

t; must match DOCTYPE root "null".
> > org.xml.sax.SAXParseException: Document root element "taglib", must match
> > DOCTYPE root "null".
> >
> > Aug 23, 2017 9:36:49 AM org.apache.commons.digester.Digester
> > error
> > SEVERE: Parse Error at line 7 column 19: Document is invalid: no grammar
> > found.
> > org.xml.sax.SAXParseException: Document is invalid: no grammar
> > found.
> >
> > Aug 23, 2017 9:36:49 AM org.apache.commons.digester.Digester
> > error
> > SEVERE: Parse Error at line 6 column 19: Document root element "taglib",
> > must match DOCTYPE root "null".
> > org.xml.sax.SAXParseException: Document root element "taglib", must match
> > DOCTYPE root "null".
> >
> > Aug 23, 2017 9:36:49 AM org.apache.commons.digester.Digester
> > error
> > SEVERE: Parse Error at line 6 column 19: Document is invalid: no grammar
> > found.
> > org.xml.sax.SAXParseException: Document is invalid: no grammar
> > found.
> >
> > Aug 23, 2017 9:36:49 AM org.apache.commons.digester.Digester
> > error
> > SEVERE: Parse Error at line 6 column 19: Document root element "taglib",
> > must match DOCTYPE root "null".
> > org.xml.sax.SAXParseException: Document root element "taglib", must match
> > DOCTYPE root "null".
> >
> > Aug 23, 2017 9:36:49 AM org.apache.commons.digester.Digester
> > error
> > SEVERE: Parse Error at line 6 column 19: Document is invalid: no grammar
> > found.
> > org.xml.sax.SAXParseException: Document is invalid: no grammar
> > found.
> >
> > Aug 23, 2017 9:36:50 AM org.apache.struts.util.PropertyMessageResources
> > 
> > INFO: Initializing, config='org.apache.struts.util.LocalStrings',
> > returnNull=true
> > Aug 23, 2017 9:36:50 AM org.apache.struts.util.PropertyMessageResources
> > 
> > INFO: Initializing, config='org.apache.struts.action.ActionResources',
> > returnNull=true
> > Aug 23, 2017 9:36:51 AM org.apache.struts.util.PropertyMessageResources
> > 
> > INFO: Initializing, config='org.apache.webapp.
> admin.ApplicationResources',
> > returnNull=true
> >
> > On Fri, Sep 8, 2017 at 1:02 PM, Greg Huber <gregh3...@gmail.com> wrote:
> >
> > > Java 1.4 should still be available, check your software resources and
> > > 5761-JV1
> > > options and the environment variable JAVA_HOME.
> > >
> > > https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/
> > > rzaha/rzahainstalljdk.htm
> > >
> > >
> > >
> > > On 7 September 2017 at 15:56, André Warnier (tomcat) <a...@ice-sa.com>
> > > wrote:
> > >
> > > > On 07.09.2017 16:21, Vinay A S wrote:
> > > >
> > > >> Hello,
> > > >>
> > > >> We have installed Apache Tomcat version 4.1.30 on our iSeries
> server.
> > > >>
> > > >
> > > > I don't even know what to tell you. Some of the people on this list
> may
> > > > not even have been born yet, when that version was released.
> > > >
> > > > (Ok, I am pushing it a bit; it was 2004, 13 years ago; so they may
> have
> > > > been born, but still in primary school)
> > > >
> > > > Recently we have upgraded the OS400 Operating System from Version 7.1
> > to
> > > >> 7.3 where Java 7 and Java 8 are introduced. After this upgrade,
> Tomcat
> > > is
> > > >> giving an HTTP status 500 exception report.
> > > >>
> > > >
> > > > I don't know if anyone here will be able to help, with such an old
> > > version
> > > > of Tomcat. But in any case, an error 500 should be reflected in the
> > > tomcat
> > > > logfiles.
> > > > Just in case, please view the logfile at the time of that error, and
> > copy
> > > > and paste the relevant part here. (Do not send it as attachment,
> really
> > > > copy and paste it in your email)
> > > >
> > > >
> > > >> We explored the Tomcat portal and found that we are running Tomcat
> on
> > a
> > > >> lower version and that needs to be upgraded.
> > > >>
> > > >
> > > > No kidding..
> > > >
> > > >  But we are unable to find the
> > > >
> > > >> exact procedure to install Tomcat on iSeries server.
> > > >>
> > > >> There is a subsystem TOMCAT running on the system with Job QP0ZSPWT
> > > being
> > > >> Active.
> > > >>
> > > >> Please advise on the version of TOMCAT that needs to be installed on
> > the
> > > >> system as well the procedure to install it.
> > > >>
> > > >>
> > > > I believe that this is a question that you should ask to your system
> > > > support people (or IBM). This list here focuses on tomcat, as per
> > > > http://tomcat.apache.org.
> > > > The current version is 8.5, which requires at least a Java 7 JVM.
> > > >
> > > > Tomcat per se is Java code, and will run on any platform that has an
> > > > appropriate JVM available.
> > > > Installing Tomcat on any platform however, is more the resort of the
> > > > package managers of the corresponding platforms/OS'es.
> > > >
> > > > First find out which version of Java is available/installed on your
> > > > platform.
> > > > Then consult this page : http://tomcat.apache.org/whichversion.html
> > > > to determine which version of Tomcat is appropriate (the higher, the
> > > > better)
> > > >
> > > > Once you have done this, there are further instructions in each
> > version's
> > > > documentation, that outline the installation. For example, for tomcat
> > > 8.5,
> > > > here :
> > > > http://tomcat.apache.org/tomcat-8.5-doc/setup.html
> > > >
> > > > The above concerns the tomcat which you would download from
> > > > tomcat.apache.org.
> > > > But in all likelihood, there are special pre-packaged tomcat versions
> > > > available for your specific platform, which might simplify this.
> > > > But this, you need to ask your sysadmins.
> > > >
> > > > Note that there are not really "tomcat upgrade" procedures for
> > upgrading
> > > > your tomcat 4.1 to 8.5.  You will need to install the new tomcat
> > > > (preferably somewhere else than the old one), and then move your
> > > > applications one by one from the old to the new.
> > > > If you are reasonably lucky, they might still work unchanged.
> > > > But do not move the old tomcat settings, to the new one. That will
> not
> > > > work, and will create a mess. Find out what you might need to change
> in
> > > the
> > > > new standard settings, and do it there (after making a backup).
> > > >
> > > >
> > > >
> > > > 
> -
> > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > > > For additional commands, e-mail: users-h...@tomcat.apache.org
> > > >
> > > >
> > >
> >
>

Re: Apache Tomcat 4.1.30 - not working with OS400 after upgrading the OS to V7R3 which uses Java 7/Java 8

[Greg Huber]

ertyMessageResources
> 
> INFO: Initializing, config='org.apache.struts.action.ActionResources',
> returnNull=true
> Aug 23, 2017 9:36:51 AM org.apache.struts.util.PropertyMessageResources
> 
> INFO: Initializing, config='org.apache.webapp.admin.ApplicationResources',
> returnNull=true
>
> On Fri, Sep 8, 2017 at 1:02 PM, Greg Huber <gregh3...@gmail.com> wrote:
>
> > Java 1.4 should still be available, check your software resources and
> > 5761-JV1
> > options and the environment variable JAVA_HOME.
> >
> > https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/
> > rzaha/rzahainstalljdk.htm
> >
> >
> >
> > On 7 September 2017 at 15:56, André Warnier (tomcat) <a...@ice-sa.com>
> > wrote:
> >
> > > On 07.09.2017 16:21, Vinay A S wrote:
> > >
> > >> Hello,
> > >>
> > >> We have installed Apache Tomcat version 4.1.30 on our iSeries server.
> > >>
> > >
> > > I don't even know what to tell you. Some of the people on this list may
> > > not even have been born yet, when that version was released.
> > >
> > > (Ok, I am pushing it a bit; it was 2004, 13 years ago; so they may have
> > > been born, but still in primary school)
> > >
> > > Recently we have upgraded the OS400 Operating System from Version 7.1
> to
> > >> 7.3 where Java 7 and Java 8 are introduced. After this upgrade, Tomcat
> > is
> > >> giving an HTTP status 500 exception report.
> > >>
> > >
> > > I don't know if anyone here will be able to help, with such an old
> > version
> > > of Tomcat. But in any case, an error 500 should be reflected in the
> > tomcat
> > > logfiles.
> > > Just in case, please view the logfile at the time of that error, and
> copy
> > > and paste the relevant part here. (Do not send it as attachment, really
> > > copy and paste it in your email)
> > >
> > >
> > >> We explored the Tomcat portal and found that we are running Tomcat on
> a
> > >> lower version and that needs to be upgraded.
> > >>
> > >
> > > No kidding..
> > >
> > >  But we are unable to find the
> > >
> > >> exact procedure to install Tomcat on iSeries server.
> > >>
> > >> There is a subsystem TOMCAT running on the system with Job QP0ZSPWT
> > being
> > >> Active.
> > >>
> > >> Please advise on the version of TOMCAT that needs to be installed on
> the
> > >> system as well the procedure to install it.
> > >>
> > >>
> > > I believe that this is a question that you should ask to your system
> > > support people (or IBM). This list here focuses on tomcat, as per
> > > http://tomcat.apache.org.
> > > The current version is 8.5, which requires at least a Java 7 JVM.
> > >
> > > Tomcat per se is Java code, and will run on any platform that has an
> > > appropriate JVM available.
> > > Installing Tomcat on any platform however, is more the resort of the
> > > package managers of the corresponding platforms/OS'es.
> > >
> > > First find out which version of Java is available/installed on your
> > > platform.
> > > Then consult this page : http://tomcat.apache.org/whichversion.html
> > > to determine which version of Tomcat is appropriate (the higher, the
> > > better)
> > >
> > > Once you have done this, there are further instructions in each
> version's
> > > documentation, that outline the installation. For example, for tomcat
> > 8.5,
> > > here :
> > > http://tomcat.apache.org/tomcat-8.5-doc/setup.html
> > >
> > > The above concerns the tomcat which you would download from
> > > tomcat.apache.org.
> > > But in all likelihood, there are special pre-packaged tomcat versions
> > > available for your specific platform, which might simplify this.
> > > But this, you need to ask your sysadmins.
> > >
> > > Note that there are not really "tomcat upgrade" procedures for
> upgrading
> > > your tomcat 4.1 to 8.5.  You will need to install the new tomcat
> > > (preferably somewhere else than the old one), and then move your
> > > applications one by one from the old to the new.
> > > If you are reasonably lucky, they might still work unchanged.
> > > But do not move the old tomcat settings, to the new one. That will not
> > > work, and will create a mess. Find out what you might need to change in
> > the
> > > new standard settings, and do it there (after making a backup).
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > > For additional commands, e-mail: users-h...@tomcat.apache.org
> > >
> > >
> >
>

Re: Apache Tomcat 4.1.30 - not working with OS400 after upgrading the OS to V7R3 which uses Java 7/Java 8

[Vinay A S]

xml.sax.SAXParseException: Document is invalid: no grammar
found.

Aug 23, 2017 9:36:49 AM org.apache.commons.digester.Digester
error
SEVERE: Parse Error at line 6 column 19: Document root element "taglib",
must match DOCTYPE root "null".
org.xml.sax.SAXParseException: Document root element "taglib", must match
DOCTYPE root "null".

Aug 23, 2017 9:36:49 AM org.apache.commons.digester.Digester
error
SEVERE: Parse Error at line 6 column 19: Document is invalid: no grammar
found.
org.xml.sax.SAXParseException: Document is invalid: no grammar
found.

Aug 23, 2017 9:36:49 AM org.apache.commons.digester.Digester
error
SEVERE: Parse Error at line 6 column 17: Document root element "taglib",
must match DOCTYPE root "null".
org.xml.sax.SAXParseException: Document root element "taglib", must match
DOCTYPE root "null".

Aug 23, 2017 9:36:49 AM org.apache.commons.digester.Digester
error
SEVERE: Parse Error at line 6 column 17: Document is invalid: no grammar
found.
org.xml.sax.SAXParseException: Document is invalid: no grammar
found.

Aug 23, 2017 9:36:49 AM org.apache.commons.digester.Digester
error
SEVERE: Parse Error at line 7 column 19: Document root element "taglib",
must match DOCTYPE root "null".
org.xml.sax.SAXParseException: Document root element "taglib", must match
DOCTYPE root "null".

Aug 23, 2017 9:36:49 AM org.apache.commons.digester.Digester
error
SEVERE: Parse Error at line 7 column 19: Document is invalid: no grammar
found.
org.xml.sax.SAXParseException: Document is invalid: no grammar
found.

Aug 23, 2017 9:36:49 AM org.apache.commons.digester.Digester
error
SEVERE: Parse Error at line 7 column 19: Document root element "taglib",
must match DOCTYPE root "null".
org.xml.sax.SAXParseException: Document root element "taglib", must match
DOCTYPE root "null".

Aug 23, 2017 9:36:49 AM org.apache.commons.digester.Digester
error
SEVERE: Parse Error at line 7 column 19: Document is invalid: no grammar
found.
org.xml.sax.SAXParseException: Document is invalid: no grammar
found.

Aug 23, 2017 9:36:49 AM org.apache.commons.digester.Digester
error
SEVERE: Parse Error at line 6 column 19: Document root element "taglib",
must match DOCTYPE root "null".
org.xml.sax.SAXParseException: Document root element "taglib", must match
DOCTYPE root "null".

Aug 23, 2017 9:36:49 AM org.apache.commons.digester.Digester
error
SEVERE: Parse Error at line 6 column 19: Document is invalid: no grammar
found.
org.xml.sax.SAXParseException: Document is invalid: no grammar
found.

Aug 23, 2017 9:36:49 AM org.apache.commons.digester.Digester
error
SEVERE: Parse Error at line 6 column 19: Document root element "taglib",
must match DOCTYPE root "null".
org.xml.sax.SAXParseException: Document root element "taglib", must match
DOCTYPE root "null".

Aug 23, 2017 9:36:49 AM org.apache.commons.digester.Digester
error
SEVERE: Parse Error at line 6 column 19: Document is invalid: no grammar
found.
org.xml.sax.SAXParseException: Document is invalid: no grammar
found.

Aug 23, 2017 9:36:50 AM org.apache.struts.util.PropertyMessageResources

INFO: Initializing, config='org.apache.struts.util.LocalStrings',
returnNull=true
Aug 23, 2017 9:36:50 AM org.apache.struts.util.PropertyMessageResources

INFO: Initializing, config='org.apache.struts.action.ActionResources',
returnNull=true
Aug 23, 2017 9:36:51 AM org.apache.struts.util.PropertyMessageResources

INFO: Initializing, config='org.apache.webapp.admin.ApplicationResources',
returnNull=true

On Fri, Sep 8, 2017 at 1:02 PM, Greg Huber <gregh3...@gmail.com> wrote:

> Java 1.4 should still be available, check your software resources and
> 5761-JV1
> options and the environment variable JAVA_HOME.
>
> https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/
> rzaha/rzahainstalljdk.htm
>
>
>
> On 7 September 2017 at 15:56, André Warnier (tomcat) <a...@ice-sa.com>
> wrote:
>
> > On 07.09.2017 16:21, Vinay A S wrote:
> >
> >> Hello,
> >>
> >> We have installed Apache Tomcat version 4.1.30 on our iSeries server.
> >>
> >
> > I don't even know what to tell you. Some of the people on this list may
> > not even have been born yet, when that version was released.
> >
> > (Ok, I am pushing it a bit; it was 2004, 13 years ago; so they may have
> > been born, but still in primary school)
> >
> > Recently we have upgraded the OS400 Operating System from Version 7.1 to
> >> 7.3 where Java 7 and Java 8 are introduced. After this upgrade, Tomcat
> is
> >> giving an HTTP status 500 exception report.
> >>
> >
> > I don't know if anyone here will be able to help, with such an old
> version
> >

Re: Apache Tomcat 4.1.30 - not working with OS400 after upgrading the OS to V7R3 which uses Java 7/Java 8

[Greg Huber]

Java 1.4 should still be available, check your software resources and 5761-JV1
options and the environment variable JAVA_HOME.

https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/rzaha/rzahainstalljdk.htm



On 7 September 2017 at 15:56, André Warnier (tomcat) <a...@ice-sa.com> wrote:

> On 07.09.2017 16:21, Vinay A S wrote:
>
>> Hello,
>>
>> We have installed Apache Tomcat version 4.1.30 on our iSeries server.
>>
>
> I don't even know what to tell you. Some of the people on this list may
> not even have been born yet, when that version was released.
>
> (Ok, I am pushing it a bit; it was 2004, 13 years ago; so they may have
> been born, but still in primary school)
>
> Recently we have upgraded the OS400 Operating System from Version 7.1 to
>> 7.3 where Java 7 and Java 8 are introduced. After this upgrade, Tomcat is
>> giving an HTTP status 500 exception report.
>>
>
> I don't know if anyone here will be able to help, with such an old version
> of Tomcat. But in any case, an error 500 should be reflected in the tomcat
> logfiles.
> Just in case, please view the logfile at the time of that error, and copy
> and paste the relevant part here. (Do not send it as attachment, really
> copy and paste it in your email)
>
>
>> We explored the Tomcat portal and found that we are running Tomcat on a
>> lower version and that needs to be upgraded.
>>
>
> No kidding..
>
>  But we are unable to find the
>
>> exact procedure to install Tomcat on iSeries server.
>>
>> There is a subsystem TOMCAT running on the system with Job QP0ZSPWT being
>> Active.
>>
>> Please advise on the version of TOMCAT that needs to be installed on the
>> system as well the procedure to install it.
>>
>>
> I believe that this is a question that you should ask to your system
> support people (or IBM). This list here focuses on tomcat, as per
> http://tomcat.apache.org.
> The current version is 8.5, which requires at least a Java 7 JVM.
>
> Tomcat per se is Java code, and will run on any platform that has an
> appropriate JVM available.
> Installing Tomcat on any platform however, is more the resort of the
> package managers of the corresponding platforms/OS'es.
>
> First find out which version of Java is available/installed on your
> platform.
> Then consult this page : http://tomcat.apache.org/whichversion.html
> to determine which version of Tomcat is appropriate (the higher, the
> better)
>
> Once you have done this, there are further instructions in each version's
> documentation, that outline the installation. For example, for tomcat 8.5,
> here :
> http://tomcat.apache.org/tomcat-8.5-doc/setup.html
>
> The above concerns the tomcat which you would download from
> tomcat.apache.org.
> But in all likelihood, there are special pre-packaged tomcat versions
> available for your specific platform, which might simplify this.
> But this, you need to ask your sysadmins.
>
> Note that there are not really "tomcat upgrade" procedures for upgrading
> your tomcat 4.1 to 8.5.  You will need to install the new tomcat
> (preferably somewhere else than the old one), and then move your
> applications one by one from the old to the new.
> If you are reasonably lucky, they might still work unchanged.
> But do not move the old tomcat settings, to the new one. That will not
> work, and will create a mess. Find out what you might need to change in the
> new standard settings, and do it there (after making a backup).
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Apache Tomcat 4.1.30 - not working with iSeries after upgrading the OS to V7R3 which uses Java 7/Java 8

[James H. H. Lampert]

On 9/7/17, 2:43 PM, Christopher Schultz wrote:

It sounds like James H.H. Lampert may be able to help you with your
problem. He's been pounding his head against his AS/400 environment
for years.


Greetings!

I finally get a chance to talk about something I know, rather than beg 
for help about something I don't know!


(And it's not necessary to use my middle initials when referring to me, 
so long as you leave out both of them. It's when people use one "H" and 
not the other that irritates me.) ;-)


Just seeing "Tomcat" and a reference to an IBM Midrange box was enough 
to catch my attention.


Everything I've come up with is based on the instructions to be found at
 
(or  if you prefer). It's currently an 
extremely slow-loading page.


What you want to do is go to the relevant download page at 
tomcat.apache.org (so far, I've ONLY run Tomcat 7 on IBM Midrange boxes, 
not earlier or later versions), and download the ZIP file (not the tar.gz).


Once you have it, figure out where you're going to put it in the IFS, 
and FTP the ZIP file into that directory.


Go into QSHELL, and navigate to where you put the ZIP file, and unzip it 
using Java's JAR command. (e.g., "JAR -xf apache-tomcat-7.0.81.zip")


Once that has completed, exit QSHELL. You might want to rename the 
Tomcat directory to something less cumbersome (our installations rename 
it to simply "tomcat")


If you're also looking at the web page, you should see a part about 
modifying catalina.sh, to force "os400" to "true." You can safely ignore it.


Now, to run Tomcat on an IBM Midrange box in any kind of meaningful way, 
you need to set up a CL program that will find the JVM, set up the 
environment variables, and launch the thing; it's simply not practical 
to do it any other way. The web page gives one very out-of-date version, 
based on running a very old Tomcat under a very old JVM that you 
probably don't have.


Our CL program, because we install it on customer boxes, is somewhat 
proprietary in nature, so I won't give you all of the source, and it's 
also fairly complex, checking for the existence of every JVM we have run 
Tomcat 7 under, and also every JVM we believe is reasonably likely to 
support Tomcat 7. It also allows us to launch Tomcat in a specific job 
queue, so it runs in a specific subsystem, and to specify minimum and 
maximum heap space (subject to the limitations of the JVM)


In our STRTOMCAT CL program, we start by building up a CL variable, 
"," that contains certain important Java options. As of just 
over a year ago, it includes:

-Dos400.awt.native=true
-Djava.awt.headless=true
-Djava.version=1.6
-XX:PermSize=256m
-XX:MaxPermSize=256m
-Djavax.servlet.request.encoding=UTF-8
-Dfile.encoding=UTF-8
and -Xms and -Xmx options with the desired heap space parameters.

Next, it looks for a suitable JVM. Currently, the JVMs we look for, in 
the order we look for them, are:

/qopensys/QIBM/ProdData/JavaVM/jdk60/32bit
/qopensys/QIBM/ProdData/JavaVM/jdk60/64bit
/qopensys/QIBM/ProdData/JavaVM/jdk626/32bit
/qopensys/QIBM/ProdData/JavaVM/jdk626/64bit
/qopensys/QIBM/ProdData/JavaVM/jdk70/32bit
/qopensys/QIBM/ProdData/JavaVM/jdk70/64bit

Once we've found one, we ADDENVVAR ENVVAR(JAVA_HOME) with the full 
pathname of the JVM and REPLACE(*YES).


We also do an ADDENVVAR ENVVAR(CATALINA_HOME) with the full pathname of 
the Tomcat directory (including the Tomcat directory itself!) and 
REPLACE(*YES).


And we do another ADDENVVAR, this time
  ADDENVVAR ENVVAR(JAVA_OPTS) VALUE() REPLACE(*YES)

Finally, with everything else set up, we

 SBMJOB CMD(QSH +
  CMD('//bin/startup.sh')) +
  JOB(CATALINA) JOBD(/) +
  JOBQ(/) INLLIBL(QGPL +
  QTEMP) CPYENVVAR(*YES) ALWMLTTHD(*YES)
(omitting the JOBQ parameter if we're using the default job queue for 
the job description).


Obviously, you will want to use some combination of job description and 
job queue that won't put Tomcat into a one-job-at-a-time batch queue. 
But just as obviously, you need to submit it as a batch job, because 
otherwise, it's going to sit there, tying up your terminal session.


We have also done a similar ENDTOMCAT CL program, that goes through much 
of the same rigmarole to select a JVM and set up environment variables, 
and then submits "shutdown.sh" as a QShell batch job, and then sits 
there, checking for the presence of a CATALINA job, and if it doesn't go 
away within a reasonable amount of time, it then abends the CATALINA job.


Note that the CATALINA job doesn't really do a whole lot; the actual 
Tomcat server runs in a job called QP0ZSPWT, that is somehow chained to 
the CATALINA job. When one job dies (either naturally or forcibly), the 
other follows immediately.


--
James H. H. Lampert


-
To unsubscribe, e-mail: 

Re: Apache Tomcat 4.1.30 - not working with iSeries after upgrading the OS to V7R3 which uses Java 7/Java 8

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ananthi,

On 9/7/17 5:12 AM, Ananthi K4 wrote:
> We have installed Apache Tomcat version 4.1.30 on our iSeries
> server. Recently we have upgraded the OS400 Operating System from
> Version 7.1 to 7.3 where Java 7 and Java 8 are introduced. After
> this upgrade, Tomcat is giving an HTTP status 500 exception
> report.
> 
> We explored the Tomcat portal and found that we are running Tomcat
> on a lower version and that needs to be upgraded. But we are unable
> to find the exact procedure to install Tomcat on iSeries server.
> 
> There is a subsystem TOMCAT running on the system with Job QP0ZSPWT
> being Active.
> 
> Please advise on the version of TOMCAT that needs to be installed
> on the system as well the procedure to install it.

It sounds like James H.H. Lampert may be able to help you with your
problem. He's been pounding his head against his AS/400 environment
for years.

I'm sure there are some OS-specific things to watch out for, but I
believe Java+Tomcat should be fairly easy to run just about anywhere:
just unpack the distribution tarball and run startup.sh from a
Unix-compatible shell and you should be up and running.

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

iQIcBAEBCAAGBQJZsb11AAoJEBzwKT+lPKRYSqgP/Ar1KeC70lL/gCXFXDhmYTZK
HiDDkHSRLotOAgtOKNK5//FdxV7L3PbGPlHquciPpfZSxbS5i/FizHKpMpoc62Sz
2+DYVplO9WwdWsjtDy63ZIN0sQ44t95FbuovwKlYq7Dd27CnfgKIruxPNy1myzTB
N7P2IneI7kXiYAuENZ/TnlddiF97r3xvOfi8/O/eYlD3pI5cQvg/YG5c7OrkxcMB
tovC+h1uZQFwOocOIfLQwWfv9kg4vi6bVFiHrlVmyruXmqbqqT42pgt0as25l1YC
q51IdkGPLuElfzGjWFPhPORGnjDaORaGv1AzE0CQsgSOKDuzqrxZqGAGEdoghPEe
3rE/hL35Aax/HL8UCJxI+zxaA+WSnSVe9TpGrnYq9W/adm/ftD1JhQI6zIRvakPU
3LlIXQ9eZNa2m4x6b7epwfc8l1rBv2/FYN6aLzXdiYOLStolVABUmlpsd9u9S7vU
h1T0QF/BwySB3JRpNtw/x+imLsJs5RsdyUk5lVrO9LcQUKR0GW4M/vDl9GrfUtiv
T363n9NWqlS3mRkz5078mNx/SxXp1K1nDCcocGX51yCnOLeQHshP5JWCysJQcKP7
WiiukfhaX29gLbsv3BwGh2RvNkwNsDTYeAwwWRey9gXFVPho2yUtsLNVl1gwzjYB
aHAVVJMDoQb9iffsKNEp
=jWe5
-END PGP SIGNATURE-

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

Re: Apache Tomcat 4.1.30 - not working with OS400 after upgrading the OS to V7R3 which uses Java 7/Java 8

[tomcat]

On 07.09.2017 16:21, Vinay A S wrote:

Hello,

We have installed Apache Tomcat version 4.1.30 on our iSeries server.


I don't even know what to tell you. Some of the people on this list may not even have been 
born yet, when that version was released.


(Ok, I am pushing it a bit; it was 2004, 13 years ago; so they may have been born, but 
still in primary school)



Recently we have upgraded the OS400 Operating System from Version 7.1 to
7.3 where Java 7 and Java 8 are introduced. After this upgrade, Tomcat is
giving an HTTP status 500 exception report.


I don't know if anyone here will be able to help, with such an old version of Tomcat. But 
in any case, an error 500 should be reflected in the tomcat logfiles.
Just in case, please view the logfile at the time of that error, and copy and paste the 
relevant part here. (Do not send it as attachment, really copy and paste it in your email)




We explored the Tomcat portal and found that we are running Tomcat on a
lower version and that needs to be upgraded.


No kidding..

 But we are unable to find the

exact procedure to install Tomcat on iSeries server.

There is a subsystem TOMCAT running on the system with Job QP0ZSPWT being
Active.

Please advise on the version of TOMCAT that needs to be installed on the
system as well the procedure to install it.



I believe that this is a question that you should ask to your system support people (or 
IBM). This list here focuses on tomcat, as per http://tomcat.apache.org.

The current version is 8.5, which requires at least a Java 7 JVM.

Tomcat per se is Java code, and will run on any platform that has an appropriate JVM 
available.
Installing Tomcat on any platform however, is more the resort of the package managers of 
the corresponding platforms/OS'es.


First find out which version of Java is available/installed on your platform.
Then consult this page : http://tomcat.apache.org/whichversion.html
to determine which version of Tomcat is appropriate (the higher, the better)

Once you have done this, there are further instructions in each version's documentation, 
that outline the installation. For example, for tomcat 8.5, here :

http://tomcat.apache.org/tomcat-8.5-doc/setup.html

The above concerns the tomcat which you would download from tomcat.apache.org.
But in all likelihood, there are special pre-packaged tomcat versions available for your 
specific platform, which might simplify this.

But this, you need to ask your sysadmins.

Note that there are not really "tomcat upgrade" procedures for upgrading your tomcat 4.1 
to 8.5.  You will need to install the new tomcat (preferably somewhere else than the old 
one), and then move your applications one by one from the old to the new.

If you are reasonably lucky, they might still work unchanged.
But do not move the old tomcat settings, to the new one. That will not work, and will 
create a mess. Find out what you might need to change in the new standard settings, and do 
it there (after making a backup).




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

Apache Tomcat 4.1.30 - not working with OS400 after upgrading the OS to V7R3 which uses Java 7/Java 8

[Vinay A S]

Hello,

We have installed Apache Tomcat version 4.1.30 on our iSeries server.
Recently we have upgraded the OS400 Operating System from Version 7.1 to
7.3 where Java 7 and Java 8 are introduced. After this upgrade, Tomcat is
giving an HTTP status 500 exception report.

We explored the Tomcat portal and found that we are running Tomcat on a
lower version and that needs to be upgraded. But we are unable to find the
exact procedure to install Tomcat on iSeries server.

There is a subsystem TOMCAT running on the system with Job QP0ZSPWT being
Active.

Please advise on the version of TOMCAT that needs to be installed on the
system as well the procedure to install it.


Regards,

Vinay A S

Apache Tomcat 4.1.30 - not working with iSeries after upgrading the OS to V7R3 which uses Java 7/Java 8

[Ananthi K4]

Hello,

We have installed Apache Tomcat version 4.1.30 on our iSeries server.
Recently we have upgraded the OS400 Operating System from Version 7.1 to
7.3 where Java 7 and Java 8 are introduced. After this upgrade, Tomcat is
giving an HTTP status 500 exception report.

We explored the Tomcat portal and found that we are running Tomcat on a
lower version and that needs to be upgraded. But we are unable to find the
exact procedure to install Tomcat on iSeries server.

There is a subsystem TOMCAT running on the system with Job QP0ZSPWT being
Active.

Please advise on the version of TOMCAT that needs to be installed on the
system as well the procedure to install it.



   
 Regards,   
   

   
 Ananthi K  
   
 iSeries Administrator - Sandvik Account
   

   






 Phone: 91-991-660-5881Manyata Tech Park, G2 
Block, 
 E-mail: ananthi.kr...@in.ibm.com  Bangalore, KA 
560045 
  
India 

Re: Tomcat 7.0.xx under Java 7?

[Mark Thomas]

On 08/02/17 00:57, James H. H. Lampert wrote:

Ladies and Gentlemen of the Tomcat List:

To date, the overwhelming bulk of our own Tomcat experience has been
under Java 6 JVMs. And we have a customer who will likely be losing that
JVM soon.

Are there any "gotchas" running 7.0.47 or later under Java 7?


No specific issues I am aware of.

General things to look out for:

- GC settings 'optimized' for an older JVM that don't make sense for the 
newer JVM. Best to remove them all and start from a clean slate.


- Web applications including libraries that are now part of the newer 
JVM and causing conflicts.


Mark


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

Tomcat 7.0.xx under Java 7?

[James H. H. Lampert]

Ladies and Gentlemen of the Tomcat List:

To date, the overwhelming bulk of our own Tomcat experience has been 
under Java 6 JVMs. And we have a customer who will likely be losing that 
JVM soon.


Are there any "gotchas" running 7.0.47 or later under Java 7?

--
James H. H. Lampert
Touchtone Corporation

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

Re: switching between Java8 and Java 7 under tomcat7 leads to error

[Konstantin Kolinko]

2016-01-26 12:19 GMT+03:00 Christoph P.U. Kukulies :
> Am 26.01.2016 um 09:36 schrieb Christoph P.U. Kukulies:
>>
>> Am 25.01.2016 um 19:34 schrieb George Sexton:
>>>
>>>
>>>
>>> On 1/25/2016 3:52 AM, Christoph P.U. Kukulies wrote:

 Thanks. Will give that a try.

 How can I tell, which java engine Tomcat is actually using?

 At a CMD prompt I'm getting:


 C:\> java -version
 java version "1.8.0_71"
 Java(TM) SE Runtime Environment (build 1.8.0_71-b15)
 Java HotSpot(TM) 64-Bit Server VM (build 25.71-b15, mixed mode)
>>>
>>>
>>> If you have a utility that shows what open files the Tomcat process has,
>>> that would work. Alternatively, get the Manager application running and see
>>> what information it provides under the Server Status screen.
>>>
>>
>> That made me ask myself, whether the parameters and settings I can see and
>> set through the manager (tomcat6w.exe) are those that the
>> Windows7 service really "sees" at startup.
>>
>> Would like to have added -Xmx768m to the startup parameters. Looking into
>> the registry HKLM\System\CurrentControlSet\Services\tomcat6
>> I can only see the ImagePath that is started ("c:\Program
>> Files\Apache_Group\Tomcat_6.0.39\bin\tomcat6.exe" //RS//Tomcat6), the
>> paramters
>> Key is empty.
>>
>> Or does tomcat6w write these parameters elsewhere?
>>
>> Thanks.
>>
>
> Sorry, discard my question above. I forgot for the moment that -Xmx is a
> Java parameter, not Tomcat.
> Nonetheless would be interesting to know, where the configurator puts its
> parameter settings and
> how one can control whether the jvm parameters are really effective.
>

The settings are written into Windows Registry
http://commons.apache.org/proper/commons-daemon/procrun.html

The service runner has debug logging, that you can enable via GUI (tomcat6w.exe)

Best regards,
Konstantin Kolinko

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

Re: switching between Java8 and Java 7 under tomcat7 leads to error

[Christoph P.U. Kukulies]

Am 25.01.2016 um 19:34 schrieb George Sexton:



On 1/25/2016 3:52 AM, Christoph P.U. Kukulies wrote:

Thanks. Will give that a try.

How can I tell, which java engine Tomcat is actually using?

At a CMD prompt I'm getting:


C:\> java -version
java version "1.8.0_71"
Java(TM) SE Runtime Environment (build 1.8.0_71-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.71-b15, mixed mode)


If you have a utility that shows what open files the Tomcat process 
has, that would work. Alternatively, get the Manager application 
running and see what information it provides under the Server Status 
screen.




That made me ask myself, whether the parameters and settings I can see 
and set through the manager (tomcat6w.exe) are those that the

Windows7 service really "sees" at startup.

Would like to have added -Xmx768m to the startup parameters. Looking 
into the registry HKLM\System\CurrentControlSet\Services\tomcat6
I can only see the ImagePath that is started ("c:\Program 
Files\Apache_Group\Tomcat_6.0.39\bin\tomcat6.exe" //RS//Tomcat6), the 
paramters

Key is empty.

Or does tomcat6w write these parameters elsewhere?

Thanks.

--
Christoph



At Am 22.01.2016 um 18:28 schrieb George Sexton:



On 1/22/2016 6:06 AM, Christoph P.U. Kukulies wrote:

Windows 7:

Today I installed Java 8 on my windows 7 machine and did an upgrade 
of the CMS at the same time (from OpenCMS 9.5.2 to 9.5.3).
After the Java update and the CMS update suddenly my tomcat 6.0.39 
didn't start any longer. The service gave an error at start time:


Der Dienst "Apache Tomcat 6.0 Tomcat6" wurde mit folgendem 
dienstspezifischem Fehler beendet: Unzulässige Funktion..




I've seen this on Windows when upgrading the JRE. The solution that 
worked for me (multiple times) was to uninstall Java, and then 
re-install it. Make sure you grab the correct version (x86, x64) to 
go with your Tomcat install.




My thoughts came to tomcat6 possibly not being compatible with 
Java8 and so I decided to install tomcat 7.0 which started fine.


When starting my CMS system again I now found that it did some 
unpleasant things for which I wanted to rule out tomcat7 being the 
culprit
and switch the jvm.dll in the tomcat7 configurator to the jre1.7 
jvm.dll.


Then suddenly I got the same error as under tomcat6.0 when I tried 
to start tomcat7 again.


Could it be that the Java8 installer screws the existing Java 7 ? 
Or does it change some global parameters that tomcat reads at start 
time.



Thanks.

--
Christoph




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

Re: switching between Java8 and Java 7 under tomcat7 leads to error

[Christoph P.U. Kukulies]

Am 26.01.2016 um 09:36 schrieb Christoph P.U. Kukulies:

Am 25.01.2016 um 19:34 schrieb George Sexton:



On 1/25/2016 3:52 AM, Christoph P.U. Kukulies wrote:

Thanks. Will give that a try.

How can I tell, which java engine Tomcat is actually using?

At a CMD prompt I'm getting:


C:\> java -version
java version "1.8.0_71"
Java(TM) SE Runtime Environment (build 1.8.0_71-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.71-b15, mixed mode)


If you have a utility that shows what open files the Tomcat process 
has, that would work. Alternatively, get the Manager application 
running and see what information it provides under the Server Status 
screen.




That made me ask myself, whether the parameters and settings I can see 
and set through the manager (tomcat6w.exe) are those that the

Windows7 service really "sees" at startup.

Would like to have added -Xmx768m to the startup parameters. Looking 
into the registry HKLM\System\CurrentControlSet\Services\tomcat6
I can only see the ImagePath that is started ("c:\Program 
Files\Apache_Group\Tomcat_6.0.39\bin\tomcat6.exe" //RS//Tomcat6), the 
paramters

Key is empty.

Or does tomcat6w write these parameters elsewhere?

Thanks.



Sorry, discard my question above. I forgot for the moment that -Xmx is a 
Java parameter, not Tomcat.
Nonetheless would be interesting to know, where the configurator puts 
its parameter settings and

how one can control whether the jvm parameters are really effective.

--
Christoph


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

Re: switching between Java8 and Java 7 under tomcat7 leads to error

[tomcat]

On 26.01.2016 10:19, Christoph P.U. Kukulies wrote:

Am 26.01.2016 um 09:36 schrieb Christoph P.U. Kukulies:

Am 25.01.2016 um 19:34 schrieb George Sexton:



On 1/25/2016 3:52 AM, Christoph P.U. Kukulies wrote:

Thanks. Will give that a try.

How can I tell, which java engine Tomcat is actually using?

At a CMD prompt I'm getting:


C:\> java -version
java version "1.8.0_71"
Java(TM) SE Runtime Environment (build 1.8.0_71-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.71-b15, mixed mode)


If you have a utility that shows what open files the Tomcat process has, that 
would
work. Alternatively, get the Manager application running and see what 
information it
provides under the Server Status screen.



That made me ask myself, whether the parameters and settings I can see and set 
through
the manager (tomcat6w.exe) are those that the
Windows7 service really "sees" at startup.

Would like to have added -Xmx768m to the startup parameters. Looking into the 
registry
HKLM\System\CurrentControlSet\Services\tomcat6
I can only see the ImagePath that is started ("c:\Program
Files\Apache_Group\Tomcat_6.0.39\bin\tomcat6.exe" //RS//Tomcat6), the paramters
Key is empty.

Or does tomcat6w write these parameters elsewhere?

Thanks.



Sorry, discard my question above. I forgot for the moment that -Xmx is a Java 
parameter,
not Tomcat.
Nonetheless would be interesting to know, where the configurator puts its 
parameter
settings and
how one can control whether the jvm parameters are really effective.

--
Christoph



Maybe time to read the FAQ ?
http://wiki.apache.org/tomcat/FAQ/Windows#Q11




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

Re: switching between Java8 and Java 7 under tomcat7 leads to error

[Christoph P.U. Kukulies]

Am 26.01.2016 um 10:40 schrieb André Warnier (tomcat):

On 26.01.2016 10:19, Christoph P.U. Kukulies wrote:

Am 26.01.2016 um 09:36 schrieb Christoph P.U. Kukulies:

Am 25.01.2016 um 19:34 schrieb George Sexton:



On 1/25/2016 3:52 AM, Christoph P.U. Kukulies wrote:

Thanks. Will give that a try.

How can I tell, which java engine Tomcat is actually using?

At a CMD prompt I'm getting:


C:\> java -version
java version "1.8.0_71"
Java(TM) SE Runtime Environment (build 1.8.0_71-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.71-b15, mixed mode)


If you have a utility that shows what open files the Tomcat process 
has, that would
work. Alternatively, get the Manager application running and see 
what information it

provides under the Server Status screen.



That made me ask myself, whether the parameters and settings I can 
see and set through

the manager (tomcat6w.exe) are those that the
Windows7 service really "sees" at startup.

Would like to have added -Xmx768m to the startup parameters. Looking 
into the registry

HKLM\System\CurrentControlSet\Services\tomcat6
I can only see the ImagePath that is started ("c:\Program
Files\Apache_Group\Tomcat_6.0.39\bin\tomcat6.exe" //RS//Tomcat6), 
the paramters

Key is empty.

Or does tomcat6w write these parameters elsewhere?

Thanks.



Sorry, discard my question above. I forgot for the moment that -Xmx 
is a Java parameter,

not Tomcat.
Nonetheless would be interesting to know, where the configurator puts 
its parameter

settings and
how one can control whether the jvm parameters are really effective.

--
Christoph



Maybe time to read the FAQ ?
http://wiki.apache.org/tomcat/FAQ/Windows#Q11



OK, fine. I read it and understood about tomcat6.exe being a wrapper 
that starts the jvm etc.

Explains a lot.
Logging is fine also. This enabled me to discover that the jvm options 
have to put in one line one by one.

I had -Xms512m - Xmx1024m in one line causing the service start to fail.


--
Christoph




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

Re: switching between Java8 and Java 7 under tomcat7 leads to error

[Karl Hauschildt]

Be careful. The only real way to know what tomcat is using is to get into
the manager who will display the java version it is using. Their startup
script makes some determination on the fly.

On Mon, Jan 25, 2016 at 1:34 PM, George Sexton <geor...@mhsoftware.com>
wrote:

>
>
> On 1/25/2016 3:52 AM, Christoph P.U. Kukulies wrote:
>
>> Thanks. Will give that a try.
>>
>> How can I tell, which java engine Tomcat is actually using?
>>
>> At a CMD prompt I'm getting:
>>
>>
>> C:\> java -version
>> java version "1.8.0_71"
>> Java(TM) SE Runtime Environment (build 1.8.0_71-b15)
>> Java HotSpot(TM) 64-Bit Server VM (build 25.71-b15, mixed mode)
>>
>
> If you have a utility that shows what open files the Tomcat process has,
> that would work. Alternatively, get the Manager application running and see
> what information it provides under the Server Status screen.
>
>
>
>
>> --
>> Christoph
>>
>>
>> At Am 22.01.2016 um 18:28 schrieb George Sexton:
>>
>>>
>>>
>>> On 1/22/2016 6:06 AM, Christoph P.U. Kukulies wrote:
>>>
>>>> Windows 7:
>>>>
>>>> Today I installed Java 8 on my windows 7 machine and did an upgrade of
>>>> the CMS at the same time (from OpenCMS 9.5.2 to 9.5.3).
>>>> After the Java update and the CMS update suddenly my tomcat 6.0.39
>>>> didn't start any longer. The service gave an error at start time:
>>>>
>>>> Der Dienst "Apache Tomcat 6.0 Tomcat6" wurde mit folgendem
>>>> dienstspezifischem Fehler beendet: Unzulässige Funktion..
>>>>
>>>>
>>> I've seen this on Windows when upgrading the JRE. The solution that
>>> worked for me (multiple times) was to uninstall Java, and then re-install
>>> it. Make sure you grab the correct version (x86, x64) to go with your
>>> Tomcat install.
>>>
>>>
>>>
>>> My thoughts came to tomcat6 possibly not being compatible with Java8 and
>>>> so I decided to install tomcat 7.0 which started fine.
>>>>
>>>> When starting my CMS system again I now found that it did some
>>>> unpleasant things for which I wanted to rule out tomcat7 being the culprit
>>>> and switch the jvm.dll in the tomcat7 configurator to the jre1.7
>>>> jvm.dll.
>>>>
>>>> Then suddenly I got the same error as under tomcat6.0 when I tried to
>>>> start tomcat7 again.
>>>>
>>>> Could it be that the Java8 installer screws the existing Java 7 ? Or
>>>> does it change some global parameters that tomcat reads at start time.
>>>>
>>>>
>>>> Thanks.
>>>>
>>>> --
>>>> Christoph
>>>>
>>>>
>>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
> --
> George Sexton
> *MH Software, Inc.*
> Voice: 303 438 9585
> http://www.mhsoftware.com
>

Re: switching between Java8 and Java 7 under tomcat7 leads to error

[George Sexton]

On 1/25/2016 3:52 AM, Christoph P.U. Kukulies wrote:

Thanks. Will give that a try.

How can I tell, which java engine Tomcat is actually using?

At a CMD prompt I'm getting:


C:\> java -version
java version "1.8.0_71"
Java(TM) SE Runtime Environment (build 1.8.0_71-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.71-b15, mixed mode)


If you have a utility that shows what open files the Tomcat process has, 
that would work. Alternatively, get the Manager application running and 
see what information it provides under the Server Status screen.





--
Christoph


At Am 22.01.2016 um 18:28 schrieb George Sexton:



On 1/22/2016 6:06 AM, Christoph P.U. Kukulies wrote:

Windows 7:

Today I installed Java 8 on my windows 7 machine and did an upgrade 
of the CMS at the same time (from OpenCMS 9.5.2 to 9.5.3).
After the Java update and the CMS update suddenly my tomcat 6.0.39 
didn't start any longer. The service gave an error at start time:


Der Dienst "Apache Tomcat 6.0 Tomcat6" wurde mit folgendem 
dienstspezifischem Fehler beendet: Unzulässige Funktion..




I've seen this on Windows when upgrading the JRE. The solution that 
worked for me (multiple times) was to uninstall Java, and then 
re-install it. Make sure you grab the correct version (x86, x64) to 
go with your Tomcat install.




My thoughts came to tomcat6 possibly not being compatible with Java8 
and so I decided to install tomcat 7.0 which started fine.


When starting my CMS system again I now found that it did some 
unpleasant things for which I wanted to rule out tomcat7 being the 
culprit
and switch the jvm.dll in the tomcat7 configurator to the jre1.7 
jvm.dll.


Then suddenly I got the same error as under tomcat6.0 when I tried 
to start tomcat7 again.


Could it be that the Java8 installer screws the existing Java 7 ? Or 
does it change some global parameters that tomcat reads at start time.



Thanks.

--
Christoph





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



--
George Sexton
*MH Software, Inc.*
Voice: 303 438 9585
http://www.mhsoftware.com

Re: switching between Java8 and Java 7 under tomcat7 leads to error

[Terence M. Bandoian]

On 1/25/2016 12:34 PM, George Sexton wrote:



On 1/25/2016 3:52 AM, Christoph P.U. Kukulies wrote:

Thanks. Will give that a try.

How can I tell, which java engine Tomcat is actually using?

At a CMD prompt I'm getting:


C:\> java -version
java version "1.8.0_71"
Java(TM) SE Runtime Environment (build 1.8.0_71-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.71-b15, mixed mode)


If you have a utility that shows what open files the Tomcat process 
has, that would work. Alternatively, get the Manager application 
running and see what information it provides under the Server Status 
screen.




Also, the Tomcat Windows Service Installer includes a configuration 
utility (I'm not sure about the zip downloads).  In the Java tab of the 
utility, the JVM may be selected.


-Terence Bandoian
/http://www.tmbsw.com/
/





--
Christoph


At Am 22.01.2016 um 18:28 schrieb George Sexton:



On 1/22/2016 6:06 AM, Christoph P.U. Kukulies wrote:

Windows 7:

Today I installed Java 8 on my windows 7 machine and did an upgrade 
of the CMS at the same time (from OpenCMS 9.5.2 to 9.5.3).
After the Java update and the CMS update suddenly my tomcat 6.0.39 
didn't start any longer. The service gave an error at start time:


Der Dienst "Apache Tomcat 6.0 Tomcat6" wurde mit folgendem 
dienstspezifischem Fehler beendet: Unzulässige Funktion..




I've seen this on Windows when upgrading the JRE. The solution that 
worked for me (multiple times) was to uninstall Java, and then 
re-install it. Make sure you grab the correct version (x86, x64) to 
go with your Tomcat install.




My thoughts came to tomcat6 possibly not being compatible with 
Java8 and so I decided to install tomcat 7.0 which started fine.


When starting my CMS system again I now found that it did some 
unpleasant things for which I wanted to rule out tomcat7 being the 
culprit
and switch the jvm.dll in the tomcat7 configurator to the jre1.7 
jvm.dll.


Then suddenly I got the same error as under tomcat6.0 when I tried 
to start tomcat7 again.


Could it be that the Java8 installer screws the existing Java 7 ? 
Or does it change some global parameters that tomcat reads at start 
time.



Thanks.

--
Christoph





-
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: switching between Java8 and Java 7 under tomcat7 leads to error

[Christoph P.U. Kukulies]

Thanks. Will give that a try.

How can I tell, which java engine Tomcat is actually using?

At a CMD prompt I'm getting:


C:\> java -version
java version "1.8.0_71"
Java(TM) SE Runtime Environment (build 1.8.0_71-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.71-b15, mixed mode)

--
Christoph


At Am 22.01.2016 um 18:28 schrieb George Sexton:



On 1/22/2016 6:06 AM, Christoph P.U. Kukulies wrote:

Windows 7:

Today I installed Java 8 on my windows 7 machine and did an upgrade 
of the CMS at the same time (from OpenCMS 9.5.2 to 9.5.3).
After the Java update and the CMS update suddenly my tomcat 6.0.39 
didn't start any longer. The service gave an error at start time:


Der Dienst "Apache Tomcat 6.0 Tomcat6" wurde mit folgendem 
dienstspezifischem Fehler beendet: Unzulässige Funktion..




I've seen this on Windows when upgrading the JRE. The solution that 
worked for me (multiple times) was to uninstall Java, and then 
re-install it. Make sure you grab the correct version (x86, x64) to go 
with your Tomcat install.




My thoughts came to tomcat6 possibly not being compatible with Java8 
and so I decided to install tomcat 7.0 which started fine.


When starting my CMS system again I now found that it did some 
unpleasant things for which I wanted to rule out tomcat7 being the 
culprit
and switch the jvm.dll in the tomcat7 configurator to the jre1.7 
jvm.dll.


Then suddenly I got the same error as under tomcat6.0 when I tried to 
start tomcat7 again.


Could it be that the Java8 installer screws the existing Java 7 ? Or 
does it change some global parameters that tomcat reads at start time.



Thanks.

--
Christoph





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

switching between Java8 and Java 7 under tomcat7 leads to error

[Christoph P.U. Kukulies]

Windows 7:

Today I installed Java 8 on my windows 7 machine and did an upgrade of 
the CMS at the same time (from OpenCMS 9.5.2 to 9.5.3).
After the Java update and the CMS update suddenly my tomcat 6.0.39 
didn't start any longer. The service gave an error at start time:


Der Dienst "Apache Tomcat 6.0 Tomcat6" wurde mit folgendem 
dienstspezifischem Fehler beendet: Unzulässige Funktion..


My thoughts came to tomcat6 possibly not being compatible with Java8 and 
so I decided to install tomcat 7.0 which started fine.


When starting my CMS system again I now found that it did some 
unpleasant things for which I wanted to rule out tomcat7 being the culprit

and switch the jvm.dll in the tomcat7 configurator to the jre1.7 jvm.dll.

Then suddenly I got the same error as under tomcat6.0 when I tried to 
start tomcat7 again.


Could it be that the Java8 installer screws the existing Java 7 ? Or 
does it change some global parameters that tomcat reads at start time.



Thanks.

--
Christoph


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

Re: switching between Java8 and Java 7 under tomcat7 leads to error

[Konstantin Kolinko]

2016-01-22 16:06 GMT+03:00 Christoph P.U. Kukulies <k...@kukulies.org>:
> Windows 7:
>
> Today I installed Java 8 on my windows 7 machine and did an upgrade of the
> CMS at the same time (from OpenCMS 9.5.2 to 9.5.3).
> After the Java update and the CMS update suddenly my tomcat 6.0.39 didn't
> start any longer. The service gave an error at start time:
>
> Der Dienst "Apache Tomcat 6.0 Tomcat6" wurde mit folgendem
> dienstspezifischem Fehler beendet: Unzulässige Funktion..
>
> My thoughts came to tomcat6 possibly not being compatible with Java8 and so
> I decided to install tomcat 7.0 which started fine.
>
> When starting my CMS system again I now found that it did some unpleasant
> things for which I wanted to rule out tomcat7 being the culprit
> and switch the jvm.dll in the tomcat7 configurator to the jre1.7 jvm.dll.
>
> Then suddenly I got the same error as under tomcat6.0 when I tried to start
> tomcat7 again.
>
> Could it be that the Java8 installer screws the existing Java 7 ? Or does it
> change some global parameters that tomcat reads at start time.

1. That "The service "Apache Tomcat 6.0 Tomcat6" terminated with
service-specific error: Incorrect function .." error (thanks to Google
Translate)  is coming from service wrapper, not from Tomcat itself.

Tomcat own errors are logged into textual log files, they are not
shown as a message window. See the log files in Tomcat's logs
directory. There is separate file for the service there.

Note that service wrapper (tomcat6.exe, tomcat7.exe) must be the same
32 vs 64 bit version as the Java jvm dll that you are using.  My guess
is that this mismatch is the reason for the error that you are
observing.

The Tomcat-[version].exe installer automatically detects 32 vs. 64bit
architecture by the jvm that you choose during installation, and
installs that version of wrapper.  If you download Tomcat as a zip
file, the only difference between "32-bit" and "64-bit" Windows zip
archives is the version of service wrapper and the version of
tc-native.dll.


2. If no jvm.dll is configured, or configured jvm.dll is not found
then the service wrapper tries to use the default (latest) JVM
configured in the system.

That default jvm changes when you upgrade from java 7 to java 8.

Also Java 8 installer usually asks (prompts) you to uninstall old
versions of java. You may have uninstalled the old version and it is
no longer found.

Best regards,
Konstantin Kolinko

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

Re: switching between Java8 and Java 7 under tomcat7 leads to error

[Christoph P.U. Kukulies]

Am 22.01.2016 um 14:29 schrieb David kerber:

On 1/22/2016 8:06 AM, Christoph P.U. Kukulies wrote:

Windows 7:

Today I installed Java 8 on my windows 7 machine and did an upgrade of
the CMS at the same time (from OpenCMS 9.5.2 to 9.5.3).
After the Java update and the CMS update suddenly my tomcat 6.0.39
didn't start any longer. The service gave an error at start time:

Der Dienst "Apache Tomcat 6.0 Tomcat6" wurde mit folgendem
dienstspezifischem Fehler beendet: Unzulässige Funktion..

My thoughts came to tomcat6 possibly not being compatible with Java8 and
so I decided to install tomcat 7.0 which started fine.

When starting my CMS system again I now found that it did some
unpleasant things for which I wanted to rule out tomcat7 being the 
culprit
and switch the jvm.dll in the tomcat7 configurator to the jre1.7 
jvm.dll.


Then suddenly I got the same error as under tomcat6.0 when I tried to
start tomcat7 again.

Could it be that the Java8 installer screws the existing Java 7 ? Or
does it change some global parameters that tomcat reads at start time.


If you take the default installation location and do not allow it to 
remove the old one, Java 8 will not alter your java 7 installation.


However, which java is found if you do not explicitly specify which 
one to run, may change.  Try dropping to a command prompt, and type


java -version


That will tell you which one is the default.  If your app needs a 
different one, you will have to specify it.



Thanks. Java -version gives


U:\>java -version
java version "1.8.0_71"
Java(TM) SE Runtime Environment (build 1.8.0_71-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.71-b15, mixed mode)

So could tomcat6 been puzzled by this? The tomcat6 configurator had most 
probably the 7.0 jvm configured, wouldn't it?
Since the java 8 installer would not mess with tomcat6 configuration. 
Iin other words: can I conclude that the java8 update (which preserved

java7) cannot be the reason why tomcat6 didn't start.



--
Christoph


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

Re: switching between Java8 and Java 7 under tomcat7 leads to error

[David kerber]

On 1/22/2016 8:06 AM, Christoph P.U. Kukulies wrote:

Windows 7:

Today I installed Java 8 on my windows 7 machine and did an upgrade of
the CMS at the same time (from OpenCMS 9.5.2 to 9.5.3).
After the Java update and the CMS update suddenly my tomcat 6.0.39
didn't start any longer. The service gave an error at start time:

Der Dienst "Apache Tomcat 6.0 Tomcat6" wurde mit folgendem
dienstspezifischem Fehler beendet: Unzulässige Funktion..

My thoughts came to tomcat6 possibly not being compatible with Java8 and
so I decided to install tomcat 7.0 which started fine.

When starting my CMS system again I now found that it did some
unpleasant things for which I wanted to rule out tomcat7 being the culprit
and switch the jvm.dll in the tomcat7 configurator to the jre1.7 jvm.dll.

Then suddenly I got the same error as under tomcat6.0 when I tried to
start tomcat7 again.

Could it be that the Java8 installer screws the existing Java 7 ? Or
does it change some global parameters that tomcat reads at start time.


If you take the default installation location and do not allow it to 
remove the old one, Java 8 will not alter your java 7 installation.


However, which java is found if you do not explicitly specify which one 
to run, may change.  Try dropping to a command prompt, and type


java -version


That will tell you which one is the default.  If your app needs a 
different one, you will have to specify it.



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

Re: switching between Java8 and Java 7 under tomcat7 leads to error

[George Sexton]

On 1/22/2016 6:06 AM, Christoph P.U. Kukulies wrote:

Windows 7:

Today I installed Java 8 on my windows 7 machine and did an upgrade of 
the CMS at the same time (from OpenCMS 9.5.2 to 9.5.3).
After the Java update and the CMS update suddenly my tomcat 6.0.39 
didn't start any longer. The service gave an error at start time:


Der Dienst "Apache Tomcat 6.0 Tomcat6" wurde mit folgendem 
dienstspezifischem Fehler beendet: Unzulässige Funktion..




I've seen this on Windows when upgrading the JRE. The solution that 
worked for me (multiple times) was to uninstall Java, and then 
re-install it. Make sure you grab the correct version (x86, x64) to go 
with your Tomcat install.




My thoughts came to tomcat6 possibly not being compatible with Java8 
and so I decided to install tomcat 7.0 which started fine.


When starting my CMS system again I now found that it did some 
unpleasant things for which I wanted to rule out tomcat7 being the 
culprit

and switch the jvm.dll in the tomcat7 configurator to the jre1.7 jvm.dll.

Then suddenly I got the same error as under tomcat6.0 when I tried to 
start tomcat7 again.


Could it be that the Java8 installer screws the existing Java 7 ? Or 
does it change some global parameters that tomcat reads at start time.



Thanks.

--
Christoph


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



--
George Sexton
*MH Software, Inc.*
Voice: 303 438 9585
http://www.mhsoftware.com

Re: Java 7 and 8 features

[David kerber]

On 10/27/2015 12:01 PM, Vinicius Corrêa de Almeida wrote:

I analized some releases and i noticed that not using java 7 features like
multi catch and in java 8 do not use lambda expressions and others
features, so i came by this email to know why the developers not using this
features?



Which version of Tomcat were you looking at?  Each version targets a 
certain java version as its minimum, so cannot use feathers which are 
not in that JRE version.



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

Java 7 and 8 features

[Vinicius Corrêa de Almeida]

I analized some releases and i noticed that not using java 7 features like
multi catch and in java 8 do not use lambda expressions and others
features, so i came by this email to know why the developers not using this
features?

Re: Java 7 and 8 features

[tomcat]

On 27.10.2015 17:01, Vinicius Corrêa de Almeida wrote:

I analized some releases and i noticed that not using java 7 features like
multi catch and in java 8 do not use lambda expressions and others
features, so i came by this email to know why the developers not using this
features?



I believe that you are asking the wrong question.

As per this page : http://tomcat.apache.org/whichversion.html

"Apache Tomcat™ is an open source software implementation of the Java Servlet and 
JavaServer Pages technologies."


In other words, Tomcat is not an implementation of any specific Java version.
If, to fulfill its target of implementing some specific version of the Java Servlet and 
JavaServer Pages technologies, it was necessary for running Tomcat code to use a certain 
minimum version of the Java JVM, then so be it, and the page above would mention that (and 
it does).
But that does not mean that every feature available in such a version of the Java JVM 
/must/ necessarily be used by Tomcat.




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

Re: Memory shortage appears as missing pulse-java.jar file error with Java 7

[Peter Lavin]

Hi Konstantin,

thanks for your comprehensive answer. On the version I am using 
(7.0.28.0), the file pulse-java.jar is not present (using linux command 
updatedb and locate to check).


I found my solution from the following link...

http://stackoverflow.com/questions/20564070/failed-to-process-jar-found-at-url-jarfilebcprov-jdk15-1-46-jar-for-servle

And although this guy's problem stemmed from a different file, he 
solved it by increasing the memory available to Tomcat. When I installed 
this particular instance of T'cat, I had overlooked to increase 
available memory. I have not had the problem since doing that.


thanks again,
Peter




On 14-01-2015 11:15, Konstantin Kolinko wrote:

2015-01-13 14:18 GMT+03:00 Peter Lavin lav...@cs.tcd.ie:


Hi all, I have deployed a simple (Eclipse developed) webservice in a 
Tomcat7

container which is running on Debian, details as follows...

The error is as follows... (abridged, but it is complaining about 
missing a

file called pulse-java.jar)

INFO: Deploying web application archive
/var/lib/tomcat7/webapps/SecureServiceExample.war
Jan 12, 2015 3:03:01 PM org.apache.catalina.startup.TldConfig 
tldScanJar

WARNING: Failed to process JAR

[jar:file:/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/ext/pulse-java.jar!/]
for TLD files
java.io.FileNotFoundException:
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/ext/pulse-java.jar (No 
such file

or directory)
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.init(ZipFile.java:215)
at java.util.zip.ZipFile.init(ZipFile.java:145)


1) It is a warning, not an error.

2) If Tomcat attempts to scan the file, it means that the file is
listed by the System classloader (or some other classloader in
classloader hierarchy).

I do not know how system classpath is configured on your system.

It is either auto-detected (and thus the file exists, but maybe it is
not readable), or there is some system configuration file for java
that has a stale value. E.g. if you are launching it from within
Eclipse IDE  it may be listed in your Java Runtime configuration.

Some versions of Java 7 certainly do have pulse-java.jar.  It is in
ext directory, so it is not part of the core JRE, but an extension.
Maybe there is a separate package that installs it?

Quick googling finds a mention that it was removed between 7u51 and 
7u71.

https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/1389493

3) Consider upgrading your Tomcat version.
https://wiki.apache.org/tomcat/FAQ/Linux_Unix#Q5

Current versions of Tomcat 7 do not scan pulse-java.jar for TLDs.

A) since 7.0.30 (r1377297) pulse-java.jar is explicitly included into
tomcat.util.scan.DefaultJarScanner.jarsToSkip value in
catalina.properties

B) since 7.0.38 (r1448831) Tomcat skips scanning of all JRE JARs as a 
whole.


4) The warning message and OOM are different errors. They are likely
not related. You have not cited the actual OOM message.

Though unneeded scanning of some large jar files is a waste of time
and may require a lot of memory. You can configure what files are
skipped via above mentioned
tomcat.util.scan.DefaultJarScanner.jarsToSkip setting.



I'm using a Debian GNU Linux 7 VM, running version.sh of Tomcat7 
yields...


Using CATALINA_BASE:   /usr/share/tomcat7
Using CATALINA_HOME:   /usr/share/tomcat7
Using CATALINA_TMPDIR: /usr/share/tomcat7/temp
Using JRE_HOME:/usr/lib/jvm/java-7-openjdk-amd64
Using CLASSPATH:

/usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-juli.jar
Server version: Apache Tomcat/7.0.28
Server built:   Apr 8 2014 08:47:08
Server number:  7.0.28.0
OS Name:Linux
OS Version: 3.2.0-4-amd64
Architecture:   amd64
JVM Version:1.7.0_65-b32
JVM Vendor: Oracle Corporation

Tomcat7 was installed using apt-get. With the default memory 
settings

(around line 271 in catalina.sh) as follows...

CATALINA_OPTS=$CATALINA_OPTS $JPDA_OPTS

The above error occurs.

When I made the following changes... (below) the error goes away

CATALINA_OPTS=-server $CATALINA_OPTS -Xms512m -Xms2048m
-XX:MaxPermSize=512m -Dcom.sun.management.jmxremote

My question... pulse-java.jar does not exist in Java 7 although it 
did in
Java 6. In Java 7, it is provided by a different file. It appears 
that the
shortage of allocated memory manifests itself as a missing file. Has 
anyone
else found anything like this or used a different solution to fix 
it?



Best regards,
Konstantin Kolinko

-
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: Memory shortage appears as missing pulse-java.jar file error with Java 7

[Peter Lavin]

Hi André, thanks for your reply.

well spotted, I've corrected my Xmx/Xms error and restarted.

On 13-01-2015 14:07, André Warnier wrote:

Peter Lavin wrote:
Tomcat7 was installed using apt-get. With the default memory 
settings (around line 271 in catalina.sh) as follows...

CATALINA_OPTS=$CATALINA_OPTS $JPDA_OPTS
The above error occurs.
When I made the following changes... (below) the error goes away
CATALINA_OPTS=-server $CATALINA_OPTS -Xms512m -Xms2048m


a typo here ? (2 times -Xms ..)

and, what was in $JPDA_OPTS ?



To your clarification...

JPDA_OPTS is set as follows (i.e. the default, just before line 270, I 
did not change this)...


=-agentlib:jdwp=transport=$JPDA_TRANSPORT,
address=$JPDA_ADDRESS,server=y,suspend=$JPDA_SUSPEND

regards,
Peter

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

Re: Memory shortage appears as missing pulse-java.jar file error with Java 7

[Konstantin Kolinko]

2015-01-13 14:18 GMT+03:00 Peter Lavin lav...@cs.tcd.ie:

 Hi all, I have deployed a simple (Eclipse developed) webservice in a Tomcat7
 container which is running on Debian, details as follows...

 The error is as follows... (abridged, but it is complaining about missing a
 file called pulse-java.jar)

 INFO: Deploying web application archive
 /var/lib/tomcat7/webapps/SecureServiceExample.war
 Jan 12, 2015 3:03:01 PM org.apache.catalina.startup.TldConfig tldScanJar
 WARNING: Failed to process JAR
 [jar:file:/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/ext/pulse-java.jar!/]
 for TLD files
 java.io.FileNotFoundException:
 /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/ext/pulse-java.jar (No such file
 or directory)
 at java.util.zip.ZipFile.open(Native Method)
 at java.util.zip.ZipFile.init(ZipFile.java:215)
 at java.util.zip.ZipFile.init(ZipFile.java:145)

1) It is a warning, not an error.

2) If Tomcat attempts to scan the file, it means that the file is
listed by the System classloader (or some other classloader in
classloader hierarchy).

I do not know how system classpath is configured on your system.

It is either auto-detected (and thus the file exists, but maybe it is
not readable), or there is some system configuration file for java
that has a stale value. E.g. if you are launching it from within
Eclipse IDE  it may be listed in your Java Runtime configuration.

Some versions of Java 7 certainly do have pulse-java.jar.  It is in
ext directory, so it is not part of the core JRE, but an extension.
Maybe there is a separate package that installs it?

Quick googling finds a mention that it was removed between 7u51 and 7u71.
https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/1389493

3) Consider upgrading your Tomcat version.
https://wiki.apache.org/tomcat/FAQ/Linux_Unix#Q5

Current versions of Tomcat 7 do not scan pulse-java.jar for TLDs.

A) since 7.0.30 (r1377297) pulse-java.jar is explicitly included into
tomcat.util.scan.DefaultJarScanner.jarsToSkip value in
catalina.properties

B) since 7.0.38 (r1448831) Tomcat skips scanning of all JRE JARs as a whole.

4) The warning message and OOM are different errors. They are likely
not related. You have not cited the actual OOM message.

Though unneeded scanning of some large jar files is a waste of time
and may require a lot of memory. You can configure what files are
skipped via above mentioned
tomcat.util.scan.DefaultJarScanner.jarsToSkip setting.


 I'm using a Debian GNU Linux 7 VM, running version.sh of Tomcat7 yields...

 Using CATALINA_BASE:   /usr/share/tomcat7
 Using CATALINA_HOME:   /usr/share/tomcat7
 Using CATALINA_TMPDIR: /usr/share/tomcat7/temp
 Using JRE_HOME:/usr/lib/jvm/java-7-openjdk-amd64
 Using CLASSPATH:
 /usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-juli.jar
 Server version: Apache Tomcat/7.0.28
 Server built:   Apr 8 2014 08:47:08
 Server number:  7.0.28.0
 OS Name:Linux
 OS Version: 3.2.0-4-amd64
 Architecture:   amd64
 JVM Version:1.7.0_65-b32
 JVM Vendor: Oracle Corporation

 Tomcat7 was installed using apt-get. With the default memory settings
 (around line 271 in catalina.sh) as follows...

 CATALINA_OPTS=$CATALINA_OPTS $JPDA_OPTS

 The above error occurs.

 When I made the following changes... (below) the error goes away

 CATALINA_OPTS=-server $CATALINA_OPTS -Xms512m -Xms2048m
 -XX:MaxPermSize=512m -Dcom.sun.management.jmxremote

 My question... pulse-java.jar does not exist in Java 7 although it did in
 Java 6. In Java 7, it is provided by a different file. It appears that the
 shortage of allocated memory manifests itself as a missing file. Has anyone
 else found anything like this or used a different solution to fix it?


Best regards,
Konstantin Kolinko

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

Re: Memory shortage appears as missing pulse-java.jar file error with Java 7

[André Warnier]

Peter Lavin wrote:


Hi all, I have deployed a simple (Eclipse developed) webservice in a 
Tomcat7 container which is running on Debian, details as follows...


The error is as follows... (abridged, but it is complaining about 
missing a file called pulse-java.jar)


INFO: Deploying web application archive 
/var/lib/tomcat7/webapps/SecureServiceExample.war

Jan 12, 2015 3:03:01 PM org.apache.catalina.startup.TldConfig tldScanJar
WARNING: Failed to process JAR 
[jar:file:/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/ext/pulse-java.jar!/] 
for TLD files
java.io.FileNotFoundException: 
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/ext/pulse-java.jar (No such 
file or directory)

at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.init(ZipFile.java:215)
at java.util.zip.ZipFile.init(ZipFile.java:145)


I'm using a Debian GNU Linux 7 VM, running version.sh of Tomcat7 yields...

Using CATALINA_BASE:   /usr/share/tomcat7
Using CATALINA_HOME:   /usr/share/tomcat7
Using CATALINA_TMPDIR: /usr/share/tomcat7/temp
Using JRE_HOME:/usr/lib/jvm/java-7-openjdk-amd64
Using CLASSPATH:   
/usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-juli.jar

Server version: Apache Tomcat/7.0.28
Server built:   Apr 8 2014 08:47:08
Server number:  7.0.28.0
OS Name:Linux
OS Version: 3.2.0-4-amd64
Architecture:   amd64
JVM Version:1.7.0_65-b32
JVM Vendor: Oracle Corporation

Tomcat7 was installed using apt-get. With the default memory settings 
(around line 271 in catalina.sh) as follows...


CATALINA_OPTS=$CATALINA_OPTS $JPDA_OPTS

The above error occurs.

When I made the following changes... (below) the error goes away

CATALINA_OPTS=-server $CATALINA_OPTS -Xms512m -Xms2048m 


a typo here ? (2 times -Xms ..)

and, what was in $JPDA_OPTS ?


-XX:MaxPermSize=512m -Dcom.sun.management.jmxremote

My question... pulse-java.jar does not exist in Java 7 although it did 
in Java 6. In Java 7, it is provided by a different file. It appears 
that the shortage of allocated memory manifests itself as a missing 
file. Has anyone else found anything like this or used a different 
solution to fix it?


regards,
Peter



-
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

Memory shortage appears as missing pulse-java.jar file error with Java 7

[Peter Lavin]

Hi all, I have deployed a simple (Eclipse developed) webservice in a 
Tomcat7 container which is running on Debian, details as follows...


The error is as follows... (abridged, but it is complaining about 
missing a file called pulse-java.jar)


INFO: Deploying web application archive 
/var/lib/tomcat7/webapps/SecureServiceExample.war
Jan 12, 2015 3:03:01 PM org.apache.catalina.startup.TldConfig 
tldScanJar
WARNING: Failed to process JAR 
[jar:file:/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/ext/pulse-java.jar!/] 
for TLD files
java.io.FileNotFoundException: 
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/ext/pulse-java.jar (No such 
file or directory)

at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.init(ZipFile.java:215)
at java.util.zip.ZipFile.init(ZipFile.java:145)


I'm using a Debian GNU Linux 7 VM, running version.sh of Tomcat7 
yields...


Using CATALINA_BASE:   /usr/share/tomcat7
Using CATALINA_HOME:   /usr/share/tomcat7
Using CATALINA_TMPDIR: /usr/share/tomcat7/temp
Using JRE_HOME:/usr/lib/jvm/java-7-openjdk-amd64
Using CLASSPATH:   
/usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-juli.jar

Server version: Apache Tomcat/7.0.28
Server built:   Apr 8 2014 08:47:08
Server number:  7.0.28.0
OS Name:Linux
OS Version: 3.2.0-4-amd64
Architecture:   amd64
JVM Version:1.7.0_65-b32
JVM Vendor: Oracle Corporation

Tomcat7 was installed using apt-get. With the default memory settings 
(around line 271 in catalina.sh) as follows...


CATALINA_OPTS=$CATALINA_OPTS $JPDA_OPTS

The above error occurs.

When I made the following changes... (below) the error goes away

CATALINA_OPTS=-server $CATALINA_OPTS -Xms512m -Xms2048m 
-XX:MaxPermSize=512m -Dcom.sun.management.jmxremote


My question... pulse-java.jar does not exist in Java 7 although it did 
in Java 6. In Java 7, it is provided by a different file. It appears 
that the shortage of allocated memory manifests itself as a missing 
file. Has anyone else found anything like this or used a different 
solution to fix it?


regards,
Peter



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

Re: Tomcat 7 / Java 7

[Rainer Frey (Inxmail GmbH)]

On 03.02.2014, at 22:19, Singh, Ragini rsi...@central.uh.edu wrote:

 Hello,
 
 I upgraded Java 1.6.45 to Java 1.7.51 using java-1.7.0-oracle.x86_64 : Oracle 
 Java Runtime Environment on RHEL 5. Used the alternatives command to make 
 the Java 7 as Java version.
 Now in my custom startup script if I define JAVA_HOME as 
 JAVA_HOME=/usr/lib/jvm/java tomcat 7 recognizes the java as 1.6 ( the 
 previous version) and gives this message
 INFO: The APR based Apache Tomcat Native library which allows optimal 
 performance in production environments was not found on the 
 java.library.path: /usr/lib/jvm/java-1.6.0-sun-1.6.0.45
 .x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.6.0-sun-1.6.0.45.x86_64/jre/lib/amd64:/usr/lib/jvm/java-1.6.0-sun-1.6.0.45.x86_64/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib
 64:/lib64:/lib:/usr/lib
 
 I modified the JAVA_HOME to JAVA_HOME=/usr/lib/jvm/jre-1.7.0-oracle.x86_64. 
 Now tomcat starts and gives the message as
 INFO: The APR based Apache Tomcat Native library which allows optimal 
 performance in production environments was not found on the 
 java.library.path: 
 /usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
 
 I believe it is not recognizing the correct Java version which is 1.7. Am I 
 missing anything ?

AFAICT Java 7 has removed $JAVA_HOME/jre/lib/architecture[/vmtype] and 
$JAVA_HOME/lib/architecture from the default java.library.path - this is 
independent of Tomcat. So it is very likely that Tomcat *is* using the desired 
Java now. Others have already written how to verify for sure.

 Thank you,
 -Ragini

Rainer Frey

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

RE: Tomcat 7 / Java 7

[Singh, Ragini]

Thank you Christopher!! I understand that the message is just an INFO and not 
an error. Also, I haven’t installed tcnative as I am not using it. My question 
was regarding the difference in messages when I change JAVA version using 
JAVA_HOME. Is there a way I can find out which version of JAVA Tomcat is using?

Thank you,
-Ragini

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Monday, February 03, 2014 3:42 PM
To: Tomcat Users List
Subject: Re: Tomcat 7 / Java 7

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ragini,

On 2/3/14, 4:19 PM, Singh, Ragini wrote:
 I upgraded Java 1.6.45 to Java 1.7.51 using
 java-1.7.0-oracle.x86_64 : Oracle Java Runtime Environment on RHEL 5. 
 Used the alternatives command to make the Java 7 as Java version. 
 Now in my custom startup script if I define JAVA_HOME as 
 JAVA_HOME=/usr/lib/jvm/java tomcat 7 recognizes the java as 1.6 ( 
 the previous version) and gives this message INFO: The APR based 
 Apache Tomcat Native library which allows optimal performance in 
 production environments was not found on the java.library.path:
 /usr/lib/jvm/java-1.6.0-sun-1.6.0.45
 .x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.6.0-sun-1.6.0.45.x86_
 64/jre/lib/amd64:/usr/lib/jvm/java-1.6.0-sun-1.6.0.45.x86_64/jre/../li
 b/amd64:/usr/java/packages/lib/amd64:/usr/lib

 
64:/lib64:/lib:/usr/lib
 
 I modified the JAVA_HOME to
 JAVA_HOME=/usr/lib/jvm/jre-1.7.0-oracle.x86_64. Now tomcat starts 
 and gives the message as INFO: The APR based Apache Tomcat Native 
 library which allows optimal performance in production environments 
 was not found on the java.library.path:
 /usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
 
 I believe it is not recognizing the correct Java version which is 1.7. 
 Am I missing anything ?

Have you installed tcnative? Installing tcnative is a prerequisite for using 
tcnative.

Note that the above is an INFO message and not an error in any way.

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

iQIcBAEBCAAGBQJS8A0eAAoJEBzwKT+lPKRYss8P/05QCOEVNmHlbjrvyZplv2yI
vLb9GL+5YhzNMawHoAKOeGzs3Pjkoux0+zbV5MNrvOZKhoM9r299eaoJTD9LVNbw
Udz/Ip9TYmdPmP5OczO8D9+FNQX2pfzqSVMABMlLvi0/scC3EyV7/+PAZUEc/lYv
K1Xm4mXiQpxCBBeS1v7D27WLzQGuIj4hj76aEwSf1tsw0GwMT6YKGioCjtSdBSeQ
hVRmVI4CcqYwVrCNDXEF9El1ZO4QDN0l4FouApJd7/mlwTT6qRE9uTP9RUFmCGKh
GT7yvP+rTnJ95A+c1jUe+FNRQDbiBAK+WMmqeNUL0GF/NVbGsL/DNykt1wrT1kR/
XgMsPWS/jFCeqpEpBBucKTrJalhNFiFltI1BLa0Lpc7eKtkWHbaDhFiSff/Q+Vf5
/ONLXsCmOSdDbzub7YH8CLlfWdykLJH++MuH1LPzy3dEkiCSFtwdAcmCo1fykH38
EtT0+Go0LNWoMKSQZYPOT3O5b71e3UgoKw8p9NWRpLNtsIVRFFsZZMomgBiVldQ1
H26Ng6rIK2XP+Aieq5V2VdraAByPkGQcKjGUexykPKZ4fewuCmKpQ+gKplxDyxFx
uP/VcRp0jywUv/4kHjMBZG+eOFPySZ09i6QkZB80cIcoRIcfseTiBh0LqchclKyA
VVbHk5QH86nuIKTo9zYF
=JVDD
-END PGP SIGNATURE-

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

Re: Tomcat 7 / Java 7

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ragini,

On 2/4/14, 10:05 AM, Singh, Ragini wrote:
 Thank you Christopher!! I understand that the message is just an
 INFO and not an error. Also, I haven’t installed tcnative as I am
 not using it. My question was regarding the difference in messages
 when I change JAVA version using JAVA_HOME. Is there a way I can
 find out which version of JAVA Tomcat is using?

You can use jinfo pid but it only works within the same JVM:
you'll have to use the right JVM version to connect in the first place.

You can also connect via JMX or similar to inspect the JVM state. Take
a look at the system properties which will tell you what's going on.

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

iQIcBAEBCAAGBQJS8RO1AAoJEBzwKT+lPKRYcZgP/jNaQsu38vml9E6zUqLGRAPu
uo1SwJj5pVSipBzZ3LCqnDkCsnxoZwc1nzMVe9yTy6AM1tjsHddOO5PQ+UeM8yKW
xhcfD4f1GYVCEpt8siYd6y5TMtYyfuOdudLXdAzQ7G26FpO1LteoWB83S73zYGdR
V+PnkWQYHNz4b8S61WbmJaGhMq3KbTD6Fvf2hlwXN8ql0egMYuYkKeBH+FfOmasl
JVz3039Kl8fXvumaYh8Uf5c8aa1XHiaGC0GB+zq96bZaqRIUWC9qrAA5zlVVh/3v
IVeqc0XUUrCo8dJUFkYWOD7BC8LuQDSn5t10Xm4LlpygI8+BHK0o896cuVv1ea1k
+BYrg1m9Piw7uAq8Bh/gNa6wXcxdIaDaeWKkn6pKQVS4km07K3HufSPDjqpLAXfo
iP4XsJa4hhzJa8vdCVISKiQK9a/OvtTv3N8bFBrtis0A1kGbD+X2GqU7BVoEtzQs
uHg9tYK7nmK0PLDF4GtXCUfssmt739FYKyzSkhRpBcTVkoD+iGAvodzrdK+iccro
X3f4elb6Ke3Sd8yE/vqacTtGfK9Q5oPQxCYtdGfuYgyU0CEh+HIq2LL2FpfMRRts
rnaZu0NOrtDDLrVlVUzybyIvuHUIUwUI3VxiIgW5kBRaXdjrvFoaj136AyWwNDbE
oN3lCkdCNB5IU+S0elp4
=MlX8
-END PGP SIGNATURE-

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

Re: Tomcat 7 / Java 7

[Mark Eggers]

Please don't top post.

On 2/4/2014 7:05 AM, Singh, Ragini wrote:

Thank you Christopher!! I understand that the message is just an INFO and not 
an error. Also, I haven’t installed tcnative as I am not using it. My question 
was regarding the difference in messages when I change JAVA version using 
JAVA_HOME. Is there a way I can find out which version of JAVA Tomcat is using?

Thank you,
-Ragini

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Monday, February 03, 2014 3:42 PM
To: Tomcat Users List
Subject: Re: Tomcat 7 / Java 7

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ragini,

On 2/3/14, 4:19 PM, Singh, Ragini wrote:

I upgraded Java 1.6.45 to Java 1.7.51 using
java-1.7.0-oracle.x86_64 : Oracle Java Runtime Environment on RHEL 5.
Used the alternatives command to make the Java 7 as Java version.
Now in my custom startup script if I define JAVA_HOME as
JAVA_HOME=/usr/lib/jvm/java tomcat 7 recognizes the java as 1.6 (
the previous version) and gives this message INFO: The APR based
Apache Tomcat Native library which allows optimal performance in
production environments was not found on the java.library.path:
/usr/lib/jvm/java-1.6.0-sun-1.6.0.45
.x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.6.0-sun-1.6.0.45.x86_
64/jre/lib/amd64:/usr/lib/jvm/java-1.6.0-sun-1.6.0.45.x86_64/jre/../li
b/amd64:/usr/java/packages/lib/amd64:/usr/lib



64:/lib64:/lib:/usr/lib


I modified the JAVA_HOME to
JAVA_HOME=/usr/lib/jvm/jre-1.7.0-oracle.x86_64. Now tomcat starts
and gives the message as INFO: The APR based Apache Tomcat Native
library which allows optimal performance in production environments
was not found on the java.library.path:
/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib

I believe it is not recognizing the correct Java version which is 1.7.
Am I missing anything ?


Have you installed tcnative? Installing tcnative is a prerequisite for using 
tcnative.

Note that the above is an INFO message and not an error in any way.

- -chris



Manager application shows the Java version at the bottom of the page.

/mde/

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

Tomcat 7 / Java 7

[Singh, Ragini]

Hello,

I upgraded Java 1.6.45 to Java 1.7.51 using java-1.7.0-oracle.x86_64 : Oracle 
Java Runtime Environment on RHEL 5. Used the alternatives command to make the 
Java 7 as Java version.
Now in my custom startup script if I define JAVA_HOME as 
JAVA_HOME=/usr/lib/jvm/java tomcat 7 recognizes the java as 1.6 ( the 
previous version) and gives this message
INFO: The APR based Apache Tomcat Native library which allows optimal 
performance in production environments was not found on the java.library.path: 
/usr/lib/jvm/java-1.6.0-sun-1.6.0.45
.x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.6.0-sun-1.6.0.45.x86_64/jre/lib/amd64:/usr/lib/jvm/java-1.6.0-sun-1.6.0.45.x86_64/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib
64:/lib64:/lib:/usr/lib

I modified the JAVA_HOME to JAVA_HOME=/usr/lib/jvm/jre-1.7.0-oracle.x86_64. 
Now tomcat starts and gives the message as
INFO: The APR based Apache Tomcat Native library which allows optimal 
performance in production environments was not found on the java.library.path: 
/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib

I believe it is not recognizing the correct Java version which is 1.7. Am I 
missing anything ?

Thank you,
-Ragini

Re: Tomcat 7 / Java 7

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ragini,

On 2/3/14, 4:19 PM, Singh, Ragini wrote:
 I upgraded Java 1.6.45 to Java 1.7.51 using
 java-1.7.0-oracle.x86_64 : Oracle Java Runtime Environment on RHEL
 5. Used the alternatives command to make the Java 7 as Java
 version. Now in my custom startup script if I define JAVA_HOME as
 JAVA_HOME=/usr/lib/jvm/java tomcat 7 recognizes the java as 1.6 (
 the previous version) and gives this message INFO: The APR based
 Apache Tomcat Native library which allows optimal performance in
 production environments was not found on the java.library.path:
 /usr/lib/jvm/java-1.6.0-sun-1.6.0.45 
 .x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.6.0-sun-1.6.0.45.x86_64/jre/lib/amd64:/usr/lib/jvm/java-1.6.0-sun-1.6.0.45.x86_64/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib

 
64:/lib64:/lib:/usr/lib
 
 I modified the JAVA_HOME to 
 JAVA_HOME=/usr/lib/jvm/jre-1.7.0-oracle.x86_64. Now tomcat
 starts and gives the message as INFO: The APR based Apache Tomcat
 Native library which allows optimal performance in production
 environments was not found on the java.library.path: 
 /usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
 
 I believe it is not recognizing the correct Java version which is 
 1.7. Am I missing anything ?

Have you installed tcnative? Installing tcnative is a prerequisite for
using tcnative.

Note that the above is an INFO message and not an error in any way.

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

iQIcBAEBCAAGBQJS8A0eAAoJEBzwKT+lPKRYss8P/05QCOEVNmHlbjrvyZplv2yI
vLb9GL+5YhzNMawHoAKOeGzs3Pjkoux0+zbV5MNrvOZKhoM9r299eaoJTD9LVNbw
Udz/Ip9TYmdPmP5OczO8D9+FNQX2pfzqSVMABMlLvi0/scC3EyV7/+PAZUEc/lYv
K1Xm4mXiQpxCBBeS1v7D27WLzQGuIj4hj76aEwSf1tsw0GwMT6YKGioCjtSdBSeQ
hVRmVI4CcqYwVrCNDXEF9El1ZO4QDN0l4FouApJd7/mlwTT6qRE9uTP9RUFmCGKh
GT7yvP+rTnJ95A+c1jUe+FNRQDbiBAK+WMmqeNUL0GF/NVbGsL/DNykt1wrT1kR/
XgMsPWS/jFCeqpEpBBucKTrJalhNFiFltI1BLa0Lpc7eKtkWHbaDhFiSff/Q+Vf5
/ONLXsCmOSdDbzub7YH8CLlfWdykLJH++MuH1LPzy3dEkiCSFtwdAcmCo1fykH38
EtT0+Go0LNWoMKSQZYPOT3O5b71e3UgoKw8p9NWRpLNtsIVRFFsZZMomgBiVldQ1
H26Ng6rIK2XP+Aieq5V2VdraAByPkGQcKjGUexykPKZ4fewuCmKpQ+gKplxDyxFx
uP/VcRp0jywUv/4kHjMBZG+eOFPySZ09i6QkZB80cIcoRIcfseTiBh0LqchclKyA
VVbHk5QH86nuIKTo9zYF
=JVDD
-END PGP SIGNATURE-

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

Re: Tomcat 7 / Java 7

[André Warnier]

Christopher,

Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ragini,

On 2/3/14, 4:19 PM, Singh, Ragini wrote:

I upgraded Java 1.6.45 to Java 1.7.51 using
java-1.7.0-oracle.x86_64 : Oracle Java Runtime Environment on RHEL
5. Used the alternatives command to make the Java 7 as Java
version. Now in my custom startup script if I define JAVA_HOME as
JAVA_HOME=/usr/lib/jvm/java tomcat 7 recognizes the java as 1.6 (
the previous version) and gives this message INFO: The APR based
Apache Tomcat Native library which allows optimal performance in
production environments was not found on the java.library.path:
/usr/lib/jvm/java-1.6.0-sun-1.6.0.45 
.x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.6.0-sun-1.6.0.45.x86_64/jre/lib/amd64:/usr/lib/jvm/java-1.6.0-sun-1.6.0.45.x86_64/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib




64:/lib64:/lib:/usr/lib
I modified the JAVA_HOME to 
JAVA_HOME=/usr/lib/jvm/jre-1.7.0-oracle.x86_64. Now tomcat

starts and gives the message as INFO: The APR based Apache Tomcat
Native library which allows optimal performance in production
environments was not found on the java.library.path: 
/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib


I believe it is not recognizing the correct Java version which is 
1.7. Am I missing anything ?


Have you installed tcnative? Installing tcnative is a prerequisite for
using tcnative.

Note that the above is an INFO message and not an error in any way.



I believe that the OP was wondering about the apparent discrepancy between his setting of 
the JAVA_HOME environment variable, and then what Tomcat prints as a java.library.path 
in the log messages.
(And I do not know if there is actually here a real discrepancy; just that the OP mentions 
there might be one).




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

Tomcat 7 / Java 7

[Singh, Ragini]

Hello,

Is Tomcat 7.0.42  compatible with Java 
7?http://stackoverflow.com/questions/9294355/is-tomcat-7-now-compatible-with-java-7
 If yes, do you know if there is something special to migrate an existing 
installation of Tomcat 7/Java 6 to Tomcat 7/Java 7?


-Ragini

Re: Tomcat 7 / Java 7

[Filip Hanik]

Yes it is compatible, and no, there is nothing you really need to do except
to test your applications that they work too.


On Mon, Jan 27, 2014 at 9:37 AM, Singh, Ragini rsi...@central.uh.eduwrote:

 Hello,

 Is Tomcat 7.0.42  compatible with Java 7?
 http://stackoverflow.com/questions/9294355/is-tomcat-7-now-compatible-with-java-7
 If yes, do you know if there is something special to migrate an existing
 installation of Tomcat 7/Java 6 to Tomcat 7/Java 7?


 -Ragini

Re: Tomcat 7 / Java 7 with TLS 1.2 algorithms

[Aurélien Terrestris]

It seems incorrect to me because RFC 5246 in 1.2 Major Differences
from TLS 1.1 says this :

..
All cipher suites in this document use P_SHA256.
..
Added HMAC-SHA256 cipher suites

I can't read anywhere that SHA384 and others SHOULD or MUST be implemented.

Other RFCs updating this 5246 (5746, 5878, 6176 and Errata) don't talk
about this either.


However, in 5246 5. HMAC and the Pseudorandom Function we can read :

In this section, we define one PRF, based on HMAC. This PRF with the
   SHA-256 hash function is used for all cipher suites defined in this
   document and in TLS documents published prior to this document when
   TLS 1.2 is negotiated.  New cipher suites MUST explicitly specify a
   PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a
   stronger standard hash function.


This allows future usage of SHA384 and others, if defined correctly.


regards
A.T.

2013/8/22 Martin Gainty mgai...@hotmail.com:
 point of confusion Eric Rescorla specifically cites SHA384 in his cipher 
 examples for TLS 1.2 Update

 http://www.ietf.org/rfc/rfc5246.txt
 http://www.ietf.org/proceedings/70/slides/tls-0.pdf

 Kuat Eshengazin used bltest as a test harness for SHA384

 bltest -R -m prf_sha384 -k tests/prf_sha384/key0 -t
 tests/prf_sha384/seed0 -h -g 148 -x

 https://bugzilla.mozilla.org/show_bug.cgi?id=480514

 Is this incorrect?
 Martin
 __
 Please do not alter or disrupt this transmission..Thank You




 Date: Thu, 22 Aug 2013 14:53:55 +0100
 Subject: Re: Tomcat 7 / Java 7 with TLS 1.2 algorithms
 From: aterrest...@gmail.com
 To: users@tomcat.apache.org

 According to RFC 5246 Appendix C (TLS 1.2), there is no SHA384. See :
 http://www.ietf.org/rfc/rfc5246.txt

 The JSSE Reference Guide also doesn't talk about this SHA384 as an
 implementation requirement. See :
 http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#impl

 This means you have a problem with SHA256 only. Maybe it's easier to
 test on client-side, with one of the following ciphers (that you find
 on the same Reference Guide ) for example :

 TLS_DH_RSA_WITH_AES_256_CBC_SHA256
 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

 Let me know if this works, or I will try to test by myself with my own 
 client.



 2013/8/22 Dennis Sosnoski d...@sosnoski.com:
  I've already done that, though as far as I can see that doesn't effect the
  digest algorithms (only the encryption options).
 
  - Dennis
 
 
  On 08/23/2013 12:24 AM, Aurélien Terrestris wrote:
 
  Hello
 
  I suppose you need to run your JVM with the unrestricted policy files (on
  b=
  oth client and server sides). You have to download them from Oracle
  website=
  for your java version, and replace the old.
 
  These files are :
  local_policy.jar
  US_export_policy.jar
 
  Regards
 
  2013/8/22 d...@sosnoski.com:
 
  Tomcat 7.0.40 seems to work well with TLS 1.2, forced by using a
  sslEnabledProtocols=TLSv1.2 attribute on the Connector. But I haven't
  been able to make it work with any of the SHA256/384 algorithms - they
  always show up in the Ignoring unsupported cipher suite list. I get the
  same thing happening when I try to use them from client code, so I know 
  it's
  not a Tomcat issue, but I'm hoping someone knows a workaround.
 
  Any suggestions?
 
  Thanks,
 
  - Dennis
 
 
 
  -
  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 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: Fwd: Tomcat 7 / Java 7 with TLS 1.2 algorithms

[Aurélien Terrestris]

Hi

the JSSE Reference Guide defines which possibilities for anyone
implementing a JSSE provider (let's call it an API if you want).
Oracle's provider only implements a part of this API, misleading you
to believe SHA384 is available when it's unfortunately not.

About Bouncy Castle, I believe they only implement a JCE provider and
not any JSSE provider. Adding their jar to your providers in the
security file is not enough.. you would have to implement a full JSSE
provider using their JCE classes. A lot of work.

If you're looking for the best security, I would tell you to use the
available DHE and ECDHE ciphersuites which make things complicated to
decrypt. Have a look here for more information :

http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html

RFC 5288 is interesting, we probably have to wait some more years
before we can use all these new ciphers.

best regards
A.T.




2013/8/23 Dennis Sosnoski d...@sosnoski.com:
 Thanks, Aurélien. I'd seen the SHA384 versions listed in the JSSE Cipher
 Suite Names and thought they were available:
 http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#ciphersuites

 I was really hoping to use one of the GCM suites, but I gather those are not
 officially approved yet either: http://tools.ietf.org/html/rfc5288 It
 appears there is growing support for these in the world, even if they're not
 yet an official part of TLS 1.2.

 On the client side, this:

 SSLContext context = SSLContext.getInstance(TLS);
 context.init(null, new TrustManager[] { tm }, null);
 SSLParameters params = context.getSupportedSSLParameters();
 String[] suites = params.getCipherSuites();
 System.out.println(Connecting with  + suites.length +  cipher
 suites supported:);
 for (int i = 0; i  suites.length; i++) {
 System.out.print(' ');
 System.out.println(suites[i]);
 }

 gives me a list of supported cipher suites including:

  TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  TLS_RSA_WITH_AES_256_CBC_SHA256
  TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
  TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
  TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
  TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
  ...

 but when I try to connect using the socket factory from the context I get
 the ssl debug information:

 Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
 Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
 Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
 Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
 Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
 ...

 where all the variations using SHA256 or SHA384 are in this second list. But
 explicitly setting a suite like:

 System.setProperty(https.cipherSuites,
 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256);

 works, while the SHA384 version fails with Unsupported ciphersuite (as
 does any version I've tried using GCM in place of CBC).

 I thought JSSE would use the JCE algorithms from BouncyCastle, but it looks
 like this doesn't work. I'll have to dig into the JSSE code to see what's
 going wrong on that part.

   - Dennis


 On 08/23/2013 03:48 AM, Aurélien Terrestris wrote:

 According to RFC 5246 Appendix C (TLS 1.2), there is no SHA384. See :
 http://www.ietf.org/rfc/rfc5246.txt

 The JSSE Reference Guide also doesn't talk about this SHA384 as an
 implementation requirement. See :

 http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#impl

 This means you have a problem with SHA256 only. Maybe it's easier to
 test on client-side, with one of the following ciphers (that you find
 on the same Reference Guide ) for example :

 TLS_DH_RSA_WITH_AES_256_CBC_SHA256
 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

 Let me know if this works, or I will try to test by myself with my own
 client.



 2013/8/22 Dennis Sosnoski d...@sosnoski.com:

 I've already done that, though as far as I can see that doesn't effect
 the
 digest algorithms (only the encryption options).

- Dennis


 On 08/23/2013 12:24 AM, Aurélien Terrestris wrote:

 Hello

 I suppose you need to run your JVM with the unrestricted policy files
 (on
 b=
 oth client and server sides). You have to download them from Oracle
 website=
for your java version, and replace the old.

 These files are :
 local_policy.jar
 US_export_policy.jar

 Regards

 2013/8/22  d...@sosnoski.com:

 Tomcat 7.0.40 seems to work well with TLS 1.2, forced by using a
 sslEnabledProtocols=TLSv1.2 attribute on the Connector. But I
 haven't
 been able to make it work with any of the SHA256/384 algorithms - they
 always show up in the Ignoring unsupported cipher suite list. I get
 the
 same thing happening when I try to use them from client code, so I know
 it's
 not a Tomcat issue, but I'm hoping someone knows a workaround.

 Any suggestions?

Re: Fwd: Tomcat 7 / Java 7 with TLS 1.2 algorithms

[Dennis Sosnoski]

Thanks for clarifying the JSSE issue. It's a shame that JSSE can't make 
use of available JCE algorithms. I've just been trying to establish the 
limits of the Java 7 implementation, and I think I understand that now.


Yes, the ECDHE ciphersuites are definitely the choice for strongest 
secrecy with good performance, and the 
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 that works on Oracle Java 7 using 
TLS 1.2 should be a reasonable choice for now (or 
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA256, for those who want really big keys).


  - Dennis

On 08/23/2013 10:06 PM, Aurélien Terrestris wrote:

Hi

the JSSE Reference Guide defines which possibilities for anyone
implementing a JSSE provider (let's call it an API if you want).
Oracle's provider only implements a part of this API, misleading you
to believe SHA384 is available when it's unfortunately not.

About Bouncy Castle, I believe they only implement a JCE provider and
not any JSSE provider. Adding their jar to your providers in the
security file is not enough.. you would have to implement a full JSSE
provider using their JCE classes. A lot of work.

If you're looking for the best security, I would tell you to use the
available DHE and ECDHE ciphersuites which make things complicated to
decrypt. Have a look here for more information :

http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html

RFC 5288 is interesting, we probably have to wait some more years
before we can use all these new ciphers.

best regards
A.T.




2013/8/23 Dennis Sosnoski d...@sosnoski.com:

Thanks, Aurélien. I'd seen the SHA384 versions listed in the JSSE Cipher
Suite Names and thought they were available:
http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#ciphersuites

I was really hoping to use one of the GCM suites, but I gather those are not
officially approved yet either: http://tools.ietf.org/html/rfc5288 It
appears there is growing support for these in the world, even if they're not
yet an official part of TLS 1.2.

On the client side, this:

 SSLContext context = SSLContext.getInstance(TLS);
 context.init(null, new TrustManager[] { tm }, null);
 SSLParameters params = context.getSupportedSSLParameters();
 String[] suites = params.getCipherSuites();
 System.out.println(Connecting with  + suites.length +  cipher
suites supported:);
 for (int i = 0; i  suites.length; i++) {
 System.out.print(' ');
 System.out.println(suites[i]);
 }

gives me a list of supported cipher suites including:

  TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  TLS_RSA_WITH_AES_256_CBC_SHA256
  TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
  TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
  TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
  TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
  ...

but when I try to connect using the socket factory from the context I get
the ssl debug information:

Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
...

where all the variations using SHA256 or SHA384 are in this second list. But
explicitly setting a suite like:

 System.setProperty(https.cipherSuites,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256);

works, while the SHA384 version fails with Unsupported ciphersuite (as
does any version I've tried using GCM in place of CBC).

I thought JSSE would use the JCE algorithms from BouncyCastle, but it looks
like this doesn't work. I'll have to dig into the JSSE code to see what's
going wrong on that part.

   - Dennis


On 08/23/2013 03:48 AM, Aurélien Terrestris wrote:

According to RFC 5246 Appendix C (TLS 1.2), there is no SHA384. See :
http://www.ietf.org/rfc/rfc5246.txt

The JSSE Reference Guide also doesn't talk about this SHA384 as an
implementation requirement. See :

http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#impl

This means you have a problem with SHA256 only. Maybe it's easier to
test on client-side, with one of the following ciphers (that you find
on the same Reference Guide ) for example :

TLS_DH_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

Let me know if this works, or I will try to test by myself with my own
client.



2013/8/22 Dennis Sosnoski d...@sosnoski.com:

I've already done that, though as far as I can see that doesn't effect
the
digest algorithms (only the encryption options).

- Dennis


On 08/23/2013 12:24 AM, Aurélien Terrestris wrote:

Hello

I suppose you need to run your JVM with the unrestricted policy files
(on
b=
oth client and server sides). You have to download them from Oracle
website=
for your java version, and replace the old

Tomcat 7 / Java 7 with TLS 1.2 algorithms

[dms]

Tomcat 7.0.40 seems to work well with TLS 1.2, forced by using a 
sslEnabledProtocols=TLSv1.2 attribute on the Connector. But I haven't been 
able to make it work with any of the SHA256/384 algorithms - they always show 
up in the Ignoring unsupported cipher suite list. I get the same thing 
happening when I try to use them from client code, so I know it's not a Tomcat 
issue, but I'm hoping someone knows a workaround.

Any suggestions?

Thanks,

  - Dennis


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

Re: Tomcat 7 / Java 7 with TLS 1.2 algorithms

[Aurélien Terrestris]

Hello

I suppose you need to run your JVM with the unrestricted policy files (on b=
oth client and server sides). You have to download them from Oracle website=
 for your java version, and replace the old.

These files are :
local_policy.jar
US_export_policy.jar

Regards

2013/8/22  d...@sosnoski.com:
 Tomcat 7.0.40 seems to work well with TLS 1.2, forced by using a 
 sslEnabledProtocols=TLSv1.2 attribute on the Connector. But I haven't 
 been able to make it work with any of the SHA256/384 algorithms - they always 
 show up in the Ignoring unsupported cipher suite list. I get the same thing 
 happening when I try to use them from client code, so I know it's not a 
 Tomcat issue, but I'm hoping someone knows a workaround.

 Any suggestions?

 Thanks,

   - Dennis



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

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

RE: Tomcat 7 / Java 7 with TLS 1.2 algorithms

[Martin Gainty]

what's supposed to happen:


The specified cipher in SSLCipherSuiteSSLCipherSuite is supposed to be enabled 
when specified within 

SSLCipherSuiteSSLCipherSuite=SHA256/384


to allow the Server to arbitrate the ordering of ciphers(instead of the client) 

SSLHonorCipherOrder=true


http://tomcat.apache.org/tomcat-7.0-doc/config/http.html


does this not work for you?


Martin Gainty 
__ 
Please do not alter or disrupt this transmission..Thank You

  



From: d...@sosnoski.com
Subject: Tomcat 7 / Java 7 with TLS 1.2 algorithms
To: users@tomcat.apache.org
CC: 
Date: Thu, 22 Aug 2013 04:41:54 -0400

Tomcat 7.0.40 seems to work well with TLS 1.2, forced by using a 
sslEnabledProtocols=TLSv1.2 attribute on the Connector. But I haven't been 
able to make it work with any of the SHA256/384 algorithms - they always show 
up in the Ignoring unsupported cipher suite list. I get the same thing 
happening when I try to use them from client code, so I know it's not a Tomcat 
issue, but I'm hoping someone knows a workaround.
 
Any suggestions?
 
Thanks,
 
  - Dennis
 

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

Re: Tomcat 7 / Java 7 with TLS 1.2 algorithms

[Dennis Sosnoski]

I've already done that, though as far as I can see that doesn't effect 
the digest algorithms (only the encryption options).


  - Dennis

On 08/23/2013 12:24 AM, Aurélien Terrestris wrote:

Hello

I suppose you need to run your JVM with the unrestricted policy files (on b=
oth client and server sides). You have to download them from Oracle website=
  for your java version, and replace the old.

These files are :
local_policy.jar
US_export_policy.jar

Regards

2013/8/22  d...@sosnoski.com:

Tomcat 7.0.40 seems to work well with TLS 1.2, forced by using a sslEnabledProtocols=TLSv1.2 
attribute on the Connector. But I haven't been able to make it work with any of the SHA256/384 
algorithms - they always show up in the Ignoring unsupported cipher suite list. I get the 
same thing happening when I try to use them from client code, so I know it's not a Tomcat issue, but I'm 
hoping someone knows a workaround.

Any suggestions?

Thanks,

   - Dennis



-
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: Tomcat 7 / Java 7 with TLS 1.2 algorithms

[Aurélien Terrestris]

According to RFC 5246 Appendix C (TLS 1.2), there is no SHA384. See :
http://www.ietf.org/rfc/rfc5246.txt

The JSSE Reference Guide also doesn't talk about this SHA384 as an
implementation requirement. See :
http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#impl

This means you have a problem with SHA256 only. Maybe it's easier to
test on client-side, with one of the following ciphers (that you find
on the same Reference Guide ) for example :

TLS_DH_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

Let me know if this works, or I will try to test by myself with my own client.



2013/8/22 Dennis Sosnoski d...@sosnoski.com:
 I've already done that, though as far as I can see that doesn't effect the
 digest algorithms (only the encryption options).

   - Dennis


 On 08/23/2013 12:24 AM, Aurélien Terrestris wrote:

 Hello

 I suppose you need to run your JVM with the unrestricted policy files (on
 b=
 oth client and server sides). You have to download them from Oracle
 website=
   for your java version, and replace the old.

 These files are :
 local_policy.jar
 US_export_policy.jar

 Regards

 2013/8/22  d...@sosnoski.com:

 Tomcat 7.0.40 seems to work well with TLS 1.2, forced by using a
 sslEnabledProtocols=TLSv1.2 attribute on the Connector. But I haven't
 been able to make it work with any of the SHA256/384 algorithms - they
 always show up in the Ignoring unsupported cipher suite list. I get the
 same thing happening when I try to use them from client code, so I know it's
 not a Tomcat issue, but I'm hoping someone knows a workaround.

 Any suggestions?

 Thanks,

- Dennis



 -
 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 unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Fwd: Tomcat 7 / Java 7 with TLS 1.2 algorithms

[Aurélien Terrestris]

According to RFC 5246 Appendix C (TLS 1.2), there is no SHA384. See :
http://www.ietf.org/rfc/rfc5246.txt

The JSSE Reference Guide also doesn't talk about this SHA384 as an
implementation requirement. See :
http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#impl

This means you have a problem with SHA256 only. Maybe it's easier to
test on client-side, with one of the following ciphers (that you find
on the same Reference Guide ) for example :

TLS_DH_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

Let me know if this works, or I will try to test by myself with my own client.



2013/8/22 Dennis Sosnoski d...@sosnoski.com:
 I've already done that, though as far as I can see that doesn't effect the
 digest algorithms (only the encryption options).

   - Dennis


 On 08/23/2013 12:24 AM, Aurélien Terrestris wrote:

 Hello

 I suppose you need to run your JVM with the unrestricted policy files (on
 b=
 oth client and server sides). You have to download them from Oracle
 website=
   for your java version, and replace the old.

 These files are :
 local_policy.jar
 US_export_policy.jar

 Regards

 2013/8/22  d...@sosnoski.com:

 Tomcat 7.0.40 seems to work well with TLS 1.2, forced by using a
 sslEnabledProtocols=TLSv1.2 attribute on the Connector. But I haven't
 been able to make it work with any of the SHA256/384 algorithms - they
 always show up in the Ignoring unsupported cipher suite list. I get the
 same thing happening when I try to use them from client code, so I know it's
 not a Tomcat issue, but I'm hoping someone knows a workaround.

 Any suggestions?

 Thanks,

- Dennis



 -
 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 unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Tomcat 7 / Java 7 with TLS 1.2 algorithms

[Martin Gainty]

point of confusion Eric Rescorla specifically cites SHA384 in his cipher 
examples for TLS 1.2 Update

http://www.ietf.org/rfc/rfc5246.txt
http://www.ietf.org/proceedings/70/slides/tls-0.pdf

Kuat Eshengazin used bltest as a test harness for SHA384
 
bltest -R -m prf_sha384 -k tests/prf_sha384/key0 -t
tests/prf_sha384/seed0 -h -g 148 -x

https://bugzilla.mozilla.org/show_bug.cgi?id=480514
 
Is this incorrect?
Martin 
__ 
Please do not alter or disrupt this transmission..Thank You

  


 Date: Thu, 22 Aug 2013 14:53:55 +0100
 Subject: Re: Tomcat 7 / Java 7 with TLS 1.2 algorithms
 From: aterrest...@gmail.com
 To: users@tomcat.apache.org
 
 According to RFC 5246 Appendix C (TLS 1.2), there is no SHA384. See :
 http://www.ietf.org/rfc/rfc5246.txt
 
 The JSSE Reference Guide also doesn't talk about this SHA384 as an
 implementation requirement. See :
 http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#impl
 
 This means you have a problem with SHA256 only. Maybe it's easier to
 test on client-side, with one of the following ciphers (that you find
 on the same Reference Guide ) for example :
 
 TLS_DH_RSA_WITH_AES_256_CBC_SHA256
 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
 
 Let me know if this works, or I will try to test by myself with my own client.
 
 
 
 2013/8/22 Dennis Sosnoski d...@sosnoski.com:
  I've already done that, though as far as I can see that doesn't effect the
  digest algorithms (only the encryption options).
 
  - Dennis
 
 
  On 08/23/2013 12:24 AM, Aurélien Terrestris wrote:
 
  Hello
 
  I suppose you need to run your JVM with the unrestricted policy files (on
  b=
  oth client and server sides). You have to download them from Oracle
  website=
  for your java version, and replace the old.
 
  These files are :
  local_policy.jar
  US_export_policy.jar
 
  Regards
 
  2013/8/22 d...@sosnoski.com:
 
  Tomcat 7.0.40 seems to work well with TLS 1.2, forced by using a
  sslEnabledProtocols=TLSv1.2 attribute on the Connector. But I haven't
  been able to make it work with any of the SHA256/384 algorithms - they
  always show up in the Ignoring unsupported cipher suite list. I get the
  same thing happening when I try to use them from client code, so I know 
  it's
  not a Tomcat issue, but I'm hoping someone knows a workaround.
 
  Any suggestions?
 
  Thanks,
 
  - Dennis
 
 
 
  -
  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 unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
  

Re: Fwd: Tomcat 7 / Java 7 with TLS 1.2 algorithms

[Dennis Sosnoski]

Thanks, Aurélien. I'd seen the SHA384 versions listed in the JSSE Cipher 
Suite Names and thought they were available: 
http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#ciphersuites


I was really hoping to use one of the GCM suites, but I gather those are 
not officially approved yet either: http://tools.ietf.org/html/rfc5288 
It appears there is growing support for these in the world, even if 
they're not yet an official part of TLS 1.2.


On the client side, this:

SSLContext context = SSLContext.getInstance(TLS);
context.init(null, new TrustManager[] { tm }, null);
SSLParameters params = context.getSupportedSSLParameters();
String[] suites = params.getCipherSuites();
System.out.println(Connecting with  + suites.length +  
cipher suites supported:);

for (int i = 0; i  suites.length; i++) {
System.out.print(' ');
System.out.println(suites[i]);
}

gives me a list of supported cipher suites including:

 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
 TLS_RSA_WITH_AES_256_CBC_SHA256
 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
 ...

but when I try to connect using the socket factory from the context I 
get the ssl debug information:


Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
...

where all the variations using SHA256 or SHA384 are in this second list. 
But explicitly setting a suite like:


System.setProperty(https.cipherSuites, 
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256);


works, while the SHA384 version fails with Unsupported ciphersuite (as 
does any version I've tried using GCM in place of CBC).


I thought JSSE would use the JCE algorithms from BouncyCastle, but it 
looks like this doesn't work. I'll have to dig into the JSSE code to see 
what's going wrong on that part.


  - Dennis

On 08/23/2013 03:48 AM, Aurélien Terrestris wrote:

According to RFC 5246 Appendix C (TLS 1.2), there is no SHA384. See :
http://www.ietf.org/rfc/rfc5246.txt

The JSSE Reference Guide also doesn't talk about this SHA384 as an
implementation requirement. See :
http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#impl

This means you have a problem with SHA256 only. Maybe it's easier to
test on client-side, with one of the following ciphers (that you find
on the same Reference Guide ) for example :

TLS_DH_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

Let me know if this works, or I will try to test by myself with my own client.



2013/8/22 Dennis Sosnoski d...@sosnoski.com:

I've already done that, though as far as I can see that doesn't effect the
digest algorithms (only the encryption options).

   - Dennis


On 08/23/2013 12:24 AM, Aurélien Terrestris wrote:

Hello

I suppose you need to run your JVM with the unrestricted policy files (on
b=
oth client and server sides). You have to download them from Oracle
website=
   for your java version, and replace the old.

These files are :
local_policy.jar
US_export_policy.jar

Regards

2013/8/22  d...@sosnoski.com:

Tomcat 7.0.40 seems to work well with TLS 1.2, forced by using a
sslEnabledProtocols=TLSv1.2 attribute on the Connector. But I haven't
been able to make it work with any of the SHA256/384 algorithms - they
always show up in the Ignoring unsupported cipher suite list. I get the
same thing happening when I try to use them from client code, so I know it's
not a Tomcat issue, but I'm hoping someone knows a workaround.

Any suggestions?

Thanks,

- Dennis



-
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 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: Java 7 support on Tomcat 5.5

[Nick Williams]

On Apr 1, 2013, at 3:44 PM, Satheesh Babu wrote:

 Good Evening!
 
 We're running our production applications in Tomcat 5.5/JRE 1.5, and there is 
 a need for us to migrate our applications to Java 7(JRE 1.7). There is no 
 information available either on java or on Apace Tomcat site regrading the 
 compatibility of java 7 with tomcat 5.5. Could you please let me know the 
 compatibility of Java 7/Tomcat 5.5 (or) do we need to upgrade tomcat to 6 
 (or) 7, for java 7.
 
 I truly appreciate your response, thanks for your timely help.
 
 Thanks,
 Satheesh Babu


First, this is the wrong list for such a question. This question belongs on the 
User's list. I am cross-posting on both lists this one time to inform you of 
this and to relocate the topic.

Second, good to hear that your organization is making the jump to Java 7. Java 
6 is no longer supported and Java 8 will be out soon.

Third, upgrade Tomcat. Tomcat 5.5 is extremely old and no longer supported. 
That's why you won't even find it on the Tomcat site proper [1] anymore, you 
can only find it in the archives. You will likely not find anyone on these 
lists willing to help you much with 5.5.

Finally, Tomcat 6 and 7 will both run quite fine on Java 7, but they will not 
compile on Java 7. If you want a version of Tomcat that compiles on Java 7, you 
will need to wait for Tomcat 8, which is currently in development and should 
(hopefully) be out later this year.

[1] http://tomcat.apache.org/
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat and Sun/Oracle Java 7

[Rainer Frey]

On 04.02.2013, at 19:40, Christopher Schultz ch...@christopherschultz.net 
wrote:
 It's a maybe. If you use -target 1.6 and you make sure not to use
 any APIs that are Java 1.7+ (not sure if the compiler actually checks
 when you use -target 1.6)

It does not. -target only sets the class file format. There's an option to set 
the 
compiler's boot classpath though, where you could point at another rt.jar, but 
I 
never used that (yet).

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

Re: Tomcat and Sun/Oracle Java 7

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 2/4/13 2:37 PM, André Warnier wrote:
 Thanks to all. I got more than I was bargaining for.
 
 To summarise thus, if I understand correctly what was said here,
 and asking forgiveness in advance for pretty bad English style :
 
 - any well-written java application, which does not use any 
 vendor-specific JVM API (or internals) should be able to run on
 any JVM of a level equal or superior to the one it compiles (or has
 been compiled) under. (Barring any specific bug in the JVM in
 question)

It's not so much using a vendor-specific API (like using Sun's Base64
encoder, etc.) but using methods from a version of the API that is
higher than what you are trying to run under. For instance, the
ResultSet.getRowId() method wasn't added until Java 6. You can compile
your class with Java 6 (which will work) and then if you try to run it
on Java 5, it won't work. Nothing vendor-specific... just a version
mismatch.

 - any well-written java web-application, written in conformance
 with a given Java Servlet Specification level, which does not use
 any of the above JVM internals nor any container-specific APIs,
 should be able to run under any java servlet container which
 supports the same Java Servlet Specification level. (Barring any
 specific bug in the servlet container in question)
 
 And if any java application or java web-application does not run as
 per the above rules, then we should ask the vendor/developer of
 this application why not.

Seems reasonable.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREIAAYFAlERIOkACgkQ9CaO5/Lv0PA8awCfZQl9xdQ4Dy9Jw69dG7lfxIAC
lHQAoMOojt4y1x7iHkY4XZ0lRDhJ4dkd
=hnfZ
-END PGP SIGNATURE-

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

Tomcat and Sun/Oracle Java 7

[André Warnier]

Hi.
What is the status of Tomcat vs Sun/oracle Java 7 ?
I vaguely remember seeing some messages on this list about some kind of 
incompatibility.
But I cannot find anything readily mentioned in Tomcat 7's Release Notes or 
similar places.

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

Re: Tomcat and Sun/Oracle Java 7

[Mark Thomas]

On 04/02/2013 09:37, André Warnier wrote:
 Hi.
 What is the status of Tomcat vs Sun/oracle Java 7 ?
 I vaguely remember seeing some messages on this list about some kind of
 incompatibility.
 But I cannot find anything readily mentioned in Tomcat 7's Release Notes
 or similar places.

There are no known issues.

There is a possible issue with JSP debugging and Java 8 but that could
be a Java 8 issue.

Mark


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

RE: Tomcat and Sun/Oracle Java 7

[Caldarale, Charles R]

 From: Mark Thomas [mailto:ma...@apache.org] 
 Subject: Re: Tomcat and Sun/Oracle Java 7

  What is the status of Tomcat vs Sun/oracle Java 7 ?
  I vaguely remember seeing some messages on this list about some kind of
  incompatibility.

 There are no known issues.

Although there are no issues with running Tomcat under Java 7, I was under the 
impression that Tomcat 7 and below could not be built with Java 7 due to JRE 
interface incompatibilities.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Re: Tomcat and Sun/Oracle Java 7

[Mark Thomas]

On 04/02/2013 13:41, Caldarale, Charles R wrote:
 From: Mark Thomas [mailto:ma...@apache.org] Subject: Re: Tomcat and
 Sun/Oracle Java 7
 
 What is the status of Tomcat vs Sun/oracle Java 7 ? I vaguely
 remember seeing some messages on this list about some kind of 
 incompatibility.
 
 There are no known issues.
 
 Although there are no issues with running Tomcat under Java 7, I was
 under the impression that Tomcat 7 and below could not be built with
 Java 7 due to JRE interface incompatibilities.

Correct. JDBC. Again.

Mark

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

Re: Tomcat and Sun/Oracle Java 7

[André Warnier]

Mark Thomas wrote:

On 04/02/2013 13:41, Caldarale, Charles R wrote:

From: Mark Thomas [mailto:ma...@apache.org] Subject: Re: Tomcat and
Sun/Oracle Java 7

What is the status of Tomcat vs Sun/oracle Java 7 ? I vaguely
remember seeing some messages on this list about some kind of 
incompatibility.

There are no known issues.

Although there are no issues with running Tomcat under Java 7, I was
under the impression that Tomcat 7 and below could not be built with
Java 7 due to JRE interface incompatibilities.


Correct. JDBC. Again.



Ok, then sorry about my persistent deep lack of knowledge of Java-things, but are the 
following assumptions correct ? (and if not, why ?)


- tomcat 6 will run fine under a Sun/Oracle Java 1.6 JVM
- tomcat 7 will run fine under a Sun/Oracle Java 1.6 JVM
- tomcat 6 will run fine under a Sun/Oracle Java 1.7 JVM
- tomcat 7 will run fine under a Sun/Oracle Java 1.7 JVM
- tomcat 6 will run fine under an OpenJDK Java 1.7 JVM
- tomcat 7 will run fine under an OpenJDK Java 1.7 JVM

and, there may (or may not) be problems compiling a servlet that uses JDBC under a 
Sun/Oracle Java 1.7 JDK, but assuming that this servlet does not use JDBC in any way :


- the classes of a servlet that has been compiled under a Sun/Oracle Java 1.6 JDK will run 
fine under Tomcat 6 and a Sun/Oracle Java 1.7 JVM
- the classes of a servlet that has been compiled under a Sun/Oracle Java 1.7 JDK will run 
fine under Tomcat 6 and a Sun/Oracle Java 1.6 JVM
- the classes of a servlet that has been compiled under a Sun/Oracle Java 1.6 JDK will run 
fine under Tomcat 6 and a OpenJDK Java 1.6 JVM
- the classes of a servlet that has been compiled under a Sun/Oracle Java 1.6 JDK will run 
fine under Tomcat 6 and a OpenJDK Java 1.7 JVM


or alternatively, is it so that to run a servlet compiled under some JDK only works under 
the corresponding JRE/JVM ?

(or any other simpler rule-of-thumb rather than my exhaustive kind of list 
above)

I apologise if these are more Java-level questions than Tomcat-level questions, but as a 
sysadmin I have to decide which JVM to install, to run Tomcat along with webapps which I 
receive pre-compiled, and other non-Tomcat Java applications also precompiled.
And I have to decide this for several Linux and Windows platforms, whereas I am told that 
for some of these platforms at least, the pre-packaged versions of Java and/or Tomcat are 
not always the most recent ones. Hence my confusion.


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

Re: Tomcat and Sun/Oracle Java 7

[Mark Thomas]

On 04/02/2013 14:39, André Warnier wrote:
 Mark Thomas wrote:
 On 04/02/2013 13:41, Caldarale, Charles R wrote:
 From: Mark Thomas [mailto:ma...@apache.org] Subject: Re: Tomcat and
 Sun/Oracle Java 7
 What is the status of Tomcat vs Sun/oracle Java 7 ? I vaguely
 remember seeing some messages on this list about some kind of
 incompatibility.
 There are no known issues.
 Although there are no issues with running Tomcat under Java 7, I was
 under the impression that Tomcat 7 and below could not be built with
 Java 7 due to JRE interface incompatibilities.

 Correct. JDBC. Again.

 
 Ok, then sorry about my persistent deep lack of knowledge of
 Java-things, but are the following assumptions correct ? (and if not,
 why ?)
 
 - tomcat 6 will run fine under a Sun/Oracle Java 1.6 JVM
 - tomcat 7 will run fine under a Sun/Oracle Java 1.6 JVM
 - tomcat 6 will run fine under a Sun/Oracle Java 1.7 JVM
 - tomcat 7 will run fine under a Sun/Oracle Java 1.7 JVM
 - tomcat 6 will run fine under an OpenJDK Java 1.7 JVM
 - tomcat 7 will run fine under an OpenJDK Java 1.7 JVM

Yes. And you can add Java 1.5 from vendor of your choice to that list
for Tomcat 6.

 and, there may (or may not) be problems compiling a servlet that uses
 JDBC under a Sun/Oracle Java 1.7 JDK,

If you use JDBC and compile with a 1.7 JDK, you must write your code to
the JDBC 4.1 interfaces. This is mainly an issue for JDBC driver /
connection pool implementers and is unlikely to impact web application
developers.

 but assuming that this servlet
 does not use JDBC in any way :
 
 - the classes of a servlet that has been compiled under a Sun/Oracle
 Java 1.6 JDK will run fine under Tomcat 6 and a Sun/Oracle Java 1.7 JVM
Yes.

 - the classes of a servlet that has been compiled under a Sun/Oracle
 Java 1.7 JDK will run fine under Tomcat 6 and a Sun/Oracle Java 1.6 JVM
Yes, providing that javac -target 1.6 ... is used and no APIs
introduced in Java 1.7 are used.

 - the classes of a servlet that has been compiled under a Sun/Oracle
 Java 1.6 JDK will run fine under Tomcat 6 and a OpenJDK Java 1.6 JVM
Yes.

 - the classes of a servlet that has been compiled under a Sun/Oracle
 Java 1.6 JDK will run fine under Tomcat 6 and a OpenJDK Java 1.7 JVM
Yes.

 or alternatively, is it so that to run a servlet compiled under some JDK
 only works under the corresponding JRE/JVM ?
 (or any other simpler rule-of-thumb rather than my exhaustive kind of
 list above)
The rule of thumb is that:
a) you must run Tomcat on a Java version greater or equal to the target
Java version the application was compiled for.
b) you must run Tomcat on at least the minimum Java version required by
that Tomcat version

For all of the above, I have assumed only the public APIs have been
used. If an app starts using JRE internals directly (e.g. classes in the
sun.* package) all bets are off.

Also, s/will/should/ since a JRE bug could break the expected compatibility.


 I apologise if these are more Java-level questions than Tomcat-level
 questions, but as a sysadmin I have to decide which JVM to install, to
 run Tomcat along with webapps which I receive pre-compiled, and other
 non-Tomcat Java applications also precompiled.
 And I have to decide this for several Linux and Windows platforms,
 whereas I am told that for some of these platforms at least, the
 pre-packaged versions of Java and/or Tomcat are not always the most
 recent ones. Hence my confusion.

It gets worse. You often find commercial applications that only run on
specific versions of the JRE and specific application server versions.
For example, it was only relatively recently that Jira was supported on
Java 7 and Tomcat 7. It wasn't just a case of being unsupported, stuff
broke if you ran it on Java 7 and/or Tomcat 7 rather than Java 6 /
Tomcat 6. That just shouldn't happen.

Personally, I'd aim for Tomcat 7 and Java 7 everywhere and require a
very good justification of why not for any exception cases.

Mark

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

RE: Tomcat and Sun/Oracle Java 7

[Caldarale, Charles R]

 From: André Warnier [mailto:a...@ice-sa.com] 
 Subject: Re: Tomcat and Sun/Oracle Java 7

 - tomcat 6 will run fine under a Sun/Oracle Java 1.6 JVM
 - tomcat 7 will run fine under a Sun/Oracle Java 1.6 JVM
 - tomcat 6 will run fine under a Sun/Oracle Java 1.7 JVM
 - tomcat 7 will run fine under a Sun/Oracle Java 1.7 JVM
 - tomcat 6 will run fine under an OpenJDK Java 1.7 JVM
 - tomcat 7 will run fine under an OpenJDK Java 1.7 JVM

The above are correct, assuming Tomcat is built with Java 6.

 there may (or may not) be problems compiling a servlet that uses 
 JDBC under a Sun/Oracle Java 1.7 JDK, but assuming that this servlet
 does not use JDBC in any way :

If the servlet compiles cleanly under Java 7, it should be runnable under Java 
7.

 - the classes of a servlet that has been compiled under a Sun/Oracle Java 1.6 
 JDK will run fine under Tomcat 6 and a Sun/Oracle Java 1.7 JVM

Yes.

 - the classes of a servlet that has been compiled under a Sun/Oracle Java 1.7 
 JDK will run fine under Tomcat 6 and a Sun/Oracle Java 1.6 JVM

No.

 - the classes of a servlet that has been compiled under a Sun/Oracle Java 1.6 
 JDK will run fine under Tomcat 6 and a OpenJDK Java 1.6 JVM

Yes.

 - the classes of a servlet that has been compiled under a Sun/Oracle Java 1.6 
 JDK will run fine under Tomcat 6 and a OpenJDK Java 1.7 JVM

Yes.

 alternatively, is it so that to run a servlet compiled under some JDK only 
 works under the corresponding JRE/JVM ?

Classes compiled under a particular major JVM version are generally not 
loadable under prior versions.  Compiler options exist to change that behavior.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Re: Tomcat and Sun/Oracle Java 7

[Jess Holle]

It's not that Tomcat doesn't *run* fine with Java 7 even if you're 
making use of JDBC.


And it's not that you can't have code that calls JDBC APIs that works 
fine with Java 6 and Java 7.


It's that you can't make Java source code which /implements /JDBC 
interfaces and make it compilable with both Java 6 and Java 7. The JDBC 
interfaces have new methods in Java 7 *and* some of these new methods 
use classes new to Java 7.


One approach to work around this is to use dynamic proxies, but this can 
be obnoxious.  Otherwise you're stuck with code that will compile only 
with Java 6 or Java 7 -- take your pick.


This isn't a Tomcat issue -- it applies to anything which ends up 
needing to implement a JDBC interface.


Standard, built-in Java classes to wrap Connection, PreparedStatement, 
etc, would go a long way towards resolving this -- as one could simply 
extend the wrapper class and override the necessary methods.  This is a 
lot easier to read than InvocationHandler code required by the dynamic 
proxy approach. I'd bet that most who end up doing any substantive work 
in this area end up creating their own reusable pass-through wrapper 
classes for easy extension.


--
Jess Holle

On 2/4/2013 8:39 AM, André Warnier wrote:

Mark Thomas wrote:

On 04/02/2013 13:41, Caldarale, Charles R wrote:

From: Mark Thomas [mailto:ma...@apache.org] Subject: Re: Tomcat and
Sun/Oracle Java 7

What is the status of Tomcat vs Sun/oracle Java 7 ? I vaguely
remember seeing some messages on this list about some kind of 
incompatibility.

There are no known issues.

Although there are no issues with running Tomcat under Java 7, I was
under the impression that Tomcat 7 and below could not be built with
Java 7 due to JRE interface incompatibilities.


Correct. JDBC. Again.



Ok, then sorry about my persistent deep lack of knowledge of 
Java-things, but are the following assumptions correct ? (and if not, 
why ?)


- tomcat 6 will run fine under a Sun/Oracle Java 1.6 JVM
- tomcat 7 will run fine under a Sun/Oracle Java 1.6 JVM
- tomcat 6 will run fine under a Sun/Oracle Java 1.7 JVM
- tomcat 7 will run fine under a Sun/Oracle Java 1.7 JVM
- tomcat 6 will run fine under an OpenJDK Java 1.7 JVM
- tomcat 7 will run fine under an OpenJDK Java 1.7 JVM

and, there may (or may not) be problems compiling a servlet that uses 
JDBC under a Sun/Oracle Java 1.7 JDK, but assuming that this servlet 
does not use JDBC in any way :


- the classes of a servlet that has been compiled under a Sun/Oracle 
Java 1.6 JDK will run fine under Tomcat 6 and a Sun/Oracle Java 1.7 JVM
- the classes of a servlet that has been compiled under a Sun/Oracle 
Java 1.7 JDK will run fine under Tomcat 6 and a Sun/Oracle Java 1.6 JVM
- the classes of a servlet that has been compiled under a Sun/Oracle 
Java 1.6 JDK will run fine under Tomcat 6 and a OpenJDK Java 1.6 JVM
- the classes of a servlet that has been compiled under a Sun/Oracle 
Java 1.6 JDK will run fine under Tomcat 6 and a OpenJDK Java 1.7 JVM


or alternatively, is it so that to run a servlet compiled under some 
JDK only works under the corresponding JRE/JVM ?
(or any other simpler rule-of-thumb rather than my exhaustive kind of 
list above)


I apologise if these are more Java-level questions than Tomcat-level 
questions, but as a sysadmin I have to decide which JVM to install, to 
run Tomcat along with webapps which I receive pre-compiled, and other 
non-Tomcat Java applications also precompiled.
And I have to decide this for several Linux and Windows platforms, 
whereas I am told that for some of these platforms at least, the 
pre-packaged versions of Java and/or Tomcat are not always the most 
recent ones. Hence my confusion.


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

.

RE: Tomcat and Sun/Oracle Java 7

[Williams, Nick]

 -Original Message-
 From: Jess Holle [mailto:je...@ptc.com]

 ...
 It's that you can't make Java source code which /implements /JDBC interfaces 
 and make it compilable with both Java 6 and Java 7. The JDBC interfaces have 
 new methods in Java 7 *and* some of these new methods use classes new to Java 
 7.
 ...

Just a quick correction. You CAN implement the JDBC interfaces so that they 
compile under both Java 7 and Java 6, as long as you don't use the @Override 
annotation on the methods you implement that were added in JDBC 4.1 (Java 7).

This e-mail may contain privileged or confidential information. If you are not 
the intended recipient: (1) you may not disclose, use, distribute, copy or rely 
upon this message or attachment(s); and (2) please notify the sender by reply 
e-mail, and then delete this message and its attachment(s). Underwriters 
Laboratories Inc. and its affiliates disclaim all liability for any errors, 
omissions, corruption or virus in this message or any attachments.


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

Re: Tomcat and Sun/Oracle Java 7

[Konstantin Kolinko]

2013/2/4 André Warnier a...@ice-sa.com:

(...)

 I apologise if these are more Java-level questions than Tomcat-level
 questions, but as a sysadmin I have to decide which JVM to install, to run
 Tomcat along with webapps which I receive pre-compiled, and other non-Tomcat
 Java applications also precompiled.
 And I have to decide this for several Linux and Windows platforms, whereas I
 am told that for some of these platforms at least, the pre-packaged versions
 of Java and/or Tomcat are not always the most recent ones. Hence my
 confusion.


For me that would depend on how mission-critical those systems are and
what are mitigation strategies in case of a failure.

First, I prefer to install a JDK instead of a JRE, because
a) it comes with trouble-shooting tools such as jstack
b) several versions of JDK can be installed in parallel, and such
installation does not require root privileges.

Second, if I run small tools, I usually use whatever JRE is installed
in the system.

If I configure Tomcat in production I prefer to select an explicit
JRE/JDK version by configuring it with $CATALINA_BASE/bin/setenv.sh.

If the web applications that you are installing in production have not
been tested on Java 7, I would stick with Java 6 for a while,  but it
is already the time to start testing them with Java 7.

In theory, applications developed with Java 6 should run on Java 7 just fine.

In practice, it needs testing, and there exist
http://www.oracle.com/technetwork/java/javase/compatibility-417013.html

(which is part of original Java 7.0.0 release notes)

Best regards,
Konstantin Kolinko

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

Re: Tomcat and Sun/Oracle Java 7

[Jess Holle]

On 2/4/2013 9:32 AM, Williams, Nick wrote:

-Original Message-
From: Jess Holle [mailto:je...@ptc.com]

...
It's that you can't make Java source code which /implements /JDBC interfaces 
and make it compilable with both Java 6 and Java 7. The JDBC interfaces have 
new methods in Java 7 *and* some of these new methods use classes new to Java 7.
...

Just a quick correction. You CAN implement the JDBC interfaces so that they 
compile under both Java 7 and Java 6, as long as you don't use the @Override 
annotation on the methods you implement that were added in JDBC 4.1 (Java 7).
I stand corrected.  Perhaps it was with 1.5 and 1.6 where I tried and 
failed to do this.


At any rate, I no bother trying such things.  I have a version of such 
code to be compiled and used with 1.5, another for 1.6 and another for 1.7.


--
Jess Holle


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

Re: Tomcat and Sun/Oracle Java 7

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 2/4/13 8:57 AM, Mark Thomas wrote:
 On 04/02/2013 13:41, Caldarale, Charles R wrote:
 From: Mark Thomas [mailto:ma...@apache.org] Subject: Re: Tomcat
 and Sun/Oracle Java 7
 
 What is the status of Tomcat vs Sun/oracle Java 7 ? I
 vaguely remember seeing some messages on this list about some
 kind of incompatibility.
 
 There are no known issues.
 
 Although there are no issues with running Tomcat under Java 7, I
 was under the impression that Tomcat 7 and below could not be
 built with Java 7 due to JRE interface incompatibilities.
 
 Correct. JDBC. Again.

No wonder those guys were so reticent to change the JDBC API to
(directly) support the upcoming Java Date  Time APIs: they've made
everyone so angry in the past they don't want to do it again ;)

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREIAAYFAlEP/7EACgkQ9CaO5/Lv0PCWhgCfUH4HYp7byPJHv2SsCc4AuchO
bowAn2wtwK5OFCV4LhcuRDb2uvby8csr
=udsk
-END PGP SIGNATURE-

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

Re: Tomcat and Sun/Oracle Java 7

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chuck,

On 2/4/13 9:55 AM, Caldarale, Charles R wrote:
 From: André Warnier [mailto:a...@ice-sa.com] - the classes of a
 servlet that has been compiled under a Sun/Oracle Java 1.7 JDK
 will run fine under Tomcat 6 and a Sun/Oracle Java 1.6 JVM
 
 No.

It's a maybe. If you use -target 1.6 and you make sure not to use
any APIs that are Java 1.7+ (not sure if the compiler actually checks
when you use -target 1.6), then the above should be possible.
Otherwise, you will have problems loading the class (lack of .class
file version support) or running the code (NoSuchMethodError, etc.).

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREIAAYFAlEQAJYACgkQ9CaO5/Lv0PD/NACeN3Cj+QSu+qDOePzn8kVtihSb
OYwAn3NhrhzcYnpkJb6IymPlbYk35tjj
=NuUe
-END PGP SIGNATURE-

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

OT RE: Tomcat and Sun/Oracle Java 7

[Williams, Nick]

 No wonder those guys were so reticent to change the JDBC API to
 (directly) support the upcoming Java Date  Time APIs: they've made everyone 
 so angry in the past they don't want to do it again ;)

 - -chris

Chris,

DID/WILL they update the JDBC API to support the new date/time API? Or did they 
decide not to? It would be unfortunate, in my mind, if they decided not to 
support what everyone the community nearly universally agrees is a better 
date/time API just because they're afraid of making some people mad by changing 
the JDBC API in a MAJOR version upgrade...

This e-mail may contain privileged or confidential information. If you are not 
the intended recipient: (1) you may not disclose, use, distribute, copy or rely 
upon this message or attachment(s); and (2) please notify the sender by reply 
e-mail, and then delete this message and its attachment(s). Underwriters 
Laboratories Inc. and its affiliates disclaim all liability for any errors, 
omissions, corruption or virus in this message or any attachments.

Re: OT RE: Tomcat and Sun/Oracle Java 7

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Nick,

On 2/4/13 1:42 PM, Williams, Nick wrote:
 No wonder those guys were so reticent to change the JDBC API to 
 (directly) support the upcoming Java Date  Time APIs: they've
 made everyone so angry in the past they don't want to do it again
 ;)
 
 - -chris
 
 Chris,
 
 DID/WILL they update the JDBC API to support the new date/time
 API? Or did they decide not to? It would be unfortunate, in my
 mind, if they decided not to support what everyone the community
 nearly universally agrees is a better date/time API just because
 they're afraid of making some people mad by changing the JDBC API
 in a MAJOR version upgrade...

Everything will work, it's just that the API isn't going to change.

So, for instance, if you want to use the new java.time.ZonedDateTime
class with one of your table fields, you'll need to use this JDBC method:

  ResultSet rs = ...;

  ZonedDateTime myTimestamp
= rs.getObject(timestamp, ZonedDateTime.class);

OR:

  PreparedStatement ps = ...;

  ps.setObject(timestamp, myTimestamp);

So it's not like it /isn't/ supported, but there are no methods that
jump out and say hey! I support java.time!.

AFAIK, java.time is in the latest OpenJDK and Oracle Java 8
milestones. There is still a fairly high degree (if you ask me) of
flux within the API at this point, so it's not entirely set in stone.
Current discussion on the [threeten] mailing list: whether or not the
Chrono class will use generics.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREIAAYFAlEQBRYACgkQ9CaO5/Lv0PB71wCeKAmoIY4ddxuup9B3v2fgXNWk
aqgAoItuWmY9dIk0MJ+2F1yWdavS+UzZ
=A0LP
-END PGP SIGNATURE-

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

Re: Tomcat and Sun/Oracle Java 7

[André Warnier]

Thanks to all. I got more than I was bargaining for.

To summarise thus, if I understand correctly what was said here, and asking forgiveness in 
advance for pretty bad English style :


- any well-written java application, which does not use any vendor-specific JVM API (or 
internals) should be able to run on any JVM of a level equal or superior to the one it 
compiles (or has been compiled) under.

(Barring any specific bug in the JVM in question)

- any well-written java web-application, written in conformance with a given Java Servlet 
Specification level, which does not use any of the above JVM internals nor any 
container-specific APIs, should be able to run under any java servlet container which 
supports the same Java Servlet Specification level.

(Barring any specific bug in the servlet container in question)

And if any java application or java web-application does not run as per the above rules, 
then we should ask the vendor/developer of this application why not.


Is that it ?



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

Re: tomcat 6.0.35 with java 7 ssl proxy request body failed

[Johanes Soetanto]

On 26 November 2012 18:22, Mark Thomas ma...@apache.org wrote:
 Johanes Soetanto otnat...@gmail.com wrote:

Hi all,

I am wondering whether there is a known issue with running Tomcat
6.0.35 with Java 7 ?

 None I can think of.

I see lots of (502)Unknown error 502: proxy: pass request body
failed.. error in our Apache log after running our Tomcat with Java
7. Once I change back Tomcat to use Java 6, I see no error at all.

 Time to get tcpdump / wireshark installed and look at what is going on on 
 port 8443.

hmn, i have been looking a way to capture the communication with
wireshark, but still haven't found a way to do it, do you know a way
to do it?

I can see some communication using tcpdump, but i don't think i can
see the packet, or am i missing something?

 Mark


Other than that I found out that I can avoid pass request body error
if I enable APR and use the same certificate. If I disable APR and use
JSSE implementation (keystore), it always give me an error at random
point. So I am not sure whether this is problem with Tomcat / Java 7 /
the SSL certificate itself.

My APR https connection is set like

Connector port=8443 maxThreads=150 scheme=https secure=true
SSLEnabled=true
SSLCertificateFile=/etc/apache2/ssl/server.crt
SSLCertificateKeyFile=/etc/apache2/ssl/server.key
/

I am not sure whether I should cc you Matt, I see you reply to me and
users@tomcat.apache.org, when I click reply it automatically set your
email address in to field.

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

Re: tomcat 6.0.35 with java 7 ssl proxy request body failed

[Konstantin Kolinko]

2012/11/26 Johanes Soetanto otnat...@gmail.com:
 Hi all,

 I am wondering whether there is a known issue with running Tomcat
 6.0.35 with Java 7 ?


1. There certainly were fixes in Tomcat 7. I am not sure whether all
of them they were backported to Tomcat 6 or not.

I think you would have better luck (and a faster fix if there is an
issue) with Tomcat 7.

2. There was an issue, but it should be fixed in = 6.0.34.

(Allow the BIO HTTP connector to be used with SSL when running under Java 7.).

3. The supported SSL features  ciphers are slightly different in Java
7 than in Java 6.
http://docs.oracle.com/javase/7/docs/technotes/guides/security/enhancements-7.html

Maybe connection between HTTPD and Tomcat uses different protocol or
different cipher in Java 6 vs. in Java 7 cases.

Supported protocols and ciphers at HTTPD side depend on what OpenSSL
library version it is using.

4. Do you observe any consequences besides those messages in the log?
Are connections failing? Are all connections failing, or only a part
of them?

Best regards,
Konstantin Kolinko

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

Re: tomcat 6.0.35 with java 7 ssl proxy request body failed

[Johanes Soetanto]

On 26 November 2012 21:05, Konstantin Kolinko knst.koli...@gmail.com wrote:
 2012/11/26 Johanes Soetanto otnat...@gmail.com:
 Hi all,

 I am wondering whether there is a known issue with running Tomcat
 6.0.35 with Java 7 ?


 1. There certainly were fixes in Tomcat 7. I am not sure whether all
 of them they were backported to Tomcat 6 or not.

 I think you would have better luck (and a faster fix if there is an
 issue) with Tomcat 7.
I changed it to use Tomcat 7.0.33, and still having the same problem.
so I guess it is not Tomcat 6.0.35 problem


 2. There was an issue, but it should be fixed in = 6.0.34.

 (Allow the BIO HTTP connector to be used with SSL when running under Java 
 7.).
I will try that next

 4. Do you observe any consequences besides those messages in the log?
 Are connections failing? Are all connections failing, or only a part
 of them?

Pretty much, some random requests got 502 error

I got Apache to log info message, and I got error

[info] SSL Library Error: 336151568 error:14094410:SSL
routines:SSL3_READ_BYTES:sslv3 alert handshake failure

Could this be simply error because failing to establish connection to tomcat ?

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

Re: tomcat 6.0.35 with java 7 ssl proxy request body failed

[Muz]

On 26 November 2012 14:28, Johanes Soetanto otnat...@gmail.com wrote:

 Unknown error 502

Hi Johanes,

What are your proxypass settings?

Thanks,
Muz

Re: tomcat 6.0.35 with java 7 ssl proxy request body failed

[Johanes Soetanto]

Hi Muz,

We use RewriteRule instead of ProxyPass which works.

RewriteRule /app(.*)$ https://127.0.0.1:8443/app$1 [P,L]

I have even changed this to use ProxyPass but without any noticeable difference

ProxyPass /app https://127.0.0.1:8443/app
ProxyPassReverse /app https://127.0.0.1:8443/app


Johanes Soetanto



On 26 November 2012 14:53, Muz muz...@gmail.com wrote:
 On 26 November 2012 14:28, Johanes Soetanto otnat...@gmail.com wrote:

 Unknown error 502

 Hi Johanes,

 What are your proxypass settings?

 Thanks,
 Muz

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

Re: tomcat 6.0.35 with java 7 ssl proxy request body failed

[Mark Thomas]

Johanes Soetanto otnat...@gmail.com wrote:

Hi all,

I am wondering whether there is a known issue with running Tomcat
6.0.35 with Java 7 ?

None I can think of.

I see lots of (502)Unknown error 502: proxy: pass request body
failed.. error in our Apache log after running our Tomcat with Java
7. Once I change back Tomcat to use Java 6, I see no error at all.

Time to get tcpdump / wireshark installed and look at what is going on on port 
8443.

Mark


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

Re: Tomcat 7.0.29 vs. Groovy with Java 7

[Konstantin Kolinko]

2012/8/16 Jess Holle je...@ptc.com:
 It appears that when one installs the groovy-all-2.0.1-indy.jar in a Tomcat
 web app, BCEL chokes on the Java 7 specific byte-code therein ala

org.apache.tomcat.util.bcel.classfile.ClassFormatException: Invalid byte
 tag in constant pool: 15
 at
 org.apache.tomcat.util.bcel.classfile.Constant.readConstant(Constant.java:131)
 at
 org.apache.tomcat.util.bcel.classfile.ConstantPool.init(ConstantPool.java:60)
 at
 org.apache.tomcat.util.bcel.classfile.ClassParser.readConstantPool(ClassParser.java:209)
 at
 org.apache.tomcat.util.bcel.classfile.ClassParser.parse(ClassParser.java:119)
 at
 org.apache.catalina.startup.ContextConfig.processAnnotationsStream(ContextConfig.java:2066)
 ...

 Is there an update planned to make org.apache.tomcat.util.bcel savvy to Java
 7 or replace it with ASM (which is fully Java 7 savvy)? [Please!]

BCEL is now being developed at Apache Commons. If one contributes a
patch there, I think it will make its way into Tomcat as well.

I do not think that anyone would bother replacing the annotation
scanning code with ASM one.

http://commons.apache.org/bcel/


 Until then, can I completely exclude this jar from annotation scanning?


1. The property in catalina.properties, as mentioned by Christopher.

2. Annotations would not be scanned if your web.xml has
metadata-complete=true.

Also, if I understand the feature described by BZ 53619, one should
also add an empty
absolute-ordering/ to web.xml.

https://issues.apache.org/bugzilla/show_bug.cgi?id=53619

Best regards,
Konstantin Kolinko

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

Re: Tomcat 7.0.29 vs. Groovy with Java 7

[Jess Holle]

On 8/17/2012 3:18 PM, Konstantin Kolinko wrote:

2012/8/16 Jess Holle je...@ptc.com:

It appears that when one installs the groovy-all-2.0.1-indy.jar in a Tomcat
web app, BCEL chokes on the Java 7 specific byte-code therein ala

org.apache.tomcat.util.bcel.classfile.ClassFormatException: Invalid byte
tag in constant pool: 15
 at
org.apache.tomcat.util.bcel.classfile.Constant.readConstant(Constant.java:131)
 at
org.apache.tomcat.util.bcel.classfile.ConstantPool.init(ConstantPool.java:60)
 at
org.apache.tomcat.util.bcel.classfile.ClassParser.readConstantPool(ClassParser.java:209)
 at
org.apache.tomcat.util.bcel.classfile.ClassParser.parse(ClassParser.java:119)
 at
org.apache.catalina.startup.ContextConfig.processAnnotationsStream(ContextConfig.java:2066)
 ...

Is there an update planned to make org.apache.tomcat.util.bcel savvy to Java
7 or replace it with ASM (which is fully Java 7 savvy)? [Please!]

BCEL is now being developed at Apache Commons. If one contributes a
patch there, I think it will make its way into Tomcat as well.

I do not think that anyone would bother replacing the annotation
scanning code with ASM one.

http://commons.apache.org/bcel/
BCEL does not appear to be terribly actively maintained -- else it 
wouldn't have had an issue with Java 7 byte code...


Until it is updated, Tomcat's annotation scanning will be broken for 
/some /Java 7 byte code.  That's not really a tenable state long term.


ASM handles Java 7 byte code now.  That's the only reason I bring it up 
(well, it's fast too...)


--
Jess Holle

Re: Tomcat 7.0.29 vs. Groovy with Java 7

[Konstantin Kolinko]

2012/8/18 Jess Holle je...@ptc.com:
 Until it is updated, Tomcat's annotation scanning will be broken for some
 Java 7 byte code.  That's not really a tenable state long term.


I have filed an issue, as this really needs to be addressed before
Tomcat 8 is released.

https://issues.apache.org/bugzilla/show_bug.cgi?id=53735

Best regards,
Konstantin Kolinko

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

Tomcat 7.0.29 vs. Groovy with Java 7

[Jess Holle]

It appears that when one installs the groovy-all-2.0.1-indy.jar in a 
Tomcat web app, BCEL chokes on the Java 7 specific byte-code therein ala


   org.apache.tomcat.util.bcel.classfile.ClassFormatException: Invalid byte tag 
in constant pool: 15
at 
org.apache.tomcat.util.bcel.classfile.Constant.readConstant(Constant.java:131)
at 
org.apache.tomcat.util.bcel.classfile.ConstantPool.init(ConstantPool.java:60)
at 
org.apache.tomcat.util.bcel.classfile.ClassParser.readConstantPool(ClassParser.java:209)
at 
org.apache.tomcat.util.bcel.classfile.ClassParser.parse(ClassParser.java:119)
at 
org.apache.catalina.startup.ContextConfig.processAnnotationsStream(ContextConfig.java:2066)
...

Is there an update planned to make org.apache.tomcat.util.bcel savvy to 
Java 7 or replace it with ASM (which is fully Java 7 savvy)? [Please!]


Until then, can I completely exclude this jar from annotation scanning?

--
Jess Holle

Re: Tomcat 7.0.29 vs. Groovy with Java 7

[Pid *]

On 16 Aug 2012, at 17:10, Jess Holle je...@ptc.com wrote:

 It appears that when one installs the groovy-all-2.0.1-indy.jar in a Tomcat 
 web app, BCEL chokes on the Java 7 specific byte-code therein ala

   org.apache.tomcat.util.bcel.classfile.ClassFormatException: Invalid byte 
 tag in constant pool: 15
   at 
 org.apache.tomcat.util.bcel.classfile.Constant.readConstant(Constant.java:131)
   at 
 org.apache.tomcat.util.bcel.classfile.ConstantPool.init(ConstantPool.java:60)
   at 
 org.apache.tomcat.util.bcel.classfile.ClassParser.readConstantPool(ClassParser.java:209)
   at 
 org.apache.tomcat.util.bcel.classfile.ClassParser.parse(ClassParser.java:119)
   at 
 org.apache.catalina.startup.ContextConfig.processAnnotationsStream(ContextConfig.java:2066)
...

 Is there an update planned to make org.apache.tomcat.util.bcel savvy to Java 
 7 or replace it with ASM (which is fully Java 7 savvy)? [Please!]

 Until then, can I completely exclude this jar from annotation scanning?

Yes!


p


 --
 Jess Holle


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

Re: Tomcat 7.0.29 vs. Groovy with Java 7

[Jess Holle]

On 8/16/2012 11:14 AM, Pid * wrote:

On 16 Aug 2012, at 17:10, Jess Holle je...@ptc.com wrote:

It appears that when one installs the groovy-all-2.0.1-indy.jar in a Tomcat web 
app, BCEL chokes on the Java 7 specific byte-code therein ala

   org.apache.tomcat.util.bcel.classfile.ClassFormatException: Invalid byte tag 
in constant pool: 15
   at 
org.apache.tomcat.util.bcel.classfile.Constant.readConstant(Constant.java:131)
   at 
org.apache.tomcat.util.bcel.classfile.ConstantPool.init(ConstantPool.java:60)
   at 
org.apache.tomcat.util.bcel.classfile.ClassParser.readConstantPool(ClassParser.java:209)
   at 
org.apache.tomcat.util.bcel.classfile.ClassParser.parse(ClassParser.java:119)
   at 
org.apache.catalina.startup.ContextConfig.processAnnotationsStream(ContextConfig.java:2066)
...

Is there an update planned to make org.apache.tomcat.util.bcel savvy to Java 7 
or replace it with ASM (which is fully Java 7 savvy)? [Please!]

Until then, can I completely exclude this jar from annotation scanning?

Yes!

Sorry, but how?

--
Jess Holle


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

Re: Tomcat 7.0.29 vs. Groovy with Java 7

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jess,

On 8/16/12 12:19 PM, Jess Holle wrote:
 On 8/16/2012 11:14 AM, Pid * wrote:
 On 16 Aug 2012, at 17:10, Jess Holle je...@ptc.com wrote:
 It appears that when one installs the groovy-all-2.0.1-indy.jar
 in a Tomcat web app, BCEL chokes on the Java 7 specific
 byte-code therein ala
 
 org.apache.tomcat.util.bcel.classfile.ClassFormatException: 
 Invalid byte tag in constant pool: 15 at 
 org.apache.tomcat.util.bcel.classfile.Constant.readConstant(Constant.java:131)


 
at
 org.apache.tomcat.util.bcel.classfile.ConstantPool.init(ConstantPool.java:60)


 
at
 org.apache.tomcat.util.bcel.classfile.ClassParser.readConstantPool(ClassParser.java:209)


 
at
 org.apache.tomcat.util.bcel.classfile.ClassParser.parse(ClassParser.java:119)


 
at
 org.apache.catalina.startup.ContextConfig.processAnnotationsStream(ContextConfig.java:2066)


 
...
 
 Is there an update planned to make org.apache.tomcat.util.bcel
 savvy to Java 7 or replace it with ASM (which is fully Java 7
 savvy)? [Please!]
 
 Until then, can I completely exclude this jar from annotation
 scanning?
 Yes!
 Sorry, but how?

I had to search around for this for a while, but I finally found it
(it's essentially undocumented) in the ChangeLog.

Look at the tomcat.util.scan.DefaultJarScanner.jarsToSkip property
in CATALINA_HOME/conf/catalina.properties

I think you can just add your JAR to that list.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAtYC4ACgkQ9CaO5/Lv0PD5uACbBAFYLPKcuE72HhKVHh7+dI3r
r78AnA3Lxv05VcwO0NtA2Tt1+1v8eBIi
=/YZH
-END PGP SIGNATURE-

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