Re: [VOTE] Release Apache Tomcat 8.5.82

[Filip Hanik]

On Mon, Aug 8, 2022 at 3:15 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> The proposed Apache Tomcat 8.5.82 release is now available for voting.
>
> The notable changes compared to 8.5.81 are:
>
>   - Update the packaged version of the Tomcat Native Library to 1.2.35 to
> pick up Windows binaries built with OpenSSL 1.1.1q.
>
>   - Enable the use of the FIPS provider for TLS enabled Connectors when
> using Tomcat Native 1.2.34 onwards built with OpenSSL 3.0.x onwards.
>
>   - Improvements to HTTP/2 header handling.
>
>   - Fix CVE-2022-34305, a low severity XSS vulnerability in the
> Form authentication example.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/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.82/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1385
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.82/
> 237076605ea6b44ec7b97ee1158d5aa7f2f0b53c
>
> The proposed 8.5.82 release is:
> [ ] Broken - do not release
>
> [X] Stable - go ahead and release as 8.5.82 (stable)

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

Re: Plans for Tomcat Native

[Filip Hanik]

Sounds like a healthy plan. +1

On Mon, May 23, 2022 at 03:52 Mark Thomas  wrote:

> Hi all,
>
> A question on the users list about Tomcat Native, OpenSSL 3.0 FIPs
> caused me to take a look at the current state of supported versions.
>
> The detail is here:
> https://github.com/apache/tomcat-native/blob/main/native/srclib/VERSIONS
>
> The planned transition to Tomcat Native 1.3 never happened in April 2021
> so I'd like to propose the following:
>
> - Create a 1.2.x branch from current main
> - main becomes 1.3.x
> - 1.3.x is updated to require at least OpenSSL 1.1.1
> - 1.3.x is updated to require at least APR 1.6.3
> - Update 1.3.x to support OpenSSL 3.x in FIPS mode
> - Update 10.1.x to require at least Tomcat Native 1.3.x
>
> 1.2.x releases will continue until we have a stable 1.3x release.
>
> Thoughts?
>
> Mark
>
> -
> 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.79

[Filip Hanik]

On Mon, May 16, 2022 at 9:14 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> The proposed Apache Tomcat 8.5.79 release is now available for voting.
>
> The notable changes compared to 8.5.78 are:
>
> - Provide a property source that sources values from Kubernetes service
> bindings. Provided by Sumit Kulhadia and Gareth Evans.
>
> - The root cause of the Linux kernel duplicate accept bug has been
> identified along with the version of the kernel that includes the fix.
> The error message displayed when this bug occurs has been updated to
> reflect this new information and to advise users to update to a
> version of the OS that uses kernel 5.10 or later. Thanks to
> Christopher Gual for the research into this issue.
>
> - Update the packaged version of the Tomcat Native Library to 1.2.33 to
> pick up Windows binaries built with OpenSSL 1.1.1o.
>
> - Add support for encrypted PKCS#1 formatted private keys when
> configuring the internal, in memory key store.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/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.79/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1375
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.79
> 1af5f227ae591e601a9426d3788bf6a60a1b75a3
>
> The proposed 8.5.79 release is:
> [ ] Broken - do not release
>
[X] Stable - go ahead and release as 8.5.79 (stable)

Filip

Re: [VOTE] Release Apache Tomcat 10.0.21

[Filip Hanik]

On Tue, May 10, 2022 at 3:39 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.21 release is now available for
> voting.
>
> Apache Tomcat 10.0.x implements Jakarta EE 9 and, as such, the primary
> package for all the specification APIs has changed from javax.* to
> jakarta.*
>
> Applications that run on Tomcat 9 will not run on Tomcat 10 without
> changes. Java EE applications designed for Tomcat 9 and earlier may be
> placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat will
> automatically convert them to Jakarta EE and copy them to the webapps
> directory
>
> The notable changes compared to 10.0.20 are:
>
> - Provide a property source that sources values from Kubernetes service
>bindings. Provided by Sumit Kulhadia and Gareth Evans.
>
> - The root cause of the Linux kernel duplicate accept bug has been
>identified along with the version of the kernel that includes the fix.
>The error message displayed when this bug occurs has been updated to
>reflect this new information and to advise users to update to a
>version of the OS that uses kernel 5.10 or later. Thanks to
>Christopher Gual for the research into this issue.
>
> - Update the packaged version of the Tomcat Native Library to 1.2.33 to
>pick up Windows binaries built with OpenSSL 1.1.1o.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-10.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.21/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1373
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.21
> feb577944dee2ac7cc9839638e9388d90067f1cb
>
> The proposed 10.0.21 release is:
> [ ] Broken - do not release
>
[X] Stable - go ahead and release as 10.0.21 (stable)

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

Re: [VOTE] Release Apache Tomcat 10.1.0-M15

[Filip Hanik]

On Tue, May 10, 2022 at 1:24 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.1.0-M15 release is now available for
> voting.
>
> Applications that run on Tomcat 9 and earlier will not run on Tomcat 10
> without changes. Java EE applications designed for Tomcat 9 and earlier
> may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat
> will automatically convert them to Jakarta EE and copy them to the
> webapps directory.
>
> The notable changes compared to 10.1.0-M14 are:
>
> - Provide a property source that sources values from Kubernetes service
>bindings. Provided by Sumit Kulhadia and Gareth Evans.
>
> - The root cause of the Linux kernel duplicate accept bug has been
>identified along with the version of the kernel that includes the fix.
>The error message displayed when this bug occurs has been updated to
>reflect this new information and to advise users to update to a
>version of the OS that uses kernel 5.10 or later. Thanks to
>Christopher Gual for the research into this issue.
>
> - Update the packaged version of the Tomcat Native Library to 1.2.33 to
>pick up Windows binaries built with OpenSSL 1.1.1o.
>
> For full details, see the change log:
> https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M15/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1371
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.0-M15
> dcf3e81b2e709574971c7a9592614d70c1b55bf7
>
>
> The proposed 10.1.0-M15 release is:
> [ ] Broken - do not release
>
> [X] Alpha - go ahead and release as 10.1.0-M15 (alpha)

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

Re: Native Compilation, Continuation 2022

[Filip Hanik]

On Wed, Apr 13, 2022 at 9:45 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Filip,
>
> On 4/11/22 18:32, Filip Hanik wrote:
> > Hi folks,
> >
> > I'm jumping in on the bandwagon again. Specifically to talk some more
> about
> > native compilation. The graal compiler is making headway, and it's
> becoming
> > better and better at native compilation [1].
> >
> > I'll put some historical context at the bottom of this post for clarity.
> I
> > have a few suggestions that I'd like some input on
> >
> > 1. Get rid of tomcat-embed-programmatic
>
> Why? Does it interfere with providing GraalVM support?
>

tomcat-embed-programmatic.jar is a subset of the existing
tomcat-embed-core.jar
Moving forward, we'd like to not have to create a secondary artifact, if we
can achieve the same optimizations by using the existing artifact
tomcat-embed-core.jar



>
> > 2. Refactor existing graal JSON instructions [2]
> > 3. Potentially introduce tomcat-embed-graal
> > 4. Add in build feature flags to the code or code optimizations
> >
> > Today
> > The amount of input we can provide to the graal compiler today, lets us
> > work around many of the issues that were the reason for the
> > tomcat-embed-programmatic.
> >
> > For example, graal can apply build time code substitution, like mentioned
> > here [4]. We can also provide multiple JSON files [2], and effectively
> > create profiles. So there can be an NIO profile, an NIO2 profile and an
> APR
> > profile, if that's desired.
> >
> > Back to Proposal
> > 1. Remove tomcat-embed-programmatic
> > I believe this served its purpose.
>
> How would anyone use Tomcat in an embedded way without this? Or are you
> suggesting that a tomcat-embed-graal could be used in its place, but
> without actually using GraalVM? Say some product wants to ship with (a)
> Tomcat embedded (using whatever strategy, where the application
> orchestrates the launch of the servlet container instead of the
> container launching the application) and (b) OpenJDK (or pick your JVM).
> Would that still be possible? Because taking that away would be a Bad
> Thing IMHO.
>

It may be easier if I illustrate this via the graal native compilation
command, where the classpath changes

## Optimized Tomcat today - uses modified programmatic artifact to achieve
optimal size

native-image \ #compiler
-H:Name=my-app-native \ #name of produced binary

-cp ../embed/tomcat-embed-programmatic.jar:my-application.jar \ #classpath
org.example.MyNativeEmbeddedTomcat #launch class

## Optimized Tomcat tomorrow - achieve the same optimizations
native-image \ #compiler
-some-flag \ #flags that select an optimized embedded tomcat profile, for
example NIO only
-H:Name=my-app-native \ #name of produced binary
-cp ../embed/tomcat-embed-core.jar:my-application.jar \ #classpath
org.example.MyNativeEmbeddedTomcat #launch class



>
> > 2. Refactor existing graal JSON files
> > This can allow us to create profiles with various memory footprints
> > depending on functionality desired.
> >
> > 3. Potentially introduce tomcat-embed-graal
> > This can have various code substitutions that we find beneficial. [4]
> >
> > 4. Add in build feature flags to the code or code optimizations
> > graal can still do static analysis to optimize inclusion of code paths.
> as
> > demonstrated in this example [5]. As this seems to pollute our codebase
> > with graal specific stuff when it could have been done as a substitution,
> > I'm still presenting it to gather more opinions.
> >
> > Filip
> >
> > Historical Context
> > When we created tomcat-embed-programmatic, we did so to reduce the memory
> > footprint[3] of the simplest tomcat installation. At the time, the graal
> > compiler was indiscriminate and would absorb virtually any class file in
> a
> > library. So we created an experimental jar, tomcat-embed-programmatic,
> that
> > was reduced to be embedded,  no resource files, no XML support, and
> removed
> > the reflection property setters for configurable components.
>
> Hmm. Perhaps I don't understand exactly what tomcat-embed-programmatic
> means. I was thinking you were talking about dropping the Tomcat class
> which is used to launch Tomcat from other Java code.
>

tomcat-embed-programmatic == tomcat-embed-core  NIO2/APR/string
resources/other-code-that-isn't-needed
Basically, to produce tomcat-embed-programmatic, we took the "core"
artifact, and removed files from the .jar file that we knew belonged in
code paths that wouldn't get executed.

Filip


> Apologies if I'm speaking from a position of ignorance.
>
> -chris
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Native Compilation, Continuation 2022

[Filip Hanik]

Hi folks,

I'm jumping in on the bandwagon again. Specifically to talk some more about
native compilation. The graal compiler is making headway, and it's becoming
better and better at native compilation [1].

I'll put some historical context at the bottom of this post for clarity. I
have a few suggestions that I'd like some input on

1. Get rid of tomcat-embed-programmatic
2. Refactor existing graal JSON instructions [2]
3. Potentially introduce tomcat-embed-graal
4. Add in build feature flags to the code or code optimizations

Today
The amount of input we can provide to the graal compiler today, lets us
work around many of the issues that were the reason for the
tomcat-embed-programmatic.

For example, graal can apply build time code substitution, like mentioned
here [4]. We can also provide multiple JSON files [2], and effectively
create profiles. So there can be an NIO profile, an NIO2 profile and an APR
profile, if that's desired.

Back to Proposal
1. Remove tomcat-embed-programmatic
I believe this served its purpose.

2. Refactor existing graal JSON files
This can allow us to create profiles with various memory footprints
depending on functionality desired.

3. Potentially introduce tomcat-embed-graal
This can have various code substitutions that we find beneficial. [4]

4. Add in build feature flags to the code or code optimizations
graal can still do static analysis to optimize inclusion of code paths. as
demonstrated in this example [5]. As this seems to pollute our codebase
with graal specific stuff when it could have been done as a substitution,
I'm still presenting it to gather more opinions.

Filip

Historical Context
When we created tomcat-embed-programmatic, we did so to reduce the memory
footprint[3] of the simplest tomcat installation. At the time, the graal
compiler was indiscriminate and would absorb virtually any class file in a
library. So we created an experimental jar, tomcat-embed-programmatic, that
was reduced to be embedded,  no resource files, no XML support, and removed
the reflection property setters for configurable components.

References
[1]
https://github.com/spring-projects-experimental/spring-native/issues/1426
[2]
https://github.com/apache/tomcat/tree/main/res/graal/tomcat-embed-core/native-image
[3]
https://github.com/spring-projects-experimental/spring-native/issues/1426#issuecomment-1019546681
[4]
https://github.com/spring-projects-experimental/spring-native/issues/1426#issue-1095362633
[5]
https://github.com/spring-projects-experimental/spring-native/issues/1426#issuecomment-1072581363

Re: [VOTE] Release Apache Tomcat 8.5.78

[Filip Hanik]

On Thu, Mar 31, 2022 at 9:55 AM Mark Thomas  wrote:

> The proposed Apache Tomcat 8.5.78 release is now available for voting.
>
> The notable changes compared to 8.5.77 are:
>
> - Update the packaged version of the Tomcat Native Library to 1.2.32 to
> pick up Windows binaries built with OpenSSL 1.1.1n.
>
> - Improve logging of unknown HTTP/2 settings frames. Pull request by
> Thomas Hoffmann.
>
> - Add additional warnings if incompatible TLS configurations are used
> such as HTTP/2 with CLIENT-CERT authentication
>
> - Harden the class loader to provide a mitigation for CVE-2022-22965
> a Spring Framework vulnerability
>
> Along with lots of other bug fixes and improvements.
>
> This is the third release of Tomcat 8.5 that has been built with Java 11
> (in Java 7 mode) instead of Java 7. Please report any strangeness you
> may observe especially if you are running Tomcat 8.5 in an environment
> using Java < 11. We don't expect any issues, but understand that we
> cannot test all possible environmental configurations.
>
> For full details, see the changelog:
> https://nightlies.apache.org/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.78/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1370
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.78
> f732d3aa5ca55eb07cb73d9ec2b585330f80f00b
>
> The proposed 8.5.78 release is:
> [ ] Broken - do not release
>
> [X] Stable - go ahead and release as 8.5.78 (stable)
Filip

Re: [VOTE] Release Apache Tomcat 9.0.62

[Filip Hanik]

On Thu, Mar 31, 2022 at 7:56 AM Rémy Maucherat  wrote:

> The proposed Apache Tomcat 9.0.62 release is now available for voting.
>
> The notable changes compared to 9.0.60 are:
>
> - Update the packaged version of the Tomcat Native Library to 1.2.32 to
>pick up Windows binaries built with OpenSSL 1.1.1n.
>
> - Improve logging of unknown HTTP/2 settings frames. Pull request by
>Thomas Hoffmann.
>
> - Add additional warnings if incompatible TLS configurations are used
>such as HTTP/2 with CLIENT-CERT authentication
>
> - Harden the class loader to provide a mitigation for CVE-2022-22965
>a Spring Framework vulnerability
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.62/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1368
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.62
> 85113741042dcce9e9792bdbc3d498172bc31291
>
> The proposed 9.0.62 release is:
> [ ] Broken - do not release
>
>  [X] Stable - go ahead and release as 9.0.62 (stable)

Filip


>
>

Re: [tomcat] branch 10.0.x updated: Add compilation support for Graal 21.3

[Filip Hanik]

From: Mark Thomas 
Sent: Monday, January 10, 2022 9:49 AM
To: dev@tomcat.apache.org 
Subject: Re: [tomcat] branch 10.0.x updated: Add compilation support for Graal 
21.3



On 10/01/2022 17:45, fha...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
>
> fhanik pushed a commit to branch 10.0.x
> in repository 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Ftomcat.git&data=04%7C01%7Cfhanik%40vmware.com%7C7ba3603eb5a84e75438908d9d461934c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637774337819926033%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=QAuAwszvuejE2s1WSBLADd9SiwXX3OTaJX56AXA%2Fejg%3D&reserved=0
>
>
> The following commit(s) were added to refs/heads/10.0.x by this push:
>   new 916f72d  Add compilation support for Graal 21.3
> 916f72d is described below

>Why is this in 10.0.x but not 10.1.x?

Wrong branch, will fix. It will end up in 10.x and 9.x

>This also breaks the build as the import was added in the wrong place.

Will fix. Suprised that "ant validate"​ didn't catch it.

Mark

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

Re: [VOTE] Release Apache Tomcat 9.0.54

[Filip Hanik]

[X] Stable - go ahead and release as 9.0.54 (stable)

On Tue, Sep 28, 2021 at 7:25 AM Rémy Maucherat  wrote:

> The proposed Apache Tomcat 9.0.54 release is now available for voting.
>
> The notable changes compared to 9.0.54 are:
>
> - Further robustness improvements to HTTP/2 flow control window
>management
>
> - Improvements to the DataSourceUserDatabase
>
> - Fix an issue that caused some Servlet non-blocking API reads of the
>HTTP request body to incorrectly use blocking IO.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-9.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.54/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1336
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.54
> 454f804f3336ec980e84eb84bb6a051e349c6d3a
>
> The proposed 9.0.54 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 9.0.54 (stable)
>
> Rémy
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [VOTE] Release Apache Tomcat 10.0.12

[Filip Hanik]

[X] Stable - go ahead and release as 10.0.12 (stable)

On Tue, Sep 28, 2021 at 6:59 AM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.12 release is now available for
> voting.
>
> Apache Tomcat 10.x implements Jakarta EE 9 and, as such, the primary
> package for all the specification APIs has changed from javax.* to
> jakarta.*
>
> Applications that run on Tomcat 9 will not run on Tomcat 10 without
> changes. Java EE applications designed for Tomcat 9 and earlier may be
> placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat will
> automatically convert them to Jakarta EE and copy them to the webapps
> directory
>
> The notable changes compared to 10.0.11 are:
>
> - Further robustness improvements to HTTP/2 flow control window
>management
>
> - Improvements to the DataSourceUserDatabase
>
> - Fix an issue that caused some Servlet non-blocking API reads of the
>HTTP request body to incorrectly use blocking IO.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-10.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.12/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1335
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.12
> 84e18583f461778707f7fd2e25b1f0677e44e899
>
> The proposed 10.0.12 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 10.0.12 (stable)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [VOTE] Release Apache Tomcat 10.1.0-M6

[Filip Hanik]

[X] Alpha - go ahead and release as 10.1.0-M6 (alpha)

On Tue, Sep 28, 2021 at 5:31 AM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.1.0-M6 release is now available for
> voting.
>
> Applications that run on Tomcat 9 and earlier will not run on Tomcat 10
> without changes. Java EE applications designed for Tomcat 9 and earlier
> may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat
> will automatically convert them to Jakarta EE and copy them to the
> webapps directory.
>
> The notable changes compared to 10.1.0-M5 are:
>
> - Servlet API updates for Servlet 6 including removal of all deprecated
>code, updated schemas and a new API for connection and request IDs.
>
> - EL API updates for EL 5.0 including deprecation of the use of
>FeatureDescriptor, improvements to BeanELResolver and the addition of
>MethodReference
>
> - Further robustness improvements to HTTP/2 flow control window
>management
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-10.1.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M6/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1334
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.0-M6
> 51d1031c36c0f2b3ee1e0d14b56228a559144153
>
>
> The proposed 10.1.0-M6 release is:
> [ ] Broken - do not release
> [ ] Alpha - go ahead and release as 10.1.0-M6 (alpha)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [PROPOSAL] Deprecate JAAS Realm in 10.0.x and remove in 10.1.x

[Filip Hanik]

On Mon, Apr 26, 2021 at 09:17 Mark Thomas  wrote:

> In reviewing references to Java EE (and J2EE) remaining in the Tomcat 10
> repo I found the following:
>
> 
> JAASRealm is prototype for Tomcat of the JAAS-based J2EE authentication
> framework for J2EE v1.4, based on the  href="https://www.jcp.org/en/jsr/detail?id=196";>JCP Specification
> Request 196 to enhance container-managed security and promote
> 'pluggable' authentication mechanisms whose implementations would be
> container-independent.
> 
>
> JSR became JASPIC (now Jakarta Security) and Tomcat has an implementation.
>
> Searching through the mailing lists I found the following references to
> usage of the JAASRealm (going back ~5 years).
>
> [1] Tomcat 7 user using JAAS based auth to an LDAP server
> [2] Tomcat 9 user using SPNEGO with the JAAS realm
> [3] Tomcat 8.5 user using SPNEGO with the JAAS realm
> [4] Tomcat 7 users with custom CLIENT-CERT auth based on JAAS realm
> [5] User wanting access to HttpServletRequest during auth
>
> Most, if not all, of those have better solutions available than the JAAS
> Realm. And those wanting some form of custom auth do have the "proper"
> Jakarta Security API to work with.
>
> Therefore, I'm not currently seeing a good reason to keep the JAASRealm.
> Any objections to immediate deprecation with removal planned for 10.1.x?


No objections,
go for it


>
> Mark
>
>
> [1] http://markmail.org/message/ndvr5ilxovoo4ins
> [2] http://markmail.org/message/5ocdnmqvvlvjsxas
> [3] http://markmail.org/message/wki275i5yhlg3yyo
> [4] http://markmail.org/message/av2sv6g4kgm6ouu4
> [5] http://markmail.org/message/fm4ggo3ge4r47gar
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Integrating migration tool into Tomcat 10

[Filip Hanik]

On Tue, Feb 9, 2021 at 14:34 Rémy Maucherat  wrote:

> On Tue, Feb 9, 2021 at 10:12 PM Mark Thomas  wrote:
>
> > Hi all,
> >
> > I've been looking at the options to integrate the Java EE to Jakarta EE
> > migration functionality into Tomcat 10.
> >
> > There are essentially two ways to do this: deployment time and runtime.
> >
> > The simplest solution to implement is probably a separate webapps-legacy
> > directory (or some other name) where WARs and DIRs added to that
> > directory get converted to Jakarta EE with the new version being placed
> > in the webapps directory. There are complexities (such as handling an
> > updates of the legacy WAR) but they should be manageable.
> >
> > A more complex version of the deploy time solution has the legacy web
> > application placed in webapps, identified as a legacy webapp and then
> > replaced with the new version (several ways to do this). The hard part
> > here is the identification of the webapp as a Java EE app. The only
> > reliable way to do this is class scanning and that is slow.
> >
> > The runtime approach converts classes and static resources as they are
> > loaded. The classes are relatively easy to handle. A
> > ClassFileTransformer can be added to the WebappClassLoader to do this.
> > The static files are more of a problem. The good news is that the
> > WebResources refactoring means static file access all goes through the
> > same code but the filtering required essentially means we'd need to load
> > static files into memory - regardless of size, convert them, and then
> > update the cache with the converted version. That is likely to have a
> > performance impact.
> >
> > Because of the performance impacts of handling static resources, the
> > runtime approach also needs a way to identify applications that need
> > conversion. I don't see a reliable, performant way to do that. Which, I
> > think, leaves us with the simple deployment time approach and something
> > (filename, special directory, something else) to mark an app as needing
> > conversion.
> >
> > A final point, which probably should have been first, is is there a
> > demand for this feature? Early indications from the users list and $work
> > is that there is (going to be) a demand for this feature.
> >
> > Thoughts?
> >
>
> I kind of proposed the "simplest" option [the one using a separate appBase
> for the EE 8 and earlier webapps] a couple times. A slightly more complex
> deploy time option could look more polished and maybe preferable, like that
> "filename" idea maybe ? Or a marker file ? I'm not sure.
>
> There's a demand for the feature for sure, but probably only up to the
> point people realize it's not actually that helpful. This adds a step to
> deployment which may fail. The offline tool however is more efficient and
> safer. Also the tool now has quite a few "advanced" options [the ones you
> just added] for migrating trickier webapps, so how is an automatic
> migration with defaults going to work out ? This looks like asking people
> to fill up the BZ with stuff.
>
> So assuming the feature goes in, maybe a hybrid solution could work better
> than a pure runtime or deploy time solution. The classloader classes and
> resources could rely on a runtime conversion [a bit costly but probably
> safer], while the static resources could be converted at deployment time
> [it's hard to give decent guarantees on resource use if done at runtime].
>
> Rémy


We’ve spent two decades optimizing the run time within the constraints that
the Servlet spec has given to us. This was driven by the market, and
accentuated when containerization became a thing.

I would suggest that those optimization not be lost and that the extra time
spent at startup, a highly repetitive operation these days, would be
something the user would have to opt in to.

Personally I like a complete offline model, yet there is immense value for
organizations that have stale projects to be upgraded easily. (albeit, one
can argue they can stay on v9 for a very long time too)

>
>
> >
> > Mark
> >
> > -
> > 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.63

[Filip Hanik]

 [X] Stable - go ahead and release as 8.5.63

On Fri, Jan 29, 2021 at 03:43 Mark Thomas  wrote:

> The proposed Apache Tomcat 8.5.63 release is now available for voting.
>
> The notable changes compared to the 8.5.61 release are:
>
> - Add a new StringInterpreter interface that allows applications to
>   provide customised string attribute value to type conversion within
>   JSPs. This allows applications to provide a conversion
>   implementation that is optimised for the application.
>
> - Add peerAddress to coyote request, which contains the IP address of
>   the direct connection peer. If a reverse proxy sits in front of
>   Tomcat and the protocol used is AJP or HTTP in combination with the
>   RemoteIp(Valve|Filter), the peer address might differ from the
>   remoteAddress. The latter then contains the address of the client in
>   front of the reverse proxy, not the address of the proxy itself.
>
> - Escape elements in the access log that need to be escaped for the
>   access log to be parsed unambiguously.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.63/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1298/
>
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.63
> eb8d36c30857866536e8c931731c9f86980b00a6
>
> The proposed 8.5.63 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 8.5.63
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [VOTE] Release Apache Tomcat 9.0.42

[Filip Hanik]

[X] Stable - go ahead and release as 9.0.42

On Wed, Jan 27, 2021 at 9:40 AM Mark Thomas  wrote:

> The proposed Apache Tomcat 9.0.42 release is now available for voting.
>
> The notable changes compared to the 9.0.41 release are:
>
> - Add support for using Unix domain sockets for NIO when running on
>   Java 16 or later.
>
> - Add a new StringInterpreter interface that allows applications to
>   provide customised string attribute value to type conversion within
>   JSPs. This allows applications to provide a conversion
>   implementation that is optimised for the application.
>
> - Add peerAddress to coyote request, which contains the IP address of
>   the direct connection peer. If a reverse proxy sits in front of
>   Tomcat and the protocol used is AJP or HTTP in combination with the
>   RemoteIp(Valve|Filter), the peer address might differ from the
>   remoteAddress. The latter then contains the address of the client in
>   front of the reverse proxy, not the address of the proxy itself.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat9/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.42/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1293/
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.42
> 868b50e7af1dd6c3489ba0fda86dfc1ff1b8c8cb
>
> The proposed 9.0.42 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 9.0.42
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [VOTE] Release Apache Tomcat 10.0.1

[Filip Hanik]

[X] Stable - go ahead and release as 10.0.1 (stable)

On Wed, Jan 27, 2021 at 8:29 AM Mark Thomas  wrote:

> On 27/01/2021 15:08, Mark Thomas wrote:
>
> > The proposed 10.0.1 release is:
> > [ ] Broken - do not release
> > [ ] Beta   - go ahead and release as 10.0.1 (beta)
> > [X] Stable - go ahead and release as 10.0.1 (stable)
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Tomcat 10.0.x and Jakarta 9 TCK status

[Filip Hanik]

Thanks for the update. Good work!

On Mon, Nov 23, 2020 at 07:07 Mark Thomas  wrote:

> Hi all,
>
> Now that the final versions of the TCKs for Jakarta 9 are available I've
> been running them against the current 10.0.x (effectively 10.0.0-M10).
>
> The results can be summarised as:
>
> Expression Language
>- Passes apart from the API signature test because we use BND
>  annotations for JPMS support
>
> Websocket
>- Passes apart from the API signature test because we use BND
>  annotations for JPMS support
>
> Servlet
>- Passes apart from the default context path test because Tomcat
>  deliberately always overrides the associated web.xml setting
>
> JSP
>   - Passes
>
> All of the above were tested with both Java 8 and Java 11.
>
> The BND failures are not a concern as the annotations have no impact at
> runtime.
>
> The Servlet failure is not a concern as Tomcat's behaviour is spec
> compliant. The spec allows implementations to override the web.xml
> setting and Tomcat will always do this.
>
> It is worth noting the Jakarta EE 9 only targetted Java 8. Current
> planning is that a Jakarta EE 9.1 release will target Java 11 support
> (while retaining Java 8 compatibility). This is essentially a no-op for
> Tomcat 10. We already have this and more. Tomcat runs on all current
> versions of the JRE including the Java 16 early access releases.
>
> In summary, Tomcat 10 is in excellent shape.
>
> Given the alpha/beta/stable definition from [1], 10.0.x now clearly
> meets the criteria for beta and some may consider it meets the criteria
> for stable. With that in mind the next 10.0.x release vote will include
> options for broken, beta and stable.
>
> Mark
>
>
> [1] http://tomcat.apache.org/whichversion.html
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Removing JDBC mode from JDBCStore

[Filip Hanik]

+1

On Mon, Nov 9, 2020 at 05:45 Rémy Maucherat  wrote:

> Hi,
>
> As part of https://github.com/apache/tomcat/pull/376 and along with the
> similar removal of JDBCRealm, I would like to propose:
> - Remove JDBC code from JDBCStore in Tomcat 10, in favor of DataSource
> code; this allows simplifying and removing global sync which obviously
> kills scalability
> - Rename JDBCStore to DataSourceStore in Tomcat 10
> - Introduce a new empty DataSourceStore store extending JDBCStore in Tomcat
> 7.0.x, 8.5.x and 9.0.x to help migration, and adjust documentation to refer
> to it
>
> Comments ?
>
> Rémy
>

Re: [VOTE] Release Apache Tomcat 9.0.39

[Filip Hanik]

[X] Stable - go ahead and release as 9.0.39

On Tue, Oct 6, 2020 at 07:49 Mark Thomas  wrote:

> The proposed Apache Tomcat 9.0.39 release is now available for voting.
>
> The notable changes compared to the 9.0.38 release are:
>
> - Refactor the handling of closed HTTP/2 streams to reduce the heap
>   usage associated with used streams and to retain information for more
>   streams in the priority tree.
>
> - Allow using the utility executor for annotation scanning. Patch
>   provided by Jatin Kamnani.
>
> - Add a bloom filter to speed up archive lookup and improve deployment
>   speed of applications with a large number of JARs. Patch provided by
>   Jatin Kamnani.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat9/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.39/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1281/
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.39
> 6989c4e9360b4f9443862968c15a95d17f264321
>
> The proposed 9.0.39 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 9.0.39
>
> -
> 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.59

[Filip Hanik]

[X] Stable - go ahead and release as 8.5.59

On Tue, Oct 6, 2020 at 10:34 Mark Thomas  wrote:

> The proposed Apache Tomcat 8.5.59 release is now available for voting.
>
> The notable changes compared to the 8.5.58 release are:
>
> - Refactor the handling of closed HTTP/2 streams to reduce the heap
>   usage associated with used streams and to retain information for more
>   streams in the priority tree.
>
> - Deprecate the JDBCRealm.
>
> - Ensure that none of the methods on a ServletContext instance always
>   fail when running under a SecurityManager. Pull request provided by
>   Kyle Stiemann.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.59/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1282/
>
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.59
> c042ec71219dbde3e1ce0381ce5be0801120d0fa
>
> The proposed 8.5.59 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 8.5.59
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [VOTE] Release Apache Tomcat 10.0.0-M9

[Filip Hanik]

[X] Alpha  - go ahead and release as 10.0.0-M9



On Tue, Oct 6, 2020 at 06:45 Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.0-M9 release is now available for
> voting.
>
> Apache Tomcat 10.x implements Jakarta EE 9 and, as such, the primary
> package for all the specification APIs has changed from javax.* to
> jakarta.*
> Applications that run on Tomcat 9 will not run on Tomcat 10 without
> changes.
>
> The notable changes compared to 10.0.0-M8 are:
>
> - Refactor the handling of closed HTTP/2 streams to reduce the heap
>   usage associated with used streams and to retain information for more
>   streams in the priority tree.
>
> - Allow using the utility executor for annotation scanning. Patch
>   provided by Jatin Kamnani.
>
> - Add a bloom filter to speed up archive lookup and improve deployment
>   speed of applications with a large number of JARs. Patch provided by
>   Jatin Kamnani.
>
>
> Along with lots of other bug fixes and improvements.
>
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat10/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.0-M9/
> The Maven staging repo is:
>
> https://repository.apache.org/content/repositories/orgapachetomcatrepo-1280/
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.0-M9
> 6f143d19d151620cd0bfe9ec2ffa429e36ad0e45
>
> The proposed 10.0.0-M9 release is:
> [ ] Broken - do not release
> [ ] Alpha  - go ahead and release as 10.0.0-M9
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Deprecated JDBCRealm

[Filip Hanik]

Easy choice. +1

On Mon, Sep 14, 2020 at 11:53 Mark Thomas  wrote:

> All,
>
>
>
> I'd like to proposed the following:
>
> - Deprecated the JDBCRealm in 7.0.x, 8.5.x and 9.0.x
>
> - Remove the JDBCRealm in 10.0.x
>
>
>
> The reasons for this are:
>
> - The JDBCRealm is single threaded
>
> - The DataSourceRealm is a better solution
>
>
>
> Thoughts?
>
>
>
> Mark
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
>
>

Re: Plans for Servlet 5.1

[Filip Hanik]

On 9/10/20, 01:17, "Mark Thomas"  wrote:

Hi all,

It looks like at least one of the specs Tomcat implements, Servlets, is
going to have at least one release between Jakarta EE 9 / Servlet 5.0 /
Tomcat 10.0 and Jakarta EE 10/ Servlet 6.0 / Tomcat 10.1

The current plan is for Servlet 5.1 to add same site cookie
configuration and pick up any other low hanging fruit (mostly clean-up &
clarification) from the issues list.

I'm currently trying to figure out what this means in terms of Tomcat
releases. It may be that other specs do something similar. If enough
specs do that, it may turn into a relatively quick Jakarta EE 10.

My current thinking is treat such releases the way we used to treat
maintenance releases of the specs. That would mean updating Tomcat to
the 5.1 release once available but not change in major or minor version.
Another way of looking at it is that Tomcat 10.0.x will support the
latest released version of Servlet 5.x and Tomcat 10.1.x will support
the latest released version of Servlet 6.x.

Sounds good. Should we go to 10.5 rather than 10.1? While the numbers don't 
mean much, we haven't had anything but .0 and .5 in a fairly long time. 

Thoughts?

Mark

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



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

Re: [VOTE] Release Apache Tomcat 10.0.0-M8

[Filip Hanik]

X] Alpha  - go ahead and release as 10.0.0-M8

On 9/10/20, 05:57, "Keiichi Fujino"  wrote:

2020年9月9日(水) 23:57 Mark Thomas :

> The proposed Apache Tomcat 10.0.0-M8 release is now available for
> voting.
>
> Apache Tomcat 10.x implements Jakarta EE 9 and, as such, the primary
> package for all the specification APIs has changed from javax.* to
> jakarta.*
> Applications that run on Tomcat 9 will not run on Tomcat 10 without
> changes.
>
> The notable changes compared to 10.0.0-M7 are:
>
> - For requests containing the Expect: 100-continue header, optional
>   support has been added to delay sending an intermediate 100 status
>   response until the servlet reads the request body, allowing the
>   servlet the opportunity to respond without asking for the request
>   body. Based on a pull request by malaysf.
>
> - Add support for a read idle timeout and a write idle timeout to the
>   WebSocket session via custom properties in the user properties
>   instance associated with the session. Based on a pull request by
>   sakshamverma.
>
> - Update the packaged version of the Tomcat Native Library to 1.2.25
>
> Along with lots of other bug fixes and improvements.
>
>
> For full details, see the changelog:
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fci.apache.org%2Fprojects%2Ftomcat%2Ftomcat10%2Fdocs%2Fchangelog.html&data=02%7C01%7Cfhanik%40vmware.com%7C800fcbbb602f44c6e14e08d855890e43%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637353394455234235&sdata=wEvQjmYGJCROLFSq7SXvZ%2FBkayksPo8CtZUoaLauTFk%3D&reserved=0
>
> It can be obtained from:
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Ftomcat%2Ftomcat-10%2Fv10.0.0-M8%2F&data=02%7C01%7Cfhanik%40vmware.com%7C800fcbbb602f44c6e14e08d855890e43%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637353394455234235&sdata=52jPuFtKait78nm%2F9XsLe1rlMHy%2F56fGk0KFZgneiFY%3D&reserved=0
> The Maven staging repo is:
>
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachetomcatrepo-1276%2F&data=02%7C01%7Cfhanik%40vmware.com%7C800fcbbb602f44c6e14e08d855890e43%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637353394455234235&sdata=EP1WtRJeqvx6R3aOH0kPA3odqyCjjqkn2EKA3gmC9Ac%3D&reserved=0
> The tag is:
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Ftomcat%2Ftree%2F10.0.0-M8&data=02%7C01%7Cfhanik%40vmware.com%7C800fcbbb602f44c6e14e08d855890e43%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637353394455234235&sdata=8C7v6QW12bBRNSI3cK4nYBEpzOhp1DAo1kXrZAK6yx4%3D&reserved=0
> b3f5e0d88336d81a61a767fc10ab06930c9587ee
>
> The proposed 10.0.0-M8 release is:
> [ ] Broken - do not release
> [X] Alpha  - go ahead and release as 10.0.0-M8
>
>
+1
Tested on examples app.


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

-- 
Keiichi.Fujino

Re: [VOTE] Release Apache Tomcat 9.0.38

[Filip Hanik]

[X] Stable - go ahead and release as 9.0.38

On 9/10/20, 05:58, "Keiichi Fujino"  wrote:

2020年9月10日(木) 18:03 Mark Thomas :

> The proposed Apache Tomcat 9.0.38 release is now available for voting.
>
> The notable changes compared to the 9.0.37 release are:
>
> - For requests containing the Expect: 100-continue header, optional
>   support has been added to delay sending an intermediate 100 status
>   response until the servlet reads the request body, allowing the
>   servlet the opportunity to respond without asking for the request
>   body. Based on a pull request by malaysf.
>
> - Add support for a read idle timeout and a write idle timeout to the
>   WebSocket session via custom properties in the user properties
>   instance associated with the session. Based on a pull request by
>   sakshamverma.
>
> - Update the packaged version of the Tomcat Native Library to 1.2.25
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fci.apache.org%2Fprojects%2Ftomcat%2Ftomcat9%2Fdocs%2Fchangelog.html&data=02%7C01%7Cfhanik%40vmware.com%7C502827cada5b4f08bde708d855892c0f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637353394925201992&sdata=uYGneNAyblbxCyyXr9DgI%2BVS%2BbpeG%2FV7ulk%2BajPYAfM%3D&reserved=0
>
> It can be obtained from:
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Ftomcat%2Ftomcat-9%2Fv9.0.38%2F&data=02%7C01%7Cfhanik%40vmware.com%7C502827cada5b4f08bde708d855892c0f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637353394925201992&sdata=mrj9bd%2BC09nOLiofZoPP1tBcyA9ycTIgFj411oAK%2Bcw%3D&reserved=0
> The Maven staging repo is:
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachetomcat-1277%2F&data=02%7C01%7Cfhanik%40vmware.com%7C502827cada5b4f08bde708d855892c0f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637353394925201992&sdata=2ZQqAq%2Fb%2BLDcPaMJ3XU4WKfmmMga8Ge2oFY2B7OEnA0%3D&reserved=0
> The tag is:
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Ftomcat%2Ftree%2F9.0.38&data=02%7C01%7Cfhanik%40vmware.com%7C502827cada5b4f08bde708d855892c0f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637353394925201992&sdata=T0EyU3P7808EYVR%2BVrf2dkRNrtBtp0ibyNEVYysS818%3D&reserved=0
> 48b6a87171e502cc0becbb4c96e2266de4e805e7
>
> The proposed 9.0.38 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 9.0.38
>
>
+1
Tested on examples app.


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

-- 
Keiichi.Fujino


-
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.58

[Filip Hanik]

[X] Stable - go ahead and release as 8.5.58

On 9/10/20, 15:10, "Mark Thomas"  wrote:

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

The notable changes compared to the 8.5.57 release are:

- For requests containing the Expect: 100-continue header, optional
  support has been added to delay sending an intermediate 100 status
  response until the servlet reads the request body, allowing the
  servlet the opportunity to respond without asking for the request
  body. Based on a pull request by malaysf.

- Add support for a read idle timeout and a write idle timeout to the
  WebSocket session via custom properties in the user properties
  instance associated with the session. Based on a pull request by
  sakshamverma.

- Update the packaged version of the Tomcat Native Library to 1.2.25

Along with lots of other bug fixes and improvements.

For full details, see the changelog:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fci.apache.org%2Fprojects%2Ftomcat%2Ftomcat85%2Fdocs%2Fchangelog.html&data=02%7C01%7Cfhanik%40vmware.com%7C495402a394b44508535a08d855d65306%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637353726288174790&sdata=tpDHNDMTkjSPzaHwUCSKiWzvvk5uvn%2BdlI7U9C8Zil8%3D&reserved=0

It can be obtained from:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Ftomcat%2Ftomcat-8%2Fv8.5.58%2F&data=02%7C01%7Cfhanik%40vmware.com%7C495402a394b44508535a08d855d65306%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637353726288174790&sdata=lQ%2BcgMZpZKn1Q0N636f36yjyp09PdYLkQokRlJek21A%3D&reserved=0

The Maven staging repo is:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachetomcat-1278%2F&data=02%7C01%7Cfhanik%40vmware.com%7C495402a394b44508535a08d855d65306%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637353726288174790&sdata=ZNYU0QSsGxM2MGLKK1bWe6x5Z395S6mxtnRzmBuvmbg%3D&reserved=0

The tag is:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Ftomcat%2Ftree%2F8.5.58&data=02%7C01%7Cfhanik%40vmware.com%7C495402a394b44508535a08d855d65306%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637353726288184778&sdata=6vQIo5ngW%2F5EQw7is8gSSStzL26sN%2F%2FaU8mrVMg%2Fkws%3D&reserved=0
2fe65bc24e48ee5ea079937e6a73576339f871ce

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

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



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

Re: Next release

[Filip Hanik]

On Thu, Sep 3, 2020 at 07:44 Mark Thomas  wrote:

>
>
> On 27/08/2020 14:15, Rémy Maucherat wrote:
>
> > On Thu, Aug 27, 2020 at 4:26 AM Filip Hanik 
> > <mailto:fi...@hanik.com>> wrote:
>
> > On Wed, Aug 26, 2020 at 12:12 Rémy Maucherat 
> > <mailto:r...@apache.org>> wrote:
>
> > On Wed, Aug 26, 2020 at 6:25 PM Filip Hanik 
> > <mailto:fi...@hanik.com>> wrote:
>
> > On Wed, Aug 26, 2020 at 09:15 Mark Thomas 
> > <mailto:ma...@apache.org>> wrote:
>
> > On 26/08/2020 17:12, Filip Hanik wrote:
>
> >
>
> > > Our cadence seems fairly predictable.
>
> > >
>
> > > Any thoughts on the timeline of the  on the next batch
>
> > of releases?
>
> >
>
> > I skipped the August releases as I was away. I'm
>
> > planning on the
>
> > September releases as usual. I'd like to get Tomcat
>
> > Native and Commons
>
> > Daemon updates into those releases if possible.
>
> >
>
> >
>
> > Thanks, that sounds like a good plan. I’m reviewing the PRs
>
> > too.
>
>
>
> Commons Daemon may not be ready in time (there was a delay due an issue
>
> with the signing system). I'm currently planning to start tagging early
>
> next week. If Daemon is ready by then great. If not, we can pick up the
>
> update next month.


+1

Filip

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

Re: Next release

[Filip Hanik]

On Wed, Aug 26, 2020 at 12:12 Rémy Maucherat  wrote:

> On Wed, Aug 26, 2020 at 6:25 PM Filip Hanik  wrote:
>
>>
>>
>> On Wed, Aug 26, 2020 at 09:15 Mark Thomas  wrote:
>>
>>> On 26/08/2020 17:12, Filip Hanik wrote:
>>>
>>> > Our cadence seems fairly predictable.
>>>
>>> >
>>>
>>> > Any thoughts on the timeline of the  on the next batch of releases?
>>>
>>>
>>>
>>> I skipped the August releases as I was away. I'm planning on the
>>>
>>> September releases as usual. I'd like to get Tomcat Native and Commons
>>>
>>> Daemon updates into those releases if possible.
>>
>>
>> Thanks, that sounds like a good plan. I’m reviewing the PRs too.
>>
>
> Can res/graal/java be moved to the main sources ?
>

It can, I didn’t want to pollute it while I marked it as experimental to
get it field tested. but main/sources makes my life easier.

Filip

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

Re: Next release

[Filip Hanik]

On Wed, Aug 26, 2020 at 09:15 Mark Thomas  wrote:

> On 26/08/2020 17:12, Filip Hanik wrote:
>
> > Our cadence seems fairly predictable.
>
> >
>
> > Any thoughts on the timeline of the  on the next batch of releases?
>
>
>
> I skipped the August releases as I was away. I'm planning on the
>
> September releases as usual. I'd like to get Tomcat Native and Commons
>
> Daemon updates into those releases if possible.


Thanks, that sounds like a good plan. I’m reviewing the PRs too.

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

Next release

[Filip Hanik]

Our cadence seems fairly predictable.

Any thoughts on the timeline of the  on the next batch of releases?

Filip

Re: [PROPOSAL] Remove the functional specs from docs webapp

[Filip Hanik]

+1

On Mon, Aug 10, 2020 at 08:46 Mark Thomas  wrote:

> Hi all,
>
> I'd like to propose removing all the functional spec pages from the
> documentation web application.
>
> My reasoning for this proposal is, in short, that we aren't using or
> maintaining these pages.
>
> I don't recall any discussion of these docs on the dev list, proposals
> to change them, proposals for additions etc.
>
> There have been changes but going back over the changes from the last 10
> years (and there are very few of them) they each appear to be part of a
> wider global change that is updating something or removing references to
> a feature that has been removed.
>
> Should someone want to revive these pages, or more likely a subset of
> them, they'll always be in the history.
>
> Thoughts?
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [tomcat] 02/02: Avoid reflection for default instantiation

[Filip Hanik]

From: Martin Grigorov 
Sent: Wednesday, July 22, 2020 2:29 AM
To: Tomcat Developers List
Subject: Re: [tomcat] 02/02: Avoid reflection for default instantiation


+public class AprStatus {
+private static volatile boolean aprInitialized = false;
+private static volatile boolean aprAvailable = false;
+private static volatile boolean useAprConnector = false;
+private static volatile boolean useOpenSSL = true;

Is this a good default value ?
OpenSSL should be used only when APR is available, no ?
If APR is not available then JSSE should be used.

Martin

Filip: It's not the intention of this commit to change the default value.
https://github.com/apache/tomcat/commit/f4dac6846c548144799b1c3f33aba4eb320a3413#diff-bda15c59296a87416d8b6da5682cffc8L82

Feel free to start another thread on that topic
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

RE: [tomcat] branch master updated: Simpler way to determine Graal runtime

[Filip Hanik]

Hi Romain,

> -Original Message-
> From: Romain Manni-Bucau 
> Sent: Wednesday, July 22, 2020 12:48 PM
> To: Tomcat Developers List 
> Subject: Re: [tomcat] branch master updated: Simpler way to determine Graal
> runtime
> 
> Thinking out loud: cant you substitute it to be hardcoded to true in native
> mode? This way you get the best of both.

This works for when you compile it to native code. Remy was talking about when 
running under the Substrate VM as a Java application. That's when I experience 
test failures and prompted me to look into a change.
If I understand it correctly, the substrate VM doesn't pick up those 
substitutions when running in Java mode.

Filip

> 
> Le mer. 22 juil. 2020 à 20:17, Filip Hanik  <mailto:fha...@vmware.com> > a écrit :
> 
> 
>   Thanks Remy,
> 
> 
> 
>   I ran into some failures when running the test suite using the substrate
> VM, but it makes more sense to adjust those tests.
> 
>   I’ll revert these today
> 
> 
> 
>   Filip
> 
> 
> 
>   From: Rémy Maucherat  <mailto:r...@apache.org> >
> Sent: Wednesday, July 22, 2020 12:10 AM
>   To: Tomcat Developers List  <mailto:dev@tomcat.apache.org> >
>   Subject: Re: [tomcat] branch master updated: Simpler way to
> determine Graal runtime
> 
> 
> 
>   On Tue, Jul 21, 2020 at 11:16 PM  <mailto:fha...@apache.org> > wrote:
> 
>   This is an automated email from the ASF dual-hosted git
> repository.
> 
>   fhanik pushed a commit to branch master
>   in repository
> https://gitbox.apache.org/repos/asf/tomcat.git
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitb
> o
> x.apache.org%2Frepos%2Fasf%2Ftomcat.git&data=02%7C01%7Cfhanik%40v
> mware.c
> om%7C5bb8217a67084dc6f0e308d82e791421%7Cb39138ca3cee4b4aa4d6c
> d83d9dd62f0
> %7C0%7C0%7C637310444856257107&sdata=T20lk9hPTLaJGtrD5ZLD3OVzkC
> amedtpcKo2
> V4MwXtg%3D&reserved=0>
> 
> 
>   The following commit(s) were added to refs/heads/master by
> this push:
>new 098c4c8  Simpler way to determine Graal runtime
>   098c4c8 is described below
> 
>   commit 098c4c81602ba1e8d5f33b0795d7caf55f70d573
>   Author: Filip Hanik  <mailto:fha...@pivotal.io> >
>   AuthorDate: Tue Jul 21 14:04:57 2020 -0700
> 
>   Simpler way to determine Graal runtime
> 
>   Also, allows to mock the behavior
> 
> https://www.graalvm.org/sdk/javadoc/org/graalvm/nativeimage/ImageInfo.h
> t
> ml#PROPERTY_IMAGE_CODE_KEY
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.g
> raalvm.org%2Fsdk%2Fjavadoc%2Forg%2Fgraalvm%2Fnativeimage%2FImageI
> nfo.htm
> l%23PROPERTY_IMAGE_CODE_KEY&data=02%7C01%7Cfhanik%40vmware.co
> m%7C5bb8217
> a67084dc6f0e308d82e791421%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7
> C0%7C0%7C6
> 37310444856267104&sdata=vHbmuRW5YP1%2B2a6romOsuaxaUHqMqF9G4
> ob7aXlSYbY%3D
> &reserved=0>
>   ---
>java/org/apache/jasper/runtime/JspRuntimeLibrary.java |
> 16 +---
>java/org/apache/naming/NamingContext.java |
> 15 +--
>java/org/apache/tomcat/util/compat/GraalCompat.java   |
> 15 +--
>3 files changed, 3 insertions(+), 43 deletions(-)
> 
>   diff --git
> a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
> b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
>   index cfb6e75..f27ce3b 100644
>   ---
> a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
>   +++
> b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
>   @@ -56,21 +56,7 @@ import
> org.apache.tomcat.InstanceManager;
> */
>public class JspRuntimeLibrary {
> 
>   -public static final boolean GRAAL;
>   -
>   -static {
>   -boolean result = false;
>   -try {
>   -Class nativeImageClazz =
> Class.forName("org.graalvm.nativeimage.ImageInfo");
>   -result =
> nativeImageClazz.getMethod("inImageCode").invoke(null) != null;
>   -// Note: This will also be true for the
> Graal substrate VM
> 
> 
> 
>   As the comment says, this must also be true when running on the
> substrate VM (= building a native image) and from what I can see this is not
> the case. Basically the code paths used on G

Re: [tomcat] branch master updated: Simpler way to determine Graal runtime

[Filip Hanik]

Good idea, I’ll add that as a separate commit.

On Wed, Jul 22, 2020 at 13:08 Rémy Maucherat  wrote:

> On Wed, Jul 22, 2020 at 8:17 PM Filip Hanik  wrote:
>
>> Thanks Remy,
>>
>>
>>
>> I ran into some failures when running the test suite using the substrate
>> VM, but it makes more sense to adjust those tests.
>>
>> I’ll revert these today
>>
>
> I think you should leave the additional check for the system property
> since it is a good override. It would be a transition when
> https://github.com/oracle/graal/issues/2395 is fixed as well.
>
> Rémy
>
>
>>
>>
>> Filip
>>
>>
>>
>> *From:* Rémy Maucherat 
>> *Sent:* Wednesday, July 22, 2020 12:10 AM
>> *To:* Tomcat Developers List 
>> *Subject:* Re: [tomcat] branch master updated: Simpler way to determine
>> Graal runtime
>>
>>
>>
>> On Tue, Jul 21, 2020 at 11:16 PM  wrote:
>>
>> This is an automated email from the ASF dual-hosted git repository.
>>
>> fhanik pushed a commit to branch master
>> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Ftomcat.git&data=02%7C01%7Cfhanik%40vmware.com%7Cc6abc62d296c4aa8151b08d82e0e86a0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637309987211057960&sdata=8g2MJ42V3ALljZcs%2Bss3Br0Gru%2F9zmUc285vBuYHr48%3D&reserved=0>
>>
>>
>> The following commit(s) were added to refs/heads/master by this push:
>>  new 098c4c8  Simpler way to determine Graal runtime
>> 098c4c8 is described below
>>
>> commit 098c4c81602ba1e8d5f33b0795d7caf55f70d573
>> Author: Filip Hanik 
>> AuthorDate: Tue Jul 21 14:04:57 2020 -0700
>>
>> Simpler way to determine Graal runtime
>>
>> Also, allows to mock the behavior
>>
>> https://www.graalvm.org/sdk/javadoc/org/graalvm/nativeimage/ImageInfo.html#PROPERTY_IMAGE_CODE_KEY
>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.graalvm.org%2Fsdk%2Fjavadoc%2Forg%2Fgraalvm%2Fnativeimage%2FImageInfo.html%23PROPERTY_IMAGE_CODE_KEY&data=02%7C01%7Cfhanik%40vmware.com%7Cc6abc62d296c4aa8151b08d82e0e86a0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637309987211067956&sdata=QppLIK0iTsVPnziX%2Bsn6Nv2MhB%2By%2FuY%2BZL99Yl4zWWk%3D&reserved=0>
>> ---
>>  java/org/apache/jasper/runtime/JspRuntimeLibrary.java | 16
>> +---
>>  java/org/apache/naming/NamingContext.java | 15
>> +--
>>  java/org/apache/tomcat/util/compat/GraalCompat.java   | 15
>> +--
>>  3 files changed, 3 insertions(+), 43 deletions(-)
>>
>> diff --git a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
>> b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
>> index cfb6e75..f27ce3b 100644
>> --- a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
>> +++ b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
>> @@ -56,21 +56,7 @@ import org.apache.tomcat.InstanceManager;
>>   */
>>  public class JspRuntimeLibrary {
>>
>> -public static final boolean GRAAL;
>> -
>> -static {
>> -boolean result = false;
>> -try {
>> -Class nativeImageClazz =
>> Class.forName("org.graalvm.nativeimage.ImageInfo");
>> -result =
>> nativeImageClazz.getMethod("inImageCode").invoke(null) != null;
>> -// Note: This will also be true for the Graal substrate VM
>>
>>
>>
>> As the comment says, this must also be true when running on the substrate
>> VM (= building a native image) and from what I can see this is not the
>> case. Basically the code paths used on Graal must be consistent.
>>
>> So it's simpler but it doesn't seem to work at this time, so you need to
>> revert this commit. You could get out of this by saying the user can just
>> set the system property, but this makes things more error prone so it's a
>> bad idea as the previous solution worked just fine.
>>
>>
>>
>> I see an enhancement to fix this as the agent would set the system
>> property: https://github.com/oracle/graal/issues/2395
>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foracle%2Fgraal%2Fissues%2F2395&data=02%7C01%7Cfhanik%40vmware.com%7Cc6abc62d296c4aa8151b08d82e0e86a0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637309987211077951&sdata=%2Fx5VP56WQnV9%2F0RIH0ZllbgqRAuxTLSqqYFdAqi%2FDA4%3D&reserved=0>
>>
>> But the Oracle folks said "no"

RE: [tomcat] branch master updated: Simpler way to determine Graal runtime

[Filip Hanik]

Thanks Remy,

I ran into some failures when running the test suite using the substrate VM, 
but it makes more sense to adjust those tests.
I’ll revert these today

Filip

From: Rémy Maucherat 
Sent: Wednesday, July 22, 2020 12:10 AM
To: Tomcat Developers List 
Subject: Re: [tomcat] branch master updated: Simpler way to determine Graal 
runtime

On Tue, Jul 21, 2020 at 11:16 PM mailto:fha...@apache.org>> 
wrote:
This is an automated email from the ASF dual-hosted git repository.

fhanik pushed a commit to branch master
in repository 
https://gitbox.apache.org/repos/asf/tomcat.git<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Ftomcat.git&data=02%7C01%7Cfhanik%40vmware.com%7Cc6abc62d296c4aa8151b08d82e0e86a0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637309987211057960&sdata=8g2MJ42V3ALljZcs%2Bss3Br0Gru%2F9zmUc285vBuYHr48%3D&reserved=0>


The following commit(s) were added to refs/heads/master by this push:
 new 098c4c8  Simpler way to determine Graal runtime
098c4c8 is described below

commit 098c4c81602ba1e8d5f33b0795d7caf55f70d573
Author: Filip Hanik mailto:fha...@pivotal.io>>
AuthorDate: Tue Jul 21 14:04:57 2020 -0700

Simpler way to determine Graal runtime

Also, allows to mock the behavior

https://www.graalvm.org/sdk/javadoc/org/graalvm/nativeimage/ImageInfo.html#PROPERTY_IMAGE_CODE_KEY<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.graalvm.org%2Fsdk%2Fjavadoc%2Forg%2Fgraalvm%2Fnativeimage%2FImageInfo.html%23PROPERTY_IMAGE_CODE_KEY&data=02%7C01%7Cfhanik%40vmware.com%7Cc6abc62d296c4aa8151b08d82e0e86a0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637309987211067956&sdata=QppLIK0iTsVPnziX%2Bsn6Nv2MhB%2By%2FuY%2BZL99Yl4zWWk%3D&reserved=0>
---
 java/org/apache/jasper/runtime/JspRuntimeLibrary.java | 16 +---
 java/org/apache/naming/NamingContext.java | 15 +--
 java/org/apache/tomcat/util/compat/GraalCompat.java   | 15 +--
 3 files changed, 3 insertions(+), 43 deletions(-)

diff --git a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java 
b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
index cfb6e75..f27ce3b 100644
--- a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
+++ b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
@@ -56,21 +56,7 @@ import org.apache.tomcat.InstanceManager;
  */
 public class JspRuntimeLibrary {

-public static final boolean GRAAL;
-
-static {
-boolean result = false;
-try {
-Class nativeImageClazz = 
Class.forName("org.graalvm.nativeimage.ImageInfo");
-result = nativeImageClazz.getMethod("inImageCode").invoke(null) != 
null;
-// Note: This will also be true for the Graal substrate VM

As the comment says, this must also be true when running on the substrate VM (= 
building a native image) and from what I can see this is not the case. 
Basically the code paths used on Graal must be consistent.
So it's simpler but it doesn't seem to work at this time, so you need to revert 
this commit. You could get out of this by saying the user can just set the 
system property, but this makes things more error prone so it's a bad idea as 
the previous solution worked just fine.

I see an enhancement to fix this as the agent would set the system property: 
https://github.com/oracle/graal/issues/2395<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foracle%2Fgraal%2Fissues%2F2395&data=02%7C01%7Cfhanik%40vmware.com%7Cc6abc62d296c4aa8151b08d82e0e86a0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637309987211077951&sdata=%2Fx5VP56WQnV9%2F0RIH0ZllbgqRAuxTLSqqYFdAqi%2FDA4%3D&reserved=0>
But the Oracle folks said "no" because they can. As usual :D

Rémy

-} catch (ClassNotFoundException e) {
-// Must be Graal
-} catch (ReflectiveOperationException | IllegalArgumentException e) {
-// Should never happen
-}
-GRAAL = result;
-}
+public static final boolean GRAAL = 
System.getProperty("org.graalvm.nativeimage.imagecode") != null;

 /**
  * Returns the value of the jakarta.servlet.error.exception request
diff --git a/java/org/apache/naming/NamingContext.java 
b/java/org/apache/naming/NamingContext.java
index 0471279..40f4085 100644
--- a/java/org/apache/naming/NamingContext.java
+++ b/java/org/apache/naming/NamingContext.java
@@ -792,20 +792,7 @@ public class NamingContext implements Context {
 // -- Protected Methods


-private static final boolean GRAAL;
-
-static {
-boolean result = false;
-try {
-Class nativeImageClazz = 
Class.forName("org.graalvm.nativeimage.ImageInfo");
-result = 
Boolean.TRUE.equals(nativeImageClazz.getMethod("inImageCode&quo

RE: [tomcat] branch master updated: Avoid reflection for default instantiation

[Filip Hanik]

Hi Christopher,
> > environments. -Class clazz =
> > Class.forName(className); -return
> > (AuthConfigFactory) clazz.getConstructor().newInstance(); + if
> > (className.equals("org.apache.catalina.authenticator.jaspic.AuthConfig
> FactoryImpl"))
> > {
> 
> Why not use AuthConfigFactoryImpl.class.getName()? It may help in the
> future with refactoring.

[Filip Hanik] 
Trying to avoid a circular dependency. You see the javax/jakarta package should 
not import org.apache.catalina code. I should be able to execute the 
AuthConfigFactory code without needing to load 
org.apache.catalina.authenticator.jaspic.AuthConfigFactoryImpl class. The JVM 
is smart enough that if the execution doesn't enter the if statement block, it 
won't attempt the classloading of the AuthConfigFactoryImpl class. However, if 
the AuthConfigFactoryImpl Class itself is part of the evaluation statement, it 
will be loaded.

The previous implementation also had it as a string, instead of 
AuthConfigFactoryImpl.class.getName() for the same reason.
https://github.com/apache/tomcat/blob/35dc7b9288aad4a7d70750c157543d4ff1593c98/java/jakarta/security/auth/message/config/AuthConfigFactory.java#L48-L49

This way, I can build a jakarta.security.auth.message library, that can be used 
without the org.apache.catalina library.

I need to change my commit to use the constant, instead of the duplicated 
string in the IF statement.

if 
(className.equals(DEFAULT_JASPI_AUTHCONFIGFACTORYIMPL)) {
return new 
org.apache.catalina.authenticator.jaspic.AuthConfigFactoryImpl();
} else {
Class clazz = Class.forName(className);
return (AuthConfigFactory) 
clazz.getConstructor().newInstance();
}

> 
> - -chris 

Re: Native Image - Reflectionless Concept

[Filip Hanik]

We've had some discussions around this, mostly high level about where 
this could go.


At this point, anyone strongly opposed to ship a light weight jar?

Do we feel the value is or is not there compared to the maintenance of it?


Filip



On 7/13/20 2:59 PM, Filip Hanik wrote:

for discussion, all feedback and questions welcome:


I've created a concept of having Apache Tomcat, embedded, run without 
reflection in a native image.
This concept creates a jar, tomcat-embedded-programmatic.jar, that can 
be fine tuned to only include what is needed in a default 
configuration when an embedded tomcat instance is used and configured 
programatically.


Steps to run Apache Tomcat using Java 8 without reflection

 1. Make sure you have native-image (from the graal installation) on
your path
 2. git clone -b feature/embed-minimal-programmatic-jar-file-master
g...@github.com:fhanik/tomcat.git
 3. cd tomcat/res/graal/
 4. ./build-tomcat-native-image.sh && ./graal-measure.sh

Should yield an output similar to (Graal 20.1):
SUCCESS: the servlet is working
RSS memory: 20.7M
Image size: 20.5M


or using an older graal, 19.2
SUCCESS: the servlet is working
RSS memory: 18.0M
Image size: 16.7M


This also leaves a file named 
${java.io.tmpdir}/XReflectionIntrospectionUtils.java so that you can 
review the solution to IntrospectionUtils.java


Goals of this concept

 1. Do not break anything
 2. Create a new and optimized for size artifact,
tomcat-embedded-programmatic
 3. Remove reflection by introspecting classes that are currently
passed into IntrospectionUtils.set/getProperty by generating
setters/getters at build time

How it's done

 1. I've build out a small introspection tool in the package
org.apache.tomcat.util.xreflect
 2. During build time, it analyses a set of known classes that are
used with IntrospectionUtils.java, and generates
XReflectionIntrospectionUtils.java
 3. When it packages tomcat-embed-programmatic.jar it uses the
generated code when calling setProperty and getProperty

A PR would look like this:
https://github.com/apache/tomcat/compare/master...fhanik:feature/embed-minimal-programmatic-jar-file-master?expand=1

Re: Native Image - Reflectionless Concept

[Filip Hanik]

On 7/20/20 8:47 AM, Romain Manni-Bucau wrote:



Le lun. 20 juil. 2020 à 17:41, Filip Hanik <mailto:fi...@hanik.com>> a écrit :


Thanks for chiming in:

On 7/16/20 6:46 AM, Romain Manni-Bucau wrote:

Hi everyone,

I think the generation is the sanest option since code stay clean
but it shouldn't be done in tomcat IMHO but in user code and with
a nice wrapper (mvn tomcat:dump/gradle tomcatDump etc, or
whatever name you like ;)).

That's always an option, but it would become an external artifact
and easily end up out of sync.


Was thinking to keep the dumper in tomcat code base and the plugin to 
consume it so it would stay in sync, but agree it is a small risk.



This build phase would dump the descriptors in plain java and
would load them with an unique - ie single for the whole webapp -
plain SPI - ServiceLoader - maybe?

The goal of this artifact was to reduce the size and classes from
a full tomcat (already available in tomcat-embed-core), down to a
code base where XML/digester/descriptors aren't used, hence
tomcat-embed-programmatic

This kind of build tool assumes you have all the runtime state in
the build - which is typically the case for graalvm - so you can
completely dump StandardContext state after start phase there and
just reload it from the precomputed model.
Only trick is about file paths which must either be recomputed or
be configurable to another base but it does not sound crazy.

The less tool-ed option would be to extract all
"reflectionfull" code in methods and use graalvm substitutions to
drop them and use plain java instead (with a good naming
convention, it can be generated as well).
Keeps the duplication but at least the main code stays clean and
optimizations stays together.


That's pretty much what we're doing right now. Many of these feel
like hacks simply to mitigate how GraalVM/AOT does code
initialization (all code loaded initialized at startup)


Reviewing the hacks, all can be done cleanly if extracted in methods. 
Pushing the logic next step - I don't know if worth it but trying to 
use this picture to explain:


1. A noxml module can be done with protected methods/extension-points 
for XML loading - even usable in java standalone mode

2. Current tomcat can extend noxml module
3. Graal can be based on 1

This would benefit both jvm and graal users at the end.
Today 1 is possible with some hacks on tomcat embedded but it is 
highly not natural so this can be an opportunity to make it a feature 
maybe?


I believe that tomcat-embed-programmatic is a viable interim solution, 
it's a low risk. The question for you, and the rest of the community, is 
the reward itself enough? ie, is it worth it?


There is some talk about making "native-ness" part of the Java itself, 
and that could change a lot of assumptions. Making it a feature, 
refactoring code to satisfy 1, is a bit more intrusive at this point in 
time. I believe it introduces more risk than reward.



Filip



Filip




Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github
<https://github.com/rmannibucau> | LinkedIn
<https://www.linkedin.com/in/rmannibucau> | Book

<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 16 juil. 2020 à 14:31, Rémy Maucherat mailto:r...@apache.org>> a écrit :

On Mon, Jul 13, 2020 at 11:59 PM Filip Hanik
mailto:fha...@vmware.com>> wrote:

for discussion, all feedback and questions welcome:


I've created a concept of having Apache Tomcat, embedded,
run without reflection in a native image.
This concept creates a jar,
tomcat-embedded-programmatic.jar, that can be fine tuned
to only include what is needed in a default configuration
when an embedded tomcat instance is used and configured
programatically.

Steps to run Apache Tomcat using Java 8 without reflection

 1. Make sure you have native-image (from the graal
installation) on your path
 2. git clone -b
feature/embed-minimal-programmatic-jar-file-master
g...@github.com:fhanik/tomcat.git
<mailto:g...@github.com:fhanik/tomcat.git>
 3. cd tomcat/res/graal/
 4. ./build-tomcat-native-image.sh && ./graal-measure.sh

Should yield an output similar to (Graal 20.1):
SUCCESS: the servlet is working
RSS memory: 20.7M
Image size: 20.5M


or using an older graal, 19.2
SUCCESS: the servlet is working
 

Re: Native Image - Reflectionless Concept

[Filip Hanik]

Thanks for chiming in:

On 7/16/20 6:46 AM, Romain Manni-Bucau wrote:

Hi everyone,

I think the generation is the sanest option since code stay clean but 
it shouldn't be done in tomcat IMHO but in user code and with a nice 
wrapper (mvn tomcat:dump/gradle tomcatDump etc, or whatever name you 
like ;)).
That's always an option, but it would become an external artifact and 
easily end up out of sync.
This build phase would dump the descriptors in plain java and would 
load them with an unique - ie single for the whole webapp - plain SPI 
- ServiceLoader - maybe?
The goal of this artifact was to reduce the size and classes from a full 
tomcat (already available in tomcat-embed-core), down to a code base 
where XML/digester/descriptors aren't used, hence tomcat-embed-programmatic
This kind of build tool assumes you have all the runtime state in the 
build - which is typically the case for graalvm - so you can 
completely dump StandardContext state after start phase there and just 
reload it from the precomputed model.
Only trick is about file paths which must either be recomputed or be 
configurable to another base but it does not sound crazy.


The less tool-ed option would be to extract all "reflectionfull" code 
in methods and use graalvm substitutions to drop them and use plain 
java instead (with a good naming convention, it can be generated as well).
Keeps the duplication but at least the main code stays clean and 
optimizations stays together.


That's pretty much what we're doing right now. Many of these feel like 
hacks simply to mitigate how GraalVM/AOT does code initialization (all 
code loaded initialized at startup)


Filip




Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog 
<https://rmannibucau.metawerx.net/> | Old Blog 
<http://rmannibucau.wordpress.com> | Github 
<https://github.com/rmannibucau> | LinkedIn 
<https://www.linkedin.com/in/rmannibucau> | Book 
<https://www.packtpub.com/application-development/java-ee-8-high-performance>



Le jeu. 16 juil. 2020 à 14:31, Rémy Maucherat <mailto:r...@apache.org>> a écrit :


On Mon, Jul 13, 2020 at 11:59 PM Filip Hanik mailto:fha...@vmware.com>> wrote:

for discussion, all feedback and questions welcome:


I've created a concept of having Apache Tomcat, embedded, run
without reflection in a native image.
This concept creates a jar, tomcat-embedded-programmatic.jar,
that can be fine tuned to only include what is needed in a
default configuration when an embedded tomcat instance is used
and configured programatically.

Steps to run Apache Tomcat using Java 8 without reflection

 1. Make sure you have native-image (from the graal
installation) on your path
 2. git clone -b
feature/embed-minimal-programmatic-jar-file-master
g...@github.com:fhanik/tomcat.git
 3. cd tomcat/res/graal/
 4. ./build-tomcat-native-image.sh && ./graal-measure.sh

Should yield an output similar to (Graal 20.1):
SUCCESS: the servlet is working
RSS memory: 20.7M
Image size: 20.5M


or using an older graal, 19.2
SUCCESS: the servlet is working
RSS memory: 18.0M
Image size: 16.7M


This also leaves a file named
${java.io.tmpdir}/XReflectionIntrospectionUtils.java so that
you can review the solution to IntrospectionUtils.java

Goals of this concept

 1. Do not break anything
 2. Create a new and optimized for size artifact,
tomcat-embedded-programmatic
 3. Remove reflection by introspecting classes that are
currently passed into IntrospectionUtils.set/getProperty
by generating setters/getters at build time

How it's done

 1. I've build out a small introspection tool in the package
org.apache.tomcat.util.xreflect
 2. During build time, it analyses a set of known classes that
are used with IntrospectionUtils.java, and generates
XReflectionIntrospectionUtils.java
 3. When it packages tomcat-embed-programmatic.jar it uses the
generated code when calling setProperty and getProperty

A PR would look like this:

https://github.com/apache/tomcat/compare/master...fhanik:feature/embed-minimal-programmatic-jar-file-master?expand=1


Well, this is a bit complex and hard to maintain (like, for
example, storeconfig), so that's a downside.

So starting with Tomcat and its initial server.xml, the process
would be:
server.xml -> equivalent Tomcat embedded code -> equivalent Tomcat
embedded code with custom IntrospectionUtils code
The concrete benefits may be limited though.

I looked at more code generation for web.xml since the digester is

Re: Native Image - Reflectionless Concept

[Filip Hanik]

Thanks for reviewing and engaging.

On 7/16/20 5:31 AM, Rémy Maucherat wrote:
On Mon, Jul 13, 2020 at 11:59 PM Filip Hanik <mailto:fha...@vmware.com>> wrote:


for discussion, all feedback and questions welcome:


I've created a concept of having Apache Tomcat, embedded, run
without reflection in a native image.
This concept creates a jar, tomcat-embedded-programmatic.jar, that
can be fine tuned to only include what is needed in a default
configuration when an embedded tomcat instance is used and
configured programatically.

Steps to run Apache Tomcat using Java 8 without reflection

 1. Make sure you have native-image (from the graal installation)
on your path
 2. git clone -b
feature/embed-minimal-programmatic-jar-file-master
g...@github.com:fhanik/tomcat.git
 3. cd tomcat/res/graal/
 4. ./build-tomcat-native-image.sh && ./graal-measure.sh

Should yield an output similar to (Graal 20.1):
SUCCESS: the servlet is working
RSS memory: 20.7M
Image size: 20.5M


or using an older graal, 19.2
SUCCESS: the servlet is working
RSS memory: 18.0M
Image size: 16.7M


This also leaves a file named
${java.io.tmpdir}/XReflectionIntrospectionUtils.java so that you
can review the solution to IntrospectionUtils.java

Goals of this concept

 1. Do not break anything
 2. Create a new and optimized for size artifact,
tomcat-embedded-programmatic
 3. Remove reflection by introspecting classes that are currently
passed into IntrospectionUtils.set/getProperty by generating
setters/getters at build time

How it's done

 1. I've build out a small introspection tool in the package
org.apache.tomcat.util.xreflect
 2. During build time, it analyses a set of known classes that are
used with IntrospectionUtils.java, and generates
XReflectionIntrospectionUtils.java
 3. When it packages tomcat-embed-programmatic.jar it uses the
generated code when calling setProperty and getProperty

A PR would look like this:

https://github.com/apache/tomcat/compare/master...fhanik:feature/embed-minimal-programmatic-jar-file-master?expand=1


Well, this is a bit complex and hard to maintain (like, for example, 
storeconfig), so that's a downside.


It is keeping track of one more artifact, tomcat-embed-programmatic.

Right now, it is manually maintaining the list of classes that it 
generates setProperty/getProperty for. I derived this list by running 
the test suite. There is of course an option to fully automate this.




So starting with Tomcat and its initial server.xml, the process would be:
server.xml -> equivalent Tomcat embedded code -> equivalent Tomcat 
embedded code with custom IntrospectionUtils code

The concrete benefits may be limited though.
The goal of this artifact is to actually strip all non programmatic code 
and bring down the code base to minimum bare essentials.


That means, it's not for applications that want to deploy a WAR file, or 
do XML based configuration. My primary use case, is a Spring Boot 
application where the framework servlets and filters are configured 
programmatically, easy for the AOT compiler to work with, and everything 
else is then handled by the framework.


There wouldn't be support by this artifact to handle EE style XML 
configurations, including fragments. That is already done by 
tomcat-embed-core, which is almost 50% larger generated native image 
size in order to support all use cases and features.




I looked at more code generation for web.xml since the digester is 
nice for that, but the benefit becomes even more questionable. It is 
harder to manage, and the generated classes have to be loaded 
dynamically [unless even more code is generated]. If there are tons of 
fragments, there is a good intuitive reason why it becomes useless. so 
I didn't want to do it. I prefer if things remain a bit EE-ish, 
ultimately.


I believe that tomcat-embed-core.jar with its META-INF GraalVM metadata 
files does support the EE feature set quite well, even though, those are 
manually maintained as well.


My primary goal was to create a leaner alternative, targeting images 
that specifically are looking to optimize image size and memory usage.



Thanks for chiming in,

Filip

Native Image - Reflectionless Concept

[Filip Hanik]

for discussion, all feedback and questions welcome:


I've created a concept of having Apache Tomcat, embedded, run without 
reflection in a native image.
This concept creates a jar, tomcat-embedded-programmatic.jar, that can be fine 
tuned to only include what is needed in a default configuration when an 
embedded tomcat instance is used and configured programatically.

Steps to run Apache Tomcat using Java 8 without reflection

  1.  Make sure you have native-image (from the graal installation) on your path
  2.  git clone -b feature/embed-minimal-programmatic-jar-file-master 
g...@github.com:fhanik/tomcat.git
  3.  cd tomcat/res/graal/
  4.  ./build-tomcat-native-image.sh && ./graal-measure.sh

Should yield an output similar to (Graal 20.1):
SUCCESS: the servlet is working
RSS memory: 20.7M
Image size: 20.5M


or using an older graal, 19.2
SUCCESS: the servlet is working
RSS memory: 18.0M
Image size: 16.7M


This also leaves a file named 
${java.io.tmpdir}/XReflectionIntrospectionUtils.java so that you can review the 
solution to IntrospectionUtils.java

Goals of this concept

  1.  Do not break anything
  2.  Create a new and optimized for size artifact, tomcat-embedded-programmatic
  3.  Remove reflection by introspecting classes that are currently passed into 
IntrospectionUtils.set/getProperty by generating setters/getters at build time

How it's done

  1.  I've build out a small introspection tool in the package 
org.apache.tomcat.util.xreflect
  2.  During build time, it analyses a set of known classes that are used with 
IntrospectionUtils.java, and generates XReflectionIntrospectionUtils.java
  3.  When it packages tomcat-embed-programmatic.jar it uses the generated code 
when calling setProperty and getProperty

A PR would look like this:
https://github.com/apache/tomcat/compare/master...fhanik:feature/embed-minimal-programmatic-jar-file-master?expand=1

Re: [tomcat] branch 9.0.x updated: Fixes OSGI bundling error

[Filip Hanik]

On 6/23/20 1:58 PM, Raymond Auge wrote:
Further review of your error seems to indicate you are not using the 
specified version of bnd. Have you overridden this in your 
build.properties file?


The regex in bnd 5.1.1 release is 
`((\(|\[)\d{1,9}(\.\d{1,9}(\.\d{1,9}(\.[-\w]+)?)?)?,\d{1,9}(\.\d{1,9}(\.\d{1,9}(\.[-\w]+)?)?)?(\]|\)))|\d{1,9}(\.\d{1,9}(\.\d{1,9}(\.[-\w]+)?)?)?`



Thank you Ray, that was it!

Filip




- Ray

On Tue, Jun 23, 2020 at 4:05 PM Raymond Auge <mailto:raymond.a...@liferay.com>> wrote:





On Tue, Jun 23, 2020 at 3:45 PM Filip Hanik
mailto:fi...@hanik.com>> wrote:

cd res/maven

ant -f mvn-pub.xml generic-install



I also ran this in the HEAD 9.0.x branch before your change
(919183b438e1a2f0004082c69e34accc0c3e2f16) without error.

- Ray

I usually run

ant clean deploy  embed

Also I've added github actions build at least in my master
fork that you can see is building on ubuntu and windows
here
https://github.com/rotty3000/tomcat/actions/runs/145316145

I'll test the instructions you've given next.

- ray

Is that last command working for you?

The error I'm getting is:

package:
  [jar] Building jar:

/development/pivotal/cloudfoundry/spring-projects/graal/tomcat10/output/build/lib/annotations-api.jar

add-osgi:
 [echo] add-osgi

/development/pivotal/cloudfoundry/spring-projects/graal/tomcat10/output/build/lib/annotations-api.jar
true
  [bnd] 1 ERRORS
  [bnd]  Invalid value for Bundle-Version,
${version_cleanup;9.0.0-native-image-dev} does not
match
[0-9]{1,9}(\.[0-9]{1,9}(\.[0-9]{1,9}(\.[0-9A-Za-z_-]+)?)?)?
  [bnd]

/development/pivotal/cloudfoundry/spring-projects/graal/tomcat10/res/bnd/annotations-api.jar.tmp.bnd:
bnd failed
  [bnd] at

aQute.bnd.ant.BndTask.executeBackwardCompatible(BndTask.java:240)
  [bnd] at
aQute.bnd.ant.BndTask.execute(BndTask.java:119)
  [bnd] at

org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)

Filip



- Ray

    On Tue, Jun 23, 2020 at 3:21 PM Filip Hanik
mailto:fha...@vmware.com>> wrote:

*From:* Raymond Auge mailto:raymond.a...@liferay.com>>
*Sent:* Tuesday, June 23, 2020 12:17 PM
*To:* Tomcat Developers List
mailto:dev@tomcat.apache.org>>
*Subject:* Re: [tomcat] branch 9.0.x updated:
Fixes OSGI bundling error

k, so travis config is borked.. I should add
github actions.

*//*

I don’t think Travis tests artifact generation

- Ray

On Tue, Jun 23, 2020 at 3:13 PM Raymond Auge
mailto:raymond.a...@liferay.com>> wrote:





-- 
*Raymond Augé*

<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)

Senior Software Architect *Liferay, Inc.*
<http://www.liferay.com> (@Liferay)




-- 
*Raymond Augé*

<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)

Senior Software Architect *Liferay, Inc.*
<http://www.liferay.com> (@Liferay)



-- 
*Raymond Augé*

<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
Senior Software Architect *Liferay, Inc.*
<http://www.liferay.com> (@Liferay)



-- 
*Raymond Augé*

<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
Senior Software Architect *Liferay, Inc.*
<http://www.liferay.com> (@Liferay)



--
*Raymond Augé* 
<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
<http://www.liferay.com> (@Liferay)

Re: [tomcat] branch 9.0.x updated: Fixes OSGI bundling error

[Filip Hanik]

On 6/23/20 12:38 PM, Raymond Auge wrote:
`ant test` transitively invokes `deploy` target which builds the 
artifacts.


You'll want to run the following commands that are currently failing for me

ant clean
ant
ant test-compile
ant embed

cd res/maven
ant -f mvn-pub.xml generic-install

Is that last command working for you?

The error I'm getting is:

package:
  [jar] Building jar: 
/development/pivotal/cloudfoundry/spring-projects/graal/tomcat10/output/build/lib/annotations-api.jar


add-osgi:
 [echo] add-osgi 
/development/pivotal/cloudfoundry/spring-projects/graal/tomcat10/output/build/lib/annotations-api.jar 
true

  [bnd] 1 ERRORS
  [bnd]  Invalid value for Bundle-Version, 
${version_cleanup;9.0.0-native-image-dev} does not match 
[0-9]{1,9}(\.[0-9]{1,9}(\.[0-9]{1,9}(\.[0-9A-Za-z_-]+)?)?)?
  [bnd] 
/development/pivotal/cloudfoundry/spring-projects/graal/tomcat10/res/bnd/annotations-api.jar.tmp.bnd: 
bnd failed
  [bnd] at 
aQute.bnd.ant.BndTask.executeBackwardCompatible(BndTask.java:240)

  [bnd] at aQute.bnd.ant.BndTask.execute(BndTask.java:119)
  [bnd] at 
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)


Filip



- Ray

On Tue, Jun 23, 2020 at 3:21 PM Filip Hanik <mailto:fha...@vmware.com>> wrote:


*From:* Raymond Auge mailto:raymond.a...@liferay.com>>
*Sent:* Tuesday, June 23, 2020 12:17 PM
*To:* Tomcat Developers List mailto:dev@tomcat.apache.org>>
*Subject:* Re: [tomcat] branch 9.0.x updated: Fixes OSGI bundling
error

k, so travis config is borked.. I should add github actions.

*//*

I don’t think Travis tests artifact generation

- Ray

On Tue, Jun 23, 2020 at 3:13 PM Raymond Auge
mailto:raymond.a...@liferay.com>> wrote:





--
*Raymond Augé* 
<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
<http://www.liferay.com> (@Liferay)

RE: [tomcat] branch 9.0.x updated: Fixes OSGI bundling error

[Filip Hanik]

From: Raymond Auge 
Sent: Tuesday, June 23, 2020 12:17 PM
To: Tomcat Developers List 
Subject: Re: [tomcat] branch 9.0.x updated: Fixes OSGI bundling error

k, so travis config is borked.. I should add github actions.

I don’t think Travis tests artifact generation

- Ray

On Tue, Jun 23, 2020 at 3:13 PM Raymond Auge 
mailto:raymond.a...@liferay.com>> wrote:

RE: [tomcat] branch 9.0.x updated: Make `ant -f mvn-pub.xml generic-install` work with the new ant tasks

[Filip Hanik]

Using outlook client, let's see if inline is working.

-Original Message-
From: Konstantin Kolinko  
Sent: Tuesday, June 23, 2020 11:36 AM
To: Tomcat Developers List 
Subject: Re: [tomcat] branch 9.0.x updated: Make `ant -f mvn-pub.xml 
generic-install` work with the new ant tasks

вт, 23 июн. 2020 г. в 21:12, :
>
> This is an automated email from the ASF dual-hosted git repository.
>
> fhanik pushed a commit to branch 9.0.x in repository 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitb
> ox.apache.org%2Frepos%2Fasf%2Ftomcat.git&data=02%7C01%7Cfhanik%40v
> mware.com%7Cac447e5f1a7e2d9f08d817a441a0%7Cb39138ca3cee4b4aa4d6cd8
> 3d9dd62f0%7C0%7C0%7C637285341532942037&sdata=QdBU7HneXndHvtLeai%2F
> brr1jHfcXAmmzcAcvbzej2Js%3D&reserved=0
>
>
> The following commit(s) were added to refs/heads/9.0.x by this push:
>  new 919183b  Make `ant -f mvn-pub.xml generic-install` work with 
> the new ant tasks 919183b is described below
>
> commit 919183b438e1a2f0004082c69e34accc0c3e2f16
> Author: Filip Hanik 
> AuthorDate: Tue Jun 23 11:11:24 2020 -0700
>
> Make `ant -f mvn-pub.xml generic-install` work with the new ant 
> tasks

1) What is meant by "new tasks"?

Filip:
We switched the ant tasks for Maven 
https://github.com/apache/tomcat/commit/5db7d814d046e8aa39ea2252343fba386a497f2e#diff-8009cab2171819dc35701f82f3b196b6

I see that mvn.properties.default has
maven-resolver-ant-tasks.version=1.2.0

Does it need an update to 1.2.1 (the latest version at Maven Central, dated 
2020-05-29)?
Or is it about some upcoming/snapshot version?

Filip:
I don't think so. The new task  doesn't have a file attribute.

2) This is 9.0.x. The master/10.0.x branch has not been updated yet.

Filip: Coming up

> ---
>  res/maven/mvn-pub.xml | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/res/maven/mvn-pub.xml b/res/maven/mvn-pub.xml index 
> ea504a2..15e9380 100644
> --- a/res/maven/mvn-pub.xml
> +++ b/res/maven/mvn-pub.xml
> @@ -50,8 +50,11 @@
>
>  
>
> -
> +
> +  
>
> +  
> +   + if:set="gpg.passphrase"/>
>  

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

RE: [tomcat] branch 9.0.x updated: Fixes OSGI bundling error

[Filip Hanik]

From: Raymond Auge 
Sent: Tuesday, June 23, 2020 11:58 AM
To: Tomcat Developers List 
Subject: Re: [tomcat] branch 9.0.x updated: Fixes OSGI bundling error

This is not a good fix. This is the same problem we had before with 
incompatible version syntax in OSGi

- Ray


Hi Ray, I can’t even build the libraries with your commit. What am I missing?

Re: Remove org.apache.catalina.tribes.transport.bio

[Filip Hanik]

On 4/29/20 8:56 AM, Rémy Maucherat wrote:
On Tue, Apr 28, 2020 at 7:18 PM Mark Thomas > wrote:


On 28/04/2020 17:30, Rémy Maucherat wrote:
> Hi,
>
> I'm still looking at things to remove or refactor in 10
following the
> rearchitecting failure for the Connector. One candidate could be the
> Tribes transport, since NIO is the default and BIO is probably
never used.
>
> Can it be removed ?

I don't see why not.

> There are a few classes here and there that could go too, for
example
> that BufferPool15Impl class. Given the name, I would say it could be
> merged into the superclass.

+1


Done. I wonder if this global static cache is actually that useful 
anymore.


ByteBuffers when first introduced, promised a lot, and delivered very 
little. The performance implications of creating new ones were pretty 
bad, imho.


There is a good chance that much of this has changed as the JVMs have 
evolved, and that a lot of code could be removed for the benefit of 
simplicity without sacrificing performance






Rémy


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org

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

Re: Remove org.apache.catalina.tribes.transport.bio

[Filip Hanik]

On Tue, Apr 28, 2020 at 10:18 Mark Thomas  wrote:

> On 28/04/2020 17:30, Rémy Maucherat wrote:
> > Hi,
> >
> > I'm still looking at things to remove or refactor in 10 following the
> > rearchitecting failure for the Connector. One candidate could be the
> > Tribes transport, since NIO is the default and BIO is probably never
> used.
> >
> > Can it be removed ?


+1.

>
>
> I don't see why not.
>
> > There are a few classes here and there that could go too, for example
> > that BufferPool15Impl class. Given the name, I would say it could be
> > merged into the superclass.
>
> +1


+1.

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

Re: [tomcat] branch 9.0.x updated (a7c132d -> 6ed7648)

[Filip Hanik]

Thanks Remy,

I’ll run the validator and adjust accordingly



On Tue, Apr 14, 2020 at 01:19 Rémy Maucherat  wrote:

> On Tue, Apr 14, 2020 at 1:50 AM  wrote:
>
>> This is an automated email from the ASF dual-hosted git repository.
>>
>> fhanik pushed a change to branch 9.0.x
>> in repository https://gitbox.apache.org/repos/asf/tomcat.git.
>>
>>
>> from a7c132d  Add 9.0.34 release date
>>  new 2e94898  Include Graal configuration files
>>  new 833625d  Make it known this is not a test class
>>  new 6ed7648  Merge pull request #274 from
>> fhanik/feature/graal-config-files-for-tomcat-9
>>
>> The 21920 revisions listed above as "new" are entirely new to this
>> repository and will be described in separate emails.  The revisions
>> listed as "add" were already present in the repository and have only
>> been added to this reference.
>>
>
> This commit needs to be fixed:
> - Not done in master (it can then be backported to 9)
> - Missing license header in many files (you can use the
> execute.validate=true property to verify)
> - Changelog
>
>
> Rémy
>
>

Re: API Change - Connector.java Constructor

[Filip Hanik]

On Fri, Apr 10, 2020 at 1:28 AM Rémy Maucherat  wrote:

>
>
>> This configuration gives the impression that the Endpoint is a child of
>> the Connector.
>> But the Connector truly only needs the ProtocolHandler interface to
>> function. The injected object would then be better to an instance of a
>> ProtocolHandler
>>
>> The XML can of course be configured to instantiate and inject the
>> ProtocolHandler handler directly into the Connector
>> In this setting, it doesn't make sense to have any properties on the
>> Connector, since the Connector receives the protocol handler already
>> configured.
>>
>> 
>> > maxHeaderCount="10" >
>>   > port="8443" SSLEnabled="true"
>>
>>  
>> sslImplementationName="org.apache.tomcat.util.net.openssl.OpenSSLImplementation">
>>   
>>   
>> > certificateKeyFile="${catalina.home}/conf/key.pem"
>>  certificateFile="${catalina.home}/conf/cert.pem"
>>  type="RSA" />
>>   
>>   
>>   > className="org.apache.coyote.http2.Http2Protocol" />
>>> 
>>
>
> Either way, I experimented a bit and it's not doable. Too many intrusive
> changes and impossibility to be compatible.
>

Sounds good.

Filip

Graal Files for Embedded jar files (9.0.x)

[Filip Hanik]

I have this one for review. I would categorize it as a safe, since it
doesn't affect backwards compatibility.

This PR [1]  has the following
components

1. Changes to build script to include reflection and resources files in
META-INF
2. The Graal configuration files under res/graal/
3. A sample embedded server
4. A script to build the native-image (requires GraalVM and native-image on
the path) under res/graal/
5. A script that runs and validates the native image under res/graal/

[1] https://github.com/apache/tomcat/pull/274

Re: API Change - Connector.java Constructor

[Filip Hanik]

Thanks Remy,

On Wed, Apr 8, 2020 at 8:48 AM Rémy Maucherat  wrote:

>
>>
> If we want to improve on the Connector situation regarding duplication and
> reflection abuse, the only solution is to expose the different objects
> involved.
>
> Since an example is usually better, I'll give one using server.xml.
>
> A typical Connector with TLS is at the moment:
>  protocol="org.apache.coyote.http11.Http11NioProtocol"
>SSLEnabled="true" scheme="https" secure="true"
>socket.directBuffer="true" socket.directSslBuffer="true"
> maxHeaderCount="10"
>
>  
> sslImplementationName="org.apache.tomcat.util.net.openssl.OpenSSLImplementation">
> 
>   certificateFile="${catalina.home}/conf/cert.pem"
>  type="RSA" />
> 
>  />
> 
>
> And it would become:
> 
>  port="8443" SSLEnabled="true"
>
>  
> sslImplementationName="org.apache.tomcat.util.net.openssl.OpenSSLImplementation">
>   
>   
>   certificateFile="${catalina.home}/conf/cert.pem"
>  type="RSA" />
>   
> 
>  maxHeaderCount="10" />
>  />
> 
>

This configuration gives the impression that the Endpoint is a child of the
Connector.
But the Connector truly only needs the ProtocolHandler interface to
function. The injected object would then be better to an instance of a
ProtocolHandler

The XML can of course be configured to instantiate and inject the
ProtocolHandler handler directly into the Connector
In this setting, it doesn't make sense to have any properties on the
Connector, since the Connector receives the protocol handler already
configured.



  
  
  

  
  
  
   

Filip


> t
> Each individual object is now created by the digester using normal bean
> rules, and I suppose it will become wired up by the Connector during init.
> Embedded can then do the same as the digester instead of having to go
> through the Connector object.
>
> Rémy
>
>
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>

Re: API Change - Connector.java Constructor

[Filip Hanik]

On Tue, Apr 7, 2020 at 9:35 AM Rémy Maucherat  wrote:

>
>> Does the connector need to know about the actual implementations?
>>
>
> Ideally no, but it removes the reflection you say is bad for Graal.
>

Correct. Turns out that the connectors use setProperty/getProperty via
reflection (IntrospectionUtils.setProperty/getProperty), so changing only
this constructor would achieve a mini step.
Before we commit any changes, I'd like to evaluate the scope of reflection
we're dealing with.

Then I can come back. I'll close the PR for now, as it only touches the
surface.

sound fair?

Filip

Re: API Change - Connector.java Constructor

[Filip Hanik]

On Tue, Apr 7, 2020 at 8:15 AM Rémy Maucherat  wrote:

> On Tue, Apr 7, 2020 at 10:16 AM Mark Thomas  wrote:
>
>> > Noted, I think a compromise may be in order. Where we simply add a
>> > constructor that avoids the Class.forName
>> > and that allows the developer to explicitly invoke a constructor that
>> > avoids it.
>>
>> My thinking was more along the following lines...
>>
>> Rewrite the Connector (and possibly some/all other components) so that
>> if a known class name was specified, rather than using the specified
>> name directly via reflection we could do something like:
>>
>> if ("org.apache.coyote.http11.Http11NioProtocol".equals(className)) {
>> protocol = new Http11NioProtocol();
>> } else if ("org...
>> ...
>> } else {
>> // OK. Unrecognised class name. Use reflection
>> ...
>> }
>>
>> Would that style of approach help at all?
>>
>
> Proposed patch:
> https://pastebin.com/ydCYnBD9
>

That patch works, I would include the check for the full classname too

Was: if ("HTTP/1.1".equals(protocol) || protocol == null)
Could be: if (protocol == null || "HTTP/1.1".equals(protocol) ||
"HTTP/1.1".equals(Http11NioProtocol.class.getName))

However, what still is awkward is that Connector.java deals with the
interface ProtocolHandler.
The loading of both the Http11NioConnector and the Ajp13NioConnector seems
to defy the purpose of having that interface being present

Is: protected final ProtocolHandler protocolHandler;

Does the connector need to know about the actual implementations?

Filip




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

Re: API Change - Connector.java Constructor

[Filip Hanik]

On Mon, Apr 6, 2020 at 11:20 AM Mark Thomas  wrote:

> On 06/04/2020 17:56, Filip Hanik wrote:
> > Team,
> >
> > As I'm slowly transitioning between projects, Apache Tomcat has once
> > again showed up in my workspace. I'm currently working on improving the
> > embedded experience for native images.
> >
> > I have a pull request,[1] <https://github.com/apache/tomcat/pull/267>,
> > that I'd like to open up a discussion about
> >
> > Goal: Able to start embedded Apache Tomcat without using reflection.
>
> Do you have a test case you are working to? It would be helpful to see
> exactly where the problems are in terms of what is considered reflection
> and what isn't.
>

Yes, I'm working on a sample that should demonstrate it.


> On that point, can we tell the tooling that reflection isn't used even
> if the automated analysis can't tell that? I'm thinking of something
> along the lines of ensuring that most execution paths - including
> embedded - avoid reflection. We should, hopefully, be able to document
> the scenarios where reflection is triggered so users know to avoid them.
>
> > This PR: Changes the constructor for Connector to not use reflection.
> > Instead the calling components will instantiate the ProtocolHandler
> >
> > Besides the constructor change, functionality should remain backwards
> > compatible.
>
> I am very uncomfortable changing the constructor for a fundamental
> component like Connector this far into a stable release - hence wanting
> to explore options.
>

Noted, I think a compromise may be in order. Where we simply add a
constructor that avoids the Class.forName
and that allows the developer to explicitly invoke a constructor that
avoids it.

Filip

API Change - Connector.java Constructor

[Filip Hanik]

Team,

As I'm slowly transitioning between projects, Apache Tomcat has once again
showed up in my workspace. I'm currently working on improving the embedded
experience for native images.

I have a pull request, [1] ,
that I'd like to open up a discussion about

Goal: Able to start embedded Apache Tomcat without using reflection.

This PR: Changes the constructor for Connector to not use reflection.
Instead the calling components will instantiate the ProtocolHandler

Besides the constructor change, functionality should remain backwards
compatible.

Please provide feedback, such as
1. Are we open to making API changes like this?
2. Does the PR introduce any problems?

Thank you
Filip

[1] https://github.com/apache/tomcat/pull/267

Re: Request line parsing

[Filip Hanik]

+1

Thorough and clear write up

On Mon, Mar 23, 2020 at 06:01 Mark Thomas  wrote:

> Hi,
>
> I am currently looking at the request line parsing. I'll try and set out
> each issue in turn.
>
> End of line parsing
> ===
>
> Prior to the recent changes, Tomcat allowed CRLF or LF to mark the end
> of a line. The unwanted side effect was that CR could appear in the
> header value. This caused problems and was tightened up to only allow
> CRLF as a line terminator.
>
> Currently Tomcat requires CRLF everywhere apart from the end of the
> request line for a HTTP 0.9 request where it also allows LF.
>
> This requirement to accept just LF as a line terminator first emerged in
> the W3C spec [1]. RFC 1945 [2] and RFC 2616 [3] retained this as a
> recommendation for all line terminators, RFC 7230 [4] no longer includes
> this recommendation.
>
> RFC 7230 also removes the expectation that a server that supports
> HTTP/1.1 will support HTTP 0.9.
>
> Arguably the current spec for HTTP/0.9 is [3].
>
> The Servlet spec references RFC 7230 and RFC 1945 so arguably HTTP/0.9
> support is expected.
>
>
> SP vs whitespace
> 
>
> Tomcat currently accepts any combination of SP and HTAB where RFC 7230
> calls for a single SP. This stems from a recommendation in RFC 2616
> which is no longer present in RFC 7230.
>
>
> I think we have three options.
>
> 1. No changes.
>CRLF is required everywhere apart from HTTP/0.9 where LF is also
>accepted.
>Any combination of SP/HTAB is accepted where SP is required.
>
> 2. Tighten up as per RFC 7230
>a) Require CRLF for all line endings
>b) Require SP where specified
>c) Drop HTTP/0.9 support
>
> 3. Relax the recent changes to allow CRLF or LF as a line terminator
>everywhere without allowing CR to appear in a request header.
>
> I think we should follow 1) for Tomcat 7, 8 & 9.
>
> I'm leaning towards 1 for 10.0.x as well with a view to discussing 2 in
> the Servlet project. i.e. explicitly dropping HTTP 0.9 support and the
> "Tolerant applications" requirements of RFC 1945 for Jakarta EE 10
> (Tomcat 10.1.x).
>
> In short this means largely do nothing apart from may be adding a few
> more tests to explicitly check behaviour for various edge cases.
>
> I'll note that the regressions reported with the recent change to
> requiring CRLF as a line terminator caused issues with valid HTTP/0.9
> requests but that this should now be resolved.
>
> We have had one user issue reported where a custom client was using LFLF
> as a line terminator and requests are now being rejected. Given that was
> never valid, I'm OK with that.
>
> Thoughts?
>
> Mark
>
>
>
> [1] https://www.w3.org/Protocols/HTTP/AsImplemented.html
> [2] https://tools.ietf.org/html/rfc1945
> [3] https://tools.ietf.org/html/rfc2616
> [4] https://tools.ietf.org/html/rfc7230
>
>
>
>
>
> With all of the above in mind I propose:
>
> - Doing nothing! I think Tomcat is striking the right balance here.
>
> This means:
> GET /CRLF   -> processed as HTTP/0.9
> GET /LF -> processed as HTTP/0.9
> GET / CRLF  -> processed as HTTP/1.1 and rejected as invalid
> GET / LF-> processed as HTTP/1.1 and rejected as invalid
>
> I want to write some tests to check this is behaving as expected but I'm
> not expecting any changes to the parsing at this point.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: For review: EncryptInterceptor for Cluster/Tribes

[Filip Hanik]

On Tue, Oct 23, 2018 at 7:05 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> All,
>
> Can I get a technical review for (a) appropriateness and (b) technical
> implementation of the attached cluster interceptor? Let's assume for a
> moment that encryption is something worth adding to clustering and not
> argue that point.
>

Sure! But maybe you can narrow down the need/use case?
ie, would just point-to-point TLS be sufficient? so that all bytes got
encrypted?
or do you want a WhatsApp type of security, where only sender and receiver
can share the a specific data package?

>
> It should be straightforward. Knowing virtually nothing about the way
> that Tribes works, implementing this as an interceptor seemed like the
> least invasive (and easiest!) way to add encryption to clustering.
>
> The only question I have about what I've actually written is what to
> do about the cipher IV? Both sides of the conversation need to know
> the IV in order to communicate. Should I just add another member to
> the class for the IV and require that users specify both the key AND
> the IV?
>

That would be one way. I think the idea of having to share a key may be the
only drawback in your implementation.
Have you considered maybe using asymmetrical encryption?

In that scenario, you would have
MemberImpl.payload = certificate or public key
Each member can broadcast their certificate, and a sender can use it to
encrypt the data only the receiver can read.
No sharing of keys.

The encryption would still be done in an interceptor just like you have it.
The Local member would hold the private key for decryption.

Filip



>
> Thanks,
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvPKqsACgkQHPApP6U8
> pFgGSxAAy1vj8FY7uzcvstimHwUGKd6dJkFiKRxygY30Lp3bHor5O4GKoWP4eWwJ
> l0rl0ojvhgLzHwPB/+Cdm1gpZD2cSSiqyz3V6eGlt8oq8mm3M4lCMqZqXckNHYG5
> cSRHXPIO0XaoCrUR2KA4NRS207OXTUYZe7ihPb0Bblev5SE/S/vIArRs+1Gybdi+
> zYXY4XwBUHRHu2PzWy6c0HFPP3hDJ85I3Mn4O/uqZgh01eRRpsfvbmros45znTfc
> frKqBeT3O/+dwNOX9HhshnIW92U8dyYto70CsKdtPrsVXpY9kQH3zOc3vC+UN2qf
> jJZYie32mHjg22JDrYOqFpfAhTQi9r4xUMzprMVjTk93p34SxvmZNbLBVi/Li6OA
> PdthMBpHiAQp+bLVGSU4UbHdEG9t/Ixp8RodWJzxGWtduy3/GGCsifQke5H6yBf5
> Kb3Rux4u/3mKwn0PZL8HljUgEZCge3g1+KOX1qL9Uw5TCKm4YIF744C1P7piSllR
> GW3UxamATH4qmZ/ccAUJVBgdQQYPjVKAc0tAvCVBZSxf6+OB8D5HfA/A8f8N7Fzj
> wBVPbcW5d4OjFpjEshOtehb74q1WAGhg1+rUkPbd1Nkd/WTQN8YXXayN0+TE28gm
> LPSv8RSsAEWFLzh/TiY8BNzdehEaHID6R6h5q7io9JNMbtljhgQ=
> =nSgU
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Tomcat JDBC Pool memory leak when using StatementFinalizer interceptor

[Filip Hanik]

Thanks Martin, I agree, regardless of use case, the pool should not
generate a leak.

let me review your proposal

Filip

On Wed, Jul 18, 2018 at 07:48 Martin Knoblauch  wrote:

> On Wed, Jul 18, 2018 at 3:24 PM, Martin Knoblauch 
> wrote:
>
> > Hi  Filip,
> >
> > On Fri, Jul 13, 2018 at 4:33 PM, Filip Hanik  wrote:
> >
> >> hi Martin,
> >>
> >> On Fri, Jul 13, 2018 at 5:48 AM, Martin Knoblauch 
> >> wrote:
> >>
> >> > Hi, (moving to developers list)
> >> >
> >> >  any ideas on the problem below? This thing is kind of itching me :-)
> >> >
> >> > So I instrumented the "StatementFinalizer" class with some logging and
> >> > learned that over time a few instances of the "StatementFinalizer" are
> >> > created, used and destroyed. So far so good. For most of those
> >> instances,
> >> > the overall number of statements that are added to the "statements"
> >> list by
> >> > "createStatement" and the number of statements removed from the list
> by
> >> > "closeInvoked" is identical and after "closeInvoked" finishes, the
> list
> >> is
> >> > empty.
> >> >
> >> >  But only for most instances of "StatementFinalizer". I could find
> that
> >> > there is one instance that is used (statements are added), but the
> >> > invocation of "closednvoked" stops after some minutes into the
> >> application.
> >> > As a result the "statements" list starts growing.
> >> >
> >>
> >> ​Could it be that your application checks out a connection and uses it
> for
> >> the life time of the application?
> >> Meaning Connection.close is never called?
> >>
> >>
> >  So in fact some instrumentation and digging deeper showed 3 different
> > problems in the application:
> >
> > 1) there is one SQL Statement not closed (revealed by
> > "StatementFinalizer(trace=true)")
> > 2) there is one connection not closed after the "final" SQL statement
> > (revealed by properly activating the "Abandoned" mechanism)
> > 3) there is one connection that is used heavily over the entire lifetime
> > of the application, and never closed. This one accumulates the memory
> that
> > made me ask the "leak" question
> >
> > Need to address all three to the application developers.
> >
> > Given that 1+2 each only happen once, the best solution to avoid the
> > "leak" might really be to just not use the "StatementFinalizer".
> >
> >
> >
> But then, just for the fun of it, would something like this patch be of
> interest? It adds a private method "removeClosed()" to the
> "StatementFinalizer code. What it does is to remove all "closed" or "null"
> statements from the "statements" list. In order to keep it low in the
> performance profile, it only does this every "sweepMinutes" minutes (new
> interceptor property). My testing shows it keeps the memory consumption
> down.
>
> Martin
>
> ---
>
> apache-tomcat-8.0.36-src/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java
> 2016-06-09 16:00:49.0 +0200
> +++
>
> apache-tomcat-8.0.36-src-mkn/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java
> 2018-07-18 14:53:35.242785369 +0200
> @@ -18,7 +18,9 @@
>
>  import java.lang.ref.WeakReference;
>  import java.lang.reflect.Method;
> +import java.sql.SQLException;
>  import java.sql.Statement;
> +import java.util.Iterator;
>  import java.util.LinkedList;
>  import java.util.List;
>  import java.util.Map;
> @@ -40,15 +42,64 @@
>  protected List statements = new LinkedList<>();
>
>  private boolean logCreationStack = false;
> +private long sweepMillis = 0;
> +private long lastSweep = 0;
> +
> +private int addedStmts = 0;
> +
> +/**
> + * Removes closed or "null" statements from the "statements" list. Useful
> for connections that are
> + * never closed. Returns without doing anything in the following cases:
> + *  - Interceptor property "sweepMinutes" is 0 (default)
> + *  - First call after "borrow"
> + *  - Time difference between now and last sweep  has not reached yet
> + *  - Only one statement on list (or list is empty)
> + */
> +private void removeClosed() {
> +
> +  

Re: Tomcat JDBC Pool memory leak when using StatementFinalizer interceptor

[Filip Hanik]

hi Martin,

On Fri, Jul 13, 2018 at 5:48 AM, Martin Knoblauch 
wrote:

> Hi, (moving to developers list)
>
>  any ideas on the problem below? This thing is kind of itching me :-)
>
> So I instrumented the "StatementFinalizer" class with some logging and
> learned that over time a few instances of the "StatementFinalizer" are
> created, used and destroyed. So far so good. For most of those instances,
> the overall number of statements that are added to the "statements" list by
> "createStatement" and the number of statements removed from the list by
> "closeInvoked" is identical and after "closeInvoked" finishes, the list is
> empty.
>
>  But only for most instances of "StatementFinalizer". I could find that
> there is one instance that is used (statements are added), but the
> invocation of "closednvoked" stops after some minutes into the application.
> As a result the "statements" list starts growing.
>

​Could it be that your application checks out a connection and uses it for
the life time of the application?
Meaning Connection.close is never called?

I see that you set ​`removeAbandonedTimeout="0"` which yields in an
infinite value.
This would be done if an application never closes a connection.

If you set removeAbandonedTimeout to a positive value and the system logs
that your connections are not being closed, then you know this is the case.

If that is the scenario you have, then you should simply remove the
StatementFinalizer as it will not do anything for you.

In most cases you shouldn't need StatementFinalizer, as applications (and
frameworks) are pretty at closing resources properly.


Filip




>
>  Rings any bells?
>
> Thanks
> Martin
>
> On Wed, Jul 11, 2018 at 4:22 PM, Martin Knoblauch 
> wrote:
>
> > Hi,
> >
> >  while analyzing some heap dump for other reasons, I found that our
> > application is apparently aggregating a considerable amount of memory in
> > "org.apache.tomcat.jdbc.pool.TrapException", which is never cleaned by
> > GC. Digging deeper, it seems that the entries of the "statements" linked
> > list in the StatementFinalizer are never removed from the list, so after
> > three weeks of lifetime one ends up with a list of 7 million entries,
> each
> > 80 bytes.
> >
> >  Now it might be, that we are just using the StatementFinalizer in a
> wrong
> > manner. And what we see is expected behavior. Below is our pool
> > configuration. Maybe something is just missing :-)
> >
> > We are at Tomcat 8.0.36 (yeah, I know, but that is the version we have to
> > use) and Java 8 (1.8.0_171). Underlying DB is Oracle 12.1.0.2 and we are
> > using the latest "ojdbc7.jar" from Oracle.
> >
> >
> >  > name="jdbc/SimManagerDS"
> > auth="Container"
> >
> > type="javax.sql.DataSource"
> > description="Oracle datasource for xxx using
> > tomcat.jdbc.pool"
> > factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
> > jmxEnabled="true"
> > jdbcInterceptors="ConnectionState;StatementFinalizer;
> > ResetAbandonedTimer;StatementCache(prepared=true,max=200)"
> >
> > initialSize="7"
> > minIdle="7"
> > maxActive="30"
> > maxIdle="10"
> >
> > testWhileIdle="true"
> > testOnBorrow="true"
> > testOnConnect="false"
> > testOnReturn="false"
> > validationQuery="SELECT 1 from dual"
> > validationInterval="3"
> >
> > logAbandoned="true"
> > removeAbandoned="false"
> > removeAbandonedTimeout="0"
> > suspectTimeout="600"
> >
> > timeBetweenEvictionRunsMillis="3"
> > minEvictableIdleTimeMillis="6"
> > maxWait="6"
> > maxAge="0"
> >
> > connectionProperties="(defaultRowPrefetch=200)"
> >
> > driverClassName="oracle.jdbc.OracleDriver"
> > url="jdbc:oracle:thin:@s###"
> > username=""
> > password=""
> >/>
> >
> > Thanks
> > Martin
> > --
> > --
> > Martin Knoblauch
> > email: k n o b i AT knobisoft DOT de
> > www: http://www.knobisoft.de
> >
>
>
>
> --
> --
> Martin Knoblauch
> email: k n o b i AT knobisoft DOT de
> www: http://www.knobisoft.de
>

Re: svn commit: r1644737 - /tomcat/trunk/webapps/docs/config/systemprops.xml

[Filip Hanik]

Mr Schultz, nothing prevents you from removing the spaces if you at the
same time fix the formatting or provide a solution to it.
I do agree, that the spaces in the code for the sake of formatting is
pretty lame, as it makes for erroneous copy/paste.

On Thu, Dec 11, 2014 at 1:03 PM, Mark Thomas  wrote:

> On 11/12/2014 19:49, schu...@apache.org wrote:
> > Author: schultz
> > Date: Thu Dec 11 19:49:25 2014
> > New Revision: 1644737
> >
> > URL: http://svn.apache.org/r1644737
> > Log:
> > Removed extraneous spaces from system property keys.
>
> -1.
>
> Those spaces are there for a good reason - it makes the page readable.
> The other system properties have them too.
>
> Mark
>
>
> >
> > Modified:
> > tomcat/trunk/webapps/docs/config/systemprops.xml
> >
> > Modified: tomcat/trunk/webapps/docs/config/systemprops.xml
> > URL:
> http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/systemprops.xml?rev=1644737&r1=1644736&r2=1644737&view=diff
> >
> ==
> > --- tomcat/trunk/webapps/docs/config/systemprops.xml (original)
> > +++ tomcat/trunk/webapps/docs/config/systemprops.xml Thu Dec 11 19:49:25
> 2014
> > @@ -597,32 +597,32 @@
> >
> >
> >
> > -
> > + name="org.apache.tomcat.websocket.ALLOW_UNSUPPORTED_EXTENSIONS">
> >If true, allow unknown extensions to be declared
> by
> >the user.
> >The default value is false.
> >  
> >
> > -
> > + name="org.apache.tomcat.websocket.DEFAULT_ORIGIN_HEADER_VALUE">
> >Default value of the origin header that will be sent by the
> client
> >   during the upgrade handshake.
> >The default is null so that no origin header is sent.
> >  
> >
> > -
> > +
> >The number of periodic ticks between periodic processing which
> >   involves in particular session expiration checks.
> >The default value is 10 which corresponds to 10
> >   seconds.
> >  
> >
> > -
> > + name="org.apache.tomcat.websocket.DISABLE_BUILTIN_EXTENSIONS">
> >If true, disable all built-in extensions provided
> by the
> >   server, such as message compression.
> >The default value is false.
> >  
> >
> > -
> > + name="org.apache.tomcat.websocket.STREAMS_DROP_EMPTY_MESSAGES">
> >If true, streams provided to the user (writer and
> output
> >stream) will not send an empty message when flushing and there is
> no
> >data to flush, or when it is closed without having been used (for
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Tomcat 9 work started

[Filip Hanik]

I honestly don't see the value of keeping BIO around. At this point in
time, there can be little else other than an emotional attachment to it. As
mentioned in this thread, the APIs and need for more functionality in the
connectors have rendered the BIO connector obsolete. If we believe that a
Tomcat 9 user would choose BIO for stability (which may have been the case
early NIO days), then the solution to that is to fix the NIO connector. The
solution should not be supporting the BIO with hacks.

I don't feel this thread has provided any real use cases that would justify
BIO remaining alive.

For example:

>We use the BIO AJP connector because we don't need
>to handle huge numbers of requests and deal with keepalive timeouts and
>all that stuff: the web server handles that for us

ok, fair enough. I actually don't know the state of the NIO AJP connector.
And I don't know what level of async or HTTP2 features AJP would even
support.

>The NIO sim-blocking (which being practical, in contrast to the
>impractical sim-non-blocking achieved by untold evils in the BIO
>connector) is kind of hacky and burns unnecessary CPU time when no
>asynchronous operations are involved.

Seems to be a contradiction to the previous statement where load was not an
issue. I truly don't see how these extra CPU cycles are an issue. And if
measured, would they even be noticeable.

Having to reimplement BIO, then add hacks around new API's seems like one
step forward two steps backwards.
Sometimes it may benefit us all to embrace change

Filip




On Mon, Nov 3, 2014 at 3:08 PM, Mark Thomas  wrote:

> On 03/11/2014 21:33, Rémy Maucherat wrote:
> > 2014-11-03 22:00 GMT+01:00 Mark Thomas :
> >
> >> The only times I see NIO go awry these days is in the async code and
> >> that is as complex as it is partly to support the continued use of BIO.
> >>
> >> There was a small hack in 7.0.x for async processing, a larger hack in
> >> 8.0.x for non-blocking I/O. I suspect an even bigger hack would be
> >> required in 9.0.x.
> >>
> >> If folks don't need async features and want to use BIO simply use Tomcat
> >> 8. Based on the typical life time of a major Tomcat version that is
> >> likely to be around for a good few years yet.
> >>
> > I wasn't really around when this was discussed, but it is a problem to
> > advertise support for Servlet 3.1 in the BIO connector. Although the API
> is
> > technically implemented, the thread model is not going to be able to
> > successfully run real apps. If there's too much demand for BIO, it could
> > stay with a lot of unsupported operations exceptions (that would also
> > include upgrade and 3.1+ non blocking mode this time).
> >
> > Comet is probably more significant than BIO for removing old code.
>
> I was going to start with removing BIO but since removing Comet appears
> to be less contentious I'll start with that.
>
> I've been spending the last hour or so looking at our current SPDY
> implementation. We are going to have issues there as well. It targets
> SPDY/2 which most browsers no longer support. Servlet 4.0 is targeting
> HTTP/2 which is going to be roughly SPDY/4+
>
> I don't know how much of the existing SPDY code is going to make sense
> with HTTP/2 but I do know what we currently have is broken with most
> browsers. I'm currently leaning towards excluding the current SDPY code
> from the build until the connector refactoring is complete and then look
> at it more closely to figure out what we can keep, what needs
> refactoring and what needs to go.
>
> To stand any chance of a robust HTTP/2 implementation I think the
> connectors need an overhaul. Hence my plans for refactoring. The more
> duplication and old/obsolete features we can remove the easier this
> clean up is going to be. Removing BIO support and the associated hacks
> is part of this clean-up.
>
> While I'm not convinced by the need to continue to provide a blocking
> connector implementation, I'm not against re-instating BIO support once
> the clean-up is complete if BIO support can be restored cleanly. What I
> want to avoid is a requirement to have to support a blocking connector
> to influence the connector refactoring.
>
> To put it another way:
> - drop BIO support now
> - clean-up the connectors
> - re-add BIO support (if possible)
> - all BIO related hacks will be in BIO specific code
>
> I'd be prepared to bend that last point depending on what the hack was.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: git (yet again)

[Filip Hanik]

On Tue, Sep 2, 2014 at 10:52 AM, Rémy Maucherat  wrote:

> 2014-09-02 18:41 GMT+02:00 Mark Thomas :
>
> > I'm leaning towards A myself.
>

​
The move to git clears a huge hurdle, and that is managing contributions.
The patch system is very difficult, and impossible to maintain. A pull
request stays alive
​ and can be maintained through code changes​
. I believe we can get more contributions by moving to Git.
​


> >
>
> Oh wow, does this mean I can resurrect my thread on Maven too ? (ideally,
> we should also move to it first, then think about how to use it later,
> otherwise people will never vote in favor)
>

​Let's skip Maven and move straight to Gradle, it has the benefit of not
needing a build system installed on the developers machine, as it gets
downloaded by the wrapper checked into the repo. This is yet one less
version that is required by the contributor.
It's built on top of Ant, and should give us all the flexibility we need.​


>
> :)
>
> Rémy
>

Re: RFC6265, cookie parsing and UTF-8

[Filip Hanik]

On Tue, Aug 26, 2014 at 12:53 PM, Mark Thomas  wrote:

> One of the aims of the proposed cookie changes [1] was to deal with the
> HTML 5 changes that mean UTF-8 can appear in cookie headers.
>
> This has some potentially large implications for Tomcat.
>

​Since we already are in the 8.0.x release cycle, I, as an end user/system
administrator, would expect parsing would remain 100% backwards compatible
for version 8.0.x+n (n=1...)​



>
> Currently, Tomcat handles cookies as MessageBytes, processing everything
> in bytes and only converting to String when necessary. This is largely
> possible because of the assumption that everything is ASCII.
>
> Introduce UTF-8 and processing everything in bytes gets a whole lot
> harder. You essentially have to decode to UTF-8 to ensure that you have
> valid data - at a which point why not just use Strings anyway?
>
> I am currently leaning towards removing a lot of the current cookie
> header caching  recycling and doing something along the following lines:
>

​all that caching/recycling is to avoid GC cycles and was in the past a
crucial performance optimization.
​back in those days, with the hardware that was available in 06-07, we were
pushing a single Tomcat instance to 60k requests per second.
creating new objects was painfully expensive at that rate.


> - Lazy parsing as currently (but unless cookie based session tracking is
>   disabled this is going to run on every request)
>

​but our cookies, JSESSIONID, doesn't have to be UTF-8, does it?
this goes hand in hand with the SessionIdGenerator that Rainer just did,
can that return UTF-8 values?
So the lazy part can apply to all other cookies, meaning, don't parse it
until the app requests it, just store the bytes and move on.
​

> - Convert headers to UTF-8 strings

- Parse them with a new parser along the lines of o.a.t.u.http.parser
> - Have that parser return an array of javax.servlet.http.Cookie objects
> - Pass those to the app if/when requested
>
> In terms of handling RFC6265 and RFC2109 my plan is to have two parsers,
> share as much code as possible and switch between them based on the
> cookie header with the expectation that 99.9% of cookies will be parsed
> by the RFC6265 parser. We could add some options to this switching to
> enable other parsers (e.g. a Netscape parser) to be used.
>

​I like the idea of swappable parsers, with the default is the exact
behavior you see now. I can see changing the default after some
stabilization.​



>
> I'd also like to keep the current cookie parsing implementation for now.
> Until we are happy with the new parsing, the current implementation will
> be the default. Once we are happy with the new parsing we can change the
> default. We can add an option to switch between the current and the new
> parsing.
>
> Thoughts?
>

​knock it out. ​



>
>
> Mark
>
>
> [1] https://wiki.apache.org/tomcat/Cookies
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Coverity static analysis scanning

[Filip Hanik]

hook me up

On Tuesday, August 26, 2014, Mark Thomas  wrote:

> All,
>
> I have been pinged off-list by Coverity to say that they have set up
> Tomcat with a free account with their static code analysis service.
>
> I think I have the ability to send invitations so if anyone wants to
> take a look at the results, just reply here.
>
> I have taken a quick look and they do appear to have found some valid
> threading issues. There are ~350 issues in total and I don't yet have a
> feel for the false positive rate.
>
> Mark
>
> -
> 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.0.11

[Filip Hanik]

 [X] Stable - go ahead and release as 8.0.11

Looks good over here.




On Mon, Aug 18, 2014 at 8:28 AM, Mark Thomas  wrote:

> On 15/08/2014 21:07, Mark Thomas wrote:
> > The proposed Apache Tomcat 8.0.11 release is now available for voting.
> >
> > The main changes since 8.0.9 are:
> > - Various improvements to the Mapper including fixing some concurrency
> >   bugs
> > - Update to Tomcat Native Library version 1.1.31 to pick up the Windows
> >   binaries that are based on OpenSSL 1.0.1h
> > - Start to add permessage-deflate to WebSocket. Currently only client
> >   to server compression is supported.
> > - Support for using the OpenSSL cipher syntax with JSSE connectors
> > - Numerous bug fixes
> >
> > There is also the usual collection of bug fixes, new features and
> > performance improvements. For full details, see the changelog:
> >
> http://svn.us.apache.org/repos/asf/tomcat/trunk/webapps/docs/changelog.xml
> >
> > It can be obtained from:
> > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.11/
> > The Maven staging repo is:
> > https://repository.apache.org/content/repositories/orgapachetomcat-1020/
> > The svn tag is:
> > http://svn.apache.org/repos/asf/tomcat/tc8.0.x/tags/TOMCAT_8_0_11/
> >
> > The proposed 8.0.11 release is:
> > [ ] Broken - do not release
> > [X] Stable - go ahead and release as 8.0.11
>
> Unit tests pass on OSX, Windows and Linux (all 64-bit, BIO, NIO, NIO2
> and APR/native).
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: svn commit: r1616644 - in /tomcat/trunk/modules/jdbc-pool: doc/jdbc-pool.xml src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java

[Filip Hanik]

you are right, I will resolve it on Monday
thanks for the review
Filip



On Sun, Aug 10, 2014 at 5:38 PM, Konstantin Kolinko 
wrote:

> 2014-08-08 4:04 GMT+04:00  :
> > Author: fhanik
> > Date: Fri Aug  8 00:04:51 2014
> > New Revision: 1616644
> >
> > URL: http://svn.apache.org/r1616644
> > Log:
> > Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=56318
> > Contribution by Danila Galimov
> > Ability to log statement creation stacks
> >
> > Modified:
> > tomcat/trunk/modules/jdbc-pool/doc/jdbc-pool.xml
> >
> tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java
> >
> > Modified: tomcat/trunk/modules/jdbc-pool/doc/jdbc-pool.xml
> > URL:
> http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/doc/jdbc-pool.xml?rev=1616644&r1=1616643&r2=1616644&view=diff
> >
> ==
> > --- tomcat/trunk/modules/jdbc-pool/doc/jdbc-pool.xml (original)
> > +++ tomcat/trunk/modules/jdbc-pool/doc/jdbc-pool.xml Fri Aug  8 00:04:51
> 2014
> > @@ -608,6 +608,13 @@
> > and closes these statements when the connection is returned to
> the pool.
> >  
> >  
> > +  
> > +(boolean as String) Enable tracing of unclosed statements.
> > +   When enabled and a connection is closed, and statements are
> not closed,
> > +   the interceptor will log all stack traces.
> > +   The default value is false.
> > +
> > +  
> >  
> >
> > name="org.apache.tomcat.jdbc.pool.interceptor.StatementCache">
> >
> > Modified:
> tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java
> > URL:
> http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java?rev=1616644&r1=1616643&r2=1616644&view=diff
> >
> ==
> > ---
> tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java
> (original)
> > +++
> tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java
> Fri Aug  8 00:04:51 2014
> > @@ -19,6 +19,7 @@ package org.apache.tomcat.jdbc.pool.inte
> >  import org.apache.juli.logging.Log;
> >  import org.apache.juli.logging.LogFactory;
> >  import org.apache.tomcat.jdbc.pool.ConnectionPool;
> > +import org.apache.tomcat.jdbc.pool.PoolProperties;
> >  import org.apache.tomcat.jdbc.pool.PooledConnection;
> >
> >  import java.lang.ref.WeakReference;
> > @@ -26,6 +27,8 @@ import java.lang.reflect.Method;
> >  import java.sql.Statement;
> >  import java.util.LinkedList;
> >  import java.util.List;
> > +import java.util.Map;
> > +
> >  /**
> >   * Keeps track of statements associated with a connection and invokes
> close upon {@link java.sql.Connection#close()}
> >   * Useful for applications that dont close the associated statements
> after being done with a connection.
> > @@ -34,13 +37,15 @@ import java.util.List;
> >  public class StatementFinalizer extends
> AbstractCreateStatementInterceptor {
> >  private static final Log log =
> LogFactory.getLog(StatementFinalizer.class);
> >
> > -protected List> statements = new
> LinkedList<>();
> > -
> > +protected List> statements = new
> LinkedList<>();
>
>
> 1. This approach is broken.
>
> Essentially this change breaks StatementFinalizer.
>
> A weak reference to a Statement is OK, because there are hard
> references to that statement object elsewhere.
>
> A weak reference to a StatementEntry class is not OK,  because it is
> the only reference to it. It is immediately eligible to be
> garbage-collected.
>
>
> > +
> > +private boolean logCreationStack = false;
> > +
> >  @Override
> >  public Object createStatement(Object proxy, Method method, Object[]
> args, Object statement, long time) {
> >  try {
> >  if (statement instanceof Statement)
> > -statements.add(new
> WeakReference<>((Statement)statement));
> > +statements.add(new WeakReference<>(new
> StatementEntry((Statement)statement)));
> >  }catch (ClassCastException x) {
> >  //ignore this one
> >  }
> > @@ -50,25 +55,58 @@ public class StatementFinalizer extends
> >  @Override
> >  public void closeInvoked() {
> >  while (statements.size()>0) {
> > -WeakReference ws = statements.remove(0);
> > -Statement st = ws.get();
> > +WeakReference ws = statements.remove(0);
> > +StatementEntry st = ws.get();
> >  if (st!=null) {
> >  try {
> > -st.close();
> > +st.getStatement().close();
> >  } catch (Exception ignore) {
> >  if (log.isDebugEnabled()) {
> >  log.debug("Unab

Re: svn commit: r1616789 - /tomcat/trunk/modules/jdbc-pool/doc/changelog.xml

[Filip Hanik]

changelog was probably built when it was published by itself in the V1
days. we can move it to the main changelog, under jdbc-pool




On Sun, Aug 10, 2014 at 3:42 PM, Konstantin Kolinko 
wrote:

> 2014-08-08 18:53 GMT+04:00  :
> > Author: fhanik
> > Date: Fri Aug  8 14:53:06 2014
> > New Revision: 1616789
> >
> > URL: http://svn.apache.org/r1616789
> > Log:
> > Update changelog with recent fixes
> >
> > Modified:
> > tomcat/trunk/modules/jdbc-pool/doc/changelog.xml
> >
> > Modified: tomcat/trunk/modules/jdbc-pool/doc/changelog.xml
> > URL:
> http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/doc/changelog.xml?rev=1616789&r1=1616788&r2=1616789&view=diff
> >
> ==
> > --- tomcat/trunk/modules/jdbc-pool/doc/changelog.xml (original)
> > +++ tomcat/trunk/modules/jdbc-pool/doc/changelog.xml Fri Aug  8 14:53:06
> 2014
> > @@ -28,6 +28,25 @@
> >
> >
> >  
> > +
> > +
>
> 1. The version number is wrong. The next version is 8.0.11.
>
> (8.0.10 was tagged a month ago and failed the vote).
>
> 2. This changelog file is not built and is not included with Tomcat
> releases.
> Is it really needed here?
>
> In Tomcat 7 we used subsection name "jdbc-pool" to list Tomcat-JDBC
> pool changes. I think we should do the same for Tomcat 8.
>
> (There have not been any such changes in 8.0.0-8.0.10, so it is the
> first time when this section will be used in Tomcat 8).
>
> Best regards,
> Konstantin Kolinko
>
> > +  
> > +
> > +  1616760 54227 Evaluate max age upon
> borrow (fhanik)
> > +  1616644 56318 Ability to trace
> statement creation in StatementFinalizer (fhanik)
> > +  1616639 53088 More identifiable thread
> name (fhanik)
> > +  1616629 56789 getPool() returns the
> actual pool, always (fhanik)
> > +  1616625 54978 Make sure proper
> connection validation always happens, regardless of config (fhanik)
> > +  1616602 54537 Performance improvement
> in StatementFinalizer (fhanik)
> > +  1616599 54395 Fix JDBC interceptor
> parsing bug (fhanik)
> > +  1616595 54235 Disallow nested pools
> exploitating using data source (fhanik)
> > +  1616592 54225 Disallow empty init SQL
> (fhanik)
> > +  1616584 53853 More flexible
> classloading (fhanik)
> > +  1616570 53200 Selective logging for
> slow versus failed queries (fhanik)
> > +
> > +  
> > +
> > +
> >  
> >
> >  
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: svn commit: r1616584 - in /tomcat/trunk/modules/jdbc-pool: doc/ src/main/java/org/apache/tomcat/jdbc/naming/ src/main/java/org/apache/tomcat/jdbc/pool/

[Filip Hanik]

all looks good


On Sun, Aug 10, 2014 at 9:04 AM, Konstantin Kolinko 
wrote:

> 2014-08-08 0:15 GMT+04:00  :
> > Author: fhanik
> > Date: Thu Aug  7 20:15:19 2014
> > New Revision: 1616584
> >
> > URL: http://svn.apache.org/r1616584
> > Log:
> > Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53853
> > Dynamic class loading of driver, validator and interceptors can be done
> from libraries on the context class loader. Behavior is partly backwards
> compatible, always try the current loader first, but then attempts the
> current thread's context class loader
> >
> > Added:
> >
> tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/ClassLoaderUtil.java
>   (with props)
> > Modified:
> > tomcat/trunk/modules/jdbc-pool/doc/jdbc-pool.xml
> >
> tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/naming/GenericNamingResourcesFactory.java
> >
> tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/PoolProperties.java
> >
> tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/PooledConnection.java
> >
> > Modified: tomcat/trunk/modules/jdbc-pool/doc/jdbc-pool.xml
> > URL:
> http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/doc/jdbc-pool.xml?rev=1616584&r1=1616583&r2=1616584&view=diff
> >
> ==
> > --- tomcat/trunk/modules/jdbc-pool/doc/jdbc-pool.xml (original)
> > +++ tomcat/trunk/modules/jdbc-pool/doc/jdbc-pool.xml Thu Aug  7 20:15:19
> 2014
> > @@ -170,6 +170,22 @@
> >
> >  
> >
> > +
> > +  
> > +System properties are JVM wide, affect all pools created in the
> JVM
> > +
> > +   name="org.apache.tomcat.jdbc.pool.onlyAttemptCurrentClassLoader"
> required="false">
> > +(boolean) Controls classloading of dynamic classes, such as
> > +   jdbc drivers, interceptors and validators. If set to false,
> default value,
> > +   the pool will first attempt to load using the current loader
> and if class loading fails
> > +   attempt to load using the thread context loader.
> > +   Set this value to try, if you wish to remain backwards
> compatible,
>
> I have already fixed the typos here.
>
> > +   Apache Tomcat 8.0.8 and earlier, and only attempt the
> current loader.
> > +   If not set then the default value is false.)
> > +
> > +  
> > +
> > +  
> >
>
> (...)
>
>
> > Modified:
> tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/PoolProperties.java
> > URL:
> http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/PoolProperties.java?rev=1616584&r1=1616583&r2=1616584&view=diff
> >
> ==
> > ---
> tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/PoolProperties.java
> (original)
> > +++
> tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/PoolProperties.java
> Thu Aug  7 20:15:19 2014
> > @@ -767,7 +767,11 @@ public class PoolProperties implements P
> >
> >  try {
> >  @SuppressWarnings("unchecked")
> > -Class validatorClass =
> (Class)Class.forName(className);
> > +Class validatorClass =
> (Class)ClassLoaderUtil.loadClass(
> > +className,
> > +PoolProperties.class.getClassLoader(),
>
> OK.
>
> > +Thread.currentThread().getContextClassLoader()
> > +);
> >  validator = validatorClass.newInstance();
> >  } catch (ClassNotFoundException e) {
> >  log.warn("The class "+className+" cannot be found.", e);
> > @@ -957,12 +961,20 @@ public class PoolProperties implements P
> >  if (log.isDebugEnabled()) {
> >  log.debug("Loading interceptor
> class:"+PoolConfiguration.PKG_PREFIX+getClassName());
> >  }
> > -clazz =
> Class.forName(PoolConfiguration.PKG_PREFIX+getClassName(), true,
> this.getClass().getClassLoader());
> > +clazz = ClassLoaderUtil.loadClass(
> > +PoolConfiguration.PKG_PREFIX+getClassName(),
> > +this.getClass().getClassLoader(),
>
> It shall be "PoolProperties.class.getClassLoader()," as well here like
> above. Otherwise the new code is not equivalent to the old one.
>
> > +Thread.currentThread().getContextClassLoader()
> > +);
> >  } else {
> >  if (log.isDebugEnabled()) {
> >  log.debug("Loading interceptor
> class:"+getClassName());
> >  }
> > -clazz = Class.forName(getClassName(), true,
> this.getClass().getClassLoader());
> > +clazz = ClassLoaderUtil.loadClass(
> > +getClassName(),
> > +  

Re: svn commit: r1613897 - /tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/FairBlockingQueue.java

[Filip Hanik]

On Mon, Jul 28, 2014 at 1:02 AM,  wrote:

> Author: kkolinko
> Date: Mon Jul 28 07:02:31 2014
> New Revision: 1613897
>
> URL: http://svn.apache.org/r1613897
> Log:
> Revert generics changes from r1613123
> The code is compiled with Java 7, so why change them?
>
copy/paste mistake from the tc7.0.x version


> With recommended Eclipse settings those produce compiler warnings.
> (Generic types/Redundant type arguments  warning)
>
Not using eclipse, and I would recommend that we don't expect our
contributors to be on a certain platform.
If we wish to enforce something, the tools should be provided within the
project itself, not depend on committers' independent platforms.
ie, the CI could complain/fail if we wish to be that strict.

Thanks for the fix.


>
> Modified:
>
> tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/FairBlockingQueue.java
>
> Modified:
> tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/FairBlockingQueue.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/FairBlockingQueue.java?rev=1613897&r1=1613896&r2=1613897&view=diff
>
> ==
> ---
> tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/FairBlockingQueue.java
> (original)
> +++
> tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/FairBlockingQueue.java
> Mon Jul 28 07:02:31 2014
> @@ -201,13 +201,13 @@ public class FairBlockingQueue implem
>  E item = items.poll();
>  if (item==null) {
>  //queue is empty, add ourselves as waiters
> -ExchangeCountDownLatch c = new
> ExchangeCountDownLatch(1);
> +ExchangeCountDownLatch c = new
> ExchangeCountDownLatch<>(1);
>  waiters.addLast(c);
>  //return a future that will wait for the object
> -result = new ItemFuture(c);
> +result = new ItemFuture<>(c);
>  } else {
>  //return a future with the item
> -result = new ItemFuture(item);
> +result = new ItemFuture<>(item);
>  }
>  } finally {
>  lock.unlock();
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [VOTE] Release Apache Tomcat 7.0.55

[Filip Hanik]

[X] Stable - go ahead and release as 7.0.55 Stable


On Fri, Jul 18, 2014 at 6:47 PM, Violeta Georgieva 
wrote:

> The proposed Apache Tomcat 7.0.55 release is now available for voting.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.55/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1019/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_55/
>
> The proposed 7.0.55 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 7.0.55 Stable
>
> Regards,
> Violeta
>

Re: [VOTE] Release Apache Tomcat 8.0.9

[Filip Hanik]

[X] Stable - go ahead and release as 8.0.9 (stable)


On Thu, Jun 19, 2014 at 8:59 AM, Jeanfrancois Arcand  wrote:

>
>
>> The proposed 8.0.9 release is:
>> [ ] Broken - do not release
>> [ ] Alpha  - go ahead and release as 8.0.9 (alpha)
>> [ ] Beta   - go ahead and release as 8.0.9 (beta)
>> [X] Stable - go ahead and release as 8.0.9 (stable)
>>
>>
>>  Websocket & Comet/Servlet 3.1 Async tested.
>
> -- Jeanfrancois
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: NIO buffering

[Filip Hanik]

Ok, Mark would know the exact details. It simply looks like a when a buffer
has been flipped already, to simplify adding more bytes, add it to a new
unflipped buffer, rather than append to existing one.
So I don't think its about reuse, I think it may be to simplify the
handling of buffer flipping.




On Wed, Apr 23, 2014 at 9:01 AM, Rémy Maucherat  wrote:

> 2014-04-23 16:50 GMT+02:00 Filip Hanik :
>
> > >I am not convinced by the NIO buffering that is used on output.
> >
> > what are you exactly referring to? Maybe I can shed some light on it.
> >
>
> Ok, so more precisely I was talking about the
> AbstractOutputBuffer.bufferedWrites field.
>
> Rémy
>
>
> >
> >
> > On Fri, Apr 18, 2014 at 1:30 PM, Rémy Maucherat  wrote:
> >
> > > Hi,
> > >
> > > I am not convinced by the NIO buffering that is used on output. Due to
> > > concurrent access issues I couldn't use it in NIO 2, but then I cannot
> > see
> > > either what it does to justify using a more complex structure over a
> > > simpler array list.
> > >
> > > If the idea was to reuse buffers (which it doesn't), there is no option
> > > except using a static buffer pool. Was that the original general idea
> > > around this deque structure ?
> > >
> > > Then the upgrade buffering is even more basic, but is probably not a
> > > performance issue, the current code is likely fast enough since it is
> so
> > > lightweight.
> > >
> > > Rémy
> > >
> >
>

Re: NIO buffering

[Filip Hanik]

>I am not convinced by the NIO buffering that is used on output.

what are you exactly referring to? Maybe I can shed some light on it.


On Fri, Apr 18, 2014 at 1:30 PM, Rémy Maucherat  wrote:

> Hi,
>
> I am not convinced by the NIO buffering that is used on output. Due to
> concurrent access issues I couldn't use it in NIO 2, but then I cannot see
> either what it does to justify using a more complex structure over a
> simpler array list.
>
> If the idea was to reuse buffers (which it doesn't), there is no option
> except using a static buffer pool. Was that the original general idea
> around this deque structure ?
>
> Then the upgrade buffering is even more basic, but is probably not a
> performance issue, the current code is likely fast enough since it is so
> lightweight.
>
> Rémy
>

Re: Special requirements on session id generator

[Filip Hanik]

regardless of the use case, a debate whether to make something pluggable or
extensible c(sh)ould be short. adding pluggability/extensibility that
doesn't change default behavior can actually leave the exact use case out
of the question.

On Friday, February 14, 2014, Konstantin Preißer 
wrote:

> Hi Rainer,
>
> > -Original Message-
> > From: Rainer Jung [mailto:rainer.j...@kippdata.de ]
> > Sent: Friday, February 14, 2014 11:07 PM
> > To: Tomcat Developers List
> > Subject: Re: Special requirements on session id generator
> >
> > On 14.02.2014 19:14, Konstantin Preißer wrote:
> > >> Fortunately I don't have to prevent any long term collisions, just
> > >> reduce the rate without increasing session id length. Therefore I
> prefer
> > >> not to keep state for a long time including tomcat restarts, or do
> > >> remote (database) calls to check ids whenever a new one is generated.
> > >
> > > While adding some information like the current time probably reduces
> the
> > possibility for collisions, I'm concerned about the security
> implications.
> > > I understand that your requirement for avoiding collisions of
> session-IDs
> > between 30 days is to ensure that a client that gets a specific
> session-id does
> > not try to reuse it some time later and, by chance, hits a session that
> has
> > been assigned to another user but uses the same session-ID.
> >
> > No, it is not about reuse and also not really about security. The
> > session id is used in some back end as well and it does not allow the
> > transaction to proceed if the same session id had been used during the
> > last 30 days. Let's say it is a flaw in the back end system we have to
> > work around.
>
> OK, then I misunderstood your requirement, sorry.
>
> So appending timestamp should be OK for this, although I personally would
> prefer to use a counter value that increments by 1 for each generated
> session-ID.
>
>
> > > However, e.g., if some attacker knows that you add a time information
> to
> > the session ID, he could just try to re-use the session-id and add some
> > timestamp values, as the time value isn't a random value that cannot be
> > predicted, so I don't see a security benefit here. (Maybe one could then
> run
> > a hash function over this combination of random bytes + timestamp so that
> > the attacker doesn't know the original session-ID, but this would
> probably
> > cause some other problems.)
> >
> > Right. That's why I don't want to reduce the number of random bits in
> > the session id. The additional timestamping is just to increase the
> > likelyness that the same id isn't used again, it is not about
> > security/predictability. Since in my case we are a boit limited in the
> > number of characters the id can have and adding a timestamp reduces the
> > space available for the encoded random data, I want to switch from hex
> > encoding to a more dense ascii encoding that allows the same amount of
> > random bits in a shorter string.
>
> Ok.
>
> >
> > > Personally, the only secure way to avoid collisions over a period of
> time
> > that I can think would be to store the generated IDs somewhere and check
> > them when they are generated. However, one would need to increase the
> > number of bytes that are used for the session-ID to ensure that the
> number
> > of possible session values at any time is at least as high as when not
> checking
> > for collisions.
> >
> > Correct.
> >
> > > However, when viewing this from an wider perspective, I don't think
> that
> > such collisions are a real problem - the client could just generate some
> > random value by it self and try to use it for a request, to see if the
> session-ID
> > is currently in use. More important would be that the number of bytes
> that is
> > used for generating a Session-ID is so high that a client has a
> vanishing chance
> > of hitting a valid session-ID, regardless of whether the value that he
> uses is
> > one that the server generated previously, or one that is randomly
> generated
> > by the client.
> >
> > This is not about ids being currently in use :). It is about the same id
> > being generated a second time by the id generator days after it was
> > originally in use. And the goal is to reduce the rate with which this is
> > happening without reducing the random part of the id to much.
> >
> > I'd do an impl of pluggable id generation in order to not have to switch
> > the manager impl. I don't think that the replacement id generator used
> > to scratch my itch is of general interest. Being able to plug another
> > impl does sound reasonable though.
> >
> > Regards,
> >
> > Rainer
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org 
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
> Regards,
> Konstantin Preißer
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tom

Re: Removal of author tags in trunk

[Filip Hanik]

feel free to remove them


On Fri, Jan 24, 2014 at 9:11 AM, Jeanfrancois Arcand  wrote:

> +1
>
> -- Jeanfrancois
>
> On 1/24/2014, 9:14 AM, Mark Thomas wrote:
>
>> Folks,
>>
>> The ASF discourages (at least it has for as long as I have been around)
>> the use of @author tags. While I have no wish to remove an existing
>> @author tag of an author that wants it to stay, I am more than happy to
>> do the leg work to remove @author tags if that author wishes.
>>
>> With this in mind, I've scanned trunk for author tags. The results are
>> at the end of this e-mail.
>>
>> If you have are for *your* @author tags to be removed from trunk, reply
>> here and I'll make the changes.
>>
>> Thanks,
>>
>> Mark
>>
>>
>> Note: I haven't taken the time to clean this list up at all
>>
>>2  * @author  Ramesh.Mandava
>>1  * @author  Marc Eaddy
>>1  * @author  B Stansberry, based on work by Craig R. McClanahan
>>1  * @author - see DefaultServlet in Catalin for other contributors
>>1  * @author Alex Cruikshank [a...@epitonic.com]
>>   19  * @author Amy Roh
>>1  * @author Andre de Jesus
>>1  * @author Andrew R. Jaquith
>>1  * @author Andy Clark
>>6  * @author Andy Clark, IBM
>>   19  * @author Anil K. Vijendran
>>1  * @author Anselm Baird-Smith
>>1  * @author Arnaud  Le Hors, IBM
>>3  * @author Bill Barker
>>   17  * @author Bip Thelin
>>4  * @author Cédrik LIME
>>   62  * @author Costin Manolache
>>5  * @author Craig McClanahan
>>  194  * @author Craig R. McClanahan
>>2  * @author Craig R. McClanahan 
>>3  * @author Dan Milstein
>>   18  * @author Dan Sandberg
>>4  * @author Danno Ferrin
>>   16  * @author David Becker
>>1  * @author Denis Benoit
>>1  * @author Dirk Verbeeck
>>6  * @author Dmitri Valdin
>>1  * @author EKR -- renamed to JSSESocketFactory
>>3  * @author Eric Ye, IBM
>>   10  * @author Fabien Carrion
>>  138  * @author Filip Hanik
>>1  * @author Gabriele Garuglieri
>>1  * @author Gal Shachor
>>6  * @author Glenn L. Nielsen
>>1  * @author Glenn Marcy, IBM
>>3  * @author Glenn Nielsen
>>1  * @author Glenn Nielsen Rich Catlett
>>4  * @author Greg Murray
>>7  * @author Greg Wilkins
>>1  * @author Guillermo Fernandes
>>1  * @author Gunnar Rjnning
>>8  * @author Guy A. Molinari
>>1  * @author Guy Molinari
>>3  * @author Hans Bergsten
>>1  * @author Hans Bergsten 
>>1  * @author Hans Bergsten [h...@gefionsoftware.com]
>>   12  * @author Harish Prabandham
>>3  * @author Henri Gomez
>>1  * @author Jacek Laskowski
>>6  * @author Jacob Hookom
>>2  * @author Jacob Hookom [jacob/hookom.net]
>>   47  * @author Jacob Hookom [ja...@hookom.net]
>>3  * @author James Duncan Davidson
>>   10  * @author James Duncan Davidson 
>>8  * @author James Duncan Davidson [dun...@eng.sun.com]
>>1  * @author James Todd
>>   10  * @author James Todd [go...@eng.sun.com]
>>4  * @author James Todd [go...@sun.com]
>>   20  * @author Jan Luehe
>>1  * @author Jason Brittain
>>1  * @author Jason Hunter
>>5  * @author Jason Hunter [j...@eng.sun.com]
>>2  * @author Jayson Falkner
>>   14  * @author Jean-Francois Arcand
>>1  * @author Jean-Frederic Clere
>>1  * @author John Holman
>>3  * @author Justyna Horwat
>>3  * @author Keith Wannamaker
>>3  * @author Kevin Seguin
>>1  * @author Kief Morris (k...@kief.com)
>>   27  * @author Kin-man Chung
>>1  * @author Larry Cable
>>7  * @author Mandar Raje
>>1  * @author Mandar Raje.
>>   15  * @author Mark Roth
>>1  * @author Martin T Dengler [r...@martindengler.com]
>>3  * @author Mel Martinez [mmarti...@g1440.com]
>>1  * @author Michael Glavassevich, IBM
>>   36  * @author Mladen Turk
>>1  * @author Neil Graham, IBM
>>   13  * @author Paul Speed
>>3  * @author Peter Donald
>>1  * @author Peter Lin
>>   43  * @author Peter Rossbach
>>1  * @author Pete

RE: [VOTE] Apache Tomcat Maven plugin 2.2

[Filip Hanik (mailing lists)]

+1

> -Original Message-
> From: Olivier Lamy [mailto:ol...@apache.org]
> Sent: Wednesday, November 06, 2013 6:05 PM
> To: Tomcat Developers List
> Subject: [VOTE] Apache Tomcat Maven plugin 2.2
> 
> Hi,
> I'd like to release Apache Tomcat Maven plugin 2.2.
> 
> We fixed 22 issues. See
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=1231212
> 0&version=12323925
> 
> Maven Staging repository:
> https://repository.apache.org/content/repositories/orgapachetomcat-085/
> 
> Source release artifact:
> https://dist.apache.org/repos/dist/dev/tomcat/maven-plugin/v2.2/
> 
> Site: http://tomcat.apache.org/maven-plugin-2.2
> 
> Vote open for 72H
> 
> [+1]
> [0]
> [-1]
> 
> Thanks
> --
> Olivier Lamy
> Ecetera: http://ecetera.com.au
> http://twitter.com/olamy | http://linkedin.com/in/olamy
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org



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

RE: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor lasts 5s?

[Filip Hanik (mailing lists)]

"http-bio-1234-exec-19" daemon prio=10 tid=0x7fc30c014000 nid=0x5bb2
runnable [0x7fc31250f000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)

this is a connection kept alive from a client, and Tomcat is waiting for it
to send the next request until it times out.

Filip


> -Original Message-
> From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
> Sent: Wednesday, November 06, 2013 10:04 AM
> To: Tomcat Developers List
> Subject: Re:
> org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor lasts 5s?
> 
> Well if the server does something I'll do. Here is my thread dump:
> https://gist.github.com/rmannibucau/156c39bed29270cd5e06
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
> 
> 
> 
> 2013/11/6 Mark Thomas :
> > On 06/11/2013 16:58, Mark Thomas wrote:
> >> On 06/11/2013 16:49, Romain Manni-Bucau wrote:
> >>> it is too long.
> >>>
> >>> If I try to summarize the execution of tests here what the user
> feel:
> >>>
> >>> 1) tomcat starts (ok a bit "long") -> understandable so OK
> >>> 2) tests are executed (~ fast if you don't abuse of shrinkwrap
> things) -> OK
> >>> 3) tomcat shutdown (after tests) -> KO: the server doesn't anything
> >>> more (no more requests to process) but is waiting for its executor
> to
> >>> shutdown
> >>
> >> Thanks, I think I understand now.
> >>
> >> There should only be a delay at point 3 if the server is still doing
> >> something otherwise the executor shut down should be pretty much
> >> immediate. If the executor is taking a noticeable time to shut down
> then
> >> it would be worth looking at what the threads are doing.
> >>
> >> If memory serves me correctly, this was added to enable a more
> graceful
> >> shutdown of WebSocket connections when the server and/or connector
> were
> >> stopped.
> >>
> >>> This is not blocking at all, I just wanted to report this is not as
> >>> nice as before when it was synchronous and that a little config
> would
> >>> help a lot (or maybe another algo).
> >>
> >> It could be made configurable but in the case you describe above it
> >> looks like there might be some other issue at play here.
> >
> > Oh, and open an enhancement request so this doesn't get lost.
> >
> > Mark
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org



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

I'm back

[Filip Hanik (mailing lists)]

Ladies and Gentlemen,
I'm back, it will take a little while to get up to speed on all changes but
I intend to get involved again, so go easy on me while I learn the new tools
of the trade ;)

Filip


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

RE: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor lasts 5s?

[Filip Hanik (mailing lists)]

Romain, what you could do for a work around right now, is to set an executor
yourself.
This way, Tomcat won't attempt to stop it, and there wont be a delay.

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

the only time tomcat attempts to stop the executor, is if it created it, but
if you pass in an executor, tomcat wont stop it.

Filip



> -Original Message-
> From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
> Sent: Wednesday, November 06, 2013 7:12 AM
> To: Tomcat Developers List
> Subject: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor
> lasts 5s?
> 
> Hi
> 
> does org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor have
> to last 5s since something was done (request) on the instance?
> 
> My issue is with arquillian (tomcat and tomee) we need to wait some
> seconds (engouh to be human visible). When running a single test (I'm
> not Linus Torvald so I need to debug sometimes ;) it is not that nice.
> 
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org



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

RE: svn commit: r1377689 - /tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java

[Filip Hanik (mailing lists)]

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Monday, August 27, 2012 3:55 PM
> To: Tomcat Developers List
> Subject: Re: svn commit: r1377689 -
> /tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListe
> ner.java
> 
> On 27/08/2012 22:48, Filip Hanik (mailing lists) wrote:
> >
> >
> >> -Original Message-
> >> From: Mark Thomas [mailto:ma...@apache.org]
> >> Sent: Monday, August 27, 2012 3:44 PM
> >> To: Tomcat Developers List
> >> Subject: Re: svn commit: r1377689 -
> >>
> /tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListe
> >> ner.java
> >>
> >> On 27/08/2012 22:37, Filip Hanik (mailing lists) wrote:
> >>>> -Original Message-
> >>>> From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
> >>>> Sent: Monday, August 27, 2012 2:09 PM
> >>>> To: Tomcat Developers List
> >>>> Subject: Re: svn commit: r1377689 -
> >>>>
> >>
> /tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListe
> >>>> ner.java
> >>>>
> >>>> 2012/8/27 Mark Thomas :
> >>>>> On 27/08/2012 15:20, fha...@apache.org wrote:
> >>>>>> Author: fhanik
> >>>>>> Date: Mon Aug 27 14:20:55 2012
> >>>>>> New Revision: 1377689
> >>>>>>
> >>>>>> URL: http://svn.apache.org/viewvc?rev=1377689&view=rev
> >>>>>> Log:
> >>>>>> Per http://markmail.org/message/nqnogctvfuyzhtol
> >>>>>>
> >>>>>> 1. Already encountered two users that would like to set this
> value.
> >>>> There is
> >>>>>> never any need to hard code any value, regardless of its use
> >>>>>
> >>>>> What is the use case for wanting to set this value? I can
> understand
> >>>>> users not liking the previous value that triggered a full GC every
> >>>> hour
> >>>>> and wanting to change that but I fail to see why anyone would want
> >> to
> >>>>> change this now it is set to trigger a full GC every 290 million
> >> years
> >>>>> or so.
> >>
> >>>> Maybe somebody wants their full GC once an hour, or once a day?
> >>
> >> That is not what this listener is for. The listener's purpose is to
> >> prevent memory leaks, not provide options that allow users to tinker
> >> with internal JVM GC settings.
> >>
> >> I have yet to see a valid use case for this new attribute.
> > [Filip Hanik]
> > The use case is very much valid, as if they had previously called that
> > method, your code will override it.
> > So in effect, you're hard coding the GC interval, but not letting a
> user
> > control it.
> 
> Nope. You should have looked at the implementation of
> sun.misc.GC#requestLatency(long) rather than assuming how it worked.
> 
> > It's not tomcat's role to configure GC intervals. It may be that
> tomcat
> > somehow initiated the GC interval, and if that is the case, it must
> expose
> > the actual interval to the user. Tomcat should not change JVM settings
> > without letting the user configure them,
> 
> Tomcat setting this value has zero impact on any user code or JRE code
> that sets a lower value either before Tomcat sets it or after.
> 
> I still see no valid use case for this attribute and without a valid use
> case my veto remains.
[Filip Hanik] 
Now you're just being stubborn. It would be like me going back and vetoing
the hard coded value, and we'd run around in circles like little chickens.
The reason I think the veto is unreasonable is that there is no
functionality removed with this. There is nothing to be lost.

IIRC any call changes the value, since there is only one daemon thread
created. And since gcDaemonProtection is true by default means that 99.9% of
tomcat instances will have this daemon thread running. Since we have this
thread running, then we might as well hand out the ability to the users.
Since you are turning this thread on, give them the ability to change the
interval at which it is running.

141 } else {
142 /* Notify the existing daemon thread
143  * that the lateency target has changed
144  */
145 lock.notify();
146 }


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



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

RE: svn commit: r1377689 - /tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java

[Filip Hanik (mailing lists)]

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Monday, August 27, 2012 3:44 PM
> To: Tomcat Developers List
> Subject: Re: svn commit: r1377689 -
> /tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListe
> ner.java
> 
> On 27/08/2012 22:37, Filip Hanik (mailing lists) wrote:
> >> -Original Message-
> >> From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
> >> Sent: Monday, August 27, 2012 2:09 PM
> >> To: Tomcat Developers List
> >> Subject: Re: svn commit: r1377689 -
> >>
> /tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListe
> >> ner.java
> >>
> >> 2012/8/27 Mark Thomas :
> >>> On 27/08/2012 15:20, fha...@apache.org wrote:
> >>>> Author: fhanik
> >>>> Date: Mon Aug 27 14:20:55 2012
> >>>> New Revision: 1377689
> >>>>
> >>>> URL: http://svn.apache.org/viewvc?rev=1377689&view=rev
> >>>> Log:
> >>>> Per http://markmail.org/message/nqnogctvfuyzhtol
> >>>>
> >>>> 1. Already encountered two users that would like to set this value.
> >> There is
> >>>> never any need to hard code any value, regardless of its use
> >>>
> >>> What is the use case for wanting to set this value? I can understand
> >>> users not liking the previous value that triggered a full GC every
> >> hour
> >>> and wanting to change that but I fail to see why anyone would want
> to
> >>> change this now it is set to trigger a full GC every 290 million
> years
> >>> or so.
> 
> >> Maybe somebody wants their full GC once an hour, or once a day?
> 
> That is not what this listener is for. The listener's purpose is to
> prevent memory leaks, not provide options that allow users to tinker
> with internal JVM GC settings.
> 
> I have yet to see a valid use case for this new attribute.
[Filip Hanik] 
The use case is very much valid, as if they had previously called that
method, your code will override it.
So in effect, you're hard coding the GC interval, but not letting a user
control it.
It's not tomcat's role to configure GC intervals. It may be that tomcat
somehow initiated the GC interval, and if that is the case, it must expose
the actual interval to the user. Tomcat should not change JVM settings
without letting the user configure them, 

Filip


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

RE: svn commit: r1377689 - /tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java

[Filip Hanik (mailing lists)]

> -Original Message-
> From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
> Sent: Monday, August 27, 2012 3:41 PM
> To: Tomcat Developers List
> Subject: Re: svn commit: r1377689 -
> /tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListe
> ner.java
> 
> 2012/8/28 Filip Hanik (mailing lists) :
> >>
> >> There are documentation glitches yet to be fixed:
> >> a. systemprops.xml change in trunk was not reverted by this commit.
> >>  It was reverted in 7.0.x only.
> > [Filip Hanik]
> > I don't see the property in trunk, do you?
> 
> I took care of that an hour ago.
> http://svn.apache.org/viewvc?rev=1377831&view=rev
[Filip Hanik] 
Got it, what's the point of the following code change?
-method.invoke(null, getGcDaemonPeriod());
+method.invoke(null,
Long.valueOf(getGcDaemonPeriod()));


> 
> >
> >> b. The new property is yet to be documented in listeners.xml.
> > [Filip Hanik]
> > Done
> >
> 
> Best regards,
> Konstantin Kolinko
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org



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

RE: svn commit: r1377689 - /tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java

[Filip Hanik (mailing lists)]

> -Original Message-
> From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
> Sent: Monday, August 27, 2012 2:09 PM
> To: Tomcat Developers List
> Subject: Re: svn commit: r1377689 -
> /tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListe
> ner.java
> 
> 2012/8/27 Mark Thomas :
> > On 27/08/2012 15:20, fha...@apache.org wrote:
> >> Author: fhanik
> >> Date: Mon Aug 27 14:20:55 2012
> >> New Revision: 1377689
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1377689&view=rev
> >> Log:
> >> Per http://markmail.org/message/nqnogctvfuyzhtol
> >>
> >> 1. Already encountered two users that would like to set this value.
> There is
> >> never any need to hard code any value, regardless of its use
> >
> > What is the use case for wanting to set this value? I can understand
> > users not liking the previous value that triggered a full GC every
> hour
> > and wanting to change that but I fail to see why anyone would want to
> > change this now it is set to trigger a full GC every 290 million years
> > or so.
> >
> >> 2. This turns it into a property on the listener
> >
> > Thanks. If the feature is retained, that is a much better
> implementation.
> >
> 
> Re: 1:
> Maybe somebody wants their full GC once an hour, or once a day?
> 
> There are documentation glitches yet to be fixed:
> a. systemprops.xml change in trunk was not reverted by this commit.
>  It was reverted in 7.0.x only.
[Filip Hanik] 
I don't see the property in trunk, do you?

> b. The new property is yet to be documented in listeners.xml.
[Filip Hanik] 
Done

Filip
> 
> Best regards,
> Konstantin Kolinko
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org



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

RE: pooledconnection & tccl?

[Filip Hanik (mailing lists)]

I've thought about this, you see if it is using TCCL it will cause a memory
leak on app reload as the app wont be unloaded due to the pool holding it.
But I think we should make it an option

Best
Filip

> -Original Message-
> From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
> Sent: Wednesday, August 22, 2012 3:14 AM
> To: Tomcat Developers List
> Subject: Re: pooledconnection & tccl?
> 
> if the resource is an app resource it should be closed with the stop()
> and
> recreated with the start
> 
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau*
> *Blog: http://rmannibucau.wordpress.com*
> 
> 
> 
> 
> 2012/8/22 Pid * 
> 
> > On 19 Aug 2012, at 19:11, Romain Manni-Bucau 
> > wrote:
> >
> > > Hi,
> > >
> > > org.apache.tomcat.jdbc.pool.PooledConnection#connectUsingDriver uses
> > tomcat
> > > classloader to create the driver, couldn't it be the TCCL?
> > >
> > > this way it could allow to provide the driver in the webapp.
> >
> > What would happen if the app is reloaded?
> >
> >
> > p
> >
> >
> >
> >
> > >
> > > *Romain Manni-Bucau*
> > > *Twitter: @rmannibucau*
> > > *Blog: http://rmannibucau.wordpress.com*
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> >


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

RE: tomat-jdbc & hashCode

[Filip Hanik (mailing lists)]

Fixed in 
r1370074 and r1370075

http://svn.apache.org/viewvc?rev=1370075&view=rev
http://svn.apache.org/viewvc?rev=1370074&view=rev


> -Original Message-----
> From: Filip Hanik Mailing Lists [mailto:devli...@hanik.com]
> Sent: Monday, July 30, 2012 5:58 AM
> To: Tomcat Developers List
> Subject: Re: tomat-jdbc & hashCode
> 
> nope, I will fix that
> 
> Filip
> 
> - Original Message -
> > From: "Romain Manni-Bucau" 
> > To: "Tomcat Developers List" 
> > Sent: Tuesday, July 24, 2012 5:18:32 PM
> > Subject: tomat-jdbc & hashCode
> >
> > Hi,
> >
> > just noticed tomcat jdbc doesn't manage hashCode if the connection is
> > already close (it is in org.apache.tomcat.jdbc.pool.JdbcInterceptor).
> > Any
> > reason to do so?
> >
> >
> > - Romain
> >
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org



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

Re: tomat-jdbc & hashCode

[Filip Hanik Mailing Lists]

nope, I will fix that

Filip

- Original Message -
> From: "Romain Manni-Bucau" 
> To: "Tomcat Developers List" 
> Sent: Tuesday, July 24, 2012 5:18:32 PM
> Subject: tomat-jdbc & hashCode
> 
> Hi,
> 
> just noticed tomcat jdbc doesn't manage hashCode if the connection is
> already close (it is in org.apache.tomcat.jdbc.pool.JdbcInterceptor).
> Any
> reason to do so?
> 
> 
> - Romain
> 

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

RE: Unit tests and trunk

[Filip Hanik (mailing lists)]

Oracle reopened 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7115226

based on the bug we filed
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7183450

Filip

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Thursday, July 12, 2012 1:30 AM
> To: Tomcat Developers List
> Subject: Re: Unit tests and trunk
> 
> On 12/07/2012 02:05, Filip Hanik wrote:
> > I can reproduce the bug in both our unit tests and the original bug
> report. further more I can turn non blocking into blocking by opening an
> closing a selector that is never used.
> >
> > definitely a bug, since a jvm/network flag resolves it.
> >
> > while your vm may support ipv6, there is still an additional software
> layer.
> 
> Indeed and all are present. The reason I said it claims to support IPv6
> is that I hadn't tested it to confirm what the OS was claiming was
> indeed true.
> 
> > I'm sure there will be more bug reports as more people turn to java 7
> on windows/hardware
> 
> Yep.
> 
> Mark
> 
> >
> > Sent from my iPhone
> >
> > On Jul 11, 2012, at 16:42, Mark Thomas  wrote:
> >
> >> On 11/07/2012 23:30, Filip Hanik (mailing lists) wrote:
> >>> I wasn't able to reproduce on a Win 7 VM because the VM environment
> itself
> >>> doesn't support IPv6
> >>
> >> Given who we work for, the opportunities for humorous comments is
> >> extensive :)
> >>
> >> I'll settle for saying that I've double checked the VM I have and it
> >> does (claim to) support IPv6. I'll try out the test case provided in
> the
> >> original bug report.
> >>
> >> Mark
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: dev-h...@tomcat.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org



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

Re: svn commit: r1360729 - in /tomcat/trunk: ./ modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/driver/ res/dbcp/

[Filip Hanik Mailing Lists]

not sure if they want to make Java 7 minimum requirement

- Original Message -
> From: "sebb" 
> To: "Tomcat Developers List" 
> Sent: Saturday, July 14, 2012 8:04:42 PM
> Subject: Re: svn commit: r1360729 - in /tomcat/trunk: ./
> modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/driver/ res/dbcp/
> 
> Do these patches need to be fed back to Commons DBCP?
> 
> Or do they only apply to the version embedded by Tomcat?
> 
> On 14 July 2012 21:47, Rainer Jung  wrote:
> > On 14.07.2012 22:25, Filip Hanik Mailing Lists wrote:
> >>
> >> I know, it's the same patch for DBCP as for DBCP2.
> >
> >
> > Roger that.
> >
> >
> >> we can fix it, not urgent though
> >
> >
> > No hurry, maybe we'll be on DBCP2 until the first TC 8 release.
> >
> > Rainer
> >
> >
> >> - Original Message -
> >>>
> >>> From: "Rainer Jung" 
> >>> To: dev@tomcat.apache.org
> >>> Sent: Friday, July 13, 2012 3:47:27 AM
> >>> Subject: Re: svn commit: r1360729 - in /tomcat/trunk: ./
> >>> modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/driver/
> >>> res/dbcp/
> >>>
> >>> On 12.07.2012 17:38, fha...@apache.org wrote:
> >>>>
> >>>> Author: fhanik
> >>>> Date: Thu Jul 12 15:38:28 2012
> >>>> New Revision: 1360729
> >>>>
> >>>> URL: http://svn.apache.org/viewvc?rev=1360729&view=rev
> >>>> Log:
> >>>> Configure Tomcat trunk to build with Java 7.
> >>>> This includes adding a patch to the Commons-DBCP code from
> >>>> res/dbcp
> >>>>
> >>>>
> >>>> Added:
> >>>>   tomcat/trunk/res/dbcp/
> >>>>   tomcat/trunk/res/dbcp/dbcp-java-7.patch   (with props)
> >>>
> >>>
> >>> Just an info: when compiling TC trunk with Java 7 and ant 1.8.2 a
> >>> few
> >>> minutes ago, many of the offsets when applying the patch were
> >>> quite
> >>> big:
> >>>
> >>>[copy] Copying 68 files to
> >>> /shared/build/dev/tomcat/deps/tomcat8-deps/tomcat8-deps/dbcp
> >>>   [patch] patching file
> >>> src/java/org/apache/commons/dbcp/DelegatingCallableStatement.java
> >>>   [patch] Hunk #1 succeeded at 660 (offset -114 lines).
> >>>   [patch] patching file
> >>> src/java/org/apache/commons/dbcp/cpdsadapter/DriverAdapterCPDS.java
> >>>   [patch] patching file
> >>> src/java/org/apache/commons/dbcp/DelegatingResultSet.java
> >>>   [patch] Hunk #1 succeeded at 1078 (offset -196 lines).
> >>>   [patch] patching file
> >>> src/java/org/apache/commons/dbcp/PoolingDataSource.java
> >>>   [patch] Hunk #1 succeeded at 437 (offset -52 lines).
> >>>   [patch] patching file
> >>> src/java/org/apache/commons/dbcp/DelegatingConnection.java
> >>>   [patch] Hunk #1 succeeded at 678 (offset -126 lines).
> >>>   [patch] patching file
> >>> src/java/org/apache/commons/dbcp/PoolingDriver.java
> >>>   [patch] Hunk #1 succeeded at 496 (offset -5 lines).
> >>>   [patch] patching file
> >>> src/java/org/apache/commons/dbcp/DelegatingStatement.java
> >>>   [patch] Hunk #1 succeeded at 385 (offset -144 lines).
> >>>   [patch] patching file
> >>> src/java/org/apache/commons/dbcp/DelegatingDatabaseMetaData.java
> >>>   [patch] Hunk #1 succeeded at 1206 (offset -171 lines).
> >>>   [patch] patching file
> >>> src/java/org/apache/commons/dbcp/BasicDataSource.java
> >>>   [patch] Hunk #1 succeeded at 28 with fuzz 1.
> >>>   [patch] Hunk #2 succeeded at 1580 (offset -221 lines).
> >>>   [patch] patching file
> >>> src/java/org/apache/commons/dbcp/datasources/InstanceKeyDataSource.java
> >>>   [patch] Hunk #1 succeeded at 887 (offset -1 lines).
> >>>
> >>> Compilation for everything including DBCP works though.
> >>>
> >>> Regards,
> >>>
> >>> Rainer
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 
> 

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

Re: svn commit: r1360729 - in /tomcat/trunk: ./ modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/driver/ res/dbcp/

[Filip Hanik Mailing Lists]

I know, it's the same patch for DBCP as for DBCP2.
we can fix it, not urgent though

- Original Message -
> From: "Rainer Jung" 
> To: dev@tomcat.apache.org
> Sent: Friday, July 13, 2012 3:47:27 AM
> Subject: Re: svn commit: r1360729 - in /tomcat/trunk: ./
> modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/driver/ res/dbcp/
> 
> On 12.07.2012 17:38, fha...@apache.org wrote:
> > Author: fhanik
> > Date: Thu Jul 12 15:38:28 2012
> > New Revision: 1360729
> >
> > URL: http://svn.apache.org/viewvc?rev=1360729&view=rev
> > Log:
> > Configure Tomcat trunk to build with Java 7.
> > This includes adding a patch to the Commons-DBCP code from res/dbcp
> >
> >
> > Added:
> >  tomcat/trunk/res/dbcp/
> >  tomcat/trunk/res/dbcp/dbcp-java-7.patch   (with props)
> 
> Just an info: when compiling TC trunk with Java 7 and ant 1.8.2 a few
> minutes ago, many of the offsets when applying the patch were quite
> big:
> 
>   [copy] Copying 68 files to
> /shared/build/dev/tomcat/deps/tomcat8-deps/tomcat8-deps/dbcp
>  [patch] patching file
> src/java/org/apache/commons/dbcp/DelegatingCallableStatement.java
>  [patch] Hunk #1 succeeded at 660 (offset -114 lines).
>  [patch] patching file
> src/java/org/apache/commons/dbcp/cpdsadapter/DriverAdapterCPDS.java
>  [patch] patching file
> src/java/org/apache/commons/dbcp/DelegatingResultSet.java
>  [patch] Hunk #1 succeeded at 1078 (offset -196 lines).
>  [patch] patching file
> src/java/org/apache/commons/dbcp/PoolingDataSource.java
>  [patch] Hunk #1 succeeded at 437 (offset -52 lines).
>  [patch] patching file
> src/java/org/apache/commons/dbcp/DelegatingConnection.java
>  [patch] Hunk #1 succeeded at 678 (offset -126 lines).
>  [patch] patching file
> src/java/org/apache/commons/dbcp/PoolingDriver.java
>  [patch] Hunk #1 succeeded at 496 (offset -5 lines).
>  [patch] patching file
> src/java/org/apache/commons/dbcp/DelegatingStatement.java
>  [patch] Hunk #1 succeeded at 385 (offset -144 lines).
>  [patch] patching file
> src/java/org/apache/commons/dbcp/DelegatingDatabaseMetaData.java
>  [patch] Hunk #1 succeeded at 1206 (offset -171 lines).
>  [patch] patching file
> src/java/org/apache/commons/dbcp/BasicDataSource.java
>  [patch] Hunk #1 succeeded at 28 with fuzz 1.
>  [patch] Hunk #2 succeeded at 1580 (offset -221 lines).
>  [patch] patching file
> src/java/org/apache/commons/dbcp/datasources/InstanceKeyDataSource.java
>  [patch] Hunk #1 succeeded at 887 (offset -1 lines).
> 
> Compilation for everything including DBCP works though.
> 
> Regards,
> 
> Rainer
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 
> 

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

Re: Current unit test behaviour for trunk using Java 7 on Solaris

[Filip Hanik Mailing Lists]

and properly fixed in 
http://svn.apache.org/viewvc?view=revision&revision=1360929

- Original Message -
> From: "Filip Hanik (mailing lists)" 
> To: "Tomcat Developers List" 
> Sent: Thursday, July 12, 2012 2:43:55 PM
> Subject: RE: Current unit test behaviour for trunk using Java 7 on Solaris
> 
> Fixed in
> http://svn.apache.org/viewvc?view=revision&revision=1360917
> 
> DBCP should compile as well as JDBC-POOL with 1.7 now too
> 
> > -Original Message-
> > From: Rainer Jung [mailto:rainer.j...@kippdata.de]
> > Sent: Thursday, July 12, 2012 6:33 AM
> > To: Tomcat Developers List
> > Subject: Current unit test behaviour for trunk using Java 7 on
> > Solaris
> > 
> > Versions
> > 
> > 
> > TC trunk r1360616 tested with Java 1.7.0_05 on Solaris 10 Sparc.
> > 
> > Compiled everything with the same JVM version using
> > 
> > compile.source=1.7
> > compile.target=1.7
> > 
> > except for DBCP which was compiled with Java 6.
> > 
> > Unit test failures
> > ==
> > 
> > One test failure, namely
> > org.apache.catalina.websocket.TestWebSocket for
> > NIO:
> > 
> > Testcase: testKey took 4.628 sec
> > Testcase: testBug53339 took 0.262 sec
> > Testcase: testSimple took 0.585 sec
> >  FAILED
> > 
> > junit.framework.AssertionFailedError:
> >  at
> > org.apache.catalina.websocket.TestWebSocket$WebSocketClient.readMessage(
> > TestWebSocket.java:419)
> >  at
> > org.apache.catalina.websocket.TestWebSocket$WebSocketClient.access$300(T
> > estWebSocket.java:343)
> >  at
> > org.apache.catalina.websocket.TestWebSocket.testSimple(TestWebSocket.jav
> > a:99)
> > 
> > Testcase: testNoConnection took 0.555 sec
> > Testcase: testNoUpgrade took 0.425 sec
> > Testcase: testDetectWrongVersion took 0.377 sec
> > 
> > possibly due to the following exception which is not happening for
> > BIO
> > and APR (negative Timeout):
> > 
> >  [junit] 12-Jul-2012 13:19:24.329 INFO [main]
> > org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler
> > ["http-nio-127.0.0.1-auto-2-48250"]
> >  [junit] 12-Jul-2012 13:19:24.330 SEVERE
> > [http-nio-127.0.0.1-auto-2-exec-1]
> > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process
> > null
> >  [junit]  java.lang.IllegalArgumentException: Negative timeout
> >  [junit] at
> >  sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> >  [junit] at
> > org.apache.tomcat.util.net.NioSelectorPool.read(NioSelectorPool.java:267
> > )
> >  [junit] at
> > org.apache.tomcat.util.net.NioSelectorPool.read(NioSelectorPool.java:227
> > )
> >  [junit] at
> > org.apache.coyote.http11.upgrade.UpgradeNioProcessor.readSocket(UpgradeN
> > ioProcessor.java:139)
> >  [junit] at
> > org.apache.coyote.http11.upgrade.UpgradeNioProcessor.read(UpgradeNioProc
> > essor.java:112)
> >  [junit] at
> > org.apache.catalina.websocket.WsFrame.nextFrame(WsFrame.java:213)
> >  [junit] at
> > org.apache.catalina.websocket.WsInputStream.nextFrame(WsInputStream.java
> > :68)
> >  [junit] at
> > org.apache.catalina.websocket.StreamInbound.onData(StreamInbound.java:11
> > 7)
> >  [junit] at
> > org.apache.coyote.http11.upgrade.UpgradeProcessor.upgradeDispatch(Upgrad
> > eProcessor.java:83)
> >  [junit] at
> > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(Abs
> > tractProtocol.java:583)
> >  [junit] at
> > org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.proce
> > ss(Http11NioProtocol.java:223)
> >  [junit] at
> > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.j
> > ava:1676)
> >  [junit] at
> > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.jav
> > a:1110)
> >  [junit] at
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.ja
> > va:603)
> >  [junit] at java.lang.Thread.run(Thread.java:722)
> >  [junit]
> >  [junit] 12-Jul-2012 13:19:24.381 INFO [main]
> > org.apache.catalina.core.StandardService.stopInternal Stopping
> > service
> > Tomcat
> > 
> > ...
> > 
> >  [junit] 12-Jul-2012 13:19:24.769 INFO [main]
> > org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
> >

RE: Current unit test behaviour for trunk using Java 7 on Solaris

[Filip Hanik (mailing lists)]

Fixed in 
http://svn.apache.org/viewvc?view=revision&revision=1360917

DBCP should compile as well as JDBC-POOL with 1.7 now too

> -Original Message-
> From: Rainer Jung [mailto:rainer.j...@kippdata.de]
> Sent: Thursday, July 12, 2012 6:33 AM
> To: Tomcat Developers List
> Subject: Current unit test behaviour for trunk using Java 7 on Solaris
> 
> Versions
> 
> 
> TC trunk r1360616 tested with Java 1.7.0_05 on Solaris 10 Sparc.
> 
> Compiled everything with the same JVM version using
> 
> compile.source=1.7
> compile.target=1.7
> 
> except for DBCP which was compiled with Java 6.
> 
> Unit test failures
> ==
> 
> One test failure, namely org.apache.catalina.websocket.TestWebSocket for
> NIO:
> 
> Testcase: testKey took 4.628 sec
> Testcase: testBug53339 took 0.262 sec
> Testcase: testSimple took 0.585 sec
>  FAILED
> 
> junit.framework.AssertionFailedError:
>  at
> org.apache.catalina.websocket.TestWebSocket$WebSocketClient.readMessage(
> TestWebSocket.java:419)
>  at
> org.apache.catalina.websocket.TestWebSocket$WebSocketClient.access$300(T
> estWebSocket.java:343)
>  at
> org.apache.catalina.websocket.TestWebSocket.testSimple(TestWebSocket.jav
> a:99)
> 
> Testcase: testNoConnection took 0.555 sec
> Testcase: testNoUpgrade took 0.425 sec
> Testcase: testDetectWrongVersion took 0.377 sec
> 
> possibly due to the following exception which is not happening for BIO
> and APR (negative Timeout):
> 
>  [junit] 12-Jul-2012 13:19:24.329 INFO [main]
> org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler
> ["http-nio-127.0.0.1-auto-2-48250"]
>  [junit] 12-Jul-2012 13:19:24.330 SEVERE
> [http-nio-127.0.0.1-auto-2-exec-1]
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process
> null
>  [junit]  java.lang.IllegalArgumentException: Negative timeout
>  [junit] at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>  [junit] at
> org.apache.tomcat.util.net.NioSelectorPool.read(NioSelectorPool.java:267
> )
>  [junit] at
> org.apache.tomcat.util.net.NioSelectorPool.read(NioSelectorPool.java:227
> )
>  [junit] at
> org.apache.coyote.http11.upgrade.UpgradeNioProcessor.readSocket(UpgradeN
> ioProcessor.java:139)
>  [junit] at
> org.apache.coyote.http11.upgrade.UpgradeNioProcessor.read(UpgradeNioProc
> essor.java:112)
>  [junit] at
> org.apache.catalina.websocket.WsFrame.nextFrame(WsFrame.java:213)
>  [junit] at
> org.apache.catalina.websocket.WsInputStream.nextFrame(WsInputStream.java
> :68)
>  [junit] at
> org.apache.catalina.websocket.StreamInbound.onData(StreamInbound.java:11
> 7)
>  [junit] at
> org.apache.coyote.http11.upgrade.UpgradeProcessor.upgradeDispatch(Upgrad
> eProcessor.java:83)
>  [junit] at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(Abs
> tractProtocol.java:583)
>  [junit] at
> org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.proce
> ss(Http11NioProtocol.java:223)
>  [junit] at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.j
> ava:1676)
>  [junit] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.jav
> a:1110)
>  [junit] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.ja
> va:603)
>  [junit] at java.lang.Thread.run(Thread.java:722)
>  [junit]
>  [junit] 12-Jul-2012 13:19:24.381 INFO [main]
> org.apache.catalina.core.StandardService.stopInternal Stopping service
> Tomcat
> 
> ...
> 
>  [junit] 12-Jul-2012 13:19:24.769 INFO [main]
> org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
> ["http-nio-127.0.0.1-auto-3-48253"]
>  [junit] 12-Jul-2012 13:19:24.795 SEVERE
> [http-nio-127.0.0.1-auto-3-exec-1]
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process
> null
>  [junit]  java.lang.IllegalArgumentException: Negative timeout
>  [junit] at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>  [junit] at
> org.apache.tomcat.util.net.NioSelectorPool.read(NioSelectorPool.java:267
> )
>  [junit] at
> org.apache.tomcat.util.net.NioSelectorPool.read(NioSelectorPool.java:227
> )
>  [junit] at
> org.apache.coyote.http11.upgrade.UpgradeNioProcessor.readSocket(UpgradeN
> ioProcessor.java:139)
>  [junit] at
> org.apache.coyote.http11.upgrade.UpgradeNioProcessor.read(UpgradeNioProc
> essor.java:98)
>  [junit] at
> org.apache.catalina.websocket.WsFrame.blockingRead(WsFrame.java:149)
>  [junit] at
> org.apache.catalina.websocket.WsFrame.(WsFrame.java:66)
>  [junit] at
> org.apache.catalina.websocket.WsFrame.nextFrame(WsFrame.java:215)
>  [junit] at
> org.apache.catalina.websocket.WsInputStream.nextFrame(WsInputStream.java
> :68)
>  [junit] at
> org.apache.catalina.websocket.WsInputStream.makePayloadDataAvailable(WsI
> nputStream.java:136)
>  [junit]

RE: svn commit: r1360905 - /tomcat/trunk/java/org/apache/tomcat/util/net/NioSelectorPool.java

[Filip Hanik (mailing lists)]

You are correct, I was chasing down the following:

Testsuite: org.apache.catalina.websocket.TestWebSocket
Tests run: 6, Failures: 1, Errors: 0, Time elapsed: 2.048 sec

INFO: Starting ProtocolHandler ["http-nio-127.0.0.1-auto-2-9027"]
Jul 12, 2012 11:56:27 AM 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler process
SEVERE: null
java.lang.IllegalArgumentException: Negative timeout
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at 
org.apache.tomcat.util.net.NioSelectorPool.read(NioSelectorPool.java:267)
at 
org.apache.tomcat.util.net.NioSelectorPool.read(NioSelectorPool.java:227)
at 
org.apache.coyote.http11.upgrade.UpgradeNioProcessor.readSocket(UpgradeNioProcessor.java:139)
at 
org.apache.coyote.http11.upgrade.UpgradeNioProcessor.read(UpgradeNioProcessor.java:112)
at org.apache.catalina.websocket.WsFrame.nextFrame(WsFrame.java:213)
at 
org.apache.catalina.websocket.WsInputStream.nextFrame(WsInputStream.java:68)
at 
org.apache.catalina.websocket.StreamInbound.onData(StreamInbound.java:117)
at 
org.apache.coyote.http11.upgrade.UpgradeProcessor.upgradeDispatch(UpgradeProcessor.java:83)
at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:583)
at 
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:223)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1676)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)

We should not use -1 in our unit tests. I'm tempted to get rid of the -1 notion 
all together, no sane person should ever use no timeout :)



> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Thursday, July 12, 2012 2:20 PM
> To: Tomcat Developers List
> Subject: Re: svn commit: r1360905 -
> /tomcat/trunk/java/org/apache/tomcat/util/net/NioSelectorPool.java
> 
> On 12/07/2012 21:11, fha...@apache.org wrote:
> > Author: fhanik
> > Date: Thu Jul 12 20:11:31 2012
> > New Revision: 1360905
> >
> > URL: http://svn.apache.org/viewvc?rev=1360905&view=rev
> > Log:
> > Correct handling of timeout - negative or zero means no timeout but an
> instant
> 
> Nope. The expected and documented behaviour for a negative timeout for
> all connectors is an infinite timeout.
> 
> Mark
> 
> >
> >
> > Modified:
> > tomcat/trunk/java/org/apache/tomcat/util/net/NioSelectorPool.java
> >
> > Modified:
> tomcat/trunk/java/org/apache/tomcat/util/net/NioSelectorPool.java
> > URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/ne
> t/NioSelectorPool.java?rev=1360905&r1=1360904&r2=1360905&view=diff
> >
> 
> ==
> > --- tomcat/trunk/java/org/apache/tomcat/util/net/NioSelectorPool.java
> (original)
> > +++ tomcat/trunk/java/org/apache/tomcat/util/net/NioSelectorPool.java
> Thu Jul 12 20:11:31 2012
> > @@ -196,7 +196,11 @@ public class NioSelectorPool {
> >  //register OP_WRITE to the selector
> >  if (key==null) key =
> socket.getIOChannel().register(selector, SelectionKey.OP_WRITE);
> >  else key.interestOps(SelectionKey.OP_WRITE);
> > -keycount = selector.select(writeTimeout);
> > +if (writeTimeout<=0) {
> > +keycount = selector.selectNow();
> > +} else {
> > +keycount = selector.select(writeTimeout);
> > +}
> >  }
> >  if (writeTimeout > 0 && (selector == null || keycount
> == 0) ) timedout = (System.currentTimeMillis()-time)>=writeTimeout;
> >  }//while
> > @@ -264,7 +268,11 @@ public class NioSelectorPool {
> >  //register OP_WRITE to the selector
> >  if (key==null) key =
> socket.getIOChannel().register(selector, SelectionKey.OP_READ);
> >  else key.interestOps(SelectionKey.OP_READ);
> > -keycount = selector.select(readTimeout);
> > +if (readTimeout<=0) {
> > +keycount = selector.selectNow();
> > +} else {
> > +keycount = selector.select(readTimeout);
> > +}
> >  }
> >  if (readTimeout > 0 && (selector == null || keycount
> == 0) ) timedout = (System.currentTimeMillis()-time)>=readTimeout;
> >  }//while
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> 
> 
> 
>

RE: access to build environment

[Filip Hanik (mailing lists)]

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Thursday, July 12, 2012 1:33 AM
> To: Tomcat Developers List
> Subject: Re: access to build environment
> 
> On 12/07/2012 02:06, Filip Hanik wrote:
> > I'd guess those two, do we use anything else for tomcat ci?
> 
> Not on ASF infrastructure.
> 
> The first step is to get trunk building with 1.7. It doesn't at the
> moment because of some jdbc-pool tests that implement some of the SQL
> interfaces. Fix those and we can change the source version in the build
> and see what breaks. Gump we can fix directly. buildbot we may need to
> ask infra to fix (whch means I might have the karma to fix it anyway).
[Filip Hanik] 
You got it. I'll be removing the jdbc-pool externals and do a svn copy for
Tomcat 7.
That way I can refactor in trunk even for jdbc-pool. 

> 
> Mark
> 
> >
> > Sent from my iPhone
> >
> > On Jul 11, 2012, at 16:42, Mark Thomas  wrote:
> >
> >> On 11/07/2012 23:40, Filip Hanik (mailing lists) wrote:
> >>> How do I get access to the build environment?
> >>
> >> Which build environment? Gump, buildbot, something else?
> >>
> >> Mark
> >>
> >>>
> >>> So we can change the build to default to Java 7
> >>>
> >>> Filip
> >>>
> >>>
> >>>
> >>>
> >>> 
> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> >>> For additional commands, e-mail: dev-h...@tomcat.apache.org
> >>>
> >>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: dev-h...@tomcat.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org



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

Re: access to build environment

[Filip Hanik]

I'd guess those two, do we use anything else for tomcat ci?

Sent from my iPhone

On Jul 11, 2012, at 16:42, Mark Thomas  wrote:

> On 11/07/2012 23:40, Filip Hanik (mailing lists) wrote:
>> How do I get access to the build environment?
> 
> Which build environment? Gump, buildbot, something else?
> 
> Mark
> 
>> 
>> So we can change the build to default to Java 7
>> 
>> Filip
>> 
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 

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

Re: Unit tests and trunk

[Filip Hanik]

I can reproduce the bug in both our unit tests and the original bug report. 
further more I can turn non blocking into blocking by opening an closing a 
selector that is never used. 

definitely a bug, since a jvm/network flag resolves it. 

while your vm may support ipv6, there is still an additional software layer. 

I'm sure there will be more bug reports as more people turn to java 7 on 
windows/hardware

Sent from my iPhone

On Jul 11, 2012, at 16:42, Mark Thomas  wrote:

> On 11/07/2012 23:30, Filip Hanik (mailing lists) wrote:
>> I wasn't able to reproduce on a Win 7 VM because the VM environment itself
>> doesn't support IPv6
> 
> Given who we work for, the opportunities for humorous comments is
> extensive :)
> 
> I'll settle for saying that I've double checked the VM I have and it
> does (claim to) support IPv6. I'll try out the test case provided in the
> original bug report.
> 
> Mark
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 

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

access to build environment

[Filip Hanik (mailing lists)]

How do I get access to the build environment?

So we can change the build to default to Java 7

Filip




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

RE: Unit tests and trunk

[Filip Hanik (mailing lists)]

I opened a new issue pointing back to the old issue

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7183450.

It may take a day or two before your bug shows up in this external database.

> -Original Message-
> From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com]
> Sent: Wednesday, July 11, 2012 4:30 PM
> To: 'Tomcat Developers List'
> Subject: RE: Unit tests and trunk
> 
> 
> 
> > -Original Message-
> > From: Mark Thomas [mailto:ma...@apache.org]
> > Sent: Wednesday, July 11, 2012 4:28 PM
> > To: Tomcat Developers List
> > Subject: Re: Unit tests and trunk
> >
> > On 11/07/2012 22:39, Filip Hanik (mailing lists) wrote:
> > > Ok, I have a resolution to this, it's a IPv6 problem. The reason it
> > worked
> > > on my virtual machine, is cause the virtual machine doesn't have
> IPv6
> > >
> > > When I add
> > > 
> > >
> > > To the unit tests, it works fine on Windows.
> > >
> > > Here is what led me to believe in this:
> > > http://blog.bielu.com/2011/11/hotspot-64bit-server-hangs-on-
> > socket.html
> >
> > Hmm. It looks like Oracle failed to reproduce the issue - possibly
> > because the IPv6 part was not clear in the original bug report.
> Probably
> > time to raise an issue with Oracle with clearer instructions to
> > reproduce. (I have a clean Win 7 VM I am happy to trial any test case
> on
> > if that helps).
> [Filip Hanik]
> I wasn't able to reproduce on a Win 7 VM because the VM environment
> itself
> doesn't support IPv6
> 
> 
> 
> >
> > Mark
> >
> >
> > >
> > >> -Original Message-
> > >> From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com]
> > >> Sent: Wednesday, July 11, 2012 2:54 PM
> > >> To: 'Tomcat Developers List'
> > >> Subject: RE: Unit tests and trunk
> > >>
> > >> The idea of creating a VM that is like mine was a good one.
> > >> I did a clean install of Windows 7 64 bit, and it works like a
> charm.
> > >> My network stack must have something installed at the network stack
> > >>
> > >> Filip
> > >>
> > >>> -Original Message-
> > >>> From: Mark Thomas [mailto:ma...@apache.org]
> > >>> Sent: Wednesday, July 11, 2012 1:32 PM
> > >>> To: Tomcat Developers List
> > >>> Subject: Re: Unit tests and trunk
> > >>>
> > >>> On 11/07/2012 20:13, Filip Hanik (mailing lists) wrote:
> > >>>>
> > >>>>
> > >>>>> -Original Message-
> > >>>>> From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com]
> > >>>>> Sent: Wednesday, July 11, 2012 10:13 AM
> > >>>>> To: 'Tomcat Developers List'
> > >>>>> Subject: RE: Unit tests and trunk
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> -Original Message-
> > >>>>>> From: Mark Thomas [mailto:ma...@apache.org]
> > >>>>>> Sent: Wednesday, July 11, 2012 2:45 AM
> > >>>>>> To: Tomcat Developers List
> > >>>>>> Subject: Re: Unit tests and trunk
> > >>>>>>
> > >>>>>> On 11/07/2012 02:27, Filip Hanik (mailing lists) wrote:
> > >>>>>>> Here's what I've found out so far
> > >>>>>>>
> > >>>>>>> The patch below does solve the problem. In a rather remarkable
> > >> way.
> > >>>>>>> The line
> > >>>>>>> int cnt = socket.write(buf); //write the data
> > >>>>>>>
> > >>>>>>> never returns 0, meaning the writes are always blocking. Even
> > >>> though
> > >>>>>> they
> > >>>>>>> are not supposed to be.
> > >>>>>>> Remove this patch, and socket.write(buf) returns 0, and then
> we
> > >>>>> never
> > >>>>>> get
> > >>>>>>> issued the OP_WRITE from the selector itself.
> > >>>>>>
> > >>>>>> I'm not sure I follow the above. Remove the patch and it
> returns
> > >> 0?
> > >>>>> [Filip Hanik]
> > &g