Re: [VOTE] Release Apache Tomcat Native 1.2.26
On 10/12/2020 21:10, Mark Thomas wrote: > Version 1.2.26 includes the following changes compared to 1.2.25 > > - Windows binaries built using 1.1.1i > > - BZ 64942 - expose support for unix domain sockets > > Various other fixes and improvements. See the changelog for details. > > The proposed release artefacts can be found at [1], > and the build was done using tag [2]. > > The Apache Tomcat Native 1.2.26 release is > [X] Stable, go ahead and release > [ ] Broken because of ... Builds from source on MacOS and Windows. Tests pass with 10.0.x on Windows and MacOS. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-jakartaee-migration] branch master updated: Make migrate.sh usable from any directory
Am 11.12.2020 um 08:25 schrieb mgrigo...@apache.org: This is an automated email from the ASF dual-hosted git repository. mgrigorov pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git The following commit(s) were added to refs/heads/master by this push: new 000c876 Make migrate.sh usable from any directory 000c876 is described below commit 000c876ea3a1e700df2fffef70b29d9c3a9dfef2 Author: Martin Tzvetanov Grigorov AuthorDate: Fri Dec 11 09:22:22 2020 +0200 Make migrate.sh usable from any directory Until now one has to `cd` to the bin/ folder to be able to execute migrate.sh, otherwise lib/ folder won't be found --- src/main/scripts/migrate.sh | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/main/scripts/migrate.sh b/src/main/scripts/migrate.sh index c2b941c..3d3f34c 100755 --- a/src/main/scripts/migrate.sh +++ b/src/main/scripts/migrate.sh @@ -1,4 +1,6 @@ #!/bin/sh +BIN_FOLDER=`dirname $PWD/$0` Does that work if $0 is an absolute path? Maybe one could cd `dirname $0` Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-jakartaee-migration] branch master updated: Make migrate.sh usable from any directory
Hi Rainer, On Fri, Dec 11, 2020 at 10:37 AM Rainer Jung wrote: > Am 11.12.2020 um 08:25 schrieb mgrigo...@apache.org: > > This is an automated email from the ASF dual-hosted git repository. > > > > mgrigorov pushed a commit to branch master > > in repository > https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git > > > > > > The following commit(s) were added to refs/heads/master by this push: > > new 000c876 Make migrate.sh usable from any directory > > 000c876 is described below > > > > commit 000c876ea3a1e700df2fffef70b29d9c3a9dfef2 > > Author: Martin Tzvetanov Grigorov > > AuthorDate: Fri Dec 11 09:22:22 2020 +0200 > > > > Make migrate.sh usable from any directory > > > > Until now one has to `cd` to the bin/ folder to be able to execute > migrate.sh, otherwise lib/ folder won't be found > > --- > > src/main/scripts/migrate.sh | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/src/main/scripts/migrate.sh b/src/main/scripts/migrate.sh > > index c2b941c..3d3f34c 100755 > > --- a/src/main/scripts/migrate.sh > > +++ b/src/main/scripts/migrate.sh > > @@ -1,4 +1,6 @@ > > #!/bin/sh > > > > +BIN_FOLDER=`dirname $PWD/$0` > > Does that work if $0 is an absolute path? > Yes, it does. I have tested it! BIN_FOLDER looks a bit strange: ///some/absolute/path/bin but it works just fine on my Ubuntu. Does it work on Solaris ? :-) > > Maybe one could > >cd `dirname $0` > > Regards, > > Rainer > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [tomcat-jakartaee-migration] branch master updated: Make migrate.sh usable from any directory
On Fri, Dec 11, 2020 at 10:41 AM Martin Grigorov wrote: > Hi Rainer, > > On Fri, Dec 11, 2020 at 10:37 AM Rainer Jung > wrote: > >> Am 11.12.2020 um 08:25 schrieb mgrigo...@apache.org: >> > This is an automated email from the ASF dual-hosted git repository. >> > >> > mgrigorov pushed a commit to branch master >> > in repository >> https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git >> > >> > >> > The following commit(s) were added to refs/heads/master by this push: >> > new 000c876 Make migrate.sh usable from any directory >> > 000c876 is described below >> > >> > commit 000c876ea3a1e700df2fffef70b29d9c3a9dfef2 >> > Author: Martin Tzvetanov Grigorov >> > AuthorDate: Fri Dec 11 09:22:22 2020 +0200 >> > >> > Make migrate.sh usable from any directory >> > >> > Until now one has to `cd` to the bin/ folder to be able to execute >> migrate.sh, otherwise lib/ folder won't be found >> > --- >> > src/main/scripts/migrate.sh | 4 +++- >> > 1 file changed, 3 insertions(+), 1 deletion(-) >> > >> > diff --git a/src/main/scripts/migrate.sh b/src/main/scripts/migrate.sh >> > index c2b941c..3d3f34c 100755 >> > --- a/src/main/scripts/migrate.sh >> > +++ b/src/main/scripts/migrate.sh >> > @@ -1,4 +1,6 @@ >> > #!/bin/sh >> > >> > +BIN_FOLDER=`dirname $PWD/$0` >> >> Does that work if $0 is an absolute path? >> > > Yes, it does. I have tested it! > BIN_FOLDER looks a bit strange: ///some/absolute/path/bin but it works > just fine on my Ubuntu. > Does it work on Solaris ? :-) > > >> >> Maybe one could >> >>cd `dirname $0` >> > Two issues with this: 1) the script usage is: ./bin/migrate.sh input.war output.war if we "cd" into bin/ then input.war is not there anymore. Its path should be fixed to ../input.war somehow 2) it would be good to leave the user back to the original directory after executing the script but pushd/popd are not available for 'sh'. We will need to use Bash or another > >> Regards, >> >> Rainer >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >>
Re: [tomcat-jakartaee-migration] branch master updated: Make migrate.sh usable from any directory
On 11/12/2020 08:49, Martin Grigorov wrote: > On Fri, Dec 11, 2020 at 10:41 AM Martin Grigorov > wrote: >> On Fri, Dec 11, 2020 at 10:37 AM Rainer Jung >>> Maybe one could >>> >>>cd `dirname $0` >>> >> > Two issues with this: > > 1) the script usage is: ./bin/migrate.sh input.war output.war > if we "cd" into bin/ then input.war is not there anymore. Its path should > be fixed to ../input.war somehow > > 2) it would be good to leave the user back to the original directory after > executing the script but pushd/popd are not available for 'sh'. We will > need to use Bash or another You might find inspiration for a fix in the Tomcat startup scripts. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-jakartaee-migration] branch master updated: Make migrate.sh usable from any directory
On Fri, Dec 11, 2020 at 10:53 AM Mark Thomas wrote: > On 11/12/2020 08:49, Martin Grigorov wrote: > > On Fri, Dec 11, 2020 at 10:41 AM Martin Grigorov > > wrote: > >> On Fri, Dec 11, 2020 at 10:37 AM Rainer Jung > > > > >>> Maybe one could > >>> > >>>cd `dirname $0` > >>> > >> > > Two issues with this: > > > > 1) the script usage is: ./bin/migrate.sh input.war output.war > > if we "cd" into bin/ then input.war is not there anymore. Its path should > > be fixed to ../input.war somehow > > > > 2) it would be good to leave the user back to the original directory > after > > executing the script but pushd/popd are not available for 'sh'. We will > > need to use Bash or another > > You might find inspiration for a fix in the Tomcat startup scripts. > Do we need to fix it ? It works fine. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [VOTE] Apache Tomcat migration tool for Jakarta EE
On Thu, Dec 10, 2020 at 5:14 PM Mark Thomas wrote: > On 10/12/2020 14:52, Romain Manni-Bucau wrote: > > Le jeu. 10 déc. 2020 à 15:49, Rémy Maucherat a écrit : > >> On Thu, Dec 10, 2020 at 3:13 PM Mark Thomas wrote: > >>> On 10/12/2020 13:58, Christopher Schultz wrote: > > > > Since this is a developer tool and not a runtime library or anything > like that, maybe we can just say "YMMV, this is available any time you > want it"? > >>> > >>> It could be a runtime library. One possibility is that we integrate it > >>> into Tomcat 10 somehow so that if you try and deploy a Java EE 8 WAR it > >>> gets automatically converted to a Jakarta EE 9 WAR. > >>> > >> > >> It sounds doable with a special folder of the host (like a > legacyAppBase), > >> and it creates the result in the host's appBase. Like > HostConfig.deployApps > >> simply does this first, then moves down the usual deployments. I'm not > sure > >> that this is really useful though. > >> > > > > Does it sound stupid to make the library a ClassFileTransformer added on > > the webapp classloader? Sounds the most hurtless for users even if it > will > > adds a small overhead (and avoids a lot of file duplication which can be > > harder to maintain at some point). > > It doesn't sound stupid at all. It was one of the options considered > when we first started thinking about this. That was before we had the > current implementation. With the experience of what the current > implementation looks like we might want to revisit that discussion. > > My own thinking was to convert appBase/javaee.war to > appBase/javaee##converted.war and let the parallel deployment code take > care of deploying just the updated version. > I would think a separate appBase is preferable since it's easier, and there's nothing to detect. Everything gets processed by the conversion tool and that's it. > > Doing conversion on the fly or at deployment/start-up time raises > various issues that boil down to "How do we detect if conversion is > required?" and "What are the performance impacts of doing so?". There > are users who want to squeeze every last drop of performance out of the > system so I think that leads to some sort of configuration option. > Still not convinced by the classloading magic (the tool does a bit more than this) and AOT would be a problem. Rémy > > Just thinking about that I thought of: > - watch what classes are requested > - as soon as javax.servlet.* (or one of the others is detected) stop the > context, enable conversion and restart the context > > Then I thought that apps might try to determine if they are running on > Java EE or Jakarta EE by trying to load classes. That could incorrectly > trigger the conversion. > > Hmm. Anything apart from an explicitly user set flag starts to look > potentially tricky for some use cases. > > Thoughts? > > Mark > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [VOTE] Apache Tomcat migration tool for Jakarta EE
Le ven. 11 déc. 2020 à 10:59, Rémy Maucherat a écrit : > On Thu, Dec 10, 2020 at 5:14 PM Mark Thomas wrote: > > > On 10/12/2020 14:52, Romain Manni-Bucau wrote: > > > Le jeu. 10 déc. 2020 à 15:49, Rémy Maucherat a > écrit : > > >> On Thu, Dec 10, 2020 at 3:13 PM Mark Thomas wrote: > > >>> On 10/12/2020 13:58, Christopher Schultz wrote: > > > > > > > > Since this is a developer tool and not a runtime library or anything > > like that, maybe we can just say "YMMV, this is available any time > you > > want it"? > > >>> > > >>> It could be a runtime library. One possibility is that we integrate > it > > >>> into Tomcat 10 somehow so that if you try and deploy a Java EE 8 WAR > it > > >>> gets automatically converted to a Jakarta EE 9 WAR. > > >>> > > >> > > >> It sounds doable with a special folder of the host (like a > > legacyAppBase), > > >> and it creates the result in the host's appBase. Like > > HostConfig.deployApps > > >> simply does this first, then moves down the usual deployments. I'm not > > sure > > >> that this is really useful though. > > >> > > > > > > Does it sound stupid to make the library a ClassFileTransformer added > on > > > the webapp classloader? Sounds the most hurtless for users even if it > > will > > > adds a small overhead (and avoids a lot of file duplication which can > be > > > harder to maintain at some point). > > > > It doesn't sound stupid at all. It was one of the options considered > > when we first started thinking about this. That was before we had the > > current implementation. With the experience of what the current > > implementation looks like we might want to revisit that discussion. > > > > My own thinking was to convert appBase/javaee.war to > > appBase/javaee##converted.war and let the parallel deployment code take > > care of deploying just the updated version. > > > > I would think a separate appBase is preferable since it's easier, and > there's nothing to detect. Everything gets processed by the conversion tool > and that's it. > > > > > > Doing conversion on the fly or at deployment/start-up time raises > > various issues that boil down to "How do we detect if conversion is > > required?" and "What are the performance impacts of doing so?". There > > are users who want to squeeze every last drop of performance out of the > > system so I think that leads to some sort of configuration option. > > > > Still not convinced by the classloading magic (the tool does a bit more > than this) and AOT would be a problem. > Same applies for the different app base, basically AOT can only work if done at build time so having a cllassfiletransfomer wired either in the config of the classloader (once again, when tuned to ignored most of commons etc by jar name and packages it will not slow down the app significantly enough to not be worth it as proven by other transformers out there - take tomee as an example ;)) and another wiring in a main - as of today - where it enables to get a new binary, potentially integrated with tomcat embedded/standalone (new Tomcat()) and then go through graalvm. > > Rémy > > > > > > Just thinking about that I thought of: > > - watch what classes are requested > > - as soon as javax.servlet.* (or one of the others is detected) stop the > > context, enable conversion and restart the context > > > > Then I thought that apps might try to determine if they are running on > > Java EE or Jakarta EE by trying to load classes. That could incorrectly > > trigger the conversion. > > > > Hmm. Anything apart from an explicitly user set flag starts to look > > potentially tricky for some use cases. > > > > Thoughts? > > > > Mark > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > >
Re: [tomcat-jakartaee-migration] branch master updated: Make migrate.sh usable from any directory
Am 11.12.2020 um 09:49 schrieb Martin Grigorov: On Fri, Dec 11, 2020 at 10:41 AM Martin Grigorov wrote: Hi Rainer, On Fri, Dec 11, 2020 at 10:37 AM Rainer Jung wrote: Am 11.12.2020 um 08:25 schrieb mgrigo...@apache.org: This is an automated email from the ASF dual-hosted git repository. mgrigorov pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git The following commit(s) were added to refs/heads/master by this push: new 000c876 Make migrate.sh usable from any directory 000c876 is described below commit 000c876ea3a1e700df2fffef70b29d9c3a9dfef2 Author: Martin Tzvetanov Grigorov AuthorDate: Fri Dec 11 09:22:22 2020 +0200 Make migrate.sh usable from any directory Until now one has to `cd` to the bin/ folder to be able to execute migrate.sh, otherwise lib/ folder won't be found --- src/main/scripts/migrate.sh | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/main/scripts/migrate.sh b/src/main/scripts/migrate.sh index c2b941c..3d3f34c 100755 --- a/src/main/scripts/migrate.sh +++ b/src/main/scripts/migrate.sh @@ -1,4 +1,6 @@ #!/bin/sh +BIN_FOLDER=`dirname $PWD/$0` Does that work if $0 is an absolute path? Yes, it does. I have tested it! BIN_FOLDER looks a bit strange: ///some/absolute/path/bin but it works just fine on my Ubuntu. Does it work on Solaris ? :-) Maybe one could cd `dirname $0` Two issues with this: 1) the script usage is: ./bin/migrate.sh input.war output.war if we "cd" into bin/ then input.war is not there anymore. Its path should be fixed to ../input.war somehow 2) it would be good to leave the user back to the original directory after executing the script but pushd/popd are not available for 'sh'. We will need to use Bash or another Solaris check: apache% cat test.sh #!/bin/sh echo `dirname $PWD/$0` apache% /home/jung/test.sh /home/jung//home/jung apache% ./test.sh /home/jung/. So the full path case does not work there. Switching to /bin/bash or /bin/ksh does not help. I agree with Mark concerning the TC scripts. Concerning your 2) above: a "cd" in the script does not change the working diretory of the calling shell. After the end of the script, the user is still in the same directory where he was before starting it. 1) is a bit more tricky, because again one would have to handle the absolute and the relative case. What might help and should be compatible would be something like mydir="$PWD" cd `dirname "$0"` BIN_FOLDER="$PWD" cd "$mydir" Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] michael-o commented on a change in pull request #382: Add support for unix domain sockets.
michael-o commented on a change in pull request #382: URL: https://github.com/apache/tomcat/pull/382#discussion_r540877133 ## File path: webapps/docs/config/http.xml ## @@ -208,6 +208,24 @@ The default is POST + Review comment: Having both enabled might lead to confusion as it does now with dual-stack socket. Most don't even know that one can pass sockopt IPV6_ONLY. I would avoid such situation unless the admin does exactly know what is happening here. Now the misfortune here is that we don't have an address field, but rather a host/port which is tied to TCP sockets. Maybe it is worth a discussion on the dev ML to move to `address` instead of `host`/`port` combination. So do all decent socket-based services like sshd, httpd, etc. WDYT? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] michael-o commented on a change in pull request #382: Add support for unix domain sockets.
michael-o commented on a change in pull request #382: URL: https://github.com/apache/tomcat/pull/382#discussion_r540877133 ## File path: webapps/docs/config/http.xml ## @@ -208,6 +208,24 @@ The default is POST + Review comment: Having both enabled might lead to confusion as it does now with dual-stack socket. Most don't even know that one can pass sockopt [`IPV6_V6ONLY`](https://www.freebsd.org/cgi/man.cgi?query=ip6&apropos=0&sektion=4&manpath=FreeBSD+12.2-RELEASE+and+Ports&arch=default&format=html). I would avoid such situation unless the admin does exactly know what is happening here. Now the misfortune here is that we don't have an address field, but rather a host/port which is tied to TCP sockets. Maybe it is worth a discussion on the dev ML to move to `address` instead of `host`/`port` combination. So do all decent socket-based services like sshd, httpd, etc. WDYT? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat-jakartaee-migration] branch master updated: Re-work how the bin folder path is calculated
This is an automated email from the ASF dual-hosted git repository. mgrigorov pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git The following commit(s) were added to refs/heads/master by this push: new e8e3318 Re-work how the bin folder path is calculated e8e3318 is described below commit e8e3318bac8851ee757af58011f21b3b7d28c97d Author: Martin Tzvetanov Grigorov AuthorDate: Fri Dec 11 13:36:03 2020 +0200 Re-work how the bin folder path is calculated Suggested-by: Rainer Jung --- src/main/scripts/migrate.sh | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/main/scripts/migrate.sh b/src/main/scripts/migrate.sh index 3d3f34c..cf43ced 100755 --- a/src/main/scripts/migrate.sh +++ b/src/main/scripts/migrate.sh @@ -1,6 +1,9 @@ #!/bin/sh -BIN_FOLDER=`dirname $PWD/$0` +mydir="$PWD" +cd `dirname "$0"` +BIN_FOLDER="$PWD" +cd "$mydir" # Assumes java is on the path java -cp "$BIN_FOLDER/../lib/*" org.apache.tomcat.jakartaee.MigrationCLI "$@" - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-jakartaee-migration] branch master updated: Make migrate.sh usable from any directory
On Fri, Dec 11, 2020 at 1:20 PM Rainer Jung wrote: > Am 11.12.2020 um 09:49 schrieb Martin Grigorov: > > On Fri, Dec 11, 2020 at 10:41 AM Martin Grigorov > > wrote: > > > >> Hi Rainer, > >> > >> On Fri, Dec 11, 2020 at 10:37 AM Rainer Jung > >> wrote: > >> > >>> Am 11.12.2020 um 08:25 schrieb mgrigo...@apache.org: > This is an automated email from the ASF dual-hosted git repository. > > mgrigorov pushed a commit to branch master > in repository > >>> https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git > > > The following commit(s) were added to refs/heads/master by this push: > new 000c876 Make migrate.sh usable from any directory > 000c876 is described below > > commit 000c876ea3a1e700df2fffef70b29d9c3a9dfef2 > Author: Martin Tzvetanov Grigorov > AuthorDate: Fri Dec 11 09:22:22 2020 +0200 > > Make migrate.sh usable from any directory > > Until now one has to `cd` to the bin/ folder to be able to > execute > >>> migrate.sh, otherwise lib/ folder won't be found > --- > src/main/scripts/migrate.sh | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/src/main/scripts/migrate.sh b/src/main/scripts/migrate.sh > index c2b941c..3d3f34c 100755 > --- a/src/main/scripts/migrate.sh > +++ b/src/main/scripts/migrate.sh > @@ -1,4 +1,6 @@ > #!/bin/sh > > +BIN_FOLDER=`dirname $PWD/$0` > >>> > >>> Does that work if $0 is an absolute path? > >>> > >> > >> Yes, it does. I have tested it! > >> BIN_FOLDER looks a bit strange: ///some/absolute/path/bin but it works > >> just fine on my Ubuntu. > >> Does it work on Solaris ? :-) > >> > >> > >>> > >>> Maybe one could > >>> > >>> cd `dirname $0` > >>> > >> > > Two issues with this: > > > > 1) the script usage is: ./bin/migrate.sh input.war output.war > > if we "cd" into bin/ then input.war is not there anymore. Its path should > > be fixed to ../input.war somehow > > > > 2) it would be good to leave the user back to the original directory > after > > executing the script but pushd/popd are not available for 'sh'. We will > > need to use Bash or another > > Solaris check: > > apache% cat test.sh > #!/bin/sh > > echo `dirname $PWD/$0` > > apache% /home/jung/test.sh > /home/jung//home/jung > > apache% ./test.sh > /home/jung/. > > So the full path case does not work there. Switching to /bin/bash or > /bin/ksh does not help. > > I agree with Mark concerning the TC scripts. > > Concerning your 2) above: a "cd" in the script does not change the > working diretory of the calling shell. After the end of the script, the > user is still in the same directory where he was before starting it. > > 1) is a bit more tricky, because again one would have to handle the > absolute and the relative case. > > What might help and should be compatible would be something like > > mydir="$PWD" > cd `dirname "$0"` > BIN_FOLDER="$PWD" > cd "$mydir" > This works perfect! Thank you, Rainer! > > Regards, > > Rainer > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
[GitHub] [tomcat] martin-g commented on a change in pull request #382: Add support for unix domain sockets.
martin-g commented on a change in pull request #382: URL: https://github.com/apache/tomcat/pull/382#discussion_r540897626 ## File path: webapps/docs/config/http.xml ## @@ -208,6 +208,24 @@ The default is POST + Review comment: I've just tested it. It seems only UDS is enabled: ``` openjdk version "16-ea" 2021-03-16 OpenJDK Runtime Environment (build 16-ea+26-1764) OpenJDK 64-Bit Server VM (build 16-ea+26-1764, mixed mode) === Protocol: org.apache.coyote.http11.Http11AprProtocol === Starting : Connector[org.apache.coyote.http11.Http11AprProtocol-8080] Dec 11, 2020 11:55:52 AM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: Loaded Apache Tomcat Native library [1.2.27] using APR version [1.6.5]. Dec 11, 2020 11:55:52 AM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true], UDS [true]. Dec 11, 2020 11:55:52 AM org.apache.catalina.core.AprLifecycleListener initializeSSL INFO: OpenSSL successfully initialized [OpenSSL 1.1.1g-dev xx XXX ] Dec 11, 2020 11:55:52 AM org.apache.coyote.http11.AbstractHttp11Protocol configureUpgradeProtocol INFO: The ["https-openssl-apr-/tmp/tomcat-uds.sock"] connector has been configured to support negotiation to [h2] via ALPN Dec 11, 2020 11:55:52 AM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler ["https-openssl-apr-/tmp/tomcat-uds.sock"] Dec 11, 2020 11:55:52 AM org.apache.catalina.core.StandardService startInternal INFO: Starting service [Tomcat] Dec 11, 2020 11:55:52 AM org.apache.catalina.core.StandardEngine startInternal INFO: Starting Servlet engine: [Apache Tomcat/10.0.0-M11-dev] Dec 11, 2020 11:55:53 AM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler ["https-openssl-apr-/tmp/tomcat-uds.sock"] === Started ``` ``` $ sudo netstat -anp | grep 2887991 (standard input):35:unix 2 [ ACC ] STREAM LISTENING 14491510 2887991/java /tmp/tomcat-uds.sock (standard input):165:unix 2 [ ] STREAM CONNECTED 14491508 2887991/java ``` This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] martin-g commented on pull request #382: Add support for unix domain sockets.
martin-g commented on pull request #382:
URL: https://github.com/apache/tomcat/pull/382#issuecomment-743155616
There is some issue with stopping an embedded Tomcat:
```
=== Started
^CDec 11, 2020 11:59:45 AM org.apache.coyote.AbstractProtocol pause
INFO: Pausing ProtocolHandler ["https-openssl-apr-/tmp/tomcat-uds.sock"]
Dec 11, 2020 11:59:45 AM org.apache.catalina.core.StandardService
stopInternal
INFO: Stopping service [Tomcat]
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.apache.catalina.loader.WebappClassLoaderBase
(file:/home/ubuntu/git/mg.solutions/http2-server-perf-tests/java/tomcat/target/tomcat-embedded-1.0-SNAPSHOT.jar)
to field java.io.ObjectStreamClass$Caches.localDescs
WARNING: Please consider reporting this to the maintainers of
org.apache.catalina.loader.WebappClassLoaderBase
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
Dec 11, 2020 11:59:45 AM org.apache.coyote.AbstractProtocol stop
INFO: Stopping ProtocolHandler ["https-openssl-apr-/tmp/tomcat-uds.sock"]
Dec 11, 2020 11:59:55 AM org.apache.tomcat.util.net.Acceptor stop
WARNING: The acceptor thread
[https-openssl-apr-/tmp/tomcat-uds.sock-Acceptor] did not stop cleanly
=== Stopped
```
and the application hangs.
Thread dump:
```
2020-12-11 12:02:45
Full thread dump OpenJDK 64-Bit Server VM (16-ea+26-1764 mixed mode):
Threads class SMR info:
_java_thread_list=0x806d7a50, length=14, elements={
0x801d1390, 0x801d2b30, 0x801ffda0,
0x802012e0,
0x80202810, 0x802042e0, 0x802058e0,
0x80206e70,
0x80297670, 0x802a23f0, 0x80697560,
0xfffef8001100,
0x806e3050, 0x800248b0
}
"Reference Handler" #2 daemon prio=10 os_prio=0 cpu=0.42ms elapsed=413.75s
tid=0x801d1390 nid=0x2c113f waiting on condition [0x609fc000]
java.lang.Thread.State: RUNNABLE
at
java.lang.ref.Reference.waitForReferencePendingList(java.base@16-ea/Native
Method)
at
java.lang.ref.Reference.processPendingReferences(java.base@16-ea/Reference.java:243)
at
java.lang.ref.Reference$ReferenceHandler.run(java.base@16-ea/Reference.java:215)
"Finalizer" #3 daemon prio=8 os_prio=0 cpu=0.46ms elapsed=413.75s
tid=0x801d2b30 nid=0x2c1140 in Object.wait() [0x607fc000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(java.base@16-ea/Native Method)
- waiting on <0x0007148016c8> (a
java.lang.ref.ReferenceQueue$Lock)
at
java.lang.ref.ReferenceQueue.remove(java.base@16-ea/ReferenceQueue.java:155)
- locked <0x0007148016c8> (a java.lang.ref.ReferenceQueue$Lock)
[GitHub] [tomcat] martin-g commented on pull request #382: Add support for unix domain sockets.
martin-g commented on pull request #382: URL: https://github.com/apache/tomcat/pull/382#issuecomment-743160059 In my test application TLS is configured but it is not used/needed by UDS so HTTP2 does not work: ``` $ curl --http2 --unix-socket /tmp/tomcat-uds.sock http://localhost/testbed/plaintext curl: (56) Recv failure: Connection reset by peer $ ubuntu@martin-arm64 /tmp [56]> curl --unix-socket /tmp/tomcat-uds.sock http://localhost/testbed/plaintext curl: (56) Recv failure: Connection reset by peer ``` If I use `h2c` then all is fine: `INFO: The ["http-apr-/tmp/tomcat-uds.sock"] connector has been configured to support HTTP upgrade to [h2c]` ``` $ curl --unix-socket /tmp/tomcat-uds.sock http://localhost/testbed/plaintext Hello world!⏎ ``` I think it would be good to document this. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] martin-g commented on pull request #382: Add support for unix domain sockets.
martin-g commented on pull request #382:
URL: https://github.com/apache/tomcat/pull/382#issuecomment-743166815
Load tested it with Vegeta:
```
$ echo "GET http://localhost/testbed/plaintext"; | vegeta attack -unix-socket
/tmp/tomcat-uds.sock -rate 0 -max-workers 128 -duration 30s | vegeta encode |
vegeta report --type json | jq .
{
"latencies": {
"total": 2849931195122,
"mean": 2189702,
"50th": 1623066,
"90th": 4702159,
"95th": 5418223,
"99th": 7096980,
"max": 69859908,
"min": 56120
},
"bytes_in": {
"total": 15618180,
"mean": 12
},
"bytes_out": {
"total": 0,
"mean": 0
},
"earliest": "2020-12-11T12:27:16.43339275Z",
"latest": "2020-12-11T12:27:46.49493Z",
"end": "2020-12-11T12:27:46.436590425Z",
"duration": 2946743,
"wait": 3250932,
"requests": 1301515,
"rate": 43383.910349897116,
"throughput": 43379.20957953359,
"success": 1,
"status_codes": {
"200": 1301515
},
"errors": []
}
```
Throughput: **43379**. Not bad at all!
With TCP I was able to get 16654 on the same server, but with Tomcat 9.0.x
and vegeta was executed on another machine.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.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 Native 1.2.26
Am 10.12.2020 um 22:10 schrieb Mark Thomas: Version 1.2.26 includes the following changes compared to 1.2.25 - Windows binaries built using 1.1.1i - BZ 64942 - expose support for unix domain sockets Various other fixes and improvements. See the changelog for details. The proposed release artefacts can be found at [1], and the build was done using tag [2]. The Apache Tomcat Native 1.2.26 release is [ ] Stable, go ahead and release [ ] Broken because of ... Thanks, Mark [1] https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/native/1.2.26 [2] https://gitbox.apache.org/repos/asf?p=tomcat-native.git;a=commit;h=64fafd13032afb34690e3c3343b6f614f04b2660 File build.properties.default contains: base-maven.loc=http://repo.maven.apache.org/maven2 Downloading from the URL fails with 501 HTTPS Required. Use https://repo.maven.apache.org/maven2/ More information at https://links.sonatype.com/central/501-https-required This happens especially for junit needed for "ant test". Switching to https in the URL should work. Of course this doesn't influence the functionality of the packaged code not the provided binaries, just the ability of running the tests (which seemingly nobody actually uses). The TC tests using tcnative are probably more important than the old bundled tcnative tests. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] martin-g commented on pull request #382: Add support for unix domain sockets.
martin-g commented on pull request #382:
URL: https://github.com/apache/tomcat/pull/382#issuecomment-743173688
Here are the results for load testing APR protocol over TCP, both Tomcat and
Vegeta running on the same machine:
```
echo "GET http://localhost:8080/testbed/plaintext"; | vegeta attack -rate 0
-max-workers 128 -duration 3
0s | vegeta encode | vegeta report --type json | jq .
{
"latencies": {
"total": 2993301754968,
"mean": 2558679,
"50th": 2097687,
"90th": 5000518,
"95th": 5898497,
"99th": 8044202,
"max": 151339083,
"min": 71830
},
"bytes_in": {
"total": 14038344,
"mean": 12
},
"bytes_out": {
"total": 0,
"mean": 0
},
"earliest": "2020-12-11T12:45:29.355079583Z",
"latest": "2020-12-11T12:45:59.355129897Z",
"end": "2020-12-11T12:45:59.356131037Z",
"duration": 3050314,
"wait": 1001140,
"requests": 1169862,
"rate": 38995.3345996245,
"throughput": 38994.03331892302,
"success": 1,
"status_codes": {
"200": 1169862
},
"errors": []
}
```
TCP: 38994
UDS: 43379
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 64974] Tomcat losing HTTP pipeline requests if asking for available bytes
https://bz.apache.org/bugzilla/show_bug.cgi?id=64974 --- Comment #4 from Mark Thomas --- I have a test case that replicates this now and some ideas for a potential fix. Combining async and pipelining does seem an odd thing to do but I don't see any spec language that would prevent it. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 1.2.26
On Thu, Dec 10, 2020 at 11:10 PM Mark Thomas wrote: > Version 1.2.26 includes the following changes compared to 1.2.25 > > - Windows binaries built using 1.1.1i > > - BZ 64942 - expose support for unix domain sockets > > Various other fixes and improvements. See the changelog for details. > > The proposed release artefacts can be found at [1], > and the build was done using tag [2]. > > The Apache Tomcat Native 1.2.26 release is > [ X ] Stable, go ahead and release > [ ] Broken because of ... > UDS works well! Martin > > Thanks, > > Mark > > > [1] > > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/native/1.2.26 > [2] > > https://gitbox.apache.org/repos/asf?p=tomcat-native.git;a=commit;h=64fafd13032afb34690e3c3343b6f614f04b2660 > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
[tomcat-native] branch master updated: Switch maven repo URL from http to https.
This is an automated email from the ASF dual-hosted git repository. rjung pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/tomcat-native.git The following commit(s) were added to refs/heads/master by this push: new e348c0e Switch maven repo URL from http to https. e348c0e is described below commit e348c0e7242f432ce932bb0b29aca7c4a85bab27 Author: Rainer Jung AuthorDate: Fri Dec 11 14:33:15 2020 +0100 Switch maven repo URL from http to https. --- build.properties.default | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/build.properties.default b/build.properties.default index d8fcdcc..e0c9c2c 100644 --- a/build.properties.default +++ b/build.properties.default @@ -36,7 +36,7 @@ compile.debug=off compile.deprecation=on compile.optimize=on -base-maven.loc=http://repo.maven.apache.org/maven2 +base-maven.loc=https://repo.maven.apache.org/maven2 # - JUnit Unit Test Suite, version 4.11 or later - junit.version=4.11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 64974] Tomcat losing HTTP pipeline requests if asking for available bytes
https://bz.apache.org/bugzilla/show_bug.cgi?id=64974 --- Comment #5 from Remy Maucherat --- (In reply to Mark Thomas from comment #4) > I have a test case that replicates this now and some ideas for a potential > fix. > > Combining async and pipelining does seem an odd thing to do but I don't see > any spec language that would prevent it. It still doesn't make sense to me and I still don't see how it really happens with input that means something and an application that doesn't actively tries to mess up its input. I think the code in Http11InputBuffer.available(boolean read) could likely use InputFilter.isFinished to avoid the edge case. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 64974] Tomcat losing HTTP pipeline requests if asking for available bytes
https://bz.apache.org/bugzilla/show_bug.cgi?id=64974 --- Comment #6 from Mark Thomas --- Both isFinished() and available() appear to have problems differentiating between current request data and pipelined request data. I thought I had a trivial fix but it is breaking other tests. Still working on it. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-native] branch master updated: Add more information around minimum versions
Am 2020-12-10 um 13:21 schrieb ma...@apache.org: This is an automated email from the ASF dual-hosted git repository. markt pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/tomcat-native.git The following commit(s) were added to refs/heads/master by this push: new 51468b2 Add more information around minimum versions 51468b2 is described below commit 51468b2357ae46ecd7363aa05285e5c48a0888b2 Author: Mark Thomas AuthorDate: Thu Dec 10 12:21:05 2020 + Add more information around minimum versions --- native/srclib/VERSIONS | 35 ++- 1 file changed, 34 insertions(+), 1 deletion(-) diff --git a/native/srclib/VERSIONS b/native/srclib/VERSIONS index f6b09de..e52a291 100644 --- a/native/srclib/VERSIONS +++ b/native/srclib/VERSIONS @@ -1,7 +1,40 @@ +The current minimum versions are: +- OpenSSL 1.0.2 +- APR 1.4.3 + The following version of the libraries are recommended: - APR 1.7.0 or later, http://apr.apache.org - OpenSSL 1.1.1g or later, http://www.openssl.org Older versions should also work but are not as thoroughly tested by the Tomcat -Native team \ No newline at end of file +Native team + +It is current anticipated that Tomcat Native releases will transition to 1.3.x +after April 2021 when the minimum version will become OpenSSL 1.1.0 and +APR 1.5.2. + +The minimum version of OpenSSL is driven by the version of OpenSSL used by +downstream distributions. + +The current state of OpenSSL in Debian is: +- OpenSSL 1.1.0l in Debian 9 (EOL in June 2022) +- OpenSSL 1.1.1d in Debian 10 + +And in Ubuntu: +- OpenSSL 1.0.2g in Ubuntu 16.04 LTS (EOL in April 2021) +- OpenSSL 1.1.1 in Ubuntu 18.04 LTS +- OpenSSL 1.1.1f in Ubuntu 20.04 LTS + + +The minimum version of APR is driven by the version of APR used by +downstream distributions. + +The current state of APR in Debian is: +- APR 1.5.2 in Debian 9 (EOL in June 2022) +- APR 1.6.5 in Debian 10 + +And in Ubuntu: +- APR 1.5.2 in Ubuntu 16.04 LTS (EOL in April 2021) +- APR 1.6.3 in Ubuntu 18.04 LTS +- APR 1.6.5 in Ubuntu 20.04 LTS I consider this to be wrong. We should support only what upstream supports, with some grace period of course. Everything else is a OS vendor problem, not ours. Especially for Mark Shuttleworth's project. M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 64974] Tomcat losing HTTP pipeline requests if asking for available bytes
https://bz.apache.org/bugzilla/show_bug.cgi?id=64974 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Mark Thomas --- Fixed in: - 10.0.x for 10.0.1 onwards - 9.0.x for 9.0.42 onwards - 8.5.x for 8.5.62 onwards -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch master updated: Fix BZ 64974 - non-blocking I/O + pipelining could drop requests
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/master by this push:
new a5b3b07 Fix BZ 64974 - non-blocking I/O + pipelining could drop
requests
a5b3b07 is described below
commit a5b3b07ace0b04db02ef99178099f0998b96e094
Author: Mark Thomas
AuthorDate: Fri Dec 11 15:59:21 2020 +
Fix BZ 64974 - non-blocking I/O + pipelining could drop requests
---
.../apache/coyote/http11/Http11InputBuffer.java| 42 +-
.../apache/coyote/http11/TestHttp11Processor.java | 91 +-
webapps/docs/changelog.xml | 9 +++
3 files changed, 118 insertions(+), 24 deletions(-)
diff --git a/java/org/apache/coyote/http11/Http11InputBuffer.java
b/java/org/apache/coyote/http11/Http11InputBuffer.java
index 555e3ad..c12df8a 100644
--- a/java/org/apache/coyote/http11/Http11InputBuffer.java
+++ b/java/org/apache/coyote/http11/Http11InputBuffer.java
@@ -654,8 +654,10 @@ public class Http11InputBuffer implements InputBuffer,
ApplicationBufferHandler
/**
- * Available bytes in the buffers (note that due to encoding, this may not
- * correspond).
+ * Available bytes in the buffers for the current request.
+ *
+ * Note that when requests are pipelined, the data in byteBuffer may relate
+ * to the next request rather than this one.
*/
int available(boolean read) {
int available;
@@ -666,12 +668,19 @@ public class Http11InputBuffer implements InputBuffer,
ApplicationBufferHandler
available = activeFilters[lastActiveFilter].available();
}
-if (available > 0 || !read) {
-return available;
-}
-
+// Only try a non-blocking read if:
+// - there is no data in the filters
+// - the caller requested a read
+// - there is no data in byteBuffer
+// - the socket wrapper indicates a read is allowed
+//
+// Notes: 1. When pipelined requests are being used available may be
+//zero even when byteBuffer has data. This is because the data
+//in byteBuffer is for the next request. We don't want to
+//attempt a read in this case.
+//2. wrapper.hasDataToRead() is present to handle the NIO2 case
try {
-if (wrapper.hasDataToRead()) {
+if (available == 0 && read && !byteBuffer.hasRemaining() &&
wrapper.hasDataToRead()) {
fill(false);
available = byteBuffer.remaining();
}
@@ -694,22 +703,9 @@ public class Http11InputBuffer implements InputBuffer,
ApplicationBufferHandler
* faking non-blocking reads with the blocking IO connector.
*/
boolean isFinished() {
-if (byteBuffer.limit() > byteBuffer.position()) {
-// Data to read in the buffer so not finished
-return false;
-}
-
-/*
- * Don't use fill(false) here because in the following circumstances
- * BIO will block - possibly indefinitely
- * - client is using keep-alive and connection is still open
- * - client has sent the complete request
- * - client has not sent any of the next request (i.e. no pipelining)
- * - application has read the complete request
- */
-
-// Check the InputFilters
-
+// The active filters have the definitive information on whether or not
+// the current request body has been read. Note that byteBuffer may
+// contain pipelined data so is not a good indicator.
if (lastActiveFilter >= 0) {
return activeFilters[lastActiveFilter].isFinished();
} else {
diff --git a/test/org/apache/coyote/http11/TestHttp11Processor.java
b/test/org/apache/coyote/http11/TestHttp11Processor.java
index e4f2e49..b6f7a6b 100644
--- a/test/org/apache/coyote/http11/TestHttp11Processor.java
+++ b/test/org/apache/coyote/http11/TestHttp11Processor.java
@@ -39,7 +39,9 @@ import java.util.concurrent.CountDownLatch;
import jakarta.servlet.AsyncContext;
import jakarta.servlet.DispatcherType;
+import jakarta.servlet.ReadListener;
import jakarta.servlet.ServletException;
+import jakarta.servlet.ServletInputStream;
import jakarta.servlet.http.Cookie;
import jakarta.servlet.http.HttpServlet;
import jakarta.servlet.http.HttpServletRequest;
@@ -381,6 +383,49 @@ public class TestHttp11Processor extends TomcatBaseTest {
@Test
+public void testPipeliningBug64974() throws Exception {
+Tomcat tomcat = getTomcatInstance();
+
+// No file system docBase required
+Context ctx = tomcat.addContext("", null);
+
+// Add protected servlet
+Wrapper w = Tomcat.addServlet(ctx, "servlet", new Bug64974Servlet());
+w.setAsyncSupported(true);
+ctx.addServlet
[tomcat] branch 9.0.x updated: Fix BZ 64974 - non-blocking I/O + pipelining could drop requests
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/9.0.x by this push:
new f950a96 Fix BZ 64974 - non-blocking I/O + pipelining could drop
requests
f950a96 is described below
commit f950a96fd0f9ffb92b32a46b8ebaa8bb455d95dd
Author: Mark Thomas
AuthorDate: Fri Dec 11 15:59:21 2020 +
Fix BZ 64974 - non-blocking I/O + pipelining could drop requests
---
.../apache/coyote/http11/Http11InputBuffer.java| 42 +-
.../apache/coyote/http11/TestHttp11Processor.java | 91 +-
webapps/docs/changelog.xml | 9 +++
3 files changed, 118 insertions(+), 24 deletions(-)
diff --git a/java/org/apache/coyote/http11/Http11InputBuffer.java
b/java/org/apache/coyote/http11/Http11InputBuffer.java
index 9e5ffe0..483b08e 100644
--- a/java/org/apache/coyote/http11/Http11InputBuffer.java
+++ b/java/org/apache/coyote/http11/Http11InputBuffer.java
@@ -654,8 +654,10 @@ public class Http11InputBuffer implements InputBuffer,
ApplicationBufferHandler
/**
- * Available bytes in the buffers (note that due to encoding, this may not
- * correspond).
+ * Available bytes in the buffers for the current request.
+ *
+ * Note that when requests are pipelined, the data in byteBuffer may relate
+ * to the next request rather than this one.
*/
int available(boolean read) {
int available;
@@ -666,12 +668,19 @@ public class Http11InputBuffer implements InputBuffer,
ApplicationBufferHandler
available = activeFilters[lastActiveFilter].available();
}
-if (available > 0 || !read) {
-return available;
-}
-
+// Only try a non-blocking read if:
+// - there is no data in the filters
+// - the caller requested a read
+// - there is no data in byteBuffer
+// - the socket wrapper indicates a read is allowed
+//
+// Notes: 1. When pipelined requests are being used available may be
+//zero even when byteBuffer has data. This is because the data
+//in byteBuffer is for the next request. We don't want to
+//attempt a read in this case.
+//2. wrapper.hasDataToRead() is present to handle the NIO2 case
try {
-if (wrapper.hasDataToRead()) {
+if (available == 0 && read && !byteBuffer.hasRemaining() &&
wrapper.hasDataToRead()) {
fill(false);
available = byteBuffer.remaining();
}
@@ -694,22 +703,9 @@ public class Http11InputBuffer implements InputBuffer,
ApplicationBufferHandler
* faking non-blocking reads with the blocking IO connector.
*/
boolean isFinished() {
-if (byteBuffer.limit() > byteBuffer.position()) {
-// Data to read in the buffer so not finished
-return false;
-}
-
-/*
- * Don't use fill(false) here because in the following circumstances
- * BIO will block - possibly indefinitely
- * - client is using keep-alive and connection is still open
- * - client has sent the complete request
- * - client has not sent any of the next request (i.e. no pipelining)
- * - application has read the complete request
- */
-
-// Check the InputFilters
-
+// The active filters have the definitive information on whether or not
+// the current request body has been read. Note that byteBuffer may
+// contain pipelined data so is not a good indicator.
if (lastActiveFilter >= 0) {
return activeFilters[lastActiveFilter].isFinished();
} else {
diff --git a/test/org/apache/coyote/http11/TestHttp11Processor.java
b/test/org/apache/coyote/http11/TestHttp11Processor.java
index 96b25dd..c2bc25a 100644
--- a/test/org/apache/coyote/http11/TestHttp11Processor.java
+++ b/test/org/apache/coyote/http11/TestHttp11Processor.java
@@ -39,7 +39,9 @@ import java.util.concurrent.CountDownLatch;
import javax.servlet.AsyncContext;
import javax.servlet.DispatcherType;
+import javax.servlet.ReadListener;
import javax.servlet.ServletException;
+import javax.servlet.ServletInputStream;
import javax.servlet.http.Cookie;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
@@ -381,6 +383,49 @@ public class TestHttp11Processor extends TomcatBaseTest {
@Test
+public void testPipeliningBug64974() throws Exception {
+Tomcat tomcat = getTomcatInstance();
+
+// No file system docBase required
+Context ctx = tomcat.addContext("", null);
+
+// Add protected servlet
+Wrapper w = Tomcat.addServlet(ctx, "servlet", new Bug64974Servlet());
+w.setAsyncSupported(true);
+ctx.addServletMappingDecoded("/f
[tomcat] branch 8.5.x updated: Fix BZ 64974 - non-blocking I/O + pipelining could drop requests
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/8.5.x by this push:
new ee14812 Fix BZ 64974 - non-blocking I/O + pipelining could drop
requests
ee14812 is described below
commit ee1481265fefb973bc6a585b973267579cf882ee
Author: Mark Thomas
AuthorDate: Fri Dec 11 15:59:21 2020 +
Fix BZ 64974 - non-blocking I/O + pipelining could drop requests
---
.../apache/coyote/http11/Http11InputBuffer.java| 42 +-
.../apache/coyote/http11/TestHttp11Processor.java | 91 +-
webapps/docs/changelog.xml | 9 +++
3 files changed, 118 insertions(+), 24 deletions(-)
diff --git a/java/org/apache/coyote/http11/Http11InputBuffer.java
b/java/org/apache/coyote/http11/Http11InputBuffer.java
index 728242e..3fe2b2b 100644
--- a/java/org/apache/coyote/http11/Http11InputBuffer.java
+++ b/java/org/apache/coyote/http11/Http11InputBuffer.java
@@ -668,8 +668,10 @@ public class Http11InputBuffer implements InputBuffer,
ApplicationBufferHandler
/**
- * Available bytes in the buffers (note that due to encoding, this may not
- * correspond).
+ * Available bytes in the buffers for the current request.
+ *
+ * Note that when requests are pipelined, the data in byteBuffer may relate
+ * to the next request rather than this one.
*/
int available(boolean read) {
int available;
@@ -680,12 +682,19 @@ public class Http11InputBuffer implements InputBuffer,
ApplicationBufferHandler
available = activeFilters[lastActiveFilter].available();
}
-if (available > 0 || !read) {
-return available;
-}
-
+// Only try a non-blocking read if:
+// - there is no data in the filters
+// - the caller requested a read
+// - there is no data in byteBuffer
+// - the socket wrapper indicates a read is allowed
+//
+// Notes: 1. When pipelined requests are being used available may be
+//zero even when byteBuffer has data. This is because the data
+//in byteBuffer is for the next request. We don't want to
+//attempt a read in this case.
+//2. wrapper.hasDataToRead() is present to handle the NIO2 case
try {
-if (wrapper.hasDataToRead()) {
+if (available == 0 && read && !byteBuffer.hasRemaining() &&
wrapper.hasDataToRead()) {
fill(false);
available = byteBuffer.remaining();
}
@@ -708,22 +717,9 @@ public class Http11InputBuffer implements InputBuffer,
ApplicationBufferHandler
* faking non-blocking reads with the blocking IO connector.
*/
boolean isFinished() {
-if (byteBuffer.limit() > byteBuffer.position()) {
-// Data to read in the buffer so not finished
-return false;
-}
-
-/*
- * Don't use fill(false) here because in the following circumstances
- * BIO will block - possibly indefinitely
- * - client is using keep-alive and connection is still open
- * - client has sent the complete request
- * - client has not sent any of the next request (i.e. no pipelining)
- * - application has read the complete request
- */
-
-// Check the InputFilters
-
+// The active filters have the definitive information on whether or not
+// the current request body has been read. Note that byteBuffer may
+// contain pipelined data so is not a good indicator.
if (lastActiveFilter >= 0) {
return activeFilters[lastActiveFilter].isFinished();
} else {
diff --git a/test/org/apache/coyote/http11/TestHttp11Processor.java
b/test/org/apache/coyote/http11/TestHttp11Processor.java
index 64d6003..089be58 100644
--- a/test/org/apache/coyote/http11/TestHttp11Processor.java
+++ b/test/org/apache/coyote/http11/TestHttp11Processor.java
@@ -39,7 +39,9 @@ import java.util.concurrent.CountDownLatch;
import javax.servlet.AsyncContext;
import javax.servlet.DispatcherType;
+import javax.servlet.ReadListener;
import javax.servlet.ServletException;
+import javax.servlet.ServletInputStream;
import javax.servlet.http.Cookie;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
@@ -383,6 +385,49 @@ public class TestHttp11Processor extends TomcatBaseTest {
@Test
+public void testPipeliningBug64974() throws Exception {
+Tomcat tomcat = getTomcatInstance();
+
+// No file system docBase required
+Context ctx = tomcat.addContext("", null);
+
+// Add protected servlet
+Wrapper w = Tomcat.addServlet(ctx, "servlet", new Bug64974Servlet());
+w.setAsyncSupported(true);
+ctx.addServletMappingDecoded("/f
Re: [tomcat-native] branch master updated: Update java code to align with 10.0.x
Am 2020-12-10 um 15:07 schrieb ma...@apache.org: + * @deprecated The scope of the APR/Native Library will be reduced in Tomcat + * 10.1.x / Tomcat Native 2.x onwards to only include those + * components required to provide OpenSSL integration with the NIO + * and NIO2 connectors. I think there should *not* be a Tomcat Native 2.x for the following reasons: * It has been mentioned numerous times that Tomcat Native is a bad name without a good meaning * > 50 % of the essential parts of Tomcat Native will be gone. It won't be Tomcat Native anymore as previously. * Since the APR connector is deprecated, de facto, it does not logically make sense to evolve Tomcat Native to a new major version. Just counter-intuitive. My counter proposal is to split Tomcat Native, phase it out and introduce Tomcat OpenSSL (Bridge) (libtcopenssl.so) or similar. The name should clearly say what it does. You won't going to continue the APRLifecycleListener, will you? WDYT? - 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
Am 2020-12-06 um 10:44 schrieb Mark Thomas: On 05/12/2020 12:59, Michael Osipov wrote: Am 2020-12-03 um 11:43 schrieb Mark Thomas: The proposed Apache Tomcat 10.0.0 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-M10 are: - Specs are now final. Tomcat passes the TCKs apart from a number of expected failures that don't impact spec compliance. - The APR/Native AJP and HTTP connectors have been deprecated. Tomcat Native will continue to be used to support OpenSSL use with NIO and NIO2. - Align the behaviour of ServletContext.getRealPath(String path) with the recent clarification from the Servlet specification project. If the path parameter does not start with / then Tomcat processes the call as if / is appended to the beginning of the provided path. 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/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-1287/ The tag is: https://github.com/apache/tomcat/tree/10.0.0 4c8b650437e2464c1c31c6598a263b3805b7a81f The proposed 10.0.0 release is: [ ] Broken - do not release [ ] Beta - go ahead and release as 10.0.0 (beta) [ ] Stable - go ahead and release as 10.0.0 (stable) This is confusing. You are casting a vote von a GA version: 10.0.0, but provide to mark this as beta? Huh? Shouldn't this be a binary vote? This is broadly in line with how we have done this previously. -Mxx or -RCxx while the build is considered alpha (spec APIs implementation incomplete and/or specs not final) That's true, but we can always improve user's perception of your naming scheme. If it is confusing for me, so it will be for others. We could, perhaps consider something like: -Mxx == alpha -RCxx == beta == stable If you have a mapping, you can safely drop it and use the target values for the sake of simplicity. No interpretations necessary. That's my POV. M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE][RESULT] Release Apache Tomcat 10.0.0
Am 2020-12-08 um 18:17 schrieb Mark Thomas: The following votes were case: Binding: +1 (beta): remm, isapir, mturk, mgrigorov, ebourg, markt No other votes were cast. The vote therefore passes. Thanks to everyone who contributed to this release. So, from the subject people get the impression Tomcat has gone GA while the body of the result contradicts. This should really be 10.0.0-beta-1 in the subject. M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-native] branch master updated: Update java code to align with 10.0.x
On 11/12/2020 16:24, Michael Osipov wrote: > Am 2020-12-10 um 15:07 schrieb ma...@apache.org: >> + * @deprecated The scope of the APR/Native Library will be reduced >> in Tomcat >> + * 10.1.x / Tomcat Native 2.x onwards to only include those >> + * components required to provide OpenSSL integration >> with the NIO >> + * and NIO2 connectors. > > I think there should *not* be a Tomcat Native 2.x for the following > reasons: > > * It has been mentioned numerous times that Tomcat Native is a bad name > without a good meaning > * > 50 % of the essential parts of Tomcat Native will be gone. It won't > be Tomcat Native anymore as previously. > * Since the APR connector is deprecated, de facto, it does not logically > make sense to evolve Tomcat Native to a new major version. Just > counter-intuitive. > > My counter proposal is to split Tomcat Native, phase it out and > introduce Tomcat OpenSSL (Bridge) (libtcopenssl.so) or similar. The name > should clearly say what it does. Using a new name is already one of the options. That possibility was mentioned in one of these threads about a week ago. > You won't going to continue the APRLifecycleListener, will you? There will almost certainly need to be something like it. I had imagined it would get a new name but hadn't given much though to what that name should be. > WDYT? We need to be careful when we use other organisation's trademarks in our product names. Some like: Apache Tomcat Bridge to OpenSSL would be fine. The other option is to give it an entirely new name. Apache Tomcat Phoenix for example. (I haven't done any checks on that name. It may be completely unsuitable - it is just an example). Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-native] branch master updated: Update java code to align with 10.0.x
On Fri, Dec 11, 2020 at 5:36 PM Mark Thomas wrote: > On 11/12/2020 16:24, Michael Osipov wrote: > > Am 2020-12-10 um 15:07 schrieb ma...@apache.org: > >> + * @deprecated The scope of the APR/Native Library will be reduced > >> in Tomcat > >> + * 10.1.x / Tomcat Native 2.x onwards to only include > those > >> + * components required to provide OpenSSL integration > >> with the NIO > >> + * and NIO2 connectors. > > > > I think there should *not* be a Tomcat Native 2.x for the following > > reasons: > > > > * It has been mentioned numerous times that Tomcat Native is a bad name > > without a good meaning > > * > 50 % of the essential parts of Tomcat Native will be gone. It won't > > be Tomcat Native anymore as previously. > > * Since the APR connector is deprecated, de facto, it does not logically > > make sense to evolve Tomcat Native to a new major version. Just > > counter-intuitive. > > > > My counter proposal is to split Tomcat Native, phase it out and > > introduce Tomcat OpenSSL (Bridge) (libtcopenssl.so) or similar. The name > > should clearly say what it does. > > Using a new name is already one of the options. That possibility was > mentioned in one of these threads about a week ago. > > > You won't going to continue the APRLifecycleListener, will you? > > There will almost certainly need to be something like it. I had imagined > it would get a new name but hadn't given much though to what that name > should be. > > > WDYT? > > We need to be careful when we use other organisation's trademarks in our > product names. Some like: > > Apache Tomcat Bridge to OpenSSL > > would be fine. The other option is to give it an entirely new name. > > Apache Tomcat Phoenix > > for example. (I haven't done any checks on that name. It may be > completely unsuitable - it is just an example). > I'm not sure this native code will stay for that long (replaced with integrated Java code possibly), so I'm not convinced a name is needed. -> modules/openssl ? Rémy > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [tomcat-native] branch master updated: Update java code to align with 10.0.x
Am 2020-12-11 um 17:36 schrieb Mark Thomas: On 11/12/2020 16:24, Michael Osipov wrote: Am 2020-12-10 um 15:07 schrieb ma...@apache.org: ... You won't going to continue the APRLifecycleListener, will you? There will almost certainly need to be something like it. I had imagined it would get a new name but hadn't given much though to what that name should be. Please consider to deprecate it too, for the sake of consistency. WDYT? We need to be careful when we use other organisation's trademarks in our product names. Some like: Apache Tomcat Bridge to OpenSSL Agreed, don't abuse trademarks. would be fine. The other option is to give it an entirely new name. Apache Tomcat Phoenix Even if it rises from the ashes, this name, hypothetically, wouldn't be a bit better than before because it says nothing about it's purpose. for example. (I haven't done any checks on that name. It may be We should discuss this after the planning of 1.3.x. M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-native] branch master updated: Update java code to align with 10.0.x
Am 2020-12-11 um 17:41 schrieb Rémy Maucherat: On Fri, Dec 11, 2020 at 5:36 PM Mark Thomas wrote: On 11/12/2020 16:24, Michael Osipov wrote: Am 2020-12-10 um 15:07 schrieb ma...@apache.org: + * @deprecated The scope of the APR/Native Library will be reduced in Tomcat + * 10.1.x / Tomcat Native 2.x onwards to only include those + * components required to provide OpenSSL integration with the NIO + * and NIO2 connectors. I think there should *not* be a Tomcat Native 2.x for the following reasons: * It has been mentioned numerous times that Tomcat Native is a bad name without a good meaning * > 50 % of the essential parts of Tomcat Native will be gone. It won't be Tomcat Native anymore as previously. * Since the APR connector is deprecated, de facto, it does not logically make sense to evolve Tomcat Native to a new major version. Just counter-intuitive. My counter proposal is to split Tomcat Native, phase it out and introduce Tomcat OpenSSL (Bridge) (libtcopenssl.so) or similar. The name should clearly say what it does. Using a new name is already one of the options. That possibility was mentioned in one of these threads about a week ago. You won't going to continue the APRLifecycleListener, will you? There will almost certainly need to be something like it. I had imagined it would get a new name but hadn't given much though to what that name should be. WDYT? We need to be careful when we use other organisation's trademarks in our product names. Some like: Apache Tomcat Bridge to OpenSSL would be fine. The other option is to give it an entirely new name. Apache Tomcat Phoenix for example. (I haven't done any checks on that name. It may be completely unsuitable - it is just an example). I'm not sure this native code will stay for that long (replaced with integrated Java code possibly), so I'm not convinced a name is needed. -> modules/openssl ? Are you referring to Panama? Or any substantial improvement to SunJSSE? I don't expect both happen before Java 17/18 and since none of them will be available for 8/11 JNI and the OpenSSL wrapper will likely live for another at least 5 or 8 years. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-native] branch master updated: Update java code to align with 10.0.x
On 11/12/2020 16:41, Rémy Maucherat wrote: > On Fri, Dec 11, 2020 at 5:36 PM Mark Thomas wrote: > >> On 11/12/2020 16:24, Michael Osipov wrote: >>> Am 2020-12-10 um 15:07 schrieb ma...@apache.org: + * @deprecated The scope of the APR/Native Library will be reduced in Tomcat + * 10.1.x / Tomcat Native 2.x onwards to only include >> those + * components required to provide OpenSSL integration with the NIO + * and NIO2 connectors. >>> >>> I think there should *not* be a Tomcat Native 2.x for the following >>> reasons: >>> >>> * It has been mentioned numerous times that Tomcat Native is a bad name >>> without a good meaning >>> * > 50 % of the essential parts of Tomcat Native will be gone. It won't >>> be Tomcat Native anymore as previously. >>> * Since the APR connector is deprecated, de facto, it does not logically >>> make sense to evolve Tomcat Native to a new major version. Just >>> counter-intuitive. >>> >>> My counter proposal is to split Tomcat Native, phase it out and >>> introduce Tomcat OpenSSL (Bridge) (libtcopenssl.so) or similar. The name >>> should clearly say what it does. >> >> Using a new name is already one of the options. That possibility was >> mentioned in one of these threads about a week ago. >> >>> You won't going to continue the APRLifecycleListener, will you? >> >> There will almost certainly need to be something like it. I had imagined >> it would get a new name but hadn't given much though to what that name >> should be. >> >>> WDYT? >> >> We need to be careful when we use other organisation's trademarks in our >> product names. Some like: >> >> Apache Tomcat Bridge to OpenSSL >> >> would be fine. The other option is to give it an entirely new name. >> >> Apache Tomcat Phoenix >> >> for example. (I haven't done any checks on that name. It may be >> completely unsuitable - it is just an example). >> > > I'm not sure this native code will stay for that long (replaced with > integrated Java code possibly), so I'm not convinced a name is needed. -> > modules/openssl ? I think the lifetime of the code is likely to be driven by the minimum Java version required by Jakarta EE and the typical lifecycle of Tomcat major versions. Assuming Tomcat 10.1.x has a minimum Java version that doesn't provide integration with native libraries OOTB then any library we provide to link Tomcat and OpenSSL is likely to have a lifespan of at least 10 years. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Objection to the deprecation of the tomcat-native/APR connector
Am 2020-12-06 um 11:03 schrieb Mark Thomas: On 05/12/2020 11:38, Michael Osipov wrote: A suitable roadmap for libtcnative would be: * Tag current patch version * Move to 1.3.0 and remove everything non-TLS/networking related out * Move to 1.4.0 drop OpenSSL support for < 1.1.1 because it requires thread locks from APR which aren't necessary with 1.1.1 * Likely split code between OpenSSL to Java and APR to Java with that we could satisfy both sides. There are a couple of complicating factors. The first is that we try not to remove or change existing API users are likely to be using in a major version. Addressing security issues is the exception to that rule. That means that org.apache.tomcat.jni will be supported until 9.0.x is EOL. Best guess in 6 to 7 years from now. I agree, that would be a bad move within the same major version. The other major factor is that Tomcat Native ships with at least one downstream distro (Debian? or was if FreeBSD?) where only older versions of OpenSSL are available. We'd like to be nice and not make things too complicated for the package maintainers. Well, isn't that really a OS vendor problem not ours? We can provide grace periods, but that's pretty much it. They need to solve that, not us on a volunteer basis. The admin/user/X can always compiled from code a brand new version and nothing hinders him to do so. FreeBSD's port of libtcnative is uptodate. I provide patches on regular basis. Vendors like Debian or Red Hat lag years behind. In the back of my mind I have had something along the following lines which isn't too far from your proposal. 1. Create Tomcat Native 2.0 for Tomcat 10.1.x onwards that provides only what is required to integrate OpenSSL with NIO and NIO2. Ideally, without a dependency on APR. Given likely minimum JRE version requirements of future Servlet specs, I think it will be a while before we can take advantage of any JRE features intended to simplify native integration. Makes sense. 2. Continue to support Tomcat Native 1.x for Tomcat 8.5.x and 9.0.x (10.0.x will be EOL with the first stable 10.1.x release) Agreed, I'd be happy to for the platforms I use. 3. Once downstream distributions have access to 1.1.1 move Tomcat Native 1.2.x to 1.3.x and remove all the OpenSSL <1.1.1 code. We can make 1.3.x recommended for Tomcat 8.5.x and 9.0.x (or even required if necessary / appropriate). This will take years. Won't it? 4. At the same time as 3 we probably want to review similar code for old Windows versions, old Linux kernels etc and drop support for some of those where appropriate too. Looking at the APR/OpenSSL code I haven't seen anything particular requiring any specific OS or kernel version. That's plain POSIX abstracted with APR and OpenSSL internals. But yes, skimming is good. I suspect there would be a Tomcat 1.4.x at some point to make OpenSSL 3 the minimum version. So you would continue to support two native code trees? Wouldn't make even more work than today? If we wanted to provide space for Tomcat/Native to continue providing the level of APR support it does today, rather than Use Tomcat Native 2.x for the OpenSSL integration we could use a new name (Tomcat TLS Native maybe?) leaving Tomcat Native free to evolve into 2.x, 3.x and beyond. This makes sense. Maybe a split from Tomcat Native would be a better alternative supporting APR only and OpenSSL only. So two libraries, not interrelated. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Objection to the deprecation of the tomcat-native/APR connector
Am 2020-12-09 um 14:36 schrieb Graham Leggett: On 01 Dec 2020, at 14:09, Mark Thomas wrote: I also object to the removal of OpenSSL code, for the same reason. It isn't being removed. The APR/Native library will be retained along with OpenSSL support for the NIO and NIO2. I expect the scope of the APR/Native library for Tomcat 10.1.x onwards will be reduced to just those native methods required to interact with OpenSSL which may mean removal of the APR dependency. If we can use OpenSSL without any native code of our own (e.g. via project Panama or similar) then better still. I don’t see the logic here. If the use of native code is a risk, then I expect to see use of openssl and any other API brought in by Panama avoided for the same reason? We are in the middle of a global pandemic. Our users do not have the resources to suddenly divert to reengineering what is to them a perfectly working system, to replace what exists with something else that just works differently. Upgrading to Tomcat 10 already requires significant re-engineering work due to the java package change for all the specification APIs. Switching an HTTP or AJP connector from APR/Native to NIO or NIO2 with OpenSSL requires a change of three/four characters in one configuration file. We have deliberately made it very easy to switch between connectors. No-one is being forced to upgrade. Atlassian forced me to upgrade. This is the core of the problem - gone are the days when Tomcat was just a simple server that people downloaded and used to make bespoke web services and could write code any way they liked. Now Tomcat is part of other systems, who in turn have other support horizons unrelated to this project. The AJP deprecation is a problem. For those unaware of what AJP did, AJP allowed a proxy server and Tomcat to be “glued” together as it they were one server, and not two discrete entities. The proxy configuration - that’s SSL, authn and authz - was passed transparently across to Tomcat which behaved as if Tomcat itself had performed the SSL, authn and authz. Sure, if you have a bespoke web service and the budget you can make hack changes to compensate. If your Tomcat is being provided by a vendor, or if you’re under financial strain due a pandemic, then no - you have a sudden very unwelcome headache. The closest RFC compliant solution to this problem is JSON Web Tokens (JWT), which allows data to be passed across both securely and in an RFC compliant way over HTTP. Tomcat should have fixed this problem first, and then deprecated AJP with the clear notice “use this alternative in future”. I don't see how JWTs relate here? But for the sake of support, especially with the addition of UDS which is very very nice, it makes logically sense to split both and maybe leave APR only under the hood of Tomcat with a few committers supporting it while a recommendation would be to try on NIO(2) and have APR as a viable alternative? Java native support for UDS will not arrive that soon, especially not in 8 or 11. WDYT? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 64830] HTTP2 : GOAWAY sent with Protocol Error and Frame Size Error
https://bz.apache.org/bugzilla/show_bug.cgi?id=64830 --- Comment #20 from Mark Thomas --- Looks like there is still an issue related to the HPACK decoder. I can see a debug log where the decoder reports a content-length that is not consistent with the value shown in the Wireshark trace. Still trying to figure out how this is happening. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] michael-o commented on pull request #382: Add support for unix domain sockets.
michael-o commented on pull request #382: URL: https://github.com/apache/tomcat/pull/382#issuecomment-743337472 @minfrin Could you kindly add a test case for this? I would like to finalize this and checkout @martin-g's comments. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Apache Tomcat migration tool for Jakarta EE
Mark, On 12/10/20 09:13, Mark Thomas wrote: On 10/12/2020 13:58, Christopher Schultz wrote: Mark, On 12/10/20 06:39, Mark Thomas wrote: The proposed Apache Tomcat migration tool for Jakarta EE 0.1.0 is now available for voting. This is (potentially) the first release. It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/jakartaee-migration/v0.1.0/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-1291/ The tag is: https://github.com/apache/tomcat-jakartaee-migration/tree/0.1.0 cbada3204bf9c43ca0cf481cd88c7521690b30a0 The proposed 0.1.0 release is: [ ] -1: Broken. Do not release because... [ ] +1: Acceptable. Go ahead and release. Do we even need (a) a release and (b) a VOTE? If we want a release, we MUST have a VOTE. I was kind of thinking that if we didn't need (a) then (b) would be unnecessary. Since this is a developer tool and not a runtime library or anything like that, maybe we can just say "YMMV, this is available any time you want it"? It could be a runtime library. One possibility is that we integrate it into Tomcat 10 somehow so that if you try and deploy a Java EE 8 WAR it gets automatically converted to a Jakarta EE 9 WAR. Witchcraft. -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Apache Tomcat migration tool for Jakarta EE
Mark, On 12/10/20 11:14, Mark Thomas wrote: On 10/12/2020 14:52, Romain Manni-Bucau wrote: Le jeu. 10 déc. 2020 à 15:49, Rémy Maucherat a écrit : On Thu, Dec 10, 2020 at 3:13 PM Mark Thomas wrote: On 10/12/2020 13:58, Christopher Schultz wrote: Since this is a developer tool and not a runtime library or anything like that, maybe we can just say "YMMV, this is available any time you want it"? It could be a runtime library. One possibility is that we integrate it into Tomcat 10 somehow so that if you try and deploy a Java EE 8 WAR it gets automatically converted to a Jakarta EE 9 WAR. It sounds doable with a special folder of the host (like a legacyAppBase), and it creates the result in the host's appBase. Like HostConfig.deployApps simply does this first, then moves down the usual deployments. I'm not sure that this is really useful though. Does it sound stupid to make the library a ClassFileTransformer added on the webapp classloader? Sounds the most hurtless for users even if it will adds a small overhead (and avoids a lot of file duplication which can be harder to maintain at some point). It doesn't sound stupid at all. It was one of the options considered when we first started thinking about this. That was before we had the current implementation. With the experience of what the current implementation looks like we might want to revisit that discussion. My own thinking was to convert appBase/javaee.war to appBase/javaee##converted.war and let the parallel deployment code take care of deploying just the updated version. Doing conversion on the fly or at deployment/start-up time raises various issues that boil down to "How do we detect if conversion is required?" and "What are the performance impacts of doing so?". There are users who want to squeeze every last drop of performance out of the system so I think that leads to some sort of configuration option. Just thinking about that I thought of: - watch what classes are requested - as soon as javax.servlet.* (or one of the others is detected) stop the context, enable conversion and restart the context Then I thought that apps might try to determine if they are running on Java EE or Jakarta EE by trying to load classes. That could incorrectly trigger the conversion. Hmm. Anything apart from an explicitly user set flag starts to look potentially tricky for some use cases. Thoughts? Read the WEB-INF/web.xml file for the web-app version? -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Apache Tomcat migration tool for Jakarta EE
Mark, On 12/10/20 11:14, Mark Thomas wrote: [snip] > Doing conversion on the fly or at deployment/start-up time raises various issues that boil down to "How do we detect if conversion is required?" and "What are the performance impacts of doing so?". There are users who want to squeeze every last drop of performance out of the system so I think that leads to some sort of configuration option. This conversion is only applied at class-loading time, yes? Not on every request, etc. I would imagine that a one-time hit for all classes wouldn't be that big of a deal. Tomcat could allow admins to either allow auto-conversion or not, for the whole server. Or, maybe, for the whole or something. -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-jakartaee-migration] branch master updated: Make migrate.sh usable from any directory
Martin, On 12/11/20 04:02, Martin Grigorov wrote: On Fri, Dec 11, 2020 at 10:53 AM Mark Thomas wrote: On 11/12/2020 08:49, Martin Grigorov wrote: On Fri, Dec 11, 2020 at 10:41 AM Martin Grigorov wrote: On Fri, Dec 11, 2020 at 10:37 AM Rainer Jung Maybe one could cd `dirname $0` Two issues with this: 1) the script usage is: ./bin/migrate.sh input.war output.war if we "cd" into bin/ then input.war is not there anymore. Its path should be fixed to ../input.war somehow 2) it would be good to leave the user back to the original directory after executing the script but pushd/popd are not available for 'sh'. We will need to use Bash or another You might find inspiration for a fix in the Tomcat startup scripts. Do we need to fix it ? It works fine. This looks weird to me: > BIN_FOLDER=`dirname $PWD/$0` Why not simply: BIN_FOLDER=$( dirname $0 ) (I have converted to $(...) instead of `...` because the syntax is better, more navigable, allows nesting, etc.) There shouldn't be any reason for the $PWD to be in there because the user's current working directory is irrelevant. -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-jakartaee-migration] branch master updated: Make migrate.sh usable from any directory
Rainer, On 12/11/20 06:19, Rainer Jung wrote: Am 11.12.2020 um 09:49 schrieb Martin Grigorov: On Fri, Dec 11, 2020 at 10:41 AM Martin Grigorov wrote: Hi Rainer, On Fri, Dec 11, 2020 at 10:37 AM Rainer Jung wrote: Am 11.12.2020 um 08:25 schrieb mgrigo...@apache.org: This is an automated email from the ASF dual-hosted git repository. mgrigorov pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git The following commit(s) were added to refs/heads/master by this push: new 000c876 Make migrate.sh usable from any directory 000c876 is described below commit 000c876ea3a1e700df2fffef70b29d9c3a9dfef2 Author: Martin Tzvetanov Grigorov AuthorDate: Fri Dec 11 09:22:22 2020 +0200 Make migrate.sh usable from any directory Until now one has to `cd` to the bin/ folder to be able to execute migrate.sh, otherwise lib/ folder won't be found --- src/main/scripts/migrate.sh | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/main/scripts/migrate.sh b/src/main/scripts/migrate.sh index c2b941c..3d3f34c 100755 --- a/src/main/scripts/migrate.sh +++ b/src/main/scripts/migrate.sh @@ -1,4 +1,6 @@ #!/bin/sh +BIN_FOLDER=`dirname $PWD/$0` Does that work if $0 is an absolute path? Yes, it does. I have tested it! BIN_FOLDER looks a bit strange: ///some/absolute/path/bin but it works just fine on my Ubuntu. Does it work on Solaris ? :-) Maybe one could cd `dirname $0` Two issues with this: 1) the script usage is: ./bin/migrate.sh input.war output.war if we "cd" into bin/ then input.war is not there anymore. Its path should be fixed to ../input.war somehow 2) it would be good to leave the user back to the original directory after executing the script but pushd/popd are not available for 'sh'. We will need to use Bash or another Solaris check: apache% cat test.sh #!/bin/sh echo `dirname $PWD/$0` apache% /home/jung/test.sh /home/jung//home/jung apache% ./test.sh /home/jung/. So the full path case does not work there. Switching to /bin/bash or /bin/ksh does not help. I agree with Mark concerning the TC scripts. Concerning your 2) above: a "cd" in the script does not change the working diretory of the calling shell. After the end of the script, the user is still in the same directory where he was before starting it. 1) is a bit more tricky, because again one would have to handle the absolute and the relative case. What might help and should be compatible would be something like mydir="$PWD" cd `dirname "$0"` BIN_FOLDER="$PWD" cd "$mydir" I would avoid using "cd" in a script if at all possible. The migration tool should be able to be run from anywhere with command-line arguments to anything you need to call (e.g. java -cp). -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-jakartaee-migration] branch master updated: Make migrate.sh usable from any directory
Hi Chris, Am 11.12.2020 um 19:53 schrieb Christopher Schultz: Rainer, On 12/11/20 06:19, Rainer Jung wrote: Am 11.12.2020 um 09:49 schrieb Martin Grigorov: On Fri, Dec 11, 2020 at 10:41 AM Martin Grigorov wrote: Hi Rainer, On Fri, Dec 11, 2020 at 10:37 AM Rainer Jung wrote: Am 11.12.2020 um 08:25 schrieb mgrigo...@apache.org: This is an automated email from the ASF dual-hosted git repository. mgrigorov pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git The following commit(s) were added to refs/heads/master by this push: new 000c876 Make migrate.sh usable from any directory 000c876 is described below commit 000c876ea3a1e700df2fffef70b29d9c3a9dfef2 Author: Martin Tzvetanov Grigorov AuthorDate: Fri Dec 11 09:22:22 2020 +0200 Make migrate.sh usable from any directory Until now one has to `cd` to the bin/ folder to be able to execute migrate.sh, otherwise lib/ folder won't be found --- src/main/scripts/migrate.sh | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/main/scripts/migrate.sh b/src/main/scripts/migrate.sh index c2b941c..3d3f34c 100755 --- a/src/main/scripts/migrate.sh +++ b/src/main/scripts/migrate.sh @@ -1,4 +1,6 @@ #!/bin/sh +BIN_FOLDER=`dirname $PWD/$0` Does that work if $0 is an absolute path? Yes, it does. I have tested it! BIN_FOLDER looks a bit strange: ///some/absolute/path/bin but it works just fine on my Ubuntu. Does it work on Solaris ? :-) Maybe one could cd `dirname $0` Two issues with this: 1) the script usage is: ./bin/migrate.sh input.war output.war if we "cd" into bin/ then input.war is not there anymore. Its path should be fixed to ../input.war somehow 2) it would be good to leave the user back to the original directory after executing the script but pushd/popd are not available for 'sh'. We will need to use Bash or another Solaris check: apache% cat test.sh #!/bin/sh echo `dirname $PWD/$0` apache% /home/jung/test.sh /home/jung//home/jung apache% ./test.sh /home/jung/. So the full path case does not work there. Switching to /bin/bash or /bin/ksh does not help. I agree with Mark concerning the TC scripts. Concerning your 2) above: a "cd" in the script does not change the working diretory of the calling shell. After the end of the script, the user is still in the same directory where he was before starting it. 1) is a bit more tricky, because again one would have to handle the absolute and the relative case. What might help and should be compatible would be something like mydir="$PWD" cd `dirname "$0"` BIN_FOLDER="$PWD" cd "$mydir" I would avoid using "cd" in a script if at all possible. The migration tool should be able to be run from anywhere with command-line arguments to anything you need to call (e.g. java -cp). What risk do you see in the two "cd" uses? How is the ability to be called from anywhere reduced by teh above construct? It was actually introduced to myke it callable from anywhere. Best regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-jakartaee-migration] branch master updated: Make migrate.sh usable from any directory
Rainer,
On 12/11/20 14:19, Rainer Jung wrote:
Hi Chris,
Am 11.12.2020 um 19:53 schrieb Christopher Schultz:
Rainer,
On 12/11/20 06:19, Rainer Jung wrote:
Am 11.12.2020 um 09:49 schrieb Martin Grigorov:
On Fri, Dec 11, 2020 at 10:41 AM Martin Grigorov
wrote:
Hi Rainer,
On Fri, Dec 11, 2020 at 10:37 AM Rainer Jung
wrote:
Am 11.12.2020 um 08:25 schrieb mgrigo...@apache.org:
This is an automated email from the ASF dual-hosted git repository.
mgrigorov pushed a commit to branch master
in repository
https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git
The following commit(s) were added to refs/heads/master by this
push:
new 000c876 Make migrate.sh usable from any directory
000c876 is described below
commit 000c876ea3a1e700df2fffef70b29d9c3a9dfef2
Author: Martin Tzvetanov Grigorov
AuthorDate: Fri Dec 11 09:22:22 2020 +0200
Make migrate.sh usable from any directory
Until now one has to `cd` to the bin/ folder to be able to
execute
migrate.sh, otherwise lib/ folder won't be found
---
src/main/scripts/migrate.sh | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/main/scripts/migrate.sh
b/src/main/scripts/migrate.sh
index c2b941c..3d3f34c 100755
--- a/src/main/scripts/migrate.sh
+++ b/src/main/scripts/migrate.sh
@@ -1,4 +1,6 @@
#!/bin/sh
+BIN_FOLDER=`dirname $PWD/$0`
Does that work if $0 is an absolute path?
Yes, it does. I have tested it!
BIN_FOLDER looks a bit strange: ///some/absolute/path/bin but it works
just fine on my Ubuntu.
Does it work on Solaris ? :-)
Maybe one could
cd `dirname $0`
Two issues with this:
1) the script usage is: ./bin/migrate.sh input.war output.war
if we "cd" into bin/ then input.war is not there anymore. Its path
should
be fixed to ../input.war somehow
2) it would be good to leave the user back to the original directory
after
executing the script but pushd/popd are not available for 'sh'. We will
need to use Bash or another
Solaris check:
apache% cat test.sh
#!/bin/sh
echo `dirname $PWD/$0`
apache% /home/jung/test.sh
/home/jung//home/jung
apache% ./test.sh
/home/jung/.
So the full path case does not work there. Switching to /bin/bash or
/bin/ksh does not help.
I agree with Mark concerning the TC scripts.
Concerning your 2) above: a "cd" in the script does not change the
working diretory of the calling shell. After the end of the script,
the user is still in the same directory where he was before starting it.
1) is a bit more tricky, because again one would have to handle the
absolute and the relative case.
What might help and should be compatible would be something like
mydir="$PWD"
cd `dirname "$0"`
BIN_FOLDER="$PWD"
cd "$mydir"
I would avoid using "cd" in a script if at all possible. The migration
tool should be able to be run from anywhere with command-line
arguments to anything you need to call (e.g. java -cp).
What risk do you see in the two "cd" uses? How is the ability to be
called from anywhere reduced by teh above construct? It was actually
introduced to myke it callable from anywhere.
The whole script can be:
BIN_FOLDER=$( dirname ${0} )
java -cp "$BIN_FOLDER/../lib/*" org.apache.tomcat.jakartaee.MigrationCLI
"$@"
The "cd" is not necessary at all and IMO is just more complicated.
Note that the "-cp" won't work because the files must be separated by :
on *NIX. Unless I don't know how to build this in Maven (which is weird,
I have no mvnw command to run, so I did "mvn verify" which did build a
.jar file), there won't be any lib directory to include.
Don't we really just want:
BIN_FOLDER=$( dirname ${0} )
java -jar "$BIN_FOLDER/target/jakartaee-migration-0.1.0.jar" \
org.apache.tomcat.jakartaee.MigrationCLI "$@"
?
Maybe I just don't understand what this script is intended to
accomplish. A shortcut for "java -jar [migration-tool]" or something else?
Every Java-related shell script I ever write looks something like this:
#/bin/sh
BIN_DIR=$( dirname ${0} )
CLASSPATH=
for jar in $BIN_DIR/lib/*.jar ; do
CLASSPATH="${CLASSPATH}:${jar}"
fi
java -cp "$CLASSPATH" ${JAVA_OPTS} ${MAIN_CLASS} "$@"
It always works from anywhere, and anything "$@" expands to is always
relative to the user's current working directory, exactly like they expect.
If you need to know what BIN_DIR is inside the Java process, then:
java -cp "$CLASSPATH" -Dbase.dir="${BIN_DIR}" ${JAVA_OPTS} \
${MAIN_CLASS} "$@"
-chris
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-jakartaee-migration] branch master updated: Make migrate.sh usable from any directory
On Fri, Dec 11, 2020, 21:34 Christopher Schultz <
ch...@christopherschultz.net> wrote:
> Rainer,
>
> On 12/11/20 14:19, Rainer Jung wrote:
> > Hi Chris,
> >
> > Am 11.12.2020 um 19:53 schrieb Christopher Schultz:
> >> Rainer,
> >>
> >> On 12/11/20 06:19, Rainer Jung wrote:
> >>> Am 11.12.2020 um 09:49 schrieb Martin Grigorov:
> On Fri, Dec 11, 2020 at 10:41 AM Martin Grigorov <
> mgrigo...@apache.org>
> wrote:
>
> > Hi Rainer,
> >
> > On Fri, Dec 11, 2020 at 10:37 AM Rainer Jung <
> rainer.j...@kippdata.de>
> > wrote:
> >
> >> Am 11.12.2020 um 08:25 schrieb mgrigo...@apache.org:
> >>> This is an automated email from the ASF dual-hosted git repository.
> >>>
> >>> mgrigorov pushed a commit to branch master
> >>> in repository
> >> https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git
> >>>
> >>>
> >>> The following commit(s) were added to refs/heads/master by this
> >>> push:
> >>>new 000c876 Make migrate.sh usable from any directory
> >>> 000c876 is described below
> >>>
> >>> commit 000c876ea3a1e700df2fffef70b29d9c3a9dfef2
> >>> Author: Martin Tzvetanov Grigorov
> >>> AuthorDate: Fri Dec 11 09:22:22 2020 +0200
> >>>
> >>> Make migrate.sh usable from any directory
> >>>
> >>> Until now one has to `cd` to the bin/ folder to be able to
> >>> execute
> >> migrate.sh, otherwise lib/ folder won't be found
> >>> ---
> >>>src/main/scripts/migrate.sh | 4 +++-
> >>>1 file changed, 3 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/src/main/scripts/migrate.sh
> >>> b/src/main/scripts/migrate.sh
> >>> index c2b941c..3d3f34c 100755
> >>> --- a/src/main/scripts/migrate.sh
> >>> +++ b/src/main/scripts/migrate.sh
> >>> @@ -1,4 +1,6 @@
> >>>#!/bin/sh
> >>>
> >>> +BIN_FOLDER=`dirname $PWD/$0`
> >>
> >> Does that work if $0 is an absolute path?
> >>
> >
> > Yes, it does. I have tested it!
> > BIN_FOLDER looks a bit strange: ///some/absolute/path/bin but it
> works
> > just fine on my Ubuntu.
> > Does it work on Solaris ? :-)
> >
> >
> >>
> >> Maybe one could
> >>
> >> cd `dirname $0`
> >>
> >
> Two issues with this:
>
> 1) the script usage is: ./bin/migrate.sh input.war output.war
> if we "cd" into bin/ then input.war is not there anymore. Its path
> should
> be fixed to ../input.war somehow
>
> 2) it would be good to leave the user back to the original directory
> after
> executing the script but pushd/popd are not available for 'sh'. We
> will
> need to use Bash or another
> >>>
> >>> Solaris check:
> >>>
> >>> apache% cat test.sh
> >>> #!/bin/sh
> >>>
> >>> echo `dirname $PWD/$0`
> >>>
> >>> apache% /home/jung/test.sh
> >>> /home/jung//home/jung
> >>>
> >>> apache% ./test.sh
> >>> /home/jung/.
> >>>
> >>> So the full path case does not work there. Switching to /bin/bash or
> >>> /bin/ksh does not help.
> >>>
> >>> I agree with Mark concerning the TC scripts.
> >>>
> >>> Concerning your 2) above: a "cd" in the script does not change the
> >>> working diretory of the calling shell. After the end of the script,
> >>> the user is still in the same directory where he was before starting
> it.
> >>>
> >>> 1) is a bit more tricky, because again one would have to handle the
> >>> absolute and the relative case.
> >>>
> >>> What might help and should be compatible would be something like
> >>>
> >>> mydir="$PWD"
> >>> cd `dirname "$0"`
> >>> BIN_FOLDER="$PWD"
> >>> cd "$mydir"
> >>
> >> I would avoid using "cd" in a script if at all possible. The migration
> >> tool should be able to be run from anywhere with command-line
> >> arguments to anything you need to call (e.g. java -cp).
> >
> > What risk do you see in the two "cd" uses? How is the ability to be
> > called from anywhere reduced by teh above construct? It was actually
> > introduced to myke it callable from anywhere.
>
> The whole script can be:
>
> BIN_FOLDER=$( dirname ${0} )
> java -cp "$BIN_FOLDER/../lib/*" org.apache.tomcat.jakartaee.MigrationCLI
> "$@"
>
> The "cd" is not necessary at all and IMO is just more complicated.
>
> Note that the "-cp" won't work because the files must be separated by :
> on *NIX. Unless I don't know how to build this in Maven (which is weird,
> I have no mvnw command to run, so I did "mvn verify" which did build a
> .jar file), there won't be any lib directory to include.
>
> Don't we really just want:
>
> BIN_FOLDER=$( dirname ${0} )
> java -jar "$BIN_FOLDER/target/jakartaee-migration-0.1.0.jar" \
>org.apache.tomcat.jakartaee.MigrationCLI "$@"
>
> ?
>
> Maybe I just don't understand what this script is intended to
> accomplish. A shortcut for "java -jar [migration-tool]" or something else?
>
> Every Java-related shell script I ever write looks something like this:
>
> #/bin/sh
> BIN_DIR=
Re: [tomcat-native] branch master updated: Update java code to align with 10.0.x
On Fri, Dec 11, 2020 at 5:50 PM Mark Thomas wrote: > On 11/12/2020 16:41, Rémy Maucherat wrote: > > On Fri, Dec 11, 2020 at 5:36 PM Mark Thomas wrote: > > > >> On 11/12/2020 16:24, Michael Osipov wrote: > >>> Am 2020-12-10 um 15:07 schrieb ma...@apache.org: > + * @deprecated The scope of the APR/Native Library will be reduced > in Tomcat > + * 10.1.x / Tomcat Native 2.x onwards to only include > >> those > + * components required to provide OpenSSL integration > with the NIO > + * and NIO2 connectors. > >>> > >>> I think there should *not* be a Tomcat Native 2.x for the following > >>> reasons: > >>> > >>> * It has been mentioned numerous times that Tomcat Native is a bad name > >>> without a good meaning > >>> * > 50 % of the essential parts of Tomcat Native will be gone. It won't > >>> be Tomcat Native anymore as previously. > >>> * Since the APR connector is deprecated, de facto, it does not > logically > >>> make sense to evolve Tomcat Native to a new major version. Just > >>> counter-intuitive. > >>> > >>> My counter proposal is to split Tomcat Native, phase it out and > >>> introduce Tomcat OpenSSL (Bridge) (libtcopenssl.so) or similar. The > name > >>> should clearly say what it does. > >> > >> Using a new name is already one of the options. That possibility was > >> mentioned in one of these threads about a week ago. > >> > >>> You won't going to continue the APRLifecycleListener, will you? > >> > >> There will almost certainly need to be something like it. I had imagined > >> it would get a new name but hadn't given much though to what that name > >> should be. > >> > >>> WDYT? > >> > >> We need to be careful when we use other organisation's trademarks in our > >> product names. Some like: > >> > >> Apache Tomcat Bridge to OpenSSL > >> > >> would be fine. The other option is to give it an entirely new name. > >> > >> Apache Tomcat Phoenix > >> > >> for example. (I haven't done any checks on that name. It may be > >> completely unsuitable - it is just an example). > >> > > > > I'm not sure this native code will stay for that long (replaced with > > integrated Java code possibly), so I'm not convinced a name is needed. -> > > modules/openssl ? > > I think the lifetime of the code is likely to be driven by the minimum > Java version required by Jakarta EE and the typical lifecycle of Tomcat > major versions. > > Assuming Tomcat 10.1.x has a minimum Java version that doesn't provide > integration with native libraries OOTB then any library we provide to > link Tomcat and OpenSSL is likely to have a lifespan of at least 10 years. > Hmmm, ok, I see no better plan. Rémy > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [tomcat-jakartaee-migration] branch master updated: Make migrate.sh usable from any directory
Martin,
On 12/11/20 15:52, Martin Grigorov wrote:
On Fri, Dec 11, 2020, 21:34 Christopher Schultz <
ch...@christopherschultz.net> wrote:
Rainer,
On 12/11/20 14:19, Rainer Jung wrote:
Hi Chris,
Am 11.12.2020 um 19:53 schrieb Christopher Schultz:
Rainer,
On 12/11/20 06:19, Rainer Jung wrote:
Am 11.12.2020 um 09:49 schrieb Martin Grigorov:
On Fri, Dec 11, 2020 at 10:41 AM Martin Grigorov <
mgrigo...@apache.org>
wrote:
Hi Rainer,
On Fri, Dec 11, 2020 at 10:37 AM Rainer Jung <
rainer.j...@kippdata.de>
wrote:
Am 11.12.2020 um 08:25 schrieb mgrigo...@apache.org:
This is an automated email from the ASF dual-hosted git repository.
mgrigorov pushed a commit to branch master
in repository
https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git
The following commit(s) were added to refs/heads/master by this
push:
new 000c876 Make migrate.sh usable from any directory
000c876 is described below
commit 000c876ea3a1e700df2fffef70b29d9c3a9dfef2
Author: Martin Tzvetanov Grigorov
AuthorDate: Fri Dec 11 09:22:22 2020 +0200
Make migrate.sh usable from any directory
Until now one has to `cd` to the bin/ folder to be able to
execute
migrate.sh, otherwise lib/ folder won't be found
---
src/main/scripts/migrate.sh | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/main/scripts/migrate.sh
b/src/main/scripts/migrate.sh
index c2b941c..3d3f34c 100755
--- a/src/main/scripts/migrate.sh
+++ b/src/main/scripts/migrate.sh
@@ -1,4 +1,6 @@
#!/bin/sh
+BIN_FOLDER=`dirname $PWD/$0`
Does that work if $0 is an absolute path?
Yes, it does. I have tested it!
BIN_FOLDER looks a bit strange: ///some/absolute/path/bin but it
works
just fine on my Ubuntu.
Does it work on Solaris ? :-)
Maybe one could
cd `dirname $0`
Two issues with this:
1) the script usage is: ./bin/migrate.sh input.war output.war
if we "cd" into bin/ then input.war is not there anymore. Its path
should
be fixed to ../input.war somehow
2) it would be good to leave the user back to the original directory
after
executing the script but pushd/popd are not available for 'sh'. We
will
need to use Bash or another
Solaris check:
apache% cat test.sh
#!/bin/sh
echo `dirname $PWD/$0`
apache% /home/jung/test.sh
/home/jung//home/jung
apache% ./test.sh
/home/jung/.
So the full path case does not work there. Switching to /bin/bash or
/bin/ksh does not help.
I agree with Mark concerning the TC scripts.
Concerning your 2) above: a "cd" in the script does not change the
working diretory of the calling shell. After the end of the script,
the user is still in the same directory where he was before starting
it.
1) is a bit more tricky, because again one would have to handle the
absolute and the relative case.
What might help and should be compatible would be something like
mydir="$PWD"
cd `dirname "$0"`
BIN_FOLDER="$PWD"
cd "$mydir"
I would avoid using "cd" in a script if at all possible. The migration
tool should be able to be run from anywhere with command-line
arguments to anything you need to call (e.g. java -cp).
What risk do you see in the two "cd" uses? How is the ability to be
called from anywhere reduced by teh above construct? It was actually
introduced to myke it callable from anywhere.
The whole script can be:
BIN_FOLDER=$( dirname ${0} )
java -cp "$BIN_FOLDER/../lib/*" org.apache.tomcat.jakartaee.MigrationCLI
"$@"
The "cd" is not necessary at all and IMO is just more complicated.
Note that the "-cp" won't work because the files must be separated by :
on *NIX. Unless I don't know how to build this in Maven (which is weird,
I have no mvnw command to run, so I did "mvn verify" which did build a
.jar file), there won't be any lib directory to include.
Don't we really just want:
BIN_FOLDER=$( dirname ${0} )
java -jar "$BIN_FOLDER/target/jakartaee-migration-0.1.0.jar" \
org.apache.tomcat.jakartaee.MigrationCLI "$@"
?
Maybe I just don't understand what this script is intended to
accomplish. A shortcut for "java -jar [migration-tool]" or something else?
Every Java-related shell script I ever write looks something like this:
#/bin/sh
BIN_DIR=$( dirname ${0} )
dirname just cuts the parent path segment.
If there is no such then it returns '.'
Play with it and see.
Yes, then you get BIN_DIR=. and:
java -cp ./lib/* [...]
Which is exactly what you want. It works with migrate.sh (no prefix,
BIN_DIR=.), ./migrate.sh (BIN_DIR=.), /usr/local/foo/migrate.sh
(BIN_DIR=/usr/local/foo), etc.
No 'cd' required at all. 50% reduction in lines of code.
-chris
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
