[Bug 65377] New: Migrate Jasper's use of deprecated boxed primitive constructors

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65377

Bug ID: 65377
   Summary: Migrate Jasper's use of deprecated boxed primitive
constructors
   Product: Tomcat 9
   Version: 9.0.46
  Hardware: PC
Status: NEW
  Severity: normal
  Priority: P2
 Component: Jasper
  Assignee: dev@tomcat.apache.org
  Reporter: a...@labkey.com
  Target Milestone: -

JDK 9 deprecated all Boolean, Byte, Character, Double, Float, Integer, Long,
and Short constructors, see
https://www.oracle.com/java/technologies/javase/9-deprecated-features.html#JDK-8065614.
JDK 16 then marked them as forRemoval=true.

Jasper generates code that uses these deprecated constructors, when binding tag
attributes to setters. This results in fairly adamant warnings when compiling
on javac (not sure how JDT reacts). For now, the generated code compiles and
the warnings could be disabled, but they're clearly telling us the JDK will
remove support in the future.

JDK documentation suggests replacing use of boxed primitive constructors with
auto-boxing or valueOf() static factory methods. JspUtil.java appears to
contain the code that needs adjusting.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 8.5.68

[Christopher Schultz]

Igal,

On 6/14/21 10:59, Igal Sapir wrote:

Chris,

On Mon, Jun 14, 2021 at 7:32 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:



Tests on Windows 10 passed except for a timing issue which wasn't
reproducible on a second run.


* Junit Tests: FAILED
*
* Tests that failed:
* org.apache.catalina.tribes.group.TestGroupChannelMemberArrival.APR.txt
* org.apache.catalina.tribes.group.TestGroupChannelMemberArrival.NIO.txt
* org.apache.catalina.tribes.group.TestGroupChannelMemberArrival.NIO2.txt
*
org.apache.catalina.tribes.group.TestGroupChannelSenderConnections.APR.txt
*
org.apache.catalina.tribes.group.TestGroupChannelSenderConnections.NIO.txt
*
org.apache.catalina.tribes.group.TestGroupChannelSenderConnections.NIO2.txt
* org.apache.catalina.tribes.group.TestGroupChannelStartStop.APR.txt
* org.apache.catalina.tribes.group.TestGroupChannelStartStop.NIO.txt
* org.apache.catalina.tribes.group.TestGroupChannelStartStop.NIO2.txt
*

org.apache.catalina.tribes.group.interceptors.TestNonBlockingCoordinator.APR.txt
*

org.apache.catalina.tribes.group.interceptors.TestNonBlockingCoordinator.NIO.txt
*

org.apache.catalina.tribes.group.interceptors.TestNonBlockingCoordinator.NIO2.txt
*
org.apache.catalina.tribes.group.interceptors.TestOrderInterceptor.APR.txt
*
org.apache.catalina.tribes.group.interceptors.TestOrderInterceptor.NIO.txt
*
org.apache.catalina.tribes.group.interceptors.TestOrderInterceptor.NIO2.txt
*

org.apache.catalina.tribes.group.interceptors.TestTcpFailureDetector.APR.txt
*

org.apache.catalina.tribes.group.interceptors.TestTcpFailureDetector.NIO.txt
*

org.apache.catalina.tribes.group.interceptors.TestTcpFailureDetector.NIO2.txt
* org.apache.tomcat.util.net.openssl.ciphers.TestCipher.APR.txt
* org.apache.tomcat.util.net.openssl.ciphers.TestCipher.NIO.txt
* org.apache.tomcat.util.net.openssl.ciphers.TestCipher.NIO2.txt
*
org.apache.tomcat.util.net
.openssl.ciphers.TestOpenSSLCipherConfigurationParser.APR.txt
*
org.apache.tomcat.util.net
.openssl.ciphers.TestOpenSSLCipherConfigurationParser.NIO.txt
*
org.apache.tomcat.util.net
.openssl.ciphers.TestOpenSSLCipherConfigurationParser.NIO2.txt



I've been having failed tests for a while now with the timing of the
tribes.** packages on Ubuntu laptop (not a VM).  At first I was concerned
but I believe that it's a non-issue.  Recently I added the following to
build.properties to skip those tests:

test.exclude=org/apache/catalina/tribes/group/Test*,org/apache/catalina/tribes/group/interceptors/Test*


Yeah, I could probably do that. Interestingly enough, my Windows 10 VM 
did *not* fail these tests, so that's nice.


I didn't test APR on Windows, though, I don't think. I don't think I had 
the right DLLs in the right places.


I'd really like to get the OpenSSL ones running properly. Something 
about telling the test suite which cipher suites are/aren't available.


-chris

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

Re: [External] : Re: JDK 17 is now in Rampdown Phase One

[Rory O'Donnell]

Hi Rick,

Excellent feedback , I suggest you send this information to the 
security-dev [1] mailing list to demonstrate the impact

it is having on you and others. Make sure to subscribe first.

Rgds,Rory

[1] security-...@openjdk.java.net 

On 14/06/2021 16:43, Rick Hillegas wrote:

Hi Rory,

Copying the Tomcat developer community since this issue probably 
affects them as well.


When I tried to build Derby with the Rampdown Phase One build of open 
JDK 17 (17-ea+26-2439), I saw many warnings related to the deprecation 
of Security Manager classes and methods, undoubtedly the consequence 
of JEP 411 (https://openjdk.java.net/jeps/411). Derby, like Tomcat, 
embraced the Security Manager early on. Permissions checks were 
rototilled across the whole code base. Our distributions ship with 
several template policy files, which we encourage users to customize 
for their environments. The "Configuring Java Security" section of our 
Security Guide explains how to do this 
(https://urldefense.com/v3/__https://db.apache.org/derby/docs/10.15/security/index.html__;!!GqivPVa7Brio!Ir7H5RCIuIIcRhganretmYcvHoP432X-jV4dVUNlqO1EmvYkTvkdZvEBdtBh9kcdocM$ 
).


My build only reported the first 100 warnings. It is likely that there 
are many more.


Having read the summary of JEP 411, I understand the motivation for 
this change. However, I don't understand how applications like Tomcat 
and Derby are supposed to respond to the new blizzard of deprecation 
warnings. For instance, is there a replacement for the deprecated 
AccessController.doPrivileged() method? Or are we supposed to simply 
disable this deprecation check? Is there some security expert whom we 
should contact about this change and how to mitigate its effects?


Thanks,
-Rick


On 6/14/21 2:18 AM, Rory O'Donnell wrote:


Hi Rick,
*
Per the JDK 17 schedule , we are in Rampdown Phase One [1].*

**Please advise if you find any issues while testing the latest Early 
Access builds**.**


 * Schedule:
 o *2021/06/10   Rampdown Phase One*
 o 2021/07/15    Rampdown Phase Two
 o 2021/08/05    Initial Release Candidate
 o 2021/08/19    Final Release Candidate
 o 2021/09/14    General Availability

The overall feature set is frozen. No further JEPs will be targeted 
to this release.


**

 * Important JEPs have been integrated – Attention Required!
 * *JEP 411: **Deprecate the Security Manager for
   Removal*
 o Deprecate, for removal, most Security Manager related classes
   and methods.
 o Warning message at startup if the Security Manager is enabled on
   the command line.
 o Warning message at run time if a Java application or library
   installs a Security Manager dynamically.
 o Deprecation is in concert with the legacy Applet API (JEP 398).
 * *JEP 407: **Remove RMI Activation*
 o Removal the Remote Method Invocation (RMI) Activation mechanism,
   while preserving the rest of RMI.
 o It was deprecated for removal by JEP
   385in Java SE 15.
 * *JEP 403: **Strongly Encapsulate JDK
   Internals*
 o Strongly encapsulate all internal elements of the JDK, except
   for critical internal APIs such as /sun.misc.Unsafe/.
 o It will no longer be possible to relax the strong encapsulation
   of internal elements via a single command-line option.

 * Other features integrated in JDK 17:
 o *JEP 306: **Restore Always-Strict Floating-Point
   Semantics*
 o JEP 356: Enhanced Pseudo-Random Number
   Generators
 o JEP 382: New macOS Rendering
   Pipeline
 o JEP 391: macOS/AArch64 Port
 o JEP 398: Deprecate the Applet API for
   Removal
 o *JEP 406: **Pattern Matching for switch
   (Preview)*
 o JEP 409: Sealed Classes
 o JEP 410: Remove the Experimental AOT and JIT
   Compiler
 o JEP 412: Foreign Function & Memory API
   (Incubator)
 o *JEP 414: **Vector API (Second
   Incubator)*
 o *JEP 415: **Context-Specific Deserialization
   Filters*

*OpenJDK 17 Early Access build 26 is available at 
**https://urldefense.com/v3/__https://jdk.java.net/17*__;Kg!!GqivPVa7Brio!Ir7H5RCIuIIcRhganretmYcvHoP432X-jV4dVUNlqO1EmvYkTvkdZvEBdtBhLKySzR0$ 



 * These early-access , open-source builds are provided under the
 o GNU 

Re: JDK 17 is now in Rampdown Phase One

[Rick Hillegas]

Hi Rory,

Copying the Tomcat developer community since this issue probably affects 
them as well.


When I tried to build Derby with the Rampdown Phase One build of open 
JDK 17 (17-ea+26-2439), I saw many warnings related to the deprecation 
of Security Manager classes and methods, undoubtedly the consequence of 
JEP 411 (https://openjdk.java.net/jeps/411). Derby, like Tomcat, 
embraced the Security Manager early on. Permissions checks were 
rototilled across the whole code base. Our distributions ship with 
several template policy files, which we encourage users to customize for 
their environments. The "Configuring Java Security" section of our 
Security Guide explains how to do this 
(https://db.apache.org/derby/docs/10.15/security/index.html).


My build only reported the first 100 warnings. It is likely that there 
are many more.


Having read the summary of JEP 411, I understand the motivation for this 
change. However, I don't understand how applications like Tomcat and 
Derby are supposed to respond to the new blizzard of deprecation 
warnings. For instance, is there a replacement for the deprecated 
AccessController.doPrivileged() method? Or are we supposed to simply 
disable this deprecation check? Is there some security expert whom we 
should contact about this change and how to mitigate its effects?


Thanks,
-Rick


On 6/14/21 2:18 AM, Rory O'Donnell wrote:


Hi Rick,
*
Per the JDK 17 schedule , we are in Rampdown Phase One [1].*

**Please advise if you find any issues while testing the latest Early 
Access builds**.**


 * Schedule:
 o *2021/06/10   Rampdown Phase One*
 o 2021/07/15    Rampdown Phase Two
 o 2021/08/05    Initial Release Candidate
 o 2021/08/19    Final Release Candidate
 o 2021/09/14    General Availability

The overall feature set is frozen. No further JEPs will be targeted to 
this release.


**

 * Important JEPs have been integrated – Attention Required!
 * *JEP 411: **Deprecate the Security Manager for
   Removal*
 o Deprecate, for removal, most Security Manager related classes
   and methods.
 o Warning message at startup if the Security Manager is enabled on
   the command line.
 o Warning message at run time if a Java application or library
   installs a Security Manager dynamically.
 o Deprecation is in concert with the legacy Applet API (JEP 398).
 * *JEP 407: **Remove RMI Activation*
 o Removal the Remote Method Invocation (RMI) Activation mechanism,
   while preserving the rest of RMI.
 o It was deprecated for removal by JEP
   385in Java SE 15.
 * *JEP 403: **Strongly Encapsulate JDK
   Internals*
 o Strongly encapsulate all internal elements of the JDK, except
   for critical internal APIs such as /sun.misc.Unsafe/.
 o It will no longer be possible to relax the strong encapsulation
   of internal elements via a single command-line option.

 * Other features integrated in JDK 17:
 o *JEP 306: **Restore Always-Strict Floating-Point
   Semantics*
 o JEP 356: Enhanced Pseudo-Random Number
   Generators
 o JEP 382: New macOS Rendering
   Pipeline
 o JEP 391: macOS/AArch64 Port
 o JEP 398: Deprecate the Applet API for
   Removal
 o *JEP 406: **Pattern Matching for switch
   (Preview)*
 o JEP 409: Sealed Classes
 o JEP 410: Remove the Experimental AOT and JIT
   Compiler
 o JEP 412: Foreign Function & Memory API
   (Incubator)
 o *JEP 414: **Vector API (Second
   Incubator)*
 o *JEP 415: **Context-Specific Deserialization
   Filters*

*OpenJDK 17 Early Access build 26 is available at 
**https://jdk.java.net/17*


 * These early-access , open-source builds are provided under the
 o GNU General Public License, version 2, with the Classpath
Exception

 * Release Notes are available at
https://jdk.java.net/17/release-notes

 * Changes in recent builds that maybe of interest:
 * *Build 26:*
 o JDK-8268241: deprecate JVM TI Heap functions 1.0
 o JDK-8266846: Add java.time.InstantSource
 o JDK-8248268: Support KWP in addition to KW
 o JDK-8204686: Dynamic parallel reference processing support for
   Parallel GC
 o JDK-8259530: Generated docs contain MIT/GPL-licenced works
   without reproducing the licence [*Reported by Apache Maven*]
 o 

Re: [VOTE] Release Apache Tomcat 8.5.68

[Igal Sapir]

Chris,

On Mon, Jun 14, 2021 at 7:32 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> 
> Tests on Windows 10 passed except for a timing issue which wasn't
> reproducible on a second run.
>
> 
> * Junit Tests: FAILED
> *
> * Tests that failed:
> * org.apache.catalina.tribes.group.TestGroupChannelMemberArrival.APR.txt
> * org.apache.catalina.tribes.group.TestGroupChannelMemberArrival.NIO.txt
> * org.apache.catalina.tribes.group.TestGroupChannelMemberArrival.NIO2.txt
> *
> org.apache.catalina.tribes.group.TestGroupChannelSenderConnections.APR.txt
> *
> org.apache.catalina.tribes.group.TestGroupChannelSenderConnections.NIO.txt
> *
> org.apache.catalina.tribes.group.TestGroupChannelSenderConnections.NIO2.txt
> * org.apache.catalina.tribes.group.TestGroupChannelStartStop.APR.txt
> * org.apache.catalina.tribes.group.TestGroupChannelStartStop.NIO.txt
> * org.apache.catalina.tribes.group.TestGroupChannelStartStop.NIO2.txt
> *
>
> org.apache.catalina.tribes.group.interceptors.TestNonBlockingCoordinator.APR.txt
> *
>
> org.apache.catalina.tribes.group.interceptors.TestNonBlockingCoordinator.NIO.txt
> *
>
> org.apache.catalina.tribes.group.interceptors.TestNonBlockingCoordinator.NIO2.txt
> *
> org.apache.catalina.tribes.group.interceptors.TestOrderInterceptor.APR.txt
> *
> org.apache.catalina.tribes.group.interceptors.TestOrderInterceptor.NIO.txt
> *
> org.apache.catalina.tribes.group.interceptors.TestOrderInterceptor.NIO2.txt
> *
>
> org.apache.catalina.tribes.group.interceptors.TestTcpFailureDetector.APR.txt
> *
>
> org.apache.catalina.tribes.group.interceptors.TestTcpFailureDetector.NIO.txt
> *
>
> org.apache.catalina.tribes.group.interceptors.TestTcpFailureDetector.NIO2.txt
> * org.apache.tomcat.util.net.openssl.ciphers.TestCipher.APR.txt
> * org.apache.tomcat.util.net.openssl.ciphers.TestCipher.NIO.txt
> * org.apache.tomcat.util.net.openssl.ciphers.TestCipher.NIO2.txt
> *
> org.apache.tomcat.util.net
> .openssl.ciphers.TestOpenSSLCipherConfigurationParser.APR.txt
> *
> org.apache.tomcat.util.net
> .openssl.ciphers.TestOpenSSLCipherConfigurationParser.NIO.txt
> *
> org.apache.tomcat.util.net
> .openssl.ciphers.TestOpenSSLCipherConfigurationParser.NIO2.txt
>

I've been having failed tests for a while now with the timing of the
tribes.** packages on Ubuntu laptop (not a VM).  At first I was concerned
but I believe that it's a non-issue.  Recently I added the following to
build.properties to skip those tests:

test.exclude=org/apache/catalina/tribes/group/Test*,org/apache/catalina/tribes/group/interceptors/Test*

Best,

Igal



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

Re: [VOTE] Release Apache Tomcat 8.5.68

[Christopher Schultz]

Mark,

On 6/11/21 16:55, Mark Thomas wrote:

On 11/06/2021 20:20, Christopher Schultz wrote:

=Not a vote=

I have an issue on Windows; I'd like some feedback.

On 6/11/21 10:01, Christopher Schultz wrote:

The proposed Apache Tomcat 8.5.68 release is now available for voting.

The notable changes compared to the (cancelled) 8.5.67 release is:

- Windows installer / uninstaller are now properly-signed.

The notable changes compared to the 8.5.66 release are:

- Improve robustness of HTTP/2 HPACK decoding

- Improvements to the handling of the Transfer-Encoding header

- Review code used to generate Java source from JSPs and tags and remove
    code found to be unnecessary.

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://ci.apache.org/projects/tomcat/tomcat-8.5.x/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.68/

The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1317/

The tag is:
https://github.com/apache/tomcat/tree/8.5.68
06846f94cda226d1ed0ff7fe05faff177d5b20b6

The proposed 8.5.68 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 8.5.68


Running the unit tests on Windows, I have a failure in the 
org.apache.catalina.core.TestAsyncContextImpl.NIO test:


Testsuite: org.apache.catalina.core.TestAsyncContextImpl
Tests run: 70, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 
69.859 sec


[]
Testcase: testBug50352 took 2.982 sec
 FAILED
Uri: /, Status: 200, Time: 2836 duration is not >= 2900
junit.framework.AssertionFailedError: Uri: /, Status: 200, Time: 2836 
duration is not >= 2900
 at 
org.apache.catalina.valves.TesterAccessLogValve.validateAccessLog(TesterAccessLogValve.java:90) 

 at 
org.apache.catalina.core.TestAsyncContextImpl.testBug50352(TestAsyncContextImpl.java:1140) 




This is running on a VirtualBox Windows 10 VM. Is this just a case of 
the JVM on Windows not implementing ms-perfect delays and/or 
time-keeping?


Looks like it, yes. The values are close enough that I wouldn't worry 
about them. With VMware Workstation I often find it is the other way. 
The tests fail because the timeouts don't happen fast enough.


Thanks for that.

Would you be able to run the TCK against this release candidate? I need 
to add that to my toolbox as well, maybe for the next release.


Thanks,
-chris

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

Re: [VOTE] Release Apache Tomcat 8.5.68

[Christopher Schultz]

All,

On 6/11/21 10:01, Christopher Schultz wrote:

The proposed Apache Tomcat 8.5.68 release is now available for voting.

The notable changes compared to the (cancelled) 8.5.67 release is:

- Windows installer / uninstaller are now properly-signed.

The notable changes compared to the 8.5.66 release are:

- Improve robustness of HTTP/2 HPACK decoding

- Improvements to the handling of the Transfer-Encoding header

- Review code used to generate Java source from JSPs and tags and remove
    code found to be unnecessary.

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://ci.apache.org/projects/tomcat/tomcat-8.5.x/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.68/

The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1317/

The tag is:
https://github.com/apache/tomcat/tree/8.5.68
06846f94cda226d1ed0ff7fe05faff177d5b20b6

The proposed 8.5.68 release is:
[ ] Broken - do not release
[X] Stable - go ahead and release as 8.5.68


Works on a development application without anything fancy. Unit tests 
pass on Linux, other than those listed below (which I expect to fail in 
this environment).


Tests on Windows 10 passed except for a timing issue which wasn't 
reproducible on a second run.


-chris

Details:

* Environment
*  Java (build): openjdk version "1.8.0_292" OpenJDK Runtime 
Environment (build 1.8.0_292-8u292-b10-0+deb9u1-b10) OpenJDK 64-Bit 
Server VM (build 25.292-b10, mixed mode)
*  Java (test): openjdk version "1.8.0_292" OpenJDK Runtime 
Environment (build 1.8.0_292-8u292-b10-0+deb9u1-b10) OpenJDK 64-Bit 
Server VM (build 25.292-b10, mixed mode)

*  OS:   Linux 4.19.0-16-amd64 x86_64
*  cc:   cc (Debian 8.3.0-6) 8.3.0
*  make: GNU Make 4.2.1
*  OpenSSL:  OpenSSL 1.1.1 11 Sep 2018
*  APR:  1.6.5
*
* Valid SHA-512 signature for apache-tomcat-8.5.68.zip
* Valid GPG signature for apache-tomcat-8.5.68.zip
* Valid SHA-512 signature for apache-tomcat-8.5.68.tar.gz
* Valid GPG signature for apache-tomcat-8.5.68.tar.gz
* Valid SHA-512 signature for apache-tomcat-8.5.68.exe
* Valid GPG signature for apache-tomcat-8.5.68.exe
* Valid SHA512 signature for apache-tomcat-8.5.68-src.zip
* Valid GPG signature for apache-tomcat-8.5.68-src.zip
* Valid SHA512 signature for apache-tomcat-8.5.68-src.tar.gz
* Valid GPG signature for apache-tomcat-8.5.68-src.tar.gz
*
* Binary Zip and tarball: Same
* Source Zip and tarball: Same
*
* Building dependencies returned: 0
* tcnative builds cleanly
* Tomcat builds cleanly
* Junit Tests: FAILED
*
* Tests that failed:
* org.apache.catalina.tribes.group.TestGroupChannelMemberArrival.APR.txt
* org.apache.catalina.tribes.group.TestGroupChannelMemberArrival.NIO.txt
* org.apache.catalina.tribes.group.TestGroupChannelMemberArrival.NIO2.txt
* org.apache.catalina.tribes.group.TestGroupChannelSenderConnections.APR.txt
* org.apache.catalina.tribes.group.TestGroupChannelSenderConnections.NIO.txt
* 
org.apache.catalina.tribes.group.TestGroupChannelSenderConnections.NIO2.txt

* org.apache.catalina.tribes.group.TestGroupChannelStartStop.APR.txt
* org.apache.catalina.tribes.group.TestGroupChannelStartStop.NIO.txt
* org.apache.catalina.tribes.group.TestGroupChannelStartStop.NIO2.txt
* 
org.apache.catalina.tribes.group.interceptors.TestNonBlockingCoordinator.APR.txt
* 
org.apache.catalina.tribes.group.interceptors.TestNonBlockingCoordinator.NIO.txt
* 
org.apache.catalina.tribes.group.interceptors.TestNonBlockingCoordinator.NIO2.txt

* org.apache.catalina.tribes.group.interceptors.TestOrderInterceptor.APR.txt
* org.apache.catalina.tribes.group.interceptors.TestOrderInterceptor.NIO.txt
* 
org.apache.catalina.tribes.group.interceptors.TestOrderInterceptor.NIO2.txt
* 
org.apache.catalina.tribes.group.interceptors.TestTcpFailureDetector.APR.txt
* 
org.apache.catalina.tribes.group.interceptors.TestTcpFailureDetector.NIO.txt
* 
org.apache.catalina.tribes.group.interceptors.TestTcpFailureDetector.NIO2.txt

* org.apache.tomcat.util.net.openssl.ciphers.TestCipher.APR.txt
* org.apache.tomcat.util.net.openssl.ciphers.TestCipher.NIO.txt
* org.apache.tomcat.util.net.openssl.ciphers.TestCipher.NIO2.txt
* 
org.apache.tomcat.util.net.openssl.ciphers.TestOpenSSLCipherConfigurationParser.APR.txt
* 
org.apache.tomcat.util.net.openssl.ciphers.TestOpenSSLCipherConfigurationParser.NIO.txt
* 
org.apache.tomcat.util.net.openssl.ciphers.TestOpenSSLCipherConfigurationParser.NIO2.txt


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

Re: [External] : Re: JDK 17 is now in Rampdown Phase One

[Rory O'Donnell]

Excellent, thank you.
On 14/06/2021 13:47, Martin Grigorov wrote:

Same for JDK 18-ea+1-7 !

Regards,
Martin

On Mon, Jun 14, 2021 at 2:35 PM Martin Grigorov > wrote:


Hi Rory,

Apache Tomcat's build and tests pass successfully with
JDK 17-ea+26-2439 on Linux x86_64 and aarch64 !

Regards,
Martin

On Mon, Jun 14, 2021 at 12:56 PM Rory O'Donnell
mailto:rory.odonn...@oracle.com>> wrote:


Hi Mark,

*Per the JDK 17 schedule , we are in Rampdown Phase One [1].*

**Please advise if you find any issues while testing the
latest Early
Access builds**.**

  * Schedule:
      o *2021/06/10   Rampdown Phase One*
      o 2021/07/15    Rampdown Phase Two
      o 2021/08/05    Initial Release Candidate
      o 2021/08/19    Final Release Candidate
      o 2021/09/14    General Availability

The overall feature set is frozen. No further JEPs will be
targeted to
this release.

**

  * Important JEPs have been integrated – Attention Required!
  * *JEP 411: **Deprecate the Security Manager for
    Removal*>
      o Deprecate, for removal, most Security Manager related
classes
        and methods.
      o Warning message at startup if the Security Manager is
enabled on
        the command line.
      o Warning message at run time if a Java application or
library
        installs a Security Manager dynamically.
      o Deprecation is in concert with the legacy Applet API
(JEP 398).
  * *JEP 407: **Remove RMI
Activation*>
      o Removal the Remote Method Invocation (RMI) Activation
mechanism,
        while preserving the rest of RMI.
      o It was deprecated for removal by JEP
        385>in Java SE 15.
  * *JEP 403: **Strongly Encapsulate JDK
    Internals*>
      o Strongly encapsulate all internal elements of the JDK,
except
        for critical internal APIs such as /sun.misc.Unsafe/.
      o It will no longer be possible to relax the strong
encapsulation
        of internal elements via a single command-line option.

  * Other features integrated in JDK 17:
      o *JEP 306: **Restore Always-Strict Floating-Point
        Semantics*>
      o JEP 356: Enhanced Pseudo-Random Number
        Generators>
      o JEP 382: New macOS Rendering
        Pipeline>
      o JEP 391: macOS/AArch64
Port>
      o JEP 398: Deprecate the Applet API for
        Removal>
      o *JEP 406: **Pattern Matching for switch
        (Preview)*>
      o JEP 409: Sealed
Classes>
      o JEP 410: Remove the Experimental AOT and JIT
        Compiler>
      o JEP 412: Foreign Function & Memory API
        (Incubator)>
      o *JEP 414: **Vector API (Second
        Incubator)*>
      o *JEP 415: **Context-Specific Deserialization
        Filters*>

*OpenJDK 17 Early Access build 26 is available at
**https://jdk.java.net/17*

>

  * These early-access , open-source builds are provided under the
      o GNU General Public License, version 2, with the 

Re: JDK 17 is now in Rampdown Phase One

[Martin Grigorov]

Same for JDK 18-ea+1-7 !

Regards,
Martin

On Mon, Jun 14, 2021 at 2:35 PM Martin Grigorov 
wrote:

> Hi Rory,
>
> Apache Tomcat's build and tests pass successfully with JDK 17-ea+26-2439
> on Linux x86_64 and aarch64 !
>
> Regards,
> Martin
>
> On Mon, Jun 14, 2021 at 12:56 PM Rory O'Donnell 
> wrote:
>
>>
>> Hi Mark,
>>
>> *Per the JDK 17 schedule , we are in Rampdown Phase One [1].*
>>
>> **Please advise if you find any issues while testing the latest Early
>> Access builds**.**
>>
>>   * Schedule:
>>   o *2021/06/10   Rampdown Phase One*
>>   o 2021/07/15Rampdown Phase Two
>>   o 2021/08/05Initial Release Candidate
>>   o 2021/08/19Final Release Candidate
>>   o 2021/09/14General Availability
>>
>> The overall feature set is frozen. No further JEPs will be targeted to
>> this release.
>>
>> **
>>
>>   * Important JEPs have been integrated – Attention Required!
>>   * *JEP 411: **Deprecate the Security Manager for
>> Removal*
>>   o Deprecate, for removal, most Security Manager related classes
>> and methods.
>>   o Warning message at startup if the Security Manager is enabled on
>> the command line.
>>   o Warning message at run time if a Java application or library
>> installs a Security Manager dynamically.
>>   o Deprecation is in concert with the legacy Applet API (JEP 398).
>>   * *JEP 407: **Remove RMI Activation*
>>   o Removal the Remote Method Invocation (RMI) Activation mechanism,
>> while preserving the rest of RMI.
>>   o It was deprecated for removal by JEP
>> 385in Java SE 15.
>>   * *JEP 403: **Strongly Encapsulate JDK
>> Internals*
>>   o Strongly encapsulate all internal elements of the JDK, except
>> for critical internal APIs such as /sun.misc.Unsafe/.
>>   o It will no longer be possible to relax the strong encapsulation
>> of internal elements via a single command-line option.
>>
>>   * Other features integrated in JDK 17:
>>   o *JEP 306: **Restore Always-Strict Floating-Point
>> Semantics*
>>   o JEP 356: Enhanced Pseudo-Random Number
>> Generators
>>   o JEP 382: New macOS Rendering
>> Pipeline
>>   o JEP 391: macOS/AArch64 Port
>>   o JEP 398: Deprecate the Applet API for
>> Removal
>>   o *JEP 406: **Pattern Matching for switch
>> (Preview)*
>>   o JEP 409: Sealed Classes
>>   o JEP 410: Remove the Experimental AOT and JIT
>> Compiler
>>   o JEP 412: Foreign Function & Memory API
>> (Incubator)
>>   o *JEP 414: **Vector API (Second
>> Incubator)*
>>   o *JEP 415: **Context-Specific Deserialization
>> Filters*
>>
>> *OpenJDK 17 Early Access build 26 is available at
>> **https://jdk.java.net/17*
>>
>>   * These early-access , open-source builds are provided under the
>>   o GNU General Public License, version 2, with the Classpath
>> Exception
>>
>>   * Release Notes are available at
>> https://jdk.java.net/17/release-notes<
>> https://jdk.java.net/17/release-notes>
>>
>>   * Changes in recent builds that maybe of interest:
>>   * *Build 26:*
>>   o JDK-8268241: deprecate JVM TI Heap functions 1.0
>>   o JDK-8266846: Add java.time.InstantSource
>>   o JDK-8248268: Support KWP in addition to KW
>>   o JDK-8204686: Dynamic parallel reference processing support for
>> Parallel GC
>>   o JDK-8259530: Generated docs contain MIT/GPL-licenced works
>> without reproducing the licence [*Reported by Apache Maven*]
>>   o JDK-8266766: Arrays of types that cannot be an annotation member
>> do not yield exceptions [*Reported by ByteBuddy*]
>>   o JDK-8266598: Exception values for
>> AnnotationTypeMismatchException are not always informative
>> [*Reported by ByteBuddy*]
>>   * *Build 25*
>>   o JDK-8266653: Change update mode for JDK rpm/deb installers as it
>> breaks "yum update" for JDK11+
>>   o JDK-8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language
>> codes to current
>>   o JDK-8229517: Support for optional asynchronous/buffered logging
>>   o JDK-8182043: Access to Windows Large Icons
>>
>>
>> *OpenJDK 18 Early Access build 1 is now available at
>> **https://jdk.java.net/18* 
>>
>>   * These 

Re: [External] : Re: JDK 17 is now in Rampdown Phase One

[Rory O'Donnell]

Thanks again Martin!

On 14/06/2021 12:35, Martin Grigorov wrote:

Hi Rory,

Apache Tomcat's build and tests pass successfully with JDK 17-ea+26-2439 on
Linux x86_64 and aarch64 !

Regards,
Martin

On Mon, Jun 14, 2021 at 12:56 PM Rory O'Donnell 
wrote:


Hi Mark,

*Per the JDK 17 schedule , we are in Rampdown Phase One [1].*

**Please advise if you find any issues while testing the latest Early
Access builds**.**

   * Schedule:
   o *2021/06/10   Rampdown Phase One*
   o 2021/07/15Rampdown Phase Two
   o 2021/08/05Initial Release Candidate
   o 2021/08/19Final Release Candidate
   o 2021/09/14General Availability

The overall feature set is frozen. No further JEPs will be targeted to
this release.

**

   * Important JEPs have been integrated – Attention Required!
   * *JEP 411: **Deprecate the Security Manager for
 Removal*
   o Deprecate, for removal, most Security Manager related classes
 and methods.
   o Warning message at startup if the Security Manager is enabled on
 the command line.
   o Warning message at run time if a Java application or library
 installs a Security Manager dynamically.
   o Deprecation is in concert with the legacy Applet API (JEP 398).
   * *JEP 407: **Remove RMI Activation*
   o Removal the Remote Method Invocation (RMI) Activation mechanism,
 while preserving the rest of RMI.
   o It was deprecated for removal by JEP
 385in Java SE 15.
   * *JEP 403: **Strongly Encapsulate JDK
 Internals*
   o Strongly encapsulate all internal elements of the JDK, except
 for critical internal APIs such as /sun.misc.Unsafe/.
   o It will no longer be possible to relax the strong encapsulation
 of internal elements via a single command-line option.

   * Other features integrated in JDK 17:
   o *JEP 306: **Restore Always-Strict Floating-Point
 Semantics*
   o JEP 356: Enhanced Pseudo-Random Number
 Generators
   o JEP 382: New macOS Rendering
 Pipeline
   o JEP 391: macOS/AArch64 Port
   o JEP 398: Deprecate the Applet API for
 Removal
   o *JEP 406: **Pattern Matching for switch
 (Preview)*
   o JEP 409: Sealed Classes
   o JEP 410: Remove the Experimental AOT and JIT
 Compiler
   o JEP 412: Foreign Function & Memory API
 (Incubator)
   o *JEP 414: **Vector API (Second
 Incubator)*
   o *JEP 415: **Context-Specific Deserialization
 Filters*

*OpenJDK 17 Early Access build 26 is available at
**https://urldefense.com/v3/__https://jdk.java.net/17*__;Kg!!GqivPVa7Brio!J84U6mJZmIe4LbezWVAJTgpq7Y_V-wJ6iBFuaYtDcLJJeYcpN9y2Vb4L8fs3H4Ac_kk$
 


   * These early-access , open-source builds are provided under the
   o GNU General Public License, version 2, with the Classpath
 Exception

   * Release Notes are available at
 
https://urldefense.com/v3/__https://jdk.java.net/17/release-notes__;!!GqivPVa7Brio!J84U6mJZmIe4LbezWVAJTgpq7Y_V-wJ6iBFuaYtDcLJJeYcpN9y2Vb4L8fs3bMx3XlI$
 <
https://urldefense.com/v3/__https://jdk.java.net/17/release-notes__;!!GqivPVa7Brio!J84U6mJZmIe4LbezWVAJTgpq7Y_V-wJ6iBFuaYtDcLJJeYcpN9y2Vb4L8fs3bMx3XlI$
 >

   * Changes in recent builds that maybe of interest:
   * *Build 26:*
   o JDK-8268241: deprecate JVM TI Heap functions 1.0
   o JDK-8266846: Add java.time.InstantSource
   o JDK-8248268: Support KWP in addition to KW
   o JDK-8204686: Dynamic parallel reference processing support for
 Parallel GC
   o JDK-8259530: Generated docs contain MIT/GPL-licenced works
 without reproducing the licence [*Reported by Apache Maven*]
   o JDK-8266766: Arrays of types that cannot be an annotation member
 do not yield exceptions [*Reported by ByteBuddy*]
   o JDK-8266598: Exception values for
 AnnotationTypeMismatchException are not always informative
 [*Reported by ByteBuddy*]
   * *Build 25*
   o JDK-8266653: Change update mode for JDK rpm/deb installers as it
 breaks "yum update" for JDK11+
   o JDK-8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language
 codes to current
   o JDK-8229517: Support for optional 

Re: JDK 17 is now in Rampdown Phase One

[Martin Grigorov]

Hi Rory,

Apache Tomcat's build and tests pass successfully with JDK 17-ea+26-2439 on
Linux x86_64 and aarch64 !

Regards,
Martin

On Mon, Jun 14, 2021 at 12:56 PM Rory O'Donnell 
wrote:

>
> Hi Mark,
>
> *Per the JDK 17 schedule , we are in Rampdown Phase One [1].*
>
> **Please advise if you find any issues while testing the latest Early
> Access builds**.**
>
>   * Schedule:
>   o *2021/06/10   Rampdown Phase One*
>   o 2021/07/15Rampdown Phase Two
>   o 2021/08/05Initial Release Candidate
>   o 2021/08/19Final Release Candidate
>   o 2021/09/14General Availability
>
> The overall feature set is frozen. No further JEPs will be targeted to
> this release.
>
> **
>
>   * Important JEPs have been integrated – Attention Required!
>   * *JEP 411: **Deprecate the Security Manager for
> Removal*
>   o Deprecate, for removal, most Security Manager related classes
> and methods.
>   o Warning message at startup if the Security Manager is enabled on
> the command line.
>   o Warning message at run time if a Java application or library
> installs a Security Manager dynamically.
>   o Deprecation is in concert with the legacy Applet API (JEP 398).
>   * *JEP 407: **Remove RMI Activation*
>   o Removal the Remote Method Invocation (RMI) Activation mechanism,
> while preserving the rest of RMI.
>   o It was deprecated for removal by JEP
> 385in Java SE 15.
>   * *JEP 403: **Strongly Encapsulate JDK
> Internals*
>   o Strongly encapsulate all internal elements of the JDK, except
> for critical internal APIs such as /sun.misc.Unsafe/.
>   o It will no longer be possible to relax the strong encapsulation
> of internal elements via a single command-line option.
>
>   * Other features integrated in JDK 17:
>   o *JEP 306: **Restore Always-Strict Floating-Point
> Semantics*
>   o JEP 356: Enhanced Pseudo-Random Number
> Generators
>   o JEP 382: New macOS Rendering
> Pipeline
>   o JEP 391: macOS/AArch64 Port
>   o JEP 398: Deprecate the Applet API for
> Removal
>   o *JEP 406: **Pattern Matching for switch
> (Preview)*
>   o JEP 409: Sealed Classes
>   o JEP 410: Remove the Experimental AOT and JIT
> Compiler
>   o JEP 412: Foreign Function & Memory API
> (Incubator)
>   o *JEP 414: **Vector API (Second
> Incubator)*
>   o *JEP 415: **Context-Specific Deserialization
> Filters*
>
> *OpenJDK 17 Early Access build 26 is available at
> **https://jdk.java.net/17*
>
>   * These early-access , open-source builds are provided under the
>   o GNU General Public License, version 2, with the Classpath
> Exception
>
>   * Release Notes are available at
> https://jdk.java.net/17/release-notes<
> https://jdk.java.net/17/release-notes>
>
>   * Changes in recent builds that maybe of interest:
>   * *Build 26:*
>   o JDK-8268241: deprecate JVM TI Heap functions 1.0
>   o JDK-8266846: Add java.time.InstantSource
>   o JDK-8248268: Support KWP in addition to KW
>   o JDK-8204686: Dynamic parallel reference processing support for
> Parallel GC
>   o JDK-8259530: Generated docs contain MIT/GPL-licenced works
> without reproducing the licence [*Reported by Apache Maven*]
>   o JDK-8266766: Arrays of types that cannot be an annotation member
> do not yield exceptions [*Reported by ByteBuddy*]
>   o JDK-8266598: Exception values for
> AnnotationTypeMismatchException are not always informative
> [*Reported by ByteBuddy*]
>   * *Build 25*
>   o JDK-8266653: Change update mode for JDK rpm/deb installers as it
> breaks "yum update" for JDK11+
>   o JDK-8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language
> codes to current
>   o JDK-8229517: Support for optional asynchronous/buffered logging
>   o JDK-8182043: Access to Windows Large Icons
>
>
> *OpenJDK 18 Early Access build 1 is now available at
> **https://jdk.java.net/18* 
>
>   * These early-access , open-source builds are provided under the
>   o GNU General Public License, version 2, with the Classpath
> Exception 
>   * Issues addressed in 

Re: [VOTE] Release Apache Tomcat 8.5.68

[Martin Grigorov]

On Fri, Jun 11, 2021 at 5:01 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> The proposed Apache Tomcat 8.5.68 release is now available for voting.
>
> The notable changes compared to the (cancelled) 8.5.67 release is:
>
> - Windows installer / uninstaller are now properly-signed.
>
> The notable changes compared to the 8.5.66 release are:
>
> - Improve robustness of HTTP/2 HPACK decoding
>
> - Improvements to the handling of the Transfer-Encoding header
>
> - Review code used to generate Java source from JSPs and tags and remove
> code found to be unnecessary.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-8.5.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.68/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1317/
>
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.68
> 06846f94cda226d1ed0ff7fe05faff177d5b20b6
>
> The proposed 8.5.68 release is:
> [ ] Broken - do not release
> [  X ] Stable - go ahead and release as 8.5.68
>


Regards,
Martin


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

JDK 17 is now in Rampdown Phase One

[Rory O'Donnell]

Hi Mark,

*Per the JDK 17 schedule , we are in Rampdown Phase One [1].*

**Please advise if you find any issues while testing the latest Early 
Access builds**.**


 * Schedule:
 o *2021/06/10   Rampdown Phase One*
 o 2021/07/15    Rampdown Phase Two
 o 2021/08/05    Initial Release Candidate
 o 2021/08/19    Final Release Candidate
 o 2021/09/14    General Availability

The overall feature set is frozen. No further JEPs will be targeted to 
this release.


**

 * Important JEPs have been integrated – Attention Required!
 * *JEP 411: **Deprecate the Security Manager for
   Removal*
 o Deprecate, for removal, most Security Manager related classes
   and methods.
 o Warning message at startup if the Security Manager is enabled on
   the command line.
 o Warning message at run time if a Java application or library
   installs a Security Manager dynamically.
 o Deprecation is in concert with the legacy Applet API (JEP 398).
 * *JEP 407: **Remove RMI Activation*
 o Removal the Remote Method Invocation (RMI) Activation mechanism,
   while preserving the rest of RMI.
 o It was deprecated for removal by JEP
   385in Java SE 15.
 * *JEP 403: **Strongly Encapsulate JDK
   Internals*
 o Strongly encapsulate all internal elements of the JDK, except
   for critical internal APIs such as /sun.misc.Unsafe/.
 o It will no longer be possible to relax the strong encapsulation
   of internal elements via a single command-line option.

 * Other features integrated in JDK 17:
 o *JEP 306: **Restore Always-Strict Floating-Point
   Semantics*
 o JEP 356: Enhanced Pseudo-Random Number
   Generators
 o JEP 382: New macOS Rendering
   Pipeline
 o JEP 391: macOS/AArch64 Port
 o JEP 398: Deprecate the Applet API for
   Removal
 o *JEP 406: **Pattern Matching for switch
   (Preview)*
 o JEP 409: Sealed Classes
 o JEP 410: Remove the Experimental AOT and JIT
   Compiler
 o JEP 412: Foreign Function & Memory API
   (Incubator)
 o *JEP 414: **Vector API (Second
   Incubator)*
 o *JEP 415: **Context-Specific Deserialization
   Filters*

*OpenJDK 17 Early Access build 26 is available at 
**https://jdk.java.net/17*


 * These early-access , open-source builds are provided under the
 o GNU General Public License, version 2, with the Classpath
   Exception

 * Release Notes are available at
   https://jdk.java.net/17/release-notes

 * Changes in recent builds that maybe of interest:
 * *Build 26:*
 o JDK-8268241: deprecate JVM TI Heap functions 1.0
 o JDK-8266846: Add java.time.InstantSource
 o JDK-8248268: Support KWP in addition to KW
 o JDK-8204686: Dynamic parallel reference processing support for
   Parallel GC
 o JDK-8259530: Generated docs contain MIT/GPL-licenced works
   without reproducing the licence [*Reported by Apache Maven*]
 o JDK-8266766: Arrays of types that cannot be an annotation member
   do not yield exceptions [*Reported by ByteBuddy*]
 o JDK-8266598: Exception values for
   AnnotationTypeMismatchException are not always informative
   [*Reported by ByteBuddy*]
 * *Build 25*
 o JDK-8266653: Change update mode for JDK rpm/deb installers as it
   breaks "yum update" for JDK11+
 o JDK-8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language
   codes to current
 o JDK-8229517: Support for optional asynchronous/buffered logging
 o JDK-8182043: Access to Windows Large Icons


*OpenJDK 18 Early Access build 1 is now available at 
**https://jdk.java.net/18* 


 * These early-access , open-source builds are provided under the
 o GNU General Public License, version 2, with the Classpath
   Exception 
 * Issues addressed in this build - here
   

*Other Topics which might be of Interest: *

**

 * Java Cryptographic Roadmap [2] has been updated.
 * Inside Java Newscast #6 [3]
 o a closer look at the list of JEPs of JDK 17 as well as the
   development process
 * Inside Java Newscast #7 [4]
 o discusses in greater detail `pattern matching for switch`,
   previewed in JDK 17

Rgds,Rory

[1] 

[Bug 65373] LDAP authentication failing for some characters in 8.5.66 but works in 8.5.65

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65373

--- Comment #12 from Mark Thomas  ---
I'm afraid there is insufficient information here to help you. You show strings
that appear to be using Java escaping but the context in which you use those
strings is not clear.

The user should enter their username and password exactly as it is stored in
LDAP. ie. in this case:

<>+="#;,rrr

The user should not be responsible for any escaping.

If the username and/or password are used in code, a configuration file or
similar then you may need to escape them according to the conventions for the
code/configuration file you are using.

Without a test case that demonstrates an issue this issue will be resolved as
invalid. See the link to the commit in comment #10 for an example of how to
construct a test case.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 65375] New: IIS 10.0 as Tomcat reverse proxy does not send auth_type and remote_user AJP heder

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65375

Bug ID: 65375
   Summary: IIS 10.0 as Tomcat reverse proxy does not send
auth_type and remote_user AJP heder
   Product: Tomcat Connectors
   Version: 1.2.46
  Hardware: PC
Status: NEW
  Severity: normal
  Priority: P2
 Component: isapi
  Assignee: dev@tomcat.apache.org
  Reporter: clerici.pa...@gmail.com
  Target Milestone: ---

I use IIS 10.0 as a reverse proxy of Tomcat 7.
IIS 10.0 use Windows Authentication.
When I run the javax.servlet.http.HttpServletRequest.getAuthType() method I get
the null value.
When I run the javax.servlet.http.HttpServletRequest.getRemoteUser() method I
get the null value.
Using IIS 6.1 with the same version of Tomcat everything works fine.
When I run the javax.servlet.http.HttpServletRequest.getAuthType() method I get
"NTLM" string.
When I run the javax.servlet.http.HttpServletRequest.getRemoteUser() method I
get the name of the user who authenticated with IIS.
The configuration of the two versions of IIS appears to be the same.
Seems to be missing some AJP headers including: remote_user (0x03) and
auth_type (0x04) which instead are sent from IIS 6.1

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org