Re: Support with error in launcher.log

[calder]

On Mon, Mar 30, 2020, 05:02 Luigi Tagliafierro 
wrote:

> Hi everybody,
>
> we are experiencing an error :  The bitbucket log
> (/var/atlassian/bitbucket_home/log/launcher.log) constantly repeats this
> error:
>
> "java.lang.IllegalArgumentException: An invalid domain
>


[.code.doxee.com] was specified for this cookie" .
>

Issue:
the domain has a dot (.) at its beginning.


The error has been present in the log for some time and continues to be.
>
> We contacted the support of atlassian, who after an analysis suggested
> that we ask you about the error in question.
> Here the link to the discussion, *and all the info, tests and steps we
> took before contacting you* :
> https://getsupport.atlassian.com/servicedesk/customer/portal/24/SSP-42041
>
> Our Tomcat version is: 8.5.29
>
> In attachment there is the complete error.
>
> We are waiting for an answer that can help you analyze or solve the
> problem,
>
> Thanks a lot,
> Regards,
>
> Luigi
>

>

Re: Support with error in launcher.log

[Svetlin Zarev]

Hi,

We've had this error and it turned out to be due to the cookie processor.
According to RFC6265, the domain attribute of the cookie must not start
with a dot, so the new cookie processor rejects those cookies. Either
remove the starting dot from the domain attribute or use the legacy cookie
processor.

Kind regards,
Svetlin

На пн, 30.03.2020 г. в 13:22 Martin Grigorov  написа:

> Hi,
>
> On Mon, Mar 30, 2020 at 1:02 PM Luigi Tagliafierro <
> ltagliafie...@doxee.com> wrote:
>
>> Hi everybody,
>>
>> we are experiencing an error :  The bitbucket log
>> (/var/atlassian/bitbucket_home/log/launcher.log) constantly repeats this
>> error:
>>
>> "java.lang.IllegalArgumentException: An invalid domain [.code.doxee.com]
>> was specified for this cookie" .
>>
>
> Is there a stacktrace with this error ?
> It would be good to see which class/method throws this exception.
>
>
>> The error has been present in the log for some time and continues to be.
>>
>> We contacted the support of atlassian, who after an analysis suggested
>> that we ask you about the error in question.
>> Here the link to the discussion, *and all the info, tests and steps we
>> took before contacting you* :
>> https://getsupport.atlassian.com/servicedesk/customer/portal/24/SSP-42041
>>
>> Our Tomcat version is: 8.5.29
>>
>
> Please try with a more recent version of Tomcat, e.g. 8.5.53.
>
>
>>
>> In attachment there is the complete error.
>>
>> We are waiting for an answer that can help you analyze or solve the
>> problem,
>>
>> Thanks a lot,
>> Regards,
>>
>> Luigi
>>
>>
>> [image: signature_1607051054]
>>
>>
>>
>> *Luigi Tagliafierro*
>>
>> *IX Team*
>>
>>
>> doxee.com 
>>
>> find us on:
>>
>> [image: signature_1049012399] [image:
>> signature_145818931] [image:
>> signature_816293899] 
>>
>>
>>
>>
>>
>> Questa email ed ogni eventuale allegato sono confidenziali.
>>
>> Se non siete il destinatario della presente ogni suo utilizzo è vietato.
>>
>> Le chiediamo di segnalare l’accaduto al  mittente e di cancellare il
>> messaggio.
>>
>> Questo messaggio è inviato da Doxee e non ha natura personale, le
>> informazioni contenute possono essere note al mittente o da altri suoi
>> collaboratori.
>>
>>
>>
>> This e-mail and any attachments are confidential.
>>
>> If you are not the intended recipient, you are hereby notified that any
>> use or distribution of this e-mail is strictly prohibited.
>>
>> Please contact the sender and delete this message from your system.
>>
>> We apologize for any inconvenience this may cause.
>>
>> This message is forwarded from Doxee and is not of a personal nature; the
>> information contained herein may be known by the sender and other employees
>> in the company.
>>
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Support with error in launcher.log

[Martin Grigorov]

Hi,

On Mon, Mar 30, 2020 at 1:02 PM Luigi Tagliafierro 
wrote:

> Hi everybody,
>
> we are experiencing an error :  The bitbucket log
> (/var/atlassian/bitbucket_home/log/launcher.log) constantly repeats this
> error:
>
> "java.lang.IllegalArgumentException: An invalid domain [.code.doxee.com]
> was specified for this cookie" .
>

Is there a stacktrace with this error ?
It would be good to see which class/method throws this exception.


> The error has been present in the log for some time and continues to be.
>
> We contacted the support of atlassian, who after an analysis suggested
> that we ask you about the error in question.
> Here the link to the discussion, *and all the info, tests and steps we
> took before contacting you* :
> https://getsupport.atlassian.com/servicedesk/customer/portal/24/SSP-42041
>
> Our Tomcat version is: 8.5.29
>

Please try with a more recent version of Tomcat, e.g. 8.5.53.


>
> In attachment there is the complete error.
>
> We are waiting for an answer that can help you analyze or solve the
> problem,
>
> Thanks a lot,
> Regards,
>
> Luigi
>
>
> [image: signature_1607051054]
>
>
>
> *Luigi Tagliafierro*
>
> *IX Team*
>
>
> doxee.com 
>
> find us on:
>
> [image: signature_1049012399] [image:
> signature_145818931] [image:
> signature_816293899] 
>
>
>
>
>
> Questa email ed ogni eventuale allegato sono confidenziali.
>
> Se non siete il destinatario della presente ogni suo utilizzo è vietato.
>
> Le chiediamo di segnalare l’accaduto al  mittente e di cancellare il
> messaggio.
>
> Questo messaggio è inviato da Doxee e non ha natura personale, le
> informazioni contenute possono essere note al mittente o da altri suoi
> collaboratori.
>
>
>
> This e-mail and any attachments are confidential.
>
> If you are not the intended recipient, you are hereby notified that any
> use or distribution of this e-mail is strictly prohibited.
>
> Please contact the sender and delete this message from your system.
>
> We apologize for any inconvenience this may cause.
>
> This message is forwarded from Doxee and is not of a personal nature; the
> information contained herein may be known by the sender and other employees
> in the company.
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Support for JDK only by Windows Installer?

[Mark Thomas]

On 16/11/2019 09:29, Alexander Norz wrote:
> Am 15.11.2019 22:23, schrieb Mark Thomas:
> 
> That is the point:
> 
>> Because Oracle changed the directory layout and names of the standard
>> registry entries and the installer probably hasn't been updated to take
>> account of that yet.
> 
> The environment variable JAVA_HOME isn't supported actually.
> 
> I added this as the last check after JRE64/32, JRE in JDK, now new JDK
> only and then environment variable.
> 
> We can discus to use environment variable first of all? I think this
> could be more common?

Thanks for the PR.

Mark

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

Re: Support for JDK only by Windows Installer?

[Konstantin Kolinko]

сб, 16 нояб. 2019 г. в 12:08, Alexander Norz
:
>
> Am 15.11.2019 22:23, schrieb Mark Thomas:
> >
> >
> > Patches welcome.
> >
> > Mark
> >
>
> A patch is nearly ready. I will sent a pull request asap.

I think that you should start with a real reproducible description of
the issue (in Bugzilla).

What JDK are you using, from what vendor, and what are the steps to
reproduce the issue.

> But because of getting no error code and finding no log-file after a failed 
> silent installation.

Generally,

1) Without a JDK the installer cannot really choose whether to install
32-bit or 64-bit binaries.
I think that we can default to 64-bit nowadays.

2) The JDK can be reconfigured later, via configuration manager
(tomcat9w.exe) or by editing the registry.

>From 1) it is odd that the installer does not fail, but from 2) you
can always fix it afterwards (as long as CPU architecture is chosen
correctly and the correct binaries are installed).

> The environment variable JAVA_HOME isn't supported actually.

>From my experience with installing the service with service.bat, the
environment variables are lost when a program runs with elevated
privileges. That is why service.bat was changed to pass all settings
as command line arguments when installing a service (calling
tomcat9[w].exe). You may find a reference to Bugzilla issue in the
commit history of the service.bat file.

Best regards,
Konstantin Kolinko

> Alexander
>
> -
> 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: Support for JDK only by Windows Installer?

[Alexander Norz]

Am 15.11.2019 22:23, schrieb Mark Thomas:

That is the point:


Because Oracle changed the directory layout and names of the standard
registry entries and the installer probably hasn't been updated to take
account of that yet.


The environment variable JAVA_HOME isn't supported actually.

I added this as the last check after JRE64/32, JRE in JDK, now new JDK 
only and then environment variable.


We can discus to use environment variable first of all? I think this 
could be more common?


Alexander

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

Re: Support for JDK only by Windows Installer?

[Alexander Norz]

Am 15.11.2019 22:23, schrieb Mark Thomas:



Patches welcome.

Mark



A patch is nearly ready. I will sent a pull request asap.

Alexander

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

Re: Support for JDK only by Windows Installer?

[Mark Thomas]

On 15/11/2019 15:50, Alexander Norz wrote:
> Hello,
> 
> is there a good point why the Windows Service Installer
> (apache-tomcat-9.0.27.exe) did not support Oracles Java JDK (11 without
> JRE) out-of-the-box especially for silent installation?

Because Oracle changed the directory layout and names of the standard
registry entries and the installer probably hasn't been updated to take
account of that yet.

> Meanwhile I know that I have to add a config-file with parameter /C for
> silent installation. But because of getting no error code and finding no
> log-file after a failed silent installation, it needs some time to solve
> this issue ;-)
> 
> IMHO unfortunately the installer does not look for Java by using the
> JAVA_HOME environment variable and also does not check the registry key
> HKLM\SOFTWARE\JavaSoft\JDK for some reasons.
> 
> I suggest to add the JDK registry key and JAVA_HOME envvar to the
> install script (source/res/tomcat.nsi), if there is no reason against to
> use JDK only?

Patches welcome.

Mark

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

Re: Support Request for problem with problem running SSL certificate on tomcat 8

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Munzer,

On 8/10/19 18:31, Munzer Khatib wrote:
> I noticed i made some typos in the commands i listed here because i
> was testing.. I started testing with Tomcat10 keystore and then the
> last rekey was for Tomcat14 keystore. All the commands reference
> the Tomcat 14 keystore.

Can you please re-post a corrected list of commands? It will
definitely help.

Did you see my separate reply about missing the keyAlias configuration
attribute? It's almost certainly the root cause of (and solution to)
your problem.

> I did export the certificate to PK#12 and still will try to extract
> private key using openssl.
> 
> Do you think this problem might be due to incompatibility between 
> keytool java version and certificate and Tomcat 8.0 release? The 
> machine has an older Windows 2008 server.
Nope. PKCS12 is a standard format and all currently-released versions
of Java support it -- correctly, as far as I can tell. You can use
keytool from any version of Java to prepare a keystore to be used by
an other version of Java.

Newer versions of Tomcat can use either a JSSE-readable file format
(like PKCS12, JKS, JCEKS, etc.) *or* the simpler PEM-encoded DER files
that e.g. Apache httpd uses.

- -chris

> On Wednesday, 7 August 2019, 09:07:58 am UTC, logo 
>  wrote:
> 
> Munzer,
> 
> 
> 
> Am 2019-08-07 09:19, schrieb Peter Kreuser:
>> Hi Munzer,
>> 
>> I guess we‘re going a slightly awkward way here, but to fix your
>>  problem with the new cert in the first place, you could use 
>> this:
>> 
>> If your keystore is the old proprietary format, convert it to 
>> PKCS12: keytool -importkeystore -srckeystore keystore.jks 
>> -destkeystore keystore.p12 -deststoretype PKCS12 -srcalias
>> tomcat -deststorepass  -destkeypass  Then
>> extract the key using openssl: openssl pkcs12 -in keystore.p12
>> -nocerts -out key.pem After that recombine it with the new cert.
>> I‘ve found this here: https://security.stackexchange.com/a/66865
>> 
>> There has to be an easier way, but as your keystore is causing 
>> troubles, I‘m not really able to troubleshoot that.
>> 
> 
> now I've replayed your commands and selfsigned the csr with my ca. 
> I see the same behaviour on tomcat10.keystore!
> 
> BT! If I replace tomcat14.keystore in the first two commands 
> with tomcat10.keystore the generated cert is imported as a 
> PrivateKeyEntry. :-)
> 
> Well IF you did it like you send in the first mail, you imported 
> the ca and the intermediate certificate into a different (unused?) 
> keystore!!!
> 
> Could you please doublecheck?
> 
> 
> Peter
> 
> BTW: did you get warnings on the console that the JKS-keystore 
> format is a proprietary format and should be converted to pkcs12?
> 
> 
>> After all, you may have to reread on cert handling with keytool 
>> vs. openssl. I prefer the openssl way ;-).
>> 
>> Peter
>> 
>> 
>> 
>> Peter Kreuser
>>> Am 06.08.2019 um 19:50 schrieb Munzer Khatib 
>>> :
>>> 
>>> Hi Peter I dont have the private key file. That is created
>>> when I create the keystore. I dont know if it can be extracted.
>>>  Munzer On Tuesday, 6 August 2019, 4:35:51 PM UTC, Peter
>>> Kreuser  wrote:
>>> 
>>> Hi,
>>> 
>>> 
 Am 06.08.2019 um 02:42 schrieb Munzer Khatib 
 :
 
 Hi Can you help me with this problem. Problem: Installing
 SSL certificate on Apache Tomcat 8.0.36 fails I am trying to 
 install a new SSL certificate into Apache tomcat 8.0.36.I
 ran same steps ran successfully in 2013 and 2016 on tomcat
 7. Nothing changed other than moving the virtual machine
 from old server to new hardware this year. Windows Server
 2008 is still the same Operating system. I created a keystore
 and extracted CSR, generated certificate using godaddy for
 Apache server and imported to server. I keep getting an SSL 
 handshake errors and I think it is because the certificate 
 entrytype is "trustedcertEntry" and not "privateKey Entry' 
 Here are the steps I used to create the keystore and import 
 certificate to it. 1) Generate a Keystorecd C:\Program 
 Files\Java\jre7\bin keytool -keysize 2048 -genkey -alias 
 tomcat -keyalg RSA  -sigalg SHA256withRSA -keypass secret19 
 -keystore tomcat10.keystore
>>> 
 2) Create a CSRkeytool -certreq -alias tomcat -keyalg RSA 
 -sigalg SHA256withRSA -keystore tomcat10.keystore -file 
 file10.csr
 
 3) Generate certificates on godaddy site for "Apache" server 
 (not tomcat) 4) Install root, intermediate and user 
 certificate keytool -import -alias root -keystore 
 tomcat14.keystore -trustcacerts -file 
 c:\cert_2022\gd-class2-root.crt
 
 keytool -import -alias intermediate -keystore 
 tomcat14.keystore -trustcacerts -file 
 c:\cert_2022\gd_bundle-g2-g1.crt keytool -import -alias 
 tomcat -keystore tomcat10.keystore  -file 
 c:\cert_2019\508c844632c0145.crt
>>> 
>>> I‘ve not found a keytool command for that. I use openssl to 

Re: Support Request for problem with problem running SSL certificate on tomcat 8

[Munzer Khatib]

 Hi Peter,
Thank you for your reply. 
I noticed i made some typos in the commands i listed here because i was 
testing.. I started testing with Tomcat10 keystore and then the last rekey was 
for Tomcat14 keystore. All the commands reference the Tomcat 14 keystore.
I did export the certificate to PK#12 and still will try to extract private key 
using openssl. 
Do you think this problem might be due to incompatibility between keytool java 
version and certificate and Tomcat 8.0 release? The machine has an older 
Windows 2008 server.
Thanks,
On Wednesday, 7 August 2019, 09:07:58 am UTC, logo  
wrote:  
 
 Munzer,



Am 2019-08-07 09:19, schrieb Peter Kreuser:
> Hi Munzer,
> 
> I guess we‘re going a slightly awkward way here, but to fix your
> problem with the new cert in the first place, you could use this:
> 
> If your keystore is the old proprietary format, convert it to PKCS12:
> keytool -importkeystore -srckeystore keystore.jks -destkeystore
> keystore.p12 -deststoretype PKCS12 -srcalias tomcat -deststorepass
>  -destkeypass 
> Then extract the key using openssl:
> openssl pkcs12 -in keystore.p12 -nocerts -out key.pem
> After that recombine it with the new cert.
> I‘ve found this here: https://security.stackexchange.com/a/66865
> 
> There has to be an easier way, but as your keystore is causing
> troubles, I‘m not really able to troubleshoot that.
> 

now I've replayed your commands and selfsigned the csr with my ca. I see 
the same behaviour on tomcat10.keystore!

BT! If I replace tomcat14.keystore in the first two commands with 
tomcat10.keystore the generated cert is imported as a PrivateKeyEntry. 
:-)

Well IF you did it like you send in the first mail, you imported the ca 
and the intermediate certificate into a different (unused?) keystore!!!

Could you please doublecheck?


Peter

BTW: did you get warnings on the console that the JKS-keystore format is 
a proprietary format and should be converted to pkcs12?


> After all, you may have to reread on cert handling with keytool vs. 
> openssl.
> I prefer the openssl way ;-).
> 
> Peter
> 
> 
> 
> Peter Kreuser
>> Am 06.08.2019 um 19:50 schrieb Munzer Khatib 
>> :
>> 
>> Hi Peter
>> I dont have the private key file. That is created when I create the 
>> keystore. I dont know if it can be extracted.
>> Munzer
>>    On Tuesday, 6 August 2019, 4:35:51 PM UTC, Peter Kreuser 
>>  wrote:
>> 
>> Hi,
>> 
>> 
>>> Am 06.08.2019 um 02:42 schrieb Munzer Khatib 
>>> :
>>> 
>>> Hi
>>> Can you help me with this problem.
>>> Problem: Installing SSL certificate on Apache Tomcat 8.0.36 fails
>>> I am trying to install a new SSL certificate into Apache tomcat 
>>> 8.0.36.I ran same steps ran successfully in 2013 and 2016 on tomcat 
>>> 7. Nothing changed other than moving the virtual machine from old 
>>> server to new hardware this year. Windows Server 2008 is still the 
>>> same Operating system.
>>> I created a keystore and extracted CSR, generated certificate using 
>>> godaddy for Apache server and imported to server. I keep getting an 
>>> SSL handshake errors and I think it is because the certificate 
>>> entrytype is "trustedcertEntry" and not "privateKey Entry'
>>> Here are the steps I used to create the keystore and import 
>>> certificate to it.
>>> 1) Generate a Keystorecd C:\Program Files\Java\jre7\bin
>>> keytool -keysize 2048 -genkey -alias tomcat -keyalg RSA  -sigalg 
>>> SHA256withRSA -keypass secret19 -keystore tomcat10.keystore
>> 
>>> 2) Create a CSRkeytool -certreq -alias tomcat -keyalg RSA -sigalg 
>>> SHA256withRSA -keystore tomcat10.keystore -file file10.csr
>>> 
>>> 3) Generate certificates on godaddy site for "Apache" server (not 
>>> tomcat)
>>> 4) Install root, intermediate and user certificate
>>> keytool -import -alias root -keystore tomcat14.keystore -trustcacerts 
>>> -file c:\cert_2022\gd-class2-root.crt
>>> 
>>> keytool -import -alias intermediate -keystore tomcat14.keystore 
>>> -trustcacerts -file c:\cert_2022\gd_bundle-g2-g1.crt
>>> keytool -import -alias tomcat -keystore tomcat10.keystore  -file 
>>> c:\cert_2019\508c844632c0145.crt
>> 
>> I‘ve not found a keytool command for that. I use openssl to convert 
>> the PEM to pkcs12/keystore format
>> 
>> Care to try the following command?
>> openssl pkcs12 -export -in cert.pem -inkey privkey.pem -name tomcat 
>> -certfile fullchain.pem -passout pass:changeit -out jssekeystore
>> 
>> Peter
>> 
>>> I am not sure why but it seems the new one is not linking all 
>>> certificates into the private key.
>>> I tried many different imports and it would never import the server 
>>> certificate as a "privateKeyentry" as the one running now.C:\Program 
>>> Files\Java\jre7\bin>keytool -list -keystore tomcat10.keystoreEnter 
>>> keystore password:
>>> Keystore type: JKSKeystore provider: SUN
>>> Your keystore contains 3 entries
>>> root, Jul 22, 2019, trustedCertEntry,Certificate fingerprint (SHA1): 
>>> 47:BE:AB:C9:22:EA:0E:78:78:34:62:A7:9F:45:C2:54:FD:E6:8Bintermediate, 
>>> Jul 22, 2019, 

Re: Support Request for problem with problem running SSL certificate on tomcat 8

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Munzer,

On 8/5/19 20:42, Munzer Khatib wrote:
> Here are the steps I used to create the keystore and import
> certificate to it.

These steps look okay, with the exception that Peter (logo) pointed
out: you have used two different keystores in your commands. Also, you
have tomcat10.keystore in your configuration and I think you might
want to be using tomcat14.keystore. Whichever keystore you use, you
need to be consistent. Feel free to make a backup copy after you
generate your CSR just in case you make a mistake and damage the key
store.

> C:\Program Files\Java\jre7\bin>keytool -list -keystore
> tomcat10.keystoreEnter keystore password: Keystore type:
> JKSKeystore provider: SUN Your keystore contains 3 entries root,
> Jul 22, 2019, trustedCertEntry,Certificate fingerprint (SHA1):
> 47:BE:AB:C9:22:EA:0E:78:78:34:62:A7:9F:45:C2:54:FD:E6:8Bintermediate,
> Jul 22, 2019, trustedCertEntry,Certificate fingerprint (SHA1):
> 27:AC:93:69:FA:52:07:BB:26:27:CE:FA:CC:BE:4E:F9:C3:19:B8tomcat, Jul
> 22, 2019, trustedCertEntry,Certificate fingerprint (SHA1):
> B6:27:BE:DF:ED:EF:EF:4D:62:D2:F1:5C:CC:C1:A2:AB:98:60:8E

Okay, that's the first entry in the file. What about the other two?

> 
> I also tried creating a PEM text file for all certificates and
> importing that into private key alias tomcat but it only imported
> the domain certificate as "trustedcertentry" My server xml file
> connector config is like this protocol="HTTP/1.1" connectionTimeout="2" redirectPort="8443"
> compression="on" URIEncoding="UTF-8" compressionMinSize="2048"
> noCompressionUserAgents="gozilla, traviata"
> compressableMimeType="text/html,text/xml,text/plain,text/css,text/java
script,text/json,application/json"/> port="443" protocol="HTTP/1.1" maxThreads="150" scheme="https"
> secure="true" clientAuth="false" sslProtocol="TLS"
> SSLEnabled="true" sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2"
> ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA3
84,
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS
_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,
> TLS_RSA_WITH_AES_256_CBC_SHA" keystorePass="password"
> keystoreFile="C:\Program Files\Java\jre7\bin\tomcat10.keystore"/>
> 

You are missing a "keyAlias" attribute. You'll want:

keyAlias="tomcat"

In that  configuration. Otherwise, Tomcat will use the
first entry found in the keystore.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl1MKqcACgkQHPApP6U8
pFhGWRAAxR38krdkv0T4UpZSgvPvhFFm5rNMaxG2JKMusybjQwO3/7H9sg6hi4TZ
XKlwrH3iqn4qcAl2GtT4oYy9VwZjoo4GPuaJzTl+qZ1gbX0vFw7YtwfKrnYVWv5A
IXprhCvZPXjIDEBgNNOoHaX9sAI0APvk6d8HDNtD/d5etqL5KxEZ3vP8o2vyV1A1
nNK0Q5wFXOxfUFpNCoGzUUdOGOAopzUtj9qmdJERi3XvGwho2IoVPfdd60Hk+/Qi
62LzTn/+rckKXhNk2A6Zgek4qFxbl60w0MpaogTPhMhC4ouQaUmy0CugBuKZfYuE
YjJzsJzlGDpXQHbOgX/wkSYhC+3Au9j1TXvflSuQG9MljtRwKKCjt3WzWHLzM30Q
/kXhFOOglIfXJ8PQdO4OUG3O0sFKbpeKNVrEy6CquhRHbYRpA1DgZPNp86oRoEnc
zPO7aqjC/hxTS9zhfCmUx1ZCb3sJg/hXuUkSi8//6UEkOLORY5qN0p2OApl+ft2j
jkoWRdvXrmQhKl0fuO5Mot27M2uOGJ/UGB2Ed0vsNOGlD2/UNg3Yz8oHi3xv1Zu0
B6tqVaRP164vHunB2ka5tGJ7jyQPw3P1Mr9Z9bbHIyKsM8ckb2QSbrKUlcsQ28gv
FT/merQctDyMS0zHVYzUobfqujE8EqC33Cyq5eedWhqGFGQpwsM=
=lp+s
-END PGP SIGNATURE-

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

Re: Support Request for problem with problem running SSL certificate on tomcat 8

[logo]

Munzer,



Am 2019-08-07 09:19, schrieb Peter Kreuser:

Hi Munzer,

I guess we‘re going a slightly awkward way here, but to fix your
problem with the new cert in the first place, you could use this:

If your keystore is the old proprietary format, convert it to PKCS12:
keytool -importkeystore -srckeystore keystore.jks -destkeystore
keystore.p12 -deststoretype PKCS12 -srcalias tomcat -deststorepass
 -destkeypass 
Then extract the key using openssl:
openssl pkcs12 -in keystore.p12 -nocerts -out key.pem
After that recombine it with the new cert.
I‘ve found this here: https://security.stackexchange.com/a/66865

There has to be an easier way, but as your keystore is causing
troubles, I‘m not really able to troubleshoot that.



now I've replayed your commands and selfsigned the csr with my ca. I see 
the same behaviour on tomcat10.keystore!


BT! If I replace tomcat14.keystore in the first two commands with 
tomcat10.keystore the generated cert is imported as a PrivateKeyEntry. 
:-)


Well IF you did it like you send in the first mail, you imported the ca 
and the intermediate certificate into a different (unused?) keystore!!!


Could you please doublecheck?


Peter

BTW: did you get warnings on the console that the JKS-keystore format is 
a proprietary format and should be converted to pkcs12?



After all, you may have to reread on cert handling with keytool vs. 
openssl.

I prefer the openssl way ;-).

Peter



Peter Kreuser
Am 06.08.2019 um 19:50 schrieb Munzer Khatib 
:


Hi Peter
I dont have the private key file. That is created when I create the 
keystore. I dont know if it can be extracted.

Munzer
   On Tuesday, 6 August 2019, 4:35:51 PM UTC, Peter Kreuser 
 wrote:


Hi,


Am 06.08.2019 um 02:42 schrieb Munzer Khatib 
:


Hi
Can you help me with this problem.
Problem: Installing SSL certificate on Apache Tomcat 8.0.36 fails
I am trying to install a new SSL certificate into Apache tomcat 
8.0.36.I ran same steps ran successfully in 2013 and 2016 on tomcat 
7. Nothing changed other than moving the virtual machine from old 
server to new hardware this year. Windows Server 2008 is still the 
same Operating system.
I created a keystore and extracted CSR, generated certificate using 
godaddy for Apache server and imported to server. I keep getting an 
SSL handshake errors and I think it is because the certificate 
entrytype is "trustedcertEntry" and not "privateKey Entry'
Here are the steps I used to create the keystore and import 
certificate to it.

1) Generate a Keystorecd C:\Program Files\Java\jre7\bin
keytool -keysize 2048 -genkey -alias tomcat -keyalg RSA  -sigalg 
SHA256withRSA -keypass secret19 -keystore tomcat10.keystore


2) Create a CSRkeytool -certreq -alias tomcat -keyalg RSA -sigalg 
SHA256withRSA -keystore tomcat10.keystore -file file10.csr


3) Generate certificates on godaddy site for "Apache" server (not 
tomcat)

4) Install root, intermediate and user certificate
keytool -import -alias root -keystore tomcat14.keystore -trustcacerts 
-file c:\cert_2022\gd-class2-root.crt


keytool -import -alias intermediate -keystore tomcat14.keystore 
-trustcacerts -file c:\cert_2022\gd_bundle-g2-g1.crt
keytool -import -alias tomcat -keystore tomcat10.keystore  -file 
c:\cert_2019\508c844632c0145.crt


I‘ve not found a keytool command for that. I use openssl to convert 
the PEM to pkcs12/keystore format


Care to try the following command?
openssl pkcs12 -export -in cert.pem -inkey privkey.pem -name tomcat 
-certfile fullchain.pem -passout pass:changeit -out jssekeystore


Peter

I am not sure why but it seems the new one is not linking all 
certificates into the private key.
I tried many different imports and it would never import the server 
certificate as a "privateKeyentry" as the one running now.C:\Program 
Files\Java\jre7\bin>keytool -list -keystore tomcat10.keystoreEnter 
keystore password:

Keystore type: JKSKeystore provider: SUN
Your keystore contains 3 entries
root, Jul 22, 2019, trustedCertEntry,Certificate fingerprint (SHA1): 
47:BE:AB:C9:22:EA:0E:78:78:34:62:A7:9F:45:C2:54:FD:E6:8Bintermediate, 
Jul 22, 2019, trustedCertEntry,Certificate fingerprint (SHA1): 
27:AC:93:69:FA:52:07:BB:26:27:CE:FA:CC:BE:4E:F9:C3:19:B8tomcat, Jul 
22, 2019, trustedCertEntry,Certificate fingerprint (SHA1): 
B6:27:BE:DF:ED:EF:EF:4D:62:D2:F1:5C:CC:C1:A2:AB:98:60:8E


I also tried creating a PEM text file for all certificates and 
importing that into private key alias tomcat but it only imported the 
domain certificate as "trustedcertentry"
My server xml file connector config is like thisport="8080" protocol="HTTP/1.1" connectionTimeout="2" 
redirectPort="8443" compression="on" URIEncoding="UTF-8" 
compressionMinSize="2048" noCompressionUserAgents="gozilla, traviata" 
compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,text/json,application/json"/>port="443" protocol="HTTP/1.1" maxThreads="150" scheme="https" 
secure="true" clientAuth="false" sslProtocol="TLS" 

Re: Support Request for problem with problem running SSL certificate on tomcat 8

[Peter Kreuser]

Hi Munzer,

I guess we‘re going a slightly awkward way here, but to fix your problem with 
the new cert in the first place, you could use this:

If your keystore is the old proprietary format, convert it to PKCS12:
keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.p12 
-deststoretype PKCS12 -srcalias tomcat -deststorepass  -destkeypass 

Then extract the key using openssl:
openssl pkcs12 -in keystore.p12 -nocerts -out key.pem
After that recombine it with the new cert.
I‘ve found this here: https://security.stackexchange.com/a/66865

There has to be an easier way, but as your keystore is causing troubles, I‘m 
not really able to troubleshoot that.

After all, you may have to reread on cert handling with keytool vs. openssl.
I prefer the openssl way ;-).

Peter



Peter Kreuser
> Am 06.08.2019 um 19:50 schrieb Munzer Khatib :
> 
> Hi Peter
> I dont have the private key file. That is created when I create the keystore. 
> I dont know if it can be extracted.
> Munzer
>On Tuesday, 6 August 2019, 4:35:51 PM UTC, Peter Kreuser 
>  wrote:  
> 
> Hi,
> 
> 
>> Am 06.08.2019 um 02:42 schrieb Munzer Khatib :
>> 
>> Hi
>> Can you help me with this problem.
>> Problem: Installing SSL certificate on Apache Tomcat 8.0.36 fails
>> I am trying to install a new SSL certificate into Apache tomcat 8.0.36.I ran 
>> same steps ran successfully in 2013 and 2016 on tomcat 7. Nothing changed 
>> other than moving the virtual machine from old server to new hardware this 
>> year. Windows Server 2008 is still the same Operating system.
>> I created a keystore and extracted CSR, generated certificate using godaddy 
>> for Apache server and imported to server. I keep getting an SSL handshake 
>> errors and I think it is because the certificate entrytype is 
>> "trustedcertEntry" and not "privateKey Entry'
>> Here are the steps I used to create the keystore and import certificate to 
>> it.
>> 1) Generate a Keystorecd C:\Program Files\Java\jre7\bin
>> keytool -keysize 2048 -genkey -alias tomcat -keyalg RSA  -sigalg 
>> SHA256withRSA -keypass secret19 -keystore tomcat10.keystore
> 
>> 2) Create a CSRkeytool -certreq -alias tomcat -keyalg RSA -sigalg 
>> SHA256withRSA -keystore tomcat10.keystore -file file10.csr
>> 
>> 3) Generate certificates on godaddy site for "Apache" server (not tomcat)
>> 4) Install root, intermediate and user certificate
>> keytool -import -alias root -keystore tomcat14.keystore -trustcacerts -file 
>> c:\cert_2022\gd-class2-root.crt
>> 
>> keytool -import -alias intermediate -keystore tomcat14.keystore 
>> -trustcacerts -file c:\cert_2022\gd_bundle-g2-g1.crt
>> keytool -import -alias tomcat -keystore tomcat10.keystore  -file 
>> c:\cert_2019\508c844632c0145.crt
> 
> I‘ve not found a keytool command for that. I use openssl to convert the PEM 
> to pkcs12/keystore format
> 
> Care to try the following command?
> openssl pkcs12 -export -in cert.pem -inkey privkey.pem -name tomcat -certfile 
> fullchain.pem -passout pass:changeit -out jssekeystore
> 
> Peter
> 
>> I am not sure why but it seems the new one is not linking all certificates 
>> into the private key.
>> I tried many different imports and it would never import the server 
>> certificate as a "privateKeyentry" as the one running now.C:\Program 
>> Files\Java\jre7\bin>keytool -list -keystore tomcat10.keystoreEnter keystore 
>> password:
>> Keystore type: JKSKeystore provider: SUN
>> Your keystore contains 3 entries
>> root, Jul 22, 2019, trustedCertEntry,Certificate fingerprint (SHA1): 
>> 47:BE:AB:C9:22:EA:0E:78:78:34:62:A7:9F:45:C2:54:FD:E6:8Bintermediate, Jul 
>> 22, 2019, trustedCertEntry,Certificate fingerprint (SHA1): 
>> 27:AC:93:69:FA:52:07:BB:26:27:CE:FA:CC:BE:4E:F9:C3:19:B8tomcat, Jul 22, 
>> 2019, trustedCertEntry,Certificate fingerprint (SHA1): 
>> B6:27:BE:DF:ED:EF:EF:4D:62:D2:F1:5C:CC:C1:A2:AB:98:60:8E
>> 
>> I also tried creating a PEM text file for all certificates and importing 
>> that into private key alias tomcat but it only imported the domain 
>> certificate as "trustedcertentry"
>> My server xml file connector config is like this> port="8080" protocol="HTTP/1.1" connectionTimeout="2" 
>> redirectPort="8443" compression="on" URIEncoding="UTF-8" 
>> compressionMinSize="2048" noCompressionUserAgents="gozilla, traviata" 
>> compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,text/json,application/json"/>>  port="443" protocol="HTTP/1.1" maxThreads="150" scheme="https" 
>> secure="true" clientAuth="false" sslProtocol="TLS" SSLEnabled="true" 
>> sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2" 
>> ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, 
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, 
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,
>>  TLS_RSA_WITH_AES_256_CBC_SHA" keystorePass="password" 
>> keystoreFile="C:\Program Files\Java\jre7\bin\tomcat10.keystore"/>

Re: Support Request for problem with problem running SSL certificate on tomcat 8

[Munzer Khatib]

 Hi Peter
I dont have the private key file. That is created when I create the keystore. I 
dont know if it can be extracted.
Munzer
On Tuesday, 6 August 2019, 4:35:51 PM UTC, Peter Kreuser 
 wrote:  
 
 Hi,


> Am 06.08.2019 um 02:42 schrieb Munzer Khatib :
> 
> Hi
> Can you help me with this problem.
> Problem: Installing SSL certificate on Apache Tomcat 8.0.36 fails
> I am trying to install a new SSL certificate into Apache tomcat 8.0.36.I ran 
> same steps ran successfully in 2013 and 2016 on tomcat 7. Nothing changed 
> other than moving the virtual machine from old server to new hardware this 
> year. Windows Server 2008 is still the same Operating system.
> I created a keystore and extracted CSR, generated certificate using godaddy 
> for Apache server and imported to server. I keep getting an SSL handshake 
> errors and I think it is because the certificate entrytype is 
> "trustedcertEntry" and not "privateKey Entry'
> Here are the steps I used to create the keystore and import certificate to it.
> 1) Generate a Keystorecd C:\Program Files\Java\jre7\bin
> keytool -keysize 2048 -genkey -alias tomcat -keyalg RSA  -sigalg 
> SHA256withRSA -keypass secret19 -keystore tomcat10.keystore

> 2) Create a CSRkeytool -certreq -alias tomcat -keyalg RSA -sigalg 
> SHA256withRSA -keystore tomcat10.keystore -file file10.csr
> 
> 3) Generate certificates on godaddy site for "Apache" server (not tomcat)
> 4) Install root, intermediate and user certificate
> keytool -import -alias root -keystore tomcat14.keystore -trustcacerts -file 
> c:\cert_2022\gd-class2-root.crt
> 
> keytool -import -alias intermediate -keystore tomcat14.keystore -trustcacerts 
> -file c:\cert_2022\gd_bundle-g2-g1.crt
> keytool -import -alias tomcat -keystore tomcat10.keystore  -file 
> c:\cert_2019\508c844632c0145.crt
> 

I‘ve not found a keytool command for that. I use openssl to convert the PEM to 
pkcs12/keystore format

Care to try the following command?
openssl pkcs12 -export -in cert.pem -inkey privkey.pem -name tomcat -certfile 
fullchain.pem -passout pass:changeit -out jssekeystore

Peter

> I am not sure why but it seems the new one is not linking all certificates 
> into the private key.
> I tried many different imports and it would never import the server 
> certificate as a "privateKeyentry" as the one running now.C:\Program 
> Files\Java\jre7\bin>keytool -list -keystore tomcat10.keystoreEnter keystore 
> password:
> Keystore type: JKSKeystore provider: SUN
> Your keystore contains 3 entries
> root, Jul 22, 2019, trustedCertEntry,Certificate fingerprint (SHA1): 
> 47:BE:AB:C9:22:EA:0E:78:78:34:62:A7:9F:45:C2:54:FD:E6:8Bintermediate, Jul 22, 
> 2019, trustedCertEntry,Certificate fingerprint (SHA1): 
> 27:AC:93:69:FA:52:07:BB:26:27:CE:FA:CC:BE:4E:F9:C3:19:B8tomcat, Jul 22, 2019, 
> trustedCertEntry,Certificate fingerprint (SHA1): 
> B6:27:BE:DF:ED:EF:EF:4D:62:D2:F1:5C:CC:C1:A2:AB:98:60:8E
> 
> I also tried creating a PEM text file for all certificates and importing that 
> into private key alias tomcat but it only imported the domain certificate as 
> "trustedcertentry"
> My server xml file connector config is like this         port="8080" protocol="HTTP/1.1" connectionTimeout="2" redirectPort="8443" 
> compression="on" URIEncoding="UTF-8" compressionMinSize="2048" 
> noCompressionUserAgents="gozilla, traviata" 
> compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,text/json,application/json"/>  port="443" protocol="HTTP/1.1" maxThreads="150" scheme="https" secure="true" 
> clientAuth="false" sslProtocol="TLS" SSLEnabled="true" 
> sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2" 
> ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, 
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, 
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,
>  TLS_RSA_WITH_AES_256_CBC_SHA" keystorePass="password" 
> keystoreFile="C:\Program Files\Java\jre7\bin\tomcat10.keystore"/>    
> 
> 
> Tried many different options for keytool command.
> Followed tomcat 8 documentation and godaddy list for installing certificate.
> When I try to access using browser I get this error
> This page can’t be displayed Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in 
> Advanced settings and try connecting to https://psscr.xyz.c
> When I use openssl I get handshake failure$openssl s_client -connect 
> 10.60.xx.xx:443CONNECTED(0003)140298896533392:error:14077410:SSL 
> routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake 
> failure:s23_clnt.c:769:---no peer certificate available---No client 
> certificate CA names sent---SSL handshake has read 7 bytes and written 289 
> bytes---New, (NONE), Cipher is (NONE)Secure Renegotiation IS NOT 
> supportedCompression: NONEExpansion: NONENo ALPN negotiatedSSL-Session:    
> Protocol  : TLSv1.2    Cipher    :     Session-ID:    Session-ID-ctx:    
> Master-Key:    Key-Arg  : None    Krb5 Principal: None    

Re: Support Request for problem with problem running SSL certificate on tomcat 8

[Peter Kreuser]

Hi,


> Am 06.08.2019 um 02:42 schrieb Munzer Khatib :
> 
> Hi
> Can you help me with this problem.
> Problem: Installing SSL certificate on Apache Tomcat 8.0.36 fails
> I am trying to install a new SSL certificate into Apache tomcat 8.0.36.I ran 
> same steps ran successfully in 2013 and 2016 on tomcat 7. Nothing changed 
> other than moving the virtual machine from old server to new hardware this 
> year. Windows Server 2008 is still the same Operating system.
> I created a keystore and extracted CSR, generated certificate using godaddy 
> for Apache server and imported to server. I keep getting an SSL handshake 
> errors and I think it is because the certificate entrytype is 
> "trustedcertEntry" and not "privateKey Entry'
> Here are the steps I used to create the keystore and import certificate to it.
> 1) Generate a Keystorecd C:\Program Files\Java\jre7\bin
> keytool -keysize 2048 -genkey -alias tomcat -keyalg RSA  -sigalg 
> SHA256withRSA -keypass secret19 -keystore tomcat10.keystore

> 2) Create a CSRkeytool -certreq -alias tomcat -keyalg RSA -sigalg 
> SHA256withRSA -keystore tomcat10.keystore -file file10.csr
> 
> 3) Generate certificates on godaddy site for "Apache" server (not tomcat)
> 4) Install root, intermediate and user certificate
> keytool -import -alias root -keystore tomcat14.keystore -trustcacerts -file 
> c:\cert_2022\gd-class2-root.crt
> 
> keytool -import -alias intermediate -keystore tomcat14.keystore -trustcacerts 
> -file c:\cert_2022\gd_bundle-g2-g1.crt
> keytool -import -alias tomcat -keystore tomcat10.keystore  -file 
> c:\cert_2019\508c844632c0145.crt
> 

I‘ve not found a keytool command for that. I use openssl to convert the PEM to 
pkcs12/keystore format

Care to try the following command?
openssl pkcs12 -export -in cert.pem -inkey privkey.pem -name tomcat -certfile 
fullchain.pem -passout pass:changeit -out jssekeystore

Peter

> I am not sure why but it seems the new one is not linking all certificates 
> into the private key.
> I tried many different imports and it would never import the server 
> certificate as a "privateKeyentry" as the one running now.C:\Program 
> Files\Java\jre7\bin>keytool -list -keystore tomcat10.keystoreEnter keystore 
> password:
> Keystore type: JKSKeystore provider: SUN
> Your keystore contains 3 entries
> root, Jul 22, 2019, trustedCertEntry,Certificate fingerprint (SHA1): 
> 47:BE:AB:C9:22:EA:0E:78:78:34:62:A7:9F:45:C2:54:FD:E6:8Bintermediate, Jul 22, 
> 2019, trustedCertEntry,Certificate fingerprint (SHA1): 
> 27:AC:93:69:FA:52:07:BB:26:27:CE:FA:CC:BE:4E:F9:C3:19:B8tomcat, Jul 22, 2019, 
> trustedCertEntry,Certificate fingerprint (SHA1): 
> B6:27:BE:DF:ED:EF:EF:4D:62:D2:F1:5C:CC:C1:A2:AB:98:60:8E
> 
> I also tried creating a PEM text file for all certificates and importing that 
> into private key alias tomcat but it only imported the domain certificate as 
> "trustedcertentry"
> My server xml file connector config is like this port="8080" protocol="HTTP/1.1" connectionTimeout="2" redirectPort="8443" 
> compression="on" URIEncoding="UTF-8" compressionMinSize="2048" 
> noCompressionUserAgents="gozilla, traviata" 
> compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,text/json,application/json"/>  port="443" protocol="HTTP/1.1" maxThreads="150" scheme="https" secure="true" 
> clientAuth="false" sslProtocol="TLS" SSLEnabled="true" 
> sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2" 
> ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, 
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, 
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,
>  TLS_RSA_WITH_AES_256_CBC_SHA" keystorePass="password" 
> keystoreFile="C:\Program Files\Java\jre7\bin\tomcat10.keystore"/>
> 
> 
> Tried many different options for keytool command.
> Followed tomcat 8 documentation and godaddy list for installing certificate.
> When I try to access using browser I get this error
> This page can’t be displayed Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in 
> Advanced settings and try connecting to https://psscr.xyz.c
> When I use openssl I get handshake failure$openssl s_client -connect 
> 10.60.xx.xx:443CONNECTED(0003)140298896533392:error:14077410:SSL 
> routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake 
> failure:s23_clnt.c:769:---no peer certificate available---No client 
> certificate CA names sent---SSL handshake has read 7 bytes and written 289 
> bytes---New, (NONE), Cipher is (NONE)Secure Renegotiation IS NOT 
> supportedCompression: NONEExpansion: NONENo ALPN negotiatedSSL-Session:
> Protocol  : TLSv1.2Cipher: Session-ID:Session-ID-ctx:
> Master-Key:Key-Arg   : NoneKrb5 Principal: NonePSK identity: None 
>PSK identity hint: NoneStart Time: 1564789174Timeout   : 300 (sec) 
>Verify return code: 0 (ok)
> Thanks,

Re: Support for Windows 8 and Windows Server 2012

[Pid *]

On 24 Aug 2012, at 07:33, Geet Chandra gee...@gmail.com wrote:

 Hi,

 Does anybody know about Tomcat (6.x or 7.x) support for Windows 8 and
 Windows Server 2012.
 If it is there, then which version, if not when can we expect.

Why not try the latest Tomcat 7 and let us know if it works?


p

 --
 Thanks  Regards
 Geet

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

Re: Support for a jarsToInclude property?

[Ognjen Blagojevic]

On 30.7.2011 0:27, Konstantin Kolinko wrote:

2. Note that you can configure JarScanner element in context.xml.
Maybe it is worth to add a pair of such attributes (skip/include)
there?

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


That makes sense. Most of the jar files are anyway in webapps WEB-INF 
folder, so it is natural to keep jar scanner configuration local to the 
context.


-Ognjen

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

Re: Support for a jarsToInclude property?

[Konstantin Kolinko]

2011/7/30 Michael Youngstrom you...@gmail.com:
 I'm working with Tomcat 7 using web xml fragements and Servlet annotations.
  When metadata-complete=false startup time is bad.  It can be improved by
 excluding jars using tomcat.util.scan.DefaultJarScanner.jarsToSkip.  This is
 great except now everytime I add a jar I need to add it to this list to keep
 my startup time good.  I also want to be very careful about what jars are
 adding configuration to my servlet container.  I would like to be able to
 selectively allow these jars to be involved in scanning and then disable all
 other jars.

 It would seem that for my use case adding
 a  tomcat.util.scan.DefaultJarScanner.jarsToInclude property would be very
 useful.  Then I could do something like:

  tomcat.util.scan.DefaultJarScanner.jarsToSkip=*.jar
  tomcat.util.scan.DefaultJarScanner.jarsToInclude=spring-web*.jar,some-other*.jar

 Or if there is a collection of jars with a similar pattern that I know don't
 need to be scanned except for maybe one or two I can do something like:

  tomcat.util.scan.DefaultJarScanner.jarsToSkip=spring-*.jar
  tomcat.util.scan.DefaultJarScanner.jarsToInclude=spring-web*.jar

 Included jars would take precedence over skipped jars.


1. I think it is OK. The example with spring framework is a good one.

Setting jarsToSkip=*.jar (or just an empty string) as the global
value, though, will affect other unsuspecting web applications that
you could deploy on the same host.


2. Note that you can configure JarScanner element in context.xml.
Maybe it is worth to add a pair of such attributes (skip/include)
there?

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


3. There are several tasks performed by JAR scanner one is the
scanning for servlets and fragments.  Another one is scanning for TLD
files.

Note:  Jar scanning for TLDs is performed only when compiling a page
that has tags in it. So, to reproduce the message printed by
TldLocationsCache one has to remove compiled JSP pages and request
loading such a page with a web browser.

Also here is interaction between Catalina (servlet container) and
Jasper (JSP compiler).

4. I wonder how JarScanner is configured and used when precompiling JSP pages.


 Thoughts?  I'd be happy to provide a patch if others think such a feature
 would be useful?


At least it would be some exercise to study Tomcat code.


5. I thought maybe JarScanner could be taught to ignore some paths,
e.g. ${java.home}. This is a different issue, though.

Best regards,
Konstantin Kolinko

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

Re: Support multiple apache contexts via one tomcat webapp context

[Hassan Schroeder]

On Mon, Jun 14, 2010 at 10:26 PM, Andrew Bruno andrew.br...@gmail.com wrote:
 I am trying to setup Apache with JkMount to tomcat to dynamically
 handle different contexts in Apache, but always use the same context
 in Tomcat.

That statement doesn't make sense to me, given your example, but...

 http://apachefrontenddomain.com.au/a/customer-1.com - jk ajp to -
 http://tomcatserver:8009/webapp
 http://apachefrontenddomain.com.au/a/customer-2.com - jk ajp to -
 http://tomcatserver:8009/webapp
 http://apachefrontenddomain.com.au/a/customer-3.com - jk ajp to -
 http://tomcatserver:8019/webapp2
 http://apachefrontenddomain.com.au/a/customer-4.com - jk ajp to -
 http://tomcatserver:8039/webapp4

 Doe anyone know how to do this?  Do I need to use Aliasing or Rewriting?

I would just use mod_proxy, but I'm a keep-it-simple kinda guy :-)

FWIW,
-- 
Hassan Schroeder  hassan.schroe...@gmail.com
twitter: @hassan

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

Re: Support multiple apache contexts via one tomcat webapp context

[Jon Brisbin]

below...

On Jun 15, 2010, at 9:06 AM, Hassan Schroeder wrote:

 On Mon, Jun 14, 2010 at 10:26 PM, Andrew Bruno andrew.br...@gmail.com wrote:
 I am trying to setup Apache with JkMount to tomcat to dynamically
 handle different contexts in Apache, but always use the same context
 in Tomcat.
 
 That statement doesn't make sense to me, given your example, but...
 
 http://apachefrontenddomain.com.au/a/customer-1.com - jk ajp to -
 http://tomcatserver:8009/webapp
 http://apachefrontenddomain.com.au/a/customer-2.com - jk ajp to -
 http://tomcatserver:8009/webapp
 http://apachefrontenddomain.com.au/a/customer-3.com - jk ajp to -
 http://tomcatserver:8019/webapp2
 http://apachefrontenddomain.com.au/a/customer-4.com - jk ajp to -
 http://tomcatserver:8039/webapp4
 
 Doe anyone know how to do this?  Do I need to use Aliasing or Rewriting?
 
 I would just use mod_proxy, but I'm a keep-it-simple kinda guy :-)

FWIW- I've moved away from Apache as a proxy entirely. I use HAProxy with ACLs. 
It's more efficient and flexible, IMHO, and the only thing I really need Apache 
for is serving PHP pages.

That said, it seems to me it would simpler to proxy /a and have a servlet 
look at PATH_INFO, then forward to whatever path or context you want.

Jon Brisbin
Portal Webmaster
NPC International, Inc.


 
 FWIW,
 -- 
 Hassan Schroeder  hassan.schroe...@gmail.com
 twitter: @hassan
 
 -
 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: Support for Java 1.6 with Tomcat 5.5.x

[Konstantin Kolinko]

2009/10/9 Steve Wade stevewadec...@yahoo.com:
 I know this configuration works and that Apache states Tomcat 5.5.x support 
 for Java 1.5 and above, but I cannot find a statement for support of Java 1.6 
 with Tomcat 5.5.x. Anyone know where this support is documented?


As far as my personal experience is,
Tomcat 5.5.x runs just fine with Java 1.6 instead of 1.5.
No special care was needed.

 Anyone know where this support is documented?

That depends on what you mean by support. If you mean it in a loose
way, then that and above in RUNNING.txt literally includes 1.6.
That is all.  Apache is not a commercial vendor, so support here
means just that.


Best regards,
Konstantin Kolinko

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

Re: Support for JSF 2.0

[Martin Dubuc]

I can't find the JSP 2.2 specification, but if you look at JSR-316, you will
see that the basis for Java EE 6 is servlet 3.0, JSP 2.2 and JSF 2.0. I am
not sure it makes much sense to align JSP 2.1 with servlet 3.0.

Martin

On Tue, Mar 17, 2009 at 4:34 PM, Mark Thomas ma...@apache.org wrote:

 Martin Dubuc wrote:
  It is my understanding that Java EE 6 will use JSP 2.2, servlet 3.0 and
 JSF
  2.0. I am wondering if Tomcat 7.0 should also support JSP 2.2 in addition
 to
  servlet 3.0.

 As far as I am aware, there is no JSP 2.2 spec in the works. If you know
 different, a reference would be useful.

 Mark

 
  I have seen on the Sun's JSF forum a poster claim that JSF 2.0 would work
  with JSP 2.0 and servlet 2.5, so I guess Tomcat 6.0.x would be sufficient
  for Web applications using JSF 2.0.
 
  Martin
 
  On Tue, Mar 17, 2009 at 11:02 AM, Mark Thomas ma...@apache.org wrote:
 
  Christopher Schultz wrote:
  Martin,
 
  On 3/9/2009 5:44 PM, Martin Dubuc wrote:
  I am wondering if there are plans to support JSF 2.0 when it is
  released. I
  assume that support for JSF 2.0 will require support for new
 servlet/JSP
  specs (somehting like servlet 3.0/JSP 2.2). Would this be done in
  version
  7.0 of Tomcat?
  http://wiki.apache.org/tomcat/TomcatVersions says there are no
 specific
  plans for Tomcat 7.0. It also links to several notes files that
 don't
  exist :(
  There are plans for Tomcat 7.0. I'll update that page and fix the links.
 
  There is no JSP 2.2 spec that I am aware of. Tomcat 7 will support
 servlet
  3.0
 
  Mark
 
  I would guess that 7.0 would be a good target for JSF 2.0 support (or
 at
  least support for those APIs that JSF 2.0 requires) but nobody's
  promising anything at this point.
 
  -chris
  -
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 


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

RE: Support for JSF 2.0

[Leo Donahue - PLANDEVX]

 I am wondering if there are plans to support JSF 2.0 when it is 
 released.

Doesn't Tomcat 6.0 already support JSF 2.0 if it supports Servlet 2.5?  I had 
this same question this morning.

https://javaserverfaces.dev.java.net/nonav/rlnotes/2.0.0/releasenotes.html
 

-Original Message-
From: Martin Dubuc [mailto:martind1...@gmail.com] 
Sent: Wednesday, March 18, 2009 6:23 AM
To: Tomcat Users List
Subject: Re: Support for JSF 2.0

I can't find the JSP 2.2 specification, but if you look at JSR-316, you will 
see that the basis for Java EE 6 is servlet 3.0, JSP 2.2 and JSF 2.0. I am not 
sure it makes much sense to align JSP 2.1 with servlet 3.0.

Martin

On Tue, Mar 17, 2009 at 4:34 PM, Mark Thomas ma...@apache.org wrote:

 Martin Dubuc wrote:
  It is my understanding that Java EE 6 will use JSP 2.2, servlet 3.0 
  and
 JSF
  2.0. I am wondering if Tomcat 7.0 should also support JSP 2.2 in 
  addition
 to
  servlet 3.0.

 As far as I am aware, there is no JSP 2.2 spec in the works. If you 
 know different, a reference would be useful.

 Mark

 
  I have seen on the Sun's JSF forum a poster claim that JSF 2.0 would 
  work with JSP 2.0 and servlet 2.5, so I guess Tomcat 6.0.x would be 
  sufficient for Web applications using JSF 2.0.
 
  Martin
 
  On Tue, Mar 17, 2009 at 11:02 AM, Mark Thomas ma...@apache.org wrote:
 
  Christopher Schultz wrote:
  Martin,
 
  On 3/9/2009 5:44 PM, Martin Dubuc wrote:
  I am wondering if there are plans to support JSF 2.0 when it is
  released. I
  assume that support for JSF 2.0 will require support for new
 servlet/JSP
  specs (somehting like servlet 3.0/JSP 2.2). Would this be done in
  version
  7.0 of Tomcat?
  http://wiki.apache.org/tomcat/TomcatVersions says there are no
 specific
  plans for Tomcat 7.0. It also links to several notes files that
 don't
  exist :(
  There are plans for Tomcat 7.0. I'll update that page and fix the links.
 
  There is no JSP 2.2 spec that I am aware of. Tomcat 7 will support
 servlet
  3.0
 
  Mark
 
  I would guess that 7.0 would be a good target for JSF 2.0 support 
  (or
 at
  least support for those APIs that JSF 2.0 requires) but nobody's 
  promising anything at this point.
 
  -chris
  ---
  -- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 
  ---
  -- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 


 -
 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: Support for JSF 2.0

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin,

On 3/9/2009 5:44 PM, Martin Dubuc wrote:
 I am wondering if there are plans to support JSF 2.0 when it is released. I
 assume that support for JSF 2.0 will require support for new servlet/JSP
 specs (somehting like servlet 3.0/JSP 2.2). Would this be done in version
 7.0 of Tomcat?

http://wiki.apache.org/tomcat/TomcatVersions says there are no specific
plans for Tomcat 7.0. It also links to several notes files that don't
exist :(

I would guess that 7.0 would be a good target for JSF 2.0 support (or at
least support for those APIs that JSF 2.0 requires) but nobody's
promising anything at this point.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkm/q4MACgkQ9CaO5/Lv0PBODgCgpfXnCRYV2uuO+wiLCa0tD/Wi
IXgAnRKtsYhM40LJ6scO+uXgfsA11tEa
=ogYc
-END PGP SIGNATURE-

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

Re: Support for JSF 2.0

[Mark Thomas]

Christopher Schultz wrote:
 Martin,
 
 On 3/9/2009 5:44 PM, Martin Dubuc wrote:
 I am wondering if there are plans to support JSF 2.0 when it is released. I
 assume that support for JSF 2.0 will require support for new servlet/JSP
 specs (somehting like servlet 3.0/JSP 2.2). Would this be done in version
 7.0 of Tomcat?
 
 http://wiki.apache.org/tomcat/TomcatVersions says there are no specific
 plans for Tomcat 7.0. It also links to several notes files that don't
 exist :(

There are plans for Tomcat 7.0. I'll update that page and fix the links.

There is no JSP 2.2 spec that I am aware of. Tomcat 7 will support servlet 3.0

Mark

 
 I would guess that 7.0 would be a good target for JSF 2.0 support (or at
 least support for those APIs that JSF 2.0 requires) but nobody's
 promising anything at this point.
 
 -chris

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



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

Re: Support for JSF 2.0

[Martin Dubuc]

It is my understanding that Java EE 6 will use JSP 2.2, servlet 3.0 and JSF
2.0. I am wondering if Tomcat 7.0 should also support JSP 2.2 in addition to
servlet 3.0.

I have seen on the Sun's JSF forum a poster claim that JSF 2.0 would work
with JSP 2.0 and servlet 2.5, so I guess Tomcat 6.0.x would be sufficient
for Web applications using JSF 2.0.

Martin

On Tue, Mar 17, 2009 at 11:02 AM, Mark Thomas ma...@apache.org wrote:

 Christopher Schultz wrote:
  Martin,
 
  On 3/9/2009 5:44 PM, Martin Dubuc wrote:
  I am wondering if there are plans to support JSF 2.0 when it is
 released. I
  assume that support for JSF 2.0 will require support for new servlet/JSP
  specs (somehting like servlet 3.0/JSP 2.2). Would this be done in
 version
  7.0 of Tomcat?
 
  http://wiki.apache.org/tomcat/TomcatVersions says there are no specific
  plans for Tomcat 7.0. It also links to several notes files that don't
  exist :(

 There are plans for Tomcat 7.0. I'll update that page and fix the links.

 There is no JSP 2.2 spec that I am aware of. Tomcat 7 will support servlet
 3.0

 Mark

 
  I would guess that 7.0 would be a good target for JSF 2.0 support (or at
  least support for those APIs that JSF 2.0 requires) but nobody's
  promising anything at this point.
 
  -chris

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



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

Re: Support for JSF 2.0

[Mark Thomas]

Martin Dubuc wrote:
 It is my understanding that Java EE 6 will use JSP 2.2, servlet 3.0 and JSF
 2.0. I am wondering if Tomcat 7.0 should also support JSP 2.2 in addition to
 servlet 3.0.

As far as I am aware, there is no JSP 2.2 spec in the works. If you know
different, a reference would be useful.

Mark

 
 I have seen on the Sun's JSF forum a poster claim that JSF 2.0 would work
 with JSP 2.0 and servlet 2.5, so I guess Tomcat 6.0.x would be sufficient
 for Web applications using JSF 2.0.
 
 Martin
 
 On Tue, Mar 17, 2009 at 11:02 AM, Mark Thomas ma...@apache.org wrote:
 
 Christopher Schultz wrote:
 Martin,

 On 3/9/2009 5:44 PM, Martin Dubuc wrote:
 I am wondering if there are plans to support JSF 2.0 when it is
 released. I
 assume that support for JSF 2.0 will require support for new servlet/JSP
 specs (somehting like servlet 3.0/JSP 2.2). Would this be done in
 version
 7.0 of Tomcat?
 http://wiki.apache.org/tomcat/TomcatVersions says there are no specific
 plans for Tomcat 7.0. It also links to several notes files that don't
 exist :(
 There are plans for Tomcat 7.0. I'll update that page and fix the links.

 There is no JSP 2.2 spec that I am aware of. Tomcat 7 will support servlet
 3.0

 Mark

 I would guess that 7.0 would be a good target for JSF 2.0 support (or at
 least support for those APIs that JSF 2.0 requires) but nobody's
 promising anything at this point.

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



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


 


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

Re: Support

[Mark Thomas]

Caldarale, Charles R wrote:
 The msvcr71.dll file (not msvci70.dll, whatever that is) is required to run 
 the Tomcat service launcher, but not needed when Tomcat is run via scripts.
 
 The reason it didn't show up on JRE/JDK 5 is because installation of that JVM 
 version slams a copy of the DLL into C:\windows\system32, regardless of what 
 impact that might have on the system.  JRE/JDK 6 installation follows the 
 rules published by Microsoft, and keeps the DLL in the JVM's bin directory.
 
 Tomcat should be distributing the DLL (or otherwise insuring its 
 availability) during installation or setup of the Windows service; however, 
 no one's been able to convince the committers of that yet.

In summary:
- the JVM requires the dll - this is a JVM bug (Sun do not agree)
- the best place to hack around this is when the jvm.dll is loaded (ie the
daemon project)
- a nice summary and all the pointers needed to fix this are here
http://www.duckware.com/tech/java6msvcr71.html
- There is a daemon issue for this
https://issues.apache.org/jira/browse/DAEMON-110
- Someone with C skills (not me - mine are terrible) needs to write a patch.

Anyone takers?

Mark




-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Support

[Martin Gainty]

java jar bootstrap.jar works fine for me..

is there ANY possible workaround to this daemon bug?

Thanks,
Martin Gainty 
__ 
Disclaimer and confidentiality note 
Everything in this e-mail and any attachments relates to the official business 
of Sender. This transmission is of a confidential nature and Sender does not 
endorse distribution to any party other than intended recipient. Sender does 
not necessarily endorse content contained within this transmission. 


 Date: Fri, 3 Oct 2008 09:10:00 +0100
 From: [EMAIL PROTECTED]
 To: users@tomcat.apache.org
 Subject: Re: Support
 
 Caldarale, Charles R wrote:
  The msvcr71.dll file (not msvci70.dll, whatever that is) is required to run 
  the Tomcat service launcher, but not needed when Tomcat is run via scripts.
  
  The reason it didn't show up on JRE/JDK 5 is because installation of that 
  JVM version slams a copy of the DLL into C:\windows\system32, regardless of 
  what impact that might have on the system.  JRE/JDK 6 installation follows 
  the rules published by Microsoft, and keeps the DLL in the JVM's bin 
  directory.
  
  Tomcat should be distributing the DLL (or otherwise insuring its 
  availability) during installation or setup of the Windows service; however, 
  no one's been able to convince the committers of that yet.
 
 In summary:
 - the JVM requires the dll - this is a JVM bug (Sun do not agree)
 - the best place to hack around this is when the jvm.dll is loaded (ie the
 daemon project)
 - a nice summary and all the pointers needed to fix this are here
 http://www.duckware.com/tech/java6msvcr71.html
 - There is a daemon issue for this
 https://issues.apache.org/jira/browse/DAEMON-110
 - Someone with C skills (not me - mine are terrible) needs to write a patch.
 
 Anyone takers?
 
 Mark
 
 
 
 
 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

_
Stay up to date on your PC, the Web, and your mobile phone with Windows Live.
http://clk.atdmt.com/MRT/go/msnnkwxp1020093185mrt/direct/01/

Re: Support

[Johnny Kewl]

- Original Message - 
From: Martin Gainty [EMAIL PROTECTED]

To: Tomcat Users List users@tomcat.apache.org
Sent: Friday, October 03, 2008 2:37 PM
Subject: RE: Support



java jar bootstrap.jar works fine for me..

is there ANY possible workaround to this daemon bug?

Thanks,
Martin Gainty
__
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official 
business of Sender. This transmission is of a confidential nature and Sender 
does not endorse distribution to any party other than intended recipient. 
Sender does not necessarily endorse content contained within this 
transmission.




Date: Fri, 3 Oct 2008 09:10:00 +0100
From: [EMAIL PROTECTED]
To: users@tomcat.apache.org
Subject: Re: Support

Caldarale, Charles R wrote:
 The msvcr71.dll file (not msvci70.dll, whatever that is) is required to 
 run the Tomcat service launcher, but not needed when Tomcat is run via 
 scripts.


 The reason it didn't show up on JRE/JDK 5 is because installation of 
 that JVM version slams a copy of the DLL into C:\windows\system32, 
 regardless of what impact that might have on the system.  JRE/JDK 6 
 installation follows the rules published by Microsoft, and keeps the DLL 
 in the JVM's bin directory.


 Tomcat should be distributing the DLL (or otherwise insuring its 
 availability) during installation or setup of the Windows service; 
 however, no one's been able to convince the committers of that yet.


In summary:
- the JVM requires the dll - this is a JVM bug (Sun do not agree)
- the best place to hack around this is when the jvm.dll is loaded (ie the
daemon project)
- a nice summary and all the pointers needed to fix this are here
http://www.duckware.com/tech/java6msvcr71.html
- There is a daemon issue for this
https://issues.apache.org/jira/browse/DAEMON-110
- Someone with C skills (not me - mine are terrible) needs to write a 
patch.


Anyone takers?

Mark


I think the only way is to open up procrun in VC and recompile it with the 
static version of the msvcr71.dll which is msvcr71.lib... then nothing else 
changes.

procrun will be slightly larger...

The Duckware guy is really pissed off... but as I see it Sun has been fixing 
the issue and is no longer able to because of MS's new dll hell policies.
So its MS's fault... but in fairness MS has always warned people... save 
space make it small and leave the libs external, and you may have pain ;)


Its 340k... nowadays no biggy...

Just needs a recompile and it should take the procrun guy all of 10 seconds 
to do ;)
Any other way fixes the TC issue... but the problem then remains... procrun 
is broken.


... I think

In the means time... if you use Java 6, the service will break, but luckily 
the msvcr71.dll you need is in the Java bin.
The real problem is that its going to catch developers, because unless they 
told about it, they probably running Adobe, or something else, that like the 
JDK 5 was doing is fixing the system... but at the client the TC Service 
breaks... more embarassing than anything else.


---
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
--- 



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Support

[Johnny Kewl]

- Original Message - 
From: Caldarale, Charles R [EMAIL PROTECTED]

To: Tomcat Users List users@tomcat.apache.org
Sent: Friday, October 03, 2008 3:42 AM
Subject: RE: Support



From: Johnny Kewl [mailto:[EMAIL PROTECTED]
Subject: Re: Support

Normally I always recomment lagging a JRE version as well...
avoid bleeding edge...


JRE/JDK 6 has been around for almost two years now, so I don't think the 
1.6.0_07 download is at all risky.  On the other hand, the 1.6.0_10 release 
really is bleeding edge.  Sun's current versioning scheme does border on the 
incomprehensible...


- Chuck

Time flies... damn.
You right its not really a TC server issue, the thing thats at the back of 
my mind is that companies are lazy... and I havnt checked lately, but 
hopefully Apple has sent out some scouts an discovered theres a new JDK ;)
In theory JDK 6 targeting 5 should be a safe bet, and on TC it is... but 
Swing and stuff like that, build it targeting 6, and if then try move it 
back to JRE 5... it hurts ;)


TC is almost immune, its a tough product... but what we find its that in the 
IDE we have both JDK 5 and JDK 6 loaded... again not really a TC issue.
Sun really seem to be on a mission... for 10 years they were sleeping, but 
now they moving at dizzy speed, your customers may not be.


---
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
---




-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Support

[Partha Goswami]

which version ?

On Fri, Oct 3, 2008 at 3:50 AM, Angelica Ardila
[EMAIL PROTECTED]wrote:

  Good afternoon, my question is this:

 That version of JDK should I use for the Tomcat 6?

 Thank you very much.

 Angélica Ardila




-- 
Regards
Partha Goswami
President
Global Web-Tech Solution
www.globalwebtechsolution.com

Re: Support

[Angelica Ardila]

The Apache Tomcat version 6

2008/10/2, Partha Goswami [EMAIL PROTECTED]:

 which version ?

 On Fri, Oct 3, 2008 at 3:50 AM, Angelica Ardila
 [EMAIL PROTECTED]wrote:

   Good afternoon, my question is this:
 
  That version of JDK should I use for the Tomcat 6?
 
  Thank you very much.
 
  Angélica Ardila
 



 --
 Regards
 Partha Goswami
 President
 Global Web-Tech Solution
 www.globalwebtechsolution.com




-- 
Cordialmente,

Angélica Ardila

Re: Support

[Partha Goswami]

I asked which version of JDK ?

On Fri, Oct 3, 2008 at 3:56 AM, Angelica Ardila [EMAIL PROTECTED]wrote:

 The Apache Tomcat version 6

 2008/10/2, Partha Goswami [EMAIL PROTECTED]:
 
  which version ?
 
  On Fri, Oct 3, 2008 at 3:50 AM, Angelica Ardila
  [EMAIL PROTECTED]wrote:
 
Good afternoon, my question is this:
  
   That version of JDK should I use for the Tomcat 6?
  
   Thank you very much.
  
   Angélica Ardila
  
 
 
 
  --
  Regards
  Partha Goswami
  President
  Global Web-Tech Solution
  www.globalwebtechsolution.com
 



 --
 Cordialmente,

 Angélica Ardila




-- 
Regards
Partha Goswami
President
Global Web-Tech Solution
www.globalwebtechsolution.com

RE: Support

[Caldarale, Charles R]

On Fri, Oct 3, 2008 at 3:50 AM, Angelica Ardila
[EMAIL PROTECTED]wrote:

 That version of JDK should I use for the Tomcat 6?

Read the release notes:
http://tomcat.apache.org/tomcat-6.0-doc/RELEASE-NOTES.txt

Tomcat 6.0 is designed to run on JSE 5.0 and later.

 - 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 start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Support

[André Warnier]

Angelica Ardila wrote:

 Good afternoon, my question is this:

That version of JDK should I use for the Tomcat 6?

Thank you very much.

Angélica Ardila


Whichever one you like, dear. ;-)

Seriously now :
JDK 6 would probably be best, and JDK 5 should work also.
But if it is only to run Tomcat, the JRE 6 should be enough also.


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Support

[Partha Goswami]

ah, JDK 6.0 has some issue, in WIndows  after installing JDK 6.0  Tomcat
6.0 u need to put msvci70.dll from Jdk folder to bin folder of tomcat ,
that's why i was asking. JDK 5 has no issue,

On Fri, Oct 3, 2008 at 3:59 AM, André Warnier [EMAIL PROTECTED] wrote:

 Angelica Ardila wrote:

  Good afternoon, my question is this:

 That version of JDK should I use for the Tomcat 6?

 Thank you very much.

 Angélica Ardila

  Whichever one you like, dear. ;-)

 Seriously now :
 JDK 6 would probably be best, and JDK 5 should work also.
 But if it is only to run Tomcat, the JRE 6 should be enough also.



 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




-- 
Regards
Partha Goswami
President
Global Web-Tech Solution
www.globalwebtechsolution.com

RE: Support

[Martin Gainty]

   Good afternoon, my question is this:
  
  That version of JDK should I use for the Tomcat 6?
  
  Thank you very much.
  
  Angélica Ardila
  
 Whichever one you like, dear. ;-)

i'll wait for christopher schultz response to this answer

 
 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

_
See how Windows Mobile brings your life together—at home, work, or on the go.
http://clk.atdmt.com/MRT/go/msnnkwxp1020093182mrt/direct/01/

Re: Support

[André Warnier]

Martin Gainty wrote:

 Good afternoon, my question is this:

That version of JDK should I use for the Tomcat 6?

Thank you very much.

Angélica Ardila


Whichever one you like, dear. ;-)


i'll wait for christopher schultz response to this answer


You are already a few off-list exchanges too late for that.
;-)


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Support

[Johnny Kewl]

- Original Message - 
From: Angelica Ardila [EMAIL PROTECTED]

To: users@tomcat.apache.org
Sent: Friday, October 03, 2008 12:20 AM
Subject: Support


Good afternoon, my question is this:

That version of JDK should I use for the Tomcat 6?

Thank you very much.

Angélica Ardila

---

We using TC5/6 with JDK1.5 all the way to JDK 6 beta (10)... no problems.

If you starting out

http://java.sun.com/javase/downloads/index.jsp

2nd item from the top (JDK 6 Update 7)... and the documentation... (Java SE 
6 Documentation)


If you need a dev IDE... its better to go here... 
http://download.netbeans.org/netbeans/6.1/final/

and get the one you want... than use the JDK option with NETBEANS
Because NB is getting huge...
What I do is dowload the PHP version... and then install the TC plugins from 
NB... its quicker than the whole GlassFish thing...


If you not developing and the JRE (SE) 5 or 6 is on the machine already... 
TC is all you need...

You have to have the JDK for the IDE however...

If you on windows, install the JDK to a non standard folder... else it gets 
updated auto... and you dont want that in a dev environment...


... enjoy TC is cool ;)

---
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
--- 




-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Support

[André Warnier]

And by her innocent question, Angelica has brought out the inherent 
personality of a number of people on this list..

Any more takers ?

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Support

[Johnny Kewl]

- Original Message - 
From: André Warnier [EMAIL PROTECTED]

To: Tomcat Users List users@tomcat.apache.org
Sent: Friday, October 03, 2008 12:29 AM
Subject: Re: Support



Angelica Ardila wrote:

 Good afternoon, my question is this:

That version of JDK should I use for the Tomcat 6?

Thank you very much.

Angélica Ardila


Whichever one you like, dear. ;-)


Oh Andre... I think we have a Casanova here ;)... you devil you


Seriously now :
JDK 6 would probably be best, and JDK 5 should work also.
But if it is only to run Tomcat, the JRE 6 should be enough also.


Normally I always recomment lagging a JRE version as well... avoid bleeding 
edge... but these Profiling tools that came in at JDK 6 rc 6 are so good, 
you just have to have it ;)


You devil
---
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
---


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Support

[Caldarale, Charles R]

 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Partha Goswami
 Subject: Re: Support

 ah, JDK 6.0 has some issue, in WIndows  after installing JDK
 6.0  Tomcat
 6.0 u need to put msvci70.dll from Jdk folder to bin folder
 of tomcat ,
 that's why i was asking. JDK 5 has no issue,

The msvcr71.dll file (not msvci70.dll, whatever that is) is required to run the 
Tomcat service launcher, but not needed when Tomcat is run via scripts.

The reason it didn't show up on JRE/JDK 5 is because installation of that JVM 
version slams a copy of the DLL into C:\windows\system32, regardless of what 
impact that might have on the system.  JRE/JDK 6 installation follows the rules 
published by Microsoft, and keeps the DLL in the JVM's bin directory.

Tomcat should be distributing the DLL (or otherwise insuring its availability) 
during installation or setup of the Windows service; however, no one's been 
able to convince the committers of that yet.

 - 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 start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Support

[Caldarale, Charles R]

 From: Johnny Kewl [mailto:[EMAIL PROTECTED]
 Subject: Re: Support

 Normally I always recomment lagging a JRE version as well...
 avoid bleeding edge...

JRE/JDK 6 has been around for almost two years now, so I don't think the 
1.6.0_07 download is at all risky.  On the other hand, the 1.6.0_10 release 
really is bleeding edge.  Sun's current versioning scheme does border on the 
incomprehensible...

 - 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 start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Support and development of versions

[David kerber]

Stephen Nelson-Smith wrote:

Hi,

So, I'm running an app which the development house say *has* to run on
4.1.31.  I'm not especially happy about this, and will try running it
under 4.1.37, but the developers say they *might* be able to get it to
run under 5.5.  I seem to recall a conversation in which I was told
that 5.5 isn't really actively supported or developed any more either.
 Is this the case?

Am I best to try to pressure the  developers to get the system to run
on 6?  Or will 4.1 be sound for a while yet, as long as I can keep on
top of bug/security fixes?
  
4.1.37 is probably your best short-term solution, and work toward 6.x in 
the mid-to-long term.




Thanks,

S.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



  




-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Support and development of versions

[Stephen Nelson-Smith]

On Thu, Feb 28, 2008 at 2:37 PM, David kerber [EMAIL PROTECTED] wrote:
  4.1.37 is probably your best short-term solution, and work toward 6.x in
  the mid-to-long term.

That was my gut feeling.  Could you explain why that is?  Is 5.5 a
wasteland?  I'll need to understand the rationale behind the
recommendation to make it stick with the development team.

S.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Support and development of versions

[Caldarale, Charles R]

 From: Stephen Nelson-Smith [mailto:[EMAIL PROTECTED] 
 Subject: Re: Support and development of versions
 
 Is 5.5 a wasteland?

It's not a wasteland, whereas 5.0 is.  However, the most attention goes
to the current level, while 4.1 and 5.5 activity is pretty much limited
to only serious bug fixes.  You definitely don't want to target for a
level that's already outdated.

 - 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 start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Support and development of versions

[David kerber]

Stephen Nelson-Smith wrote:

On Thu, Feb 28, 2008 at 2:37 PM, David kerber [EMAIL PROTECTED] wrote:
  

 4.1.37 is probably your best short-term solution, and work toward 6.x in
 the mid-to-long term.



That was my gut feeling.  Could you explain why that is?  Is 5.5 a
wasteland?  I'll need to understand the rationale behind the
recommendation to make it stick with the development team.
  
Actually, 5.5.x is quite good and I use it in production, but it's in 
kind of a no-man's land development-wise.  Since 6.x has been around for 
a year or so, it's stable, and it's most likely getting the bulk of the 
development effort, and you know that 5.5.x development is going to be 
stopped before 6.x is, at some point in the future.  If you're porting 
an app from 4.x to something newer anyway, you might as well port to the 
one you know is going to have the longest lifetime, instead of using a 
mid-term version. 

If your app was already written for 5, I'd say stick with that line, but 
I wouldn't do new development or older-version porting to it.


D



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Support and development of versions

[Mark Thomas]

Stephen Nelson-Smith wrote:

On Thu, Feb 28, 2008 at 2:37 PM, David kerber [EMAIL PROTECTED] wrote:

 4.1.37 is probably your best short-term solution, and work toward 6.x in
 the mid-to-long term.


That was my gut feeling.  Could you explain why that is?  Is 5.5 a
wasteland?  I'll need to understand the rationale behind the
recommendation to make it stick with the development team.


Current status is available from:

http://wiki.apache.org/tomcat/TomcatVersions

Mark


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Support and development of versions

[Stephen Nelson-Smith]

On Thu, Feb 28, 2008 at 6:15 PM, Mark Thomas [EMAIL PROTECTED] wrote:

 Stephen Nelson-Smith wrote:
   On Thu, Feb 28, 2008 at 2:37 PM, David kerber [EMAIL PROTECTED] wrote:
4.1.37 is probably your best short-term solution, and work toward 6.x in
the mid-to-long term.
  
   That was my gut feeling.  Could you explain why that is?  Is 5.5 a
   wasteland?  I'll need to understand the rationale behind the
   recommendation to make it stick with the development team.

  Current status is available from:

  http://wiki.apache.org/tomcat/TomcatVersions

Thanks - that's a very handy summary.

Could someone help me  understand the differences between the servlet
and JSP versions?  Do the numbers imply no backward and/or forward
compatibility?  Given that the app I am administering was written some
years ago for 4.1, and I've been told it needs a specific Java version
(1.4.2_11) does this increase the likelihood of substantial rewrites
being needed to run on newer versions of Tomcat?

I'm puzzled - I don't know much about Java - how much changes?  And
why so quickly!?

S.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Support and development of versions

[Jason Pyeron]

 

 -Original Message-
 From: Mark Thomas [mailto:[EMAIL PROTECTED] 
 
 Current status is available from:
 
 http://wiki.apache.org/tomcat/TomcatVersions
 


What does RTC, for the process field stand for?


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron  PD Inc. http://www.pdinc.us -
- Principal Consultant  10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you
have received it in error, purge the message from your system and
notify the sender immediately.  Any other use of the email by you
is prohibited. 


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Support and development of versions

[Caldarale, Charles R]

 From: Stephen Nelson-Smith [mailto:[EMAIL PROTECTED] 
 Subject: Re: Support and development of versions
 
 Could someone help me  understand the differences between the servlet
 and JSP versions?

The servlet and JSP specs are the place to look.  Each document includes
a section on what's changed from earlier versions.
http://jcp.org/aboutJava/communityprocess/mrel/jsr154/index2.html
http://jcp.org/aboutJava/communityprocess/final/jsr245/index.html

 Do the numbers imply no backward and/or forward
 compatibility?

Newer versions of Tomcat should run webapps based on older
specifications without any real difficulty.  Problems arise when webapps
do something container specific, such as depend on bugs fixed in later
versions.  Tomcat configuration has changed significantly, as might be
expected, so don't just blindly copy over your old server.xml and
Context elements when moving up.  Read the Tomcat docs, and modify the
various .xml files that come with the version of Tomcat you're moving
to.

 I've been told it needs a specific Java version (1.4.2_11)

The above is highly likely to be pure BS.  Again, other than webapps
absuing the system by being dependent on bugs or security holes fixed in
later levels, older programs run happily on the latest JVMs (which also
tend to be significantly faster than older ones).

The one significant incompatibility I remember is that classes being
imported must be part of a package.  It was never good practice to use
packageless classes, and at some point in the last few years it became
illegal.

 - 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 start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Support and development of versions

[Jason Pyeron]

 

 -Original Message-
 From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] 
 Sent: Thursday, February 28, 2008 16:12
 To: Tomcat Users List
 Subject: RE: Support and development of versions
 
  From: Stephen Nelson-Smith [mailto:[EMAIL PROTECTED] 
  Subject: Re: Support and development of versions
  
  Could someone help me  understand the differences between 
 the servlet
  and JSP versions?
 
 The servlet and JSP specs are the place to look.  Each 
 document includes
 a section on what's changed from earlier versions.
 http://jcp.org/aboutJava/communityprocess/mrel/jsr154/index2.html
 http://jcp.org/aboutJava/communityprocess/final/jsr245/index.html
 
  Do the numbers imply no backward and/or forward
  compatibility?
 
 Newer versions of Tomcat should run webapps based on older
 specifications without any real difficulty.  Problems arise 
 when webapps
 do something container specific, such as depend on bugs fixed in later
 versions.  Tomcat configuration has changed significantly, as might be
 expected, so don't just blindly copy over your old server.xml and
 Context elements when moving up.  Read the Tomcat docs, and 
 modify the
 various .xml files that come with the version of Tomcat you're moving
 to.
 
  I've been told it needs a specific Java version (1.4.2_11)
 
 The above is highly likely to be pure BS.  

It might not be, but it should not be.

http://java.sun.com/j2se/1.5.0/compatibility.html
and
http://java.sun.com/javase/6/webnotes/compatibility.html




-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron  PD Inc. http://www.pdinc.us -
- Principal Consultant  10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you
have received it in error, purge the message from your system and
notify the sender immediately.  Any other use of the email by you
is prohibited. 


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Support and development of versions

[Mark Thomas]

Jason Pyeron wrote:
 


-Original Message-
From: Mark Thomas [mailto:[EMAIL PROTECTED] 


Current status is available from:

http://wiki.apache.org/tomcat/TomcatVersions




What does RTC, for the process field stand for?


Review Then Commit. It means every patch must get at least 3 more +1 votes 
than -1 votes (from the committers) before it can be applied to that branch.


Mark


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Support and development of versions

[Caldarale, Charles R]

 From: Jason Pyeron [mailto:[EMAIL PROTECTED] 
 Subject: RE: Support and development of versions
 
 It might not be, but it should not be.
 http://java.sun.com/j2se/1.5.0/compatibility.html
 and
 http://java.sun.com/javase/6/webnotes/compatibility.html

Other than enum becoming a reserved word, did you see anything in there
that was significant?

 - 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 start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]