Re: [VOTE] Apache Tomcat migration tool for Jakarta EE
On Thu, Dec 10, 2020 at 11:45 PM Mark Thomas wrote: > On 11/12/2020 06:58, Martin Grigorov wrote: > > On Thu, Dec 10, 2020 at 11:50 PM Igal Sapir wrote: > > > >> On Thu, Dec 10, 2020 at 5:58 AM Christopher Schultz < > >> ch...@christopherschultz.net> 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? > >>> > >>> I once heard Ross say that there was an ASP project (Subversion?) that > >>> never had votes; they only had releases. That seemed to cut-down on the > >>> red-tape required to get things out into the world. I can't find a > >>> reference for that, now. > >>> > >>> 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"? > >>> > >>> That said, I have no objections whatsoever with holding a vote. I am an > >>> unsigned "0" on the vote itself; I have not even downloaded the source > >>> let alone attempted to migrate a project using it. > >>> > >> > >> I'm a +0 on this one. Like Chris, I also did not even download nor > tested > >> that tool. > >> > >> Did we use that tool to migrate the Tomcat examples? Were they all > >> migrated successfully? > >> > > > > No. The examples were migrated manually, i.e. their source code was > > migrated. > > The tool migrates binary files (.war,.jar, .class). It is useful when > your > > application depends on third party libraries which still use javax.** > > Martin is correct, the examples were migrated using a package rename in > the IDE. > > The JSTL JARs (used by the examples webapp) were migrated with this tool. > Thank you both for clarifying. My question just shows why at this point I should remain a +0 on this one. Igal > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [VOTE] Release Apache Tomcat Native 1.2.26
On Thu, Dec 10, 2020 at 1: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 > Tested with Tomcat 9.0.41 and Java 13.0.4 on Ubuntu 20.04 Best, Igal > [ ] 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 > > - > 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:58 AM Christopher Schultz < ch...@christopherschultz.net> 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? > > I once heard Ross say that there was an ASP project (Subversion?) that > never had votes; they only had releases. That seemed to cut-down on the > red-tape required to get things out into the world. I can't find a > reference for that, now. > > 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"? > > That said, I have no objections whatsoever with holding a vote. I am an > unsigned "0" on the vote itself; I have not even downloaded the source > let alone attempted to migrate a project using it. > I'm a +0 on this one. Like Chris, I also did not even download nor tested that tool. Did we use that tool to migrate the Tomcat examples? Were they all migrated successfully? Igal > > -chris > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [tomcat] 01/02: Replace Collections.sort() with List.sort()
On Thu, Dec 3, 2020 at 2:48 PM Martin Grigorov wrote: > Hi, > > Shall we backport these commits to 9.x and 8.5? > It will make it easier to backport future changes in these classes. > +1 No need to diverge the branches unnecessarily. Igal > > Martin > > On Fri, Dec 4, 2020, 00:06 Emmanuel Bourg wrote: > > > Hi Christopher, > > > > Le 03/12/2020 à 21:49, Christopher Schultz a écrit : > > > > > I'm curious as to why this change is warranted. I'm not suggesting it's > > > not... just wondering what the benefit is? Avoiding a pass-through > > > method call? > > > > It's the shorter idiom to sort lists with Java 8+, it just improves the > > readability. I don't think the method call avoided has any impact, the > > actual sorting dominates the time spent anyway. > > > > Emmanuel Bourg > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > >
Re: [VOTE] Release Apache Tomcat 8.5.61
On Thu, Dec 3, 2020 at 6:49 AM Mark Thomas wrote: > The proposed Apache Tomcat 8.5.61 release is now available for voting. > > The notable changes compared to the 8.5.60 release are: > > - 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. > > - Fix a potential file descriptor leak when WebSocket connections are > attempted and fail. Patch provided by Maurizio Adami. > > - Ensure that the LoadBalancerDrainingValve uses the correct setting > for the secure attribute for any session cookies it creates. Based on > a pull request by Andreas Kurth. > > Along with lots of other bug fixes and improvements. > > For full details, see the changelog: > https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.61/ > > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1290/ > > The tag is: > https://github.com/apache/tomcat/tree/8.5.61 > 77d330abea52e4aeb039ca7eb8a766e0e1c56a71 > > The proposed 8.5.61 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 8.5.61 > Tested on Ubuntu 20.04 with Java 13.0.4 and TC-Native 1.2.25 Best, Igal > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [VOTE] Release Apache Tomcat 9.0.41
On Thu, Dec 3, 2020 at 5:12 AM Mark Thomas wrote: > The proposed Apache Tomcat 9.0.41 release is now available for voting. > > The notable changes compared to the 9.0.40 release are: > > - 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. > > - Fix a potential file descriptor leak when WebSocket connections are > attempted and fail. Patch provided by Maurizio Adami. > > - Ensure that the LoadBalancerDrainingValve uses the correct setting >for the secure attribute for any session cookies it creates. Based on >a pull request by Andreas Kurth. > > Along with lots of other bug fixes and improvements. > > For full details, see the changelog: > https://ci.apache.org/projects/tomcat/tomcat9/docs/changelog.html > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.41/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1289/ > The tag is: > https://github.com/apache/tomcat/tree/9.0.41 > 75d7a2069bf4360bcd8b885c6b7387d70c9cb052 > > The proposed 9.0.41 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 9.0.41 > Tested with Ubuntu 20.04, Java 13.0.4, and TC-Native 1.2.25 Best, Igal > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [VOTE] Release Apache Tomcat 10.0.0
On Thu, Dec 3, 2020 at 2:50 AM Mark Thomas wrote: > 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 > [X] Beta - go ahead and release as 10.0.0 (beta) > [ ] Stable - go ahead and release as 10.0.0 (stable) > Tested on Ubuntu 20.04 with Java 13.0.4 and TC-Native 1.2.25 Best, Igal > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Tomcat Native Build Instructions
On Thu, Dec 3, 2020 at 2:31 PM Emmanuel Bourg wrote: > Le 03/12/2020 à 23:00, Igal Sapir a écrit : > > > It seems that the package is named "libapr1-dev" and I'm not sure if that > > was a recent change or not. > > > > I want to update the docs but not sure if that would break non-Ubuntu > > Debian-based builds. > > > > Any thoughts? > > libapr1.0-dev was in Debian Sid between 2004 and 2006, it has only been > part of Debian 3.1 Sarge until its EOL in 2008. (the Ubuntu release at > this time was 6.06 Dapper Drake, EOL in 2011) > > libapr1-dev has been used to build tomcat-native in Debian (and Ubuntu) > since its first upload in 2008 [1]. > Thanks Emmanuel! I'm surprised that no one has complained about the docs being misaligned so far. Best, Igal > > Emmanuel Bourg > > [1] https://salsa.debian.org/java-team/tomcat-native/-/commit/201da1d9 > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Tomcat Native Build Instructions
The docs for building Tomcat Native [1] states "libapr1.0-dev" as a prerequisite for Debian based systems, but on Ubuntu 20.04 that throws an error: > Package libapr1.0-dev is not available, but is referred to by another package. > This may mean that the package is missing, has been obsoleted, or > is only available from another source It seems that the package is named "libapr1-dev" and I'm not sure if that was a recent change or not. I want to update the docs but not sure if that would break non-Ubuntu Debian-based builds. Any thoughts? Thank you, Igal [1] http://tomcat.apache.org/native-doc/#Requirements
Re: [VOTE] Release Apache Tomcat 8.5.60
On Thu, Nov 12, 2020 at 9:54 AM Mark Thomas wrote: > The proposed Apache Tomcat 8.5.60 release is now available for voting. > > > The proposed 8.5.60 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 8.5.60 > +1 Unit tests passed on Ubuntu with Java 11 and Tomcat Native 1.2.23 Igal > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [VOTE] Release Apache Tomcat 9.0.40
On Thu, Nov 12, 2020 at 7:58 AM Mark Thomas wrote: > The proposed Apache Tomcat 9.0.40 release is now available for voting. > > > The proposed 9.0.40 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 9.0.40 > +1 Unit tests passed on Ubuntu with Java 11 and Tomcat Native 1.2.23 Igal > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [VOTE] Release Apache Tomcat 10.0.0-M10
On Thu, Nov 12, 2020 at 4:32 AM Mark Thomas wrote: > The proposed Apache Tomcat 10.0.0-M10 release is now available for > voting. > > > The proposed 10.0.0-M10 release is: > [ ] Broken - do not release > [X] Alpha - go ahead and release as 10.0.0-M10 > +1 Tested on Ubuntu with Java 11 and Tomcat Native 1.2.23 Best, Igal > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: JPMS module names
Mark, On Thu, Oct 29, 2020 at 12:43 PM Mark Thomas wrote: > Hi all, > > Just a reminder that this is on the radar. I'll likely be looking to > make these changes early next week as part of the prep for the next > release round (I need to sort this to be able to fix BZ 64849 sensibly). > > Mark > > > On 27/10/2020 20:04, Mark Thomas wrote: > > Hi all, > > > > We are starting to get JPMS related bug reports. Resolving the issues is > > technically simple but depends on us deciding on the names to use for > > the various modules. > > > > The names we choose for our own modules are easy. Generally we are using > > the same or derivation from the OSGi module name. > > > > The names we use for the spec API modules are a little more tricky. We > > need to (try and) remain aligned with the RI spec JARs. > > > > It looks like Jakarta EE 9 onwards is going to have consistent naming > > (at least it does for the modules we use). Java EE 8 / Jakarta EE 8 is a > > bit more inconsistent. > > > > I have put together a wiki page that documents the current position and > > the naming I propose we use in Tomcat. > > > > https://cwiki.apache.org/confluence/display/TOMCAT/JPMS+names > > > > Comments (in this thread ideally) welcome. > +1. Your proposal looks good. Best, Igal > > > > Once we (appear to) have consensus I'll update the builds to use the new > > names and start fixing the associated bugs. > > > > Mark > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: svn/git for website
Dave, On Wed, Oct 28, 2020 at 9:36 PM Dave Fisher wrote: > Hi - > > I may have helpful ideas. Tell me where the Tomcst site repository and > build are located. > The SVN repo for the Tomcat site is at http://svn.apache.org/repos/asf/tomcat/site/ I'm not sure where the build scripts are stored or executed from. Thanks, Igal > > Regards, > Dave > > Sent from my iPhone > > > On Oct 27, 2020, at 12:18 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > > > > Konstantin, > > > >> On 10/26/20 20:47, Konstantin Kolinko wrote: > >> пт, 2 окт. 2020 г. в 00:09, Mark Thomas : > >>> > >>> Hi all, > >>> > >>> The topic came up at the BoF session at the end of the Tomcat track of > >>> migrating the website from svn to git. There were strong opinions both > >>> for migrating and for sticking with svn. > >>> > >>> As a middle ground I'd like to propose we ask Infra to create a git > >>> mirror of the svn repo. > >>> > >>> For those who favour git: > >>> The git mirror would be read-only but it would be possible to: > >>> - clone the git mirror > >>> - make changes in git > >>> - use git-svn to commit those changes back to svn > >>> - then the mirror automatically replicates them back to git > >>> > >>> For those who favour svn there would be no change. > >>> > >>> If there is agreement on this approach, I volunteer to contact infra to > >>> get it set up. > >> My proposal at BoF was for a partial mirror. > >> The issue is that > >> 1. I think that this mirror is intended as a tool to collect feedback > >> / patches from random people, and to lower barriers for contribution. > >> 2. The full Tomcat site is large. It includes documentation for all > >> versions of Tomcat, including javadocs. Those pages are changed rarely > >> and are not needed for people who contribute small changes for the > >> site. The source code for those pages is elsewhere. > > > > The question I have to ask, here is: why do we bother putting all those > files in revision-control? The users guide for 4 different versions of > Tomcat is not a problem, but the javadocs are just stupid to store. > > > > Is there some policy we are following by having all those files in > there? Or is it just to make sure that website "publication" is as simple > as "svn checkout"? > > > >> 3. Subversion has easy commands to cope with such large source trees. > >> This feature is called "sparse checkouts". > >> For our site the necessary commands are documented in README.txt. > >> Essentially, it is done with --depth and --set-depth arguments to "svn > >> checkout" and "svn update" commands > >> Speaking about Git, there are huge repositories [1] out there, but I > >> think that the majority of people are not accustomed to them. > >> [1] https://en.wikipedia.org/wiki/Monorepo > >> I see that Git developers recently did some work to make dealing with > >> such repositories simpler, with addition of "git sparse-checkout" > >> command in Git 2.25.0 [2], released in January 2020. > >> [2] > https://github.com/git/git/blob/v2.25.0/Documentation/RelNotes/2.25.0.txt > >> Though I think that support in tools is still lacking. E.g. missing in > >> TortoiseGit. [3] > >> [3] https://gitlab.com/tortoisegit/tortoisegit/issues/1599 > >> If we go with a full Git mirror or with migration to Git, then I think > >> that somebody has to prepare an update to README.txt. > >> If we go with a partial Git mirror, I think it could be named > >> "tomcat-site-dev", reserving the name "tomcat-site" for a full mirror > >> if we ever make one. > >> Ignored paths for git-svn are configured with "--ignore-paths" > >> argument or with "svn-remote..ignore-paths" configuration > >> option. [4] > >> [4] https://git-scm.com/docs/git-svn > >> Other notes: > >> 4. Release managers use Subversion to publish the binaries. > >> Thus I expect that they are able to update the published documentation > >> with Subversion as well. > >> 5. Publishing the javadocs generates small changes over a large number > >> of files. The script that generates the commit email notes that the > >> diff is huge and trims it all to a small summary. > >> If we ever migrate to Git, I wonder whether a similar script in Git is > >> able to cope with it. > > > > We might also want to consider complicating the website-building process > in order to simplify the repository. Yes, "disk space is cheap" but it's > kind of ridiculous that we have all that derivative content in RCS, > separate from its canonical source. > > > > -chris > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: svn/git for website
On Tue, Oct 27, 2020 at 12:17 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > Konstantin, > > On 10/26/20 20:47, Konstantin Kolinko wrote: > > пт, 2 окт. 2020 г. в 00:09, Mark Thomas : > >> > >> Hi all, > >> > >> The topic came up at the BoF session at the end of the Tomcat track of > >> migrating the website from svn to git. There were strong opinions both > >> for migrating and for sticking with svn. > >> > >> As a middle ground I'd like to propose we ask Infra to create a git > >> mirror of the svn repo. > >> > >> For those who favour git: > >> The git mirror would be read-only but it would be possible to: > >> - clone the git mirror > >> - make changes in git > >> - use git-svn to commit those changes back to svn > >> - then the mirror automatically replicates them back to git > >> > >> For those who favour svn there would be no change. > >> > >> If there is agreement on this approach, I volunteer to contact infra to > >> get it set up. > > > > My proposal at BoF was for a partial mirror. > > > > The issue is that > > > > 1. I think that this mirror is intended as a tool to collect feedback > > / patches from random people, and to lower barriers for contribution. > > > > 2. The full Tomcat site is large. It includes documentation for all > > versions of Tomcat, including javadocs. Those pages are changed rarely > > and are not needed for people who contribute small changes for the > > site. The source code for those pages is elsewhere. > > The question I have to ask, here is: why do we bother putting all those > files in revision-control? The users guide for 4 different versions of > Tomcat is not a problem, but the javadocs are just stupid to store. > > Is there some policy we are following by having all those files in > there? Or is it just to make sure that website "publication" is as > simple as "svn checkout"? > > > 3. Subversion has easy commands to cope with such large source trees. > > This feature is called "sparse checkouts". > > > > For our site the necessary commands are documented in README.txt. > > Essentially, it is done with --depth and --set-depth arguments to "svn > > checkout" and "svn update" commands > > > > Speaking about Git, there are huge repositories [1] out there, but I > > think that the majority of people are not accustomed to them. > > > > [1] https://en.wikipedia.org/wiki/Monorepo > > > > I see that Git developers recently did some work to make dealing with > > such repositories simpler, with addition of "git sparse-checkout" > > command in Git 2.25.0 [2], released in January 2020. > > > > [2] > https://github.com/git/git/blob/v2.25.0/Documentation/RelNotes/2.25.0.txt > > > > Though I think that support in tools is still lacking. E.g. missing in > > TortoiseGit. [3] > > > > [3] https://gitlab.com/tortoisegit/tortoisegit/issues/1599 > > > > > > If we go with a full Git mirror or with migration to Git, then I think > > that somebody has to prepare an update to README.txt. > > > > If we go with a partial Git mirror, I think it could be named > > "tomcat-site-dev", reserving the name "tomcat-site" for a full mirror > > if we ever make one. > > > > > > Ignored paths for git-svn are configured with "--ignore-paths" > > argument or with "svn-remote..ignore-paths" configuration > > option. [4] > > > > [4] https://git-scm.com/docs/git-svn > > > > > > Other notes: > > > > 4. Release managers use Subversion to publish the binaries. > > > > Thus I expect that they are able to update the published documentation > > with Subversion as well. > > > > 5. Publishing the javadocs generates small changes over a large number > > of files. The script that generates the commit email notes that the > > diff is huge and trims it all to a small summary. > > > > If we ever migrate to Git, I wonder whether a similar script in Git is > > able to cope with it. > > We might also want to consider complicating the website-building process > in order to simplify the repository. Yes, "disk space is cheap" but it's > kind of ridiculous that we have all that derivative content in RCS, > separate from its canonical source. > That makes a lot of sense to me. I'm sure that the whole process can be scripted, including the script that Konstantin mentioned in his item [5]. I also wonder if Git LFS (Large File Storage) [1][2] would solve the issue of repo size here. >From [1]: "Git Large File Storage (LFS) replaces large files such as audio samples, videos, datasets, and graphics with text pointers inside Git, while storing the file contents on a remote server". It allows to set file patterns, e.g. "*.jpg", or "/javadoc/*" for files that should not be tracked by Git and do not need to be downloaded from the server unless requested. Igal [1] https://git-lfs.github.com/ [2] https://www.atlassian.com/git/tutorials/git-lfs > > -chris > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands,
Re: [VOTE] Release Apache Tomcat 8.5.59
On Tue, Oct 6, 2020 at 10:34 AM Mark Thomas wrote: > The proposed Apache Tomcat 8.5.59 release is now available for voting. > > > > The proposed 8.5.59 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 8.5.59 > Unit tests passed on Ubuntu 20.04 with Java 11 and TCNative 1.2.23 Igal
Re: [VOTE] Release Apache Tomcat 9.0.39
On Tue, Oct 6, 2020 at 7:49 AM Mark Thomas wrote: > The proposed Apache Tomcat 9.0.39 release is now available for voting. > > > > The proposed 9.0.39 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 9.0.39 > Unit tests passed on Ubuntu 20.04 with Java 11 and TCNative 1.2.23 Igal
Re: [VOTE] Release Apache Tomcat 9.0.39
I got an error [1] running unit tests. Will run it again in case it's just a fluke or a fragile test case. Igal [1] Testcase: testExceedMaxActiveStreams02[0] took 0.282 sec Caused an ERROR End of input stream java.io.IOException: End of input stream at org.apache.coyote.http2.Http2TestBase$TestInput.fill(Http2TestBase.java:979) at org.apache.coyote.http2.Http2Parser$Input.fill(Http2Parser.java:707) at org.apache.coyote.http2.Http2Parser.readFrame(Http2Parser.java:78) at org.apache.coyote.http2.Http2Parser.readFrame(Http2Parser.java:71) at org.apache.coyote.http2.TestHttp2Section_5_1.testExceedMaxActiveStreams02(TestHttp2Section_5_1.java:303) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 07-Oct-2020 14:19:13.286 FINE [http-nio-127.0.0.1-auto-6-exec-4] org.apache.coyote.http2.Http2UpgradeHandler.upgradeDispatch Connection error org.apache.coyote.http2.ConnectionException: There was an error during the HPACK decoding of HTTP headers at org.apache.coyote.http2.Http2Parser.readHeaderPayload(Http2Parser.java:488) at org.apache.coyote.http2.Http2Parser.readHeadersFrame(Http2Parser.java:269) at org.apache.coyote.http2.Http2AsyncParser$FrameCompletionHandler.completed(Http2AsyncParser.java:249) at org.apache.coyote.http2.Http2AsyncParser$FrameCompletionHandler.completed(Http2AsyncParser.java:164) at org.apache.tomcat.util.net.SocketWrapperBase$VectoredIOCompletionHandler.completed(SocketWrapperBase.java:1087) at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper$NioOperationState.run(NioEndpoint.java:1511) at org.apache.tomcat.util.net.SocketWrapperBase$OperationState.start(SocketWrapperBase.java:1039) at org.apache.tomcat.util.net.SocketWrapperBase.vectoredOperation(SocketWrapperBase.java:1450) at org.apache.tomcat.util.net.SocketWrapperBase.read(SocketWrapperBase.java:1293) at org.apache.tomcat.util.net.SocketWrapperBase.read(SocketWrapperBase.java:1265) at org.apache.coyote.http2.Http2AsyncParser.readFrame(Http2AsyncParser.java:138) at org.apache.coyote.http2.Http2Parser.readFrame(Http2Parser.java:71) at org.apache.coyote.http2.Http2UpgradeHandler.upgradeDispatch(Http2UpgradeHandler.java:339) at org.apache.coyote.http2.Http2AsyncUpgradeHandler.upgradeDispatch(Http2AsyncUpgradeHandler.java:40) at org.apache.coyote.http11.upgrade.UpgradeProcessorInternal.dispatch(UpgradeProcessorInternal.java:54) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:59) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1590) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.base/java.lang.Thread.run(Thread.java:834) Caused by: org.apache.coyote.http2.HpackException: Connection [5], Stream [5], received multiple [:method] headers at org.apache.coyote.http2.Stream.emitHeader(Stream.java:329) at org.apache.coyote.http2.HpackDecoder.emitHeader(HpackDecoder.java:431) at org.apache.coyote.http2.HpackDecoder.addStaticTableEntry(HpackDecoder.java:300) at org.apache.coyote.http2.HpackDecoder.handleIndex(HpackDecoder.java:267) at org.apache.coyote.http2.HpackDecoder.decode(HpackDecoder.java:111) at org.apache.coyote.http2.Http2Parser.readHeaderPayload(Http2Parser.java:485) ... 22 more On Wed, Oct 7, 2020 at 2:15 PM Raymond Auge wrote: > On Tue, Oct 6, 2020 at 10:49 AM Mark Thomas wrote: > > > The proposed Apache Tomcat 9.0.39 release is now available for voting. > > > > The notable changes compared to the 9.0.38 release are: > > > > - Refactor the handling of closed HTTP/2 streams to reduce the heap > > usage associated with used streams and to retain information for more > > streams in the priority tree. > > > > - Allow using the utility executor for annotation scanning. Patch > > provided by Jatin Kamnani. > > > > - Add a bloom filter to speed up archive lookup and
Re: [VOTE] Release Apache Tomcat 10.0.0-M9
On Tue, Oct 6, 2020 at 6:38 AM Mark Thomas wrote: > The proposed Apache Tomcat 10.0.0-M9 release is now available for > voting. > > > > The proposed 10.0.0-M9 release is: > [ ] Broken - do not release > [X] Alpha - go ahead and release as 10.0.0-M9 > Unit tests passed on Ubuntu 20.04 with Java 8 and TCNative 1.2.23 Igal > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Use of "constants" in Manager to generate HTML/CSS content
Konstantin, On Sun, Aug 16, 2020 at 1:00 PM Konstantin Kolinko wrote: > вс, 16 авг. 2020 г. в 21:32, Igal Sapir : > > > > I don't see any scripts either. Why not add a CSP and set script to > 'none'? I can add that if no one objects. > > > > sessionsList.jsp has onclick attributes. Maybe it can be modified to > work without them, I do not know. > Definitely something to consider. I naively searched for "script" and missed that. Thank you, Igal > > K.Kolinko > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [tomcat] branch master updated: Extracted CSS styles to external file for better code mainenance
Michael, On Sun, Aug 16, 2020 at 11:37 AM Michael Osipov wrote: > Am 2020-08-16 um 20:05 schrieb isa...@apache.org: > > This is an automated email from the ASF dual-hosted git repository. > > > > isapir 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 9c5d2e3 Extracted CSS styles to external file for better code > mainenance > > 9c5d2e3 is described below > > > > commit 9c5d2e3b633fdb651bc9f11db4aac97ad3ad4df2 > > Author: Igal Sapir > > AuthorDate: Sun Aug 16 11:05:05 2020 -0700 > > > > Extracted CSS styles to external file for better code mainenance > > > > Also replaced gif logo with svg > > --- > > java/org/apache/catalina/manager/Constants.java| 79 +- > > There is a slight problem to that: TOMCAT_CSS is shared throughout the > codebase. Do you want to break that up in CSS modules or duplicate code? > The new file "manager.css" includes the code from TOMCAT_CSS, which is really just a few lines of CSS [1]. We can certainly add another file with just that but IMO it would be an overkill and would result in an additional unnecessary http request. Igal [1] https://github.com/apache/tomcat/blob/69602cb1ef0dc3aa2188a1b3be9fa3a1440cd1b1/java/org/apache/catalina/util/TomcatCSS.java#L25 > > M > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Use of "constants" in Manager to generate HTML/CSS content
On Wed, Aug 12, 2020 at 8:47 AM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Konstantin, > > On 8/12/20 10:02, Konstantin Kolinko wrote: > > вт, 28 июл. 2020 г. в 16:55, Christopher Schultz > > : > >> > >> All, > >> > >> I was looking at this PR[1] and wondering why we have huge swaths > >> of CSS and HTML in a Java source file, instead of using e.g. JSP > >> or some other content-generation framework. > > > > I remember that I once read some praise for being able to use the > > Manager web application when there is no Jasper and no JSP > > compiler available. It was more than 5 years ago and I do not > > remember the details - maybe it was some small system with limited > > hardware. > > Agreed. > > > The Manager app does use JSPs nowadays, not for some unimportant > > pages: listing of sessions and listing attributes of a session. > > Okay. Are you suggesting then that JSP can/should be required for > Manager usage? Or maybe just for certain functions? > > >> I know, I hate JSP, too, but having large blocks of HTML and CSS > >> in Java strings is just ... awful. > >> > >> Also, is there a particular reason we are using embedded CSS in > >> the pages instead of an external CSS file? > > > > Originally it was rather small. It grows with time. > > Okay. I think it's time to separate. > > > A separate file needs a license header, so the size will grow. > > I'm okay with that. > > >> Ultimately, it would be a good idea to move all CSS and even > >> styles into a separate CSS file so we can tighten-up the Content > >> Security Policy on the manager app. This can help prevent attacks > >> if there happens to be some kind of XSS vulnerability hiding in > >> there somewhere. > > > > I do not get how having a separate file [matters] with Content > > Security Policy. > > Having separate CSS allows a site to allow external styles but > prohibit in-page styles. The allow-token for CSP for inline styles is > "unsafe-inline". > > The reason this is a security issue is for XSS attacks. If an XSS > attack is in progress, the script may attempt to modify the page's > styles to manipulate the user. For example, hiding some important data > or warning message. XSS would have more difficulty spoofing an > externally-loaded CSS file. > > I don't think we have any js in the Manager, but external js is better > as well, as the page is therefore prohibited from running any js code > appearing in the page: all scripts must be external. > I don't see any scripts either. Why not add a CSP and set script to 'none'? I can add that if no one objects. > > Speaking of which, we should look at defining a CSP for the Manager > application. > > >> Any objections to evicting the CSS to begin with? > > > > No objection, if you want it. > I have extracted the CSS from the Java code on master [2]. I plan to port that to 9.0.x and 8.5.x. Feedback welcomed. I also replaced the old GIF logo with an SVG image from the main page as it looks more modern and crisp, especially on high resolution screens. I personally don't think that a few KBs make a difference with the code size, but if it is a concern then we can remove the multiple copies of the logos (Tomcat and ASF) for example from the different web applications, and copy them over at build time. So we will have a slightly smaller codebase at the expense of a bit more complicated build process. Best, Igal [2] https://github.com/apache/tomcat/commit/9c5d2e3b633fdb651bc9f11db4aac97ad3ad4df2 > > > > We already have image files. Thus, why not? > > Sine you mentioned it, how to we "license" image files? > > >> [1] https://github.com/apache/tomcat/pull/327 > > > > An odd PR. I see that it makes some visual changes, but there is > > no description nor discussion what the actual changes are. > > I care less about this specific PR and more about cleaning everything up > . > > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl80Dx8ACgkQHPApP6U8 > pFhSSg/9EQQpZ6WLOeMA7o41UJ3o/X49Xu5h7mliFhIQ6xNkoqW6sWkOHy0LURqU > 4S+WaPQzNsXqU8gREcKcU1OPNFnh2i3hGaD6mc/Tr5PMg82qBDwozxM9L6pcKo/N > d30RiJ5MeenrLZ/chbC8Kq4pqBbNtChQWmVH4Dp469DIAwhE3A6T7pwiB1bB72Tz > DxW/1PTAZENvkchkhll/UyEd+pJV9rq1CrrR8LRpqkEkZqu50vKFhE7XWIn4AkZf > OXhtI+SLh/1cxeVMfVjq7JyoslMHiZ7d+55wybvdRWZLns+OMeOTjxW6nzAaB8nN > SYEs/x/+HOV2x91btCpurttGFNzjdU3VqnM/Xk0mThVoxP0CktOSePGlUKd8gqi1 > Jed/RxeaKSUSjrghhCJLnvsNhqUfXMy35eATWdJ+YPhIyxM1aotBPZN9zZRKh2zp > IPM/VvpFWJsIiIzbzhLfQfRNK9UpLaTL96s+V/5opoIHpPVpW+T8uSVrFpysfErE > fZVC027SgEDzDjtBvPhRN4E8kK4rUKiAOyJJX/M3q7iJKZj1zy5NOo3RQZ7WAqIv > Qx8mAwIi+/cNaQotbCuTkTpObzSHetR6OF9RQDZG/zAMI+W5/9eVTrZucto4yCB8 > 9fMGf2YTrqnF4qF5JMAKzRH+kucGyZx4q8aX9SY+RTl5GuGcGKI= > =xI8S > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail:
Re: Use of "constants" in Manager to generate HTML/CSS content
Chris, On Mon, Aug 10, 2020 at 12:20 PM Martin Grigorov wrote: > > On Tue, Jul 28, 2020, 16:48 Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> All, >> >> I was looking at this PR[1] and wondering why we have huge swaths of >> CSS and HTML in a Java source file, instead of using e.g. JSP or some >> other content-generation framework. >> >> I know, I hate JSP, too, but having large blocks of HTML and CSS in >> Java strings is just ... awful. >> >> Also, is there a particular reason we are using embedded CSS in the >> pages instead of an external CSS file? >> >> Ultimately, it would be a good idea to move all CSS and even styles >> into a separate CSS file so we can tighten-up the Content Security >> Policy on the manager app. This can help prevent attacks if there >> happens to be some kind of XSS vulnerability hiding in there somewhere. >> >> Any objections to evicting the CSS to begin with? >> > It's funny, I was thinking the same thing a couple of weeks ago but didn't want to cause a merge conflict for the PR so waited to see what's going on with that, though as I commented on it I don't like that it changes the theme colors, etc. If you are already working on that then great. If you haven't started, and you have better things to do, I'd be happy to clean that up so please LMK. Best, Igal > > +1 > > >> Thanks, >> - -chris >> >> [1] https://github.com/apache/tomcat/pull/327 >> -BEGIN PGP SIGNATURE- >> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ >> >> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8gLJsACgkQHPApP6U8 >> pFgKCw//WY8p/EBS7sxDYgnV6W4pjeuAuhXv6ierajPH28NfdokIRlU4IfFIUVIE >> Ck98rK9uH98o6QFkWC70MVYV+NbEi4CwrjPhuFV/rEplyqfA+Ijs5g069a1g15On >> fw5V44CK2JBj0AjT4ZtMVWOSxDElHZc3SjZmyaie0pk2zDVxYwSwhoRPtqzms5rH >> zTlu48R14t1O9PLsWGthwdVStAn9WlE7hBLI3yLag/QKUqlOR/a8Fy75mbMma5a9 >> cmG8Lh5Jo8a6YzD0q37sdOmKN5d9lZxZkz3x21Cy3v2qcKcaGUcAttAEe9hFKEzh >> I0hOMKYc/2n2aNpMTjIkG86fXzAYB1IIsfiGxlwP/nY6HzJ9XRolD9+kT7LZ/tP3 >> 7SKL8rVoKi5SWiH+g3jGifVkxfiHlMhvZikAbC75ngP7mNXZFHPdnF3rvai/cbum >> FWUpLDoW/oTs87v9l071hs+hf2PffvqL/v5AeoMbGf/VDpf/zcuNy0wlB2w6Nxo9 >> K8sBVHQGJzIlaR9fqLyYJkJ8kmSb37t7BxPXLuGSCr98uUD8bSy2IwC2IxessXQc >> E+oIyJ0mlPdKU1dh5yFtMzCp4S9olUg4diqOxpToGm2hnmdnkRY3OarC1OU839NC >> Yd5uYA9XoYxBro2oNfB1gCNB5Ve4aLVOV0Q3iKcW83b8jLiNgzY= >> =Z+cI >> -END PGP SIGNATURE- >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >>
Re: How to run individual Test
Saksham, On Mon, Aug 10, 2020 at 9:46 AM Saksham Verma wrote: > Hi Dev Team, > > Need help with below questions: > > 1. The Pull request Tests are failing on Travis CI. But Is there any way I > can get the logs for the test job? > > 2. How can I run any individual test. > See section 7 of the BUILDING.txt [1] file. Igal [1] https://github.com/apache/tomcat/blob/master/BUILDING.txt#L308 > Whenever I am trying to run a single test I get below error: > java.lang.VerifyError: Inconsistent stackmap frames at branch target 392 > Exception Details: > Location: > > org/apache/juli/ClassLoaderLogManager.readConfiguration(Ljava/lang/ClassLoader;)V > @392: ldc_w > Reason: > Type uninitialized 370 (current frame, stack[2]) is not assignable to > uninitialized 366 (stack map, stack[2]) > Current Frame: > bci: @383 > flags: { } > locals: { 'org/apache/juli/ClassLoaderLogManager', > 'java/lang/ClassLoader', 'java/io/InputStream', 'java/lang/String' } > stack: { uninitialized 366, uninitialized 366, uninitialized 370, > uninitialized 370, 'java/lang/String', integer } > Stackmap Frame: > bci: @392 > flags: { } > locals: { 'org/apache/juli/ClassLoaderLogManager', > 'java/lang/ClassLoader', 'java/io/InputStream', 'java/lang/String' } > stack: { uninitialized 366, uninitialized 366, uninitialized 366, > uninitialized 366, 'java/lang/String' } > Bytecode: > > Thanks, > Saksham >
Re: Publishing EOL dates on whichversion?
Chris, On Thu, Aug 6, 2020 at 8:29 AM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > All, > > I'm wondering if we shouldn't add EOL dates to the "which version" page. > > The table on that page is very busy, but I think it would help to know: > > 1. When a currently-supported version will be EOL'd (e.g. 7.0.x) > 2. When a superseded version has been EOL'd (e.g. 6.0.x) > +1. Very useful and important information IMO. > We might be able to shrink the table horizontally a little by > shrinkking / abbreviating some of the column headers. For example > replace "Authentication (JASPIC) Spec" with "JASPIC". Maybe drop > "Spec" from all headers. Maybe shorten "Latest Released Version" to > "Latest" and "Supported Java Versions" to "Java". We could use a > stylesheet to add those longer headers for printing, and we could use > "title"s to expand the headers if you float a mouse/tap a finger on > the headings to get more information. We could also put a key below > the table. > > WDYT? > There are many opportunities for improving the layout, and I'd be happy to get back on that. It is a bit challenging for me to work with SVN though as I'm much more familiar with Git and I don't have much time ATM to work on improving my SVN skills (which would probably become obsolete soon anyway). It'd be great if we could move the website to Git. Many apache projects use the `-site` or `-website` suffix, so it can be something like `tomcat-site`. Best, Igal > > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8sIa8ACgkQHPApP6U8 > pFhjkA/8DLMqIHgF130aGL2YXWuG5OKl/WHh1NFUHhcWHg1zu4zosaMeqExcxFdM > 20kE44WjbcD0kvAEeAvR6ejOLm1S7lfXzCs41ZnJI6v4wyhEfp+n9gfYESF3kZqU > 5v4IhD0XBspp60iom2BVggF61qu2ZIE9BCD+zv5ikELni4+psg1T7WkTomtIj8Id > W0A+QGMnsYyAGZpqxPRM3agn/T2A+pbsQKFTfqX8KEot+m00PrEy5HRjeYCRpm4Y > OtlHrPLhrOutS7M3K8b191BPf7I55pGEfsq7rSHnpD0H+KM4ur9v6tHtWNutwVTY > 3Y2Fs357Cckr+jU0YpBEDn/2jmHioiShMYNmchalkvbXCiCESzgzhr5oazU7tp9j > et7zFy3XlJ1e0fJ3vq/LQnu6HqCwPRPaF27h8hyVrLSzatrPb9Cb2/AGr3SaHonK > 9YmpziI1MR4i358y3cxeVIaTMal6MDAjRn8fIfQxxm3k5PZiHb+aMNd4Mion11xH > SqVAep9FyV9V0AbikoazTzUApPBosiD0onioq3o6ApSVfdaa+shh2jmI2JFzRGkf > Unpb3xGRye3EZZVjwXCDw0QJ2UVx65gM7k5W0xvUr0IOmSjJVLBpi1Z1Zv7ijNN0 > nj8x3UUTNrABK8PniUIZ+xafoRFlPv4RDGcf6laCdks5R5y31+8= > =8Ax9 > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Jasper throws an NPE when running in IntelliJ IDEA
I have set up Tomcat in IntelliJ using the ant task, `ant ide-intellij`. I added the PATH variables for ANT_HOME and TOMCAT_BUILD_LIBS, and marked the directory webapps/examples/WEB-INF/classes as a Source Folder. If I call the URI for /tomcat.gif, for example, it works as expected and I get the image, but if I try to run /index.jsp I get the NPE below [1]. Further, when I check the IDE for implementations of the abstract class org.apache.jasper.runtime.HttpJspBase I can't find any, which is very puzzling to me. What am I doing wrong? Thanks, Igal [1] org.apache.jasper.JasperException: java.lang.NullPointerException org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:639) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:515) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:385) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:329) javax.servlet.http.HttpServlet.service(HttpServlet.java:741) *Root Cause* java.lang.NullPointerException org.apache.jsp.index_jsp._jspService(index_jsp.java:431) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) javax.servlet.http.HttpServlet.service(HttpServlet.java:741) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:477) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:385) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:329) javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
Re: Broken links on the website
Scratch that. I don't know why Google is indexing the wrong page. The actual Download page [2] was a bit slow but renders properly. Sorry about that. Perhaps we can remove the wrong page or add a meta tag with a canonical tag [3], e.g. https://tomcat.apache.org/download-90.cgi; /> Igal [2] https://tomcat.apache.org/download-90.cgi [3] https://support.google.com/webmasters/answer/139066?hl=en On Tue, Dec 17, 2019 at 6:18 PM Igal Sapir wrote: > Something went wrong on the website. Specifically, the Download page for > 9.0 [1] shows attributes that should be evaluated, e.g. [define > v]9.0.30[end]. That also breaks the download links which do not evaluate > the version number properly. > > I can look into it tomorrow, but if someone more familiar with recent > changes can fix it that would be great. > > Also, migrating the source to Git would be very helpful since if it were > in Git I could have looked into it now. SVN is a bit more challenging for > me ATM. > > Thank you, > > Igal > > [1] https://tomcat.apache.org/download-90 > >
Broken links on the website
Something went wrong on the website. Specifically, the Download page for 9.0 [1] shows attributes that should be evaluated, e.g. [define v]9.0.30[end]. That also breaks the download links which do not evaluate the version number properly. I can look into it tomorrow, but if someone more familiar with recent changes can fix it that would be great. Also, migrating the source to Git would be very helpful since if it were in Git I could have looked into it now. SVN is a bit more challenging for me ATM. Thank you, Igal [1] https://tomcat.apache.org/download-90
Re: Initial set of patches for Jakarta EE 9
On 12/1/2019 1:28 PM, Mark Thomas wrote: On 30/11/2019 21:11, Igal Sapir wrote: First issue I noticed when trying to build on Windows: compile: [javac] Compiling 1727 source files to E:\Workspace\test\tomcat-jakarta\output\classes [javac] E:\Workspace\test\tomcat-jakarta\java\org\apache\tomcat\util\http\RequestUtil.java:21: error: package javax.servlet.http does not exist [javac] import javax.servlet.http.HttpServletRequest; [javac] ^ [javac] E:\Workspace\test\tomcat-jakarta\java\org\apache\tomcat\util\http\RequestUtil.java:122: error: cannot find symbol [javac] public static boolean isSameOrigin(HttpServletRequest request, String origin) { [javac] ^ [javac] symbol: class HttpServletRequest [javac] location: class RequestUtil [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] 2 errors BUILD FAILED E:\Workspace\test\tomcat-jakarta\build.xml:706: Compile failed; see the compiler error output for details. Sorry. My error. When I rebased the branch I forgot to check if any additional changes were required. I've fixed this now. Note I used a force push to try and keep to the one commit per package I used originally. Should be OK now. This one built fine but got some failing test cases on a busy Windows machine, so possibly false positives: [concat] Testsuites with failed tests: [concat] TEST-org.apache.catalina.authenticator.TestFormAuthenticator.APR.txt [concat] TEST-org.apache.catalina.core.TestAsyncContextImpl.NIO2.txt [concat] TEST-org.apache.coyote.http2.TestStreamProcessor.APR.txt [concat] TEST-org.apache.coyote.http2.TestStreamProcessor.NIO.txt [concat] TEST-org.apache.coyote.http2.TestStreamProcessor.NIO2.txt [concat] TEST-org.apache.jasper.runtime.TestJspRuntimeLibrary.APR.txt [concat] TEST-org.apache.jasper.runtime.TestJspRuntimeLibrary.NIO.txt [concat] TEST-org.apache.jasper.runtime.TestJspRuntimeLibrary.NIO2.txt [concat] TEST-org.apache.tomcat.websocket.TestWebSocketFrameClientSSL.APR.txt Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Initial set of patches for Jakarta EE 9
Mark, On 11/28/2019 11:46 AM, Mark Thomas wrote: Hi all, I have pushed an initial set of patches for Jakarta EE 9 here: https://github.com/markt-asf/tomcat/tree/jakarta The current status is: - All the packages changing in Jakarta EE 9 have been renamed - Any associated constants, service loader files etc. have also been renamed - It builds - The unit tests pass (excluding those that depend on JSTL - more on that below) - A basic smoke test passes Please try and build it, take it for a spin and report back on this thread if you find any issues. First issue I noticed when trying to build on Windows: compile: [javac] Compiling 1727 source files to E:\Workspace\test\tomcat-jakarta\output\classes [javac] E:\Workspace\test\tomcat-jakarta\java\org\apache\tomcat\util\http\RequestUtil.java:21: error: package javax.servlet.http does not exist [javac] import javax.servlet.http.HttpServletRequest; [javac] ^ [javac] E:\Workspace\test\tomcat-jakarta\java\org\apache\tomcat\util\http\RequestUtil.java:122: error: cannot find symbol [javac] public static boolean isSameOrigin(HttpServletRequest request, String origin) { [javac] ^ [javac] symbol: class HttpServletRequest [javac] location: class RequestUtil [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] 2 errors BUILD FAILED E:\Workspace\test\tomcat-jakarta\build.xml:706: Compile failed; see the compiler error output for details. Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.49
On 11/18/2019 1:22 PM, Mark Thomas wrote: On 17/11/2019 19:01, Mark Thomas wrote: We have a regression affecting 8.5.x (and 7.0.x). The fix [1] for an issue raised on the users list [2] was incorrect and creating a different issue [3]. There are two questions to address. a) Do we cancel the 8.5.49 release for this and roll a 8.5.50 release? b) Do we fix this by a) correcting [1] or back-porting the change to a single poll set? I'm leaning towards 8.5.50 and back-port the single poll set change. Thoughts? +1 for 8.5.50 Igal Mark [1] https://github.com/apache/tomcat/commit/fffb08790e642e03f00c5f96a3a61ee09a2c8342 [2] https://markmail.org/thread/lh7pst3bwptpcyco [3] https://tomcat.markmail.org/thread/btjionfhp2olyjne The proposed Apache Tomcat 8.5.49 release is now available for voting. The major changes compared to the 8.5.47 release are: - Improvements to Async error handling - Stricter processing of HTTP headers when looking for specific token values - Fix various issues that could lead to modification to a JSP not being reflected in the served page Along with lots of other bug fixes and improvements. For full details, see the changelog: https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.49/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-1238/ The tag is: https://github.com/apache/tomcat/tree/8.5.49 The proposed 8.5.49 release is: [ ] Broken - do not release [ ] Stable - go ahead and release as 8.5.49 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.29
On 11/16/2019 10:56 AM, Mark Thomas wrote: The proposed Apache Tomcat 9.0.29 release is now available for voting. The proposed 9.0.29 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 9.0.29 Unit tests passed on Windows 10 and Ubuntu 18.04 Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.49
On 11/17/2019 11:01 AM, Mark Thomas wrote: The proposed Apache Tomcat 8.5.49 release is now available for voting. The proposed 8.5.49 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 8.5.49 Unit tests passed on Windows 10 and Ubuntu 18.04 Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.47
On 10/7/2019 6:58 AM, Mark Thomas wrote: The proposed Apache Tomcat 8.5.47 release is now available for voting. The major changes compared to the 8.5.46 release are: I'm getting similar test failures as I did for 9.0.27 on that same Windows machine: > grep -A 5 FAILED output/build/logs/*.txt output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt: FAILED output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt-Uri: /stage1, Status: 500, Time: 2248 duration is not < 1600 output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt-junit.framework.AssertionFailedError: Uri: /stage1, Status: 500, Time: 2248 duration is not < 1600 output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt- at org.apache.catalina.valves.TesterAccessLogValve.validateAccessLog(TesterAccessLogValve.java:92) output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt- at org.apache.catalina.core.TestAsyncContextImpl.doTestDispatchError(TestAsyncContextImpl.java:1015) output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt- at org.apache.catalina.core.TestAsyncContextImpl.testDispatchErrorWithThreadMultiple(TestAsyncContextImpl.java:921) -- output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt: FAILED output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt-Uri: /stage1, Status: 500, Time: 4018 duration is not < 1600 output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt-junit.framework.AssertionFailedError: Uri: /stage1, Status: 500, Time: 4018 duration is not < 1600 output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt- at org.apache.catalina.valves.TesterAccessLogValve.validateAccessLog(TesterAccessLogValve.java:92) output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt- at org.apache.catalina.core.TestAsyncContextImpl.doTestDispatchError(TestAsyncContextImpl.java:1015) output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt- at org.apache.catalina.core.TestAsyncContextImpl.testDispatchErrorMultiple(TestAsyncContextImpl.java:906) -- output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt: FAILED output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt-Uri: /stage1, Status: 500, Time: 2182 duration is not < 1600 output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt-junit.framework.AssertionFailedError: Uri: /stage1, Status: 500, Time: 2182 duration is not < 1600 output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt- at org.apache.catalina.valves.TesterAccessLogValve.validateAccessLog(TesterAccessLogValve.java:92) output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt- at org.apache.catalina.core.TestAsyncContextImpl.doTestDispatchError(TestAsyncContextImpl.java:1015) output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt- at org.apache.catalina.core.TestAsyncContextImpl.testDispatchErrorDoubleThenComplete(TestAsyncContextImpl.java:931) -- output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt: FAILED output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt-Uri: /stage1, Status: 500, Time: 2512 duration is not < 1600 output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt-junit.framework.AssertionFailedError: Uri: /stage1, Status: 500, Time: 2512 duration is not < 1600 output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt- at org.apache.catalina.valves.TesterAccessLogValve.validateAccessLog(TesterAccessLogValve.java:92) output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt- at org.apache.catalina.core.TestAsyncContextImpl.doTestDispatchError(TestAsyncContextImpl.java:1015) output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt- at org.apache.catalina.core.TestAsyncContextImpl.testDispatchErrorSingle(TestAsyncContextImpl.java:896) -- output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt: FAILED output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt-Uri: /stage1, Status: 500, Time: 1843 duration is not < 1600 output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt-junit.framework.AssertionFailedError: Uri: /stage1, Status: 500, Time: 1843 duration is not < 1600 output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt- at org.apache.catalina.valves.TesterAccessLogValve.validateAccessLog(TesterAccessLogValve.java:92) output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt- at org.apache.catalina.core.TestAsyncContextImpl.doTestDispatchError(TestAsyncContextImpl.java:1015) output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.APR.txt- at
Re: [VOTE] Release Apache Tomcat 9.0.27
Mark, On 10/7/2019 4:51 AM, Mark Thomas wrote: The proposed Apache Tomcat 9.0.27 release is now available for voting. I'm getting the failures below [1] for unit tests on Windows 10 with Java 1.8u181. False positives? Igal [1] output\build\logs> grep -A 5 FAILED * */* TEST-org.apache.coyote.http2.TestStreamProcessor.APR.txt: FAILED TEST-org.apache.coyote.http2.TestStreamProcessor.APR.txt-expected:<...3-Header-[:status]-[[304] TEST-org.apache.coyote.http2.TestStreamProcessor.APR.txt-3-Header-[etag]-[W/"957-1447269522000"]] TEST-org.apache.coyote.http2.TestStreamProcessor.APR.txt-3-Header-[date]-[W...> but was:<...3-Header-[:status]-[[200] TEST-org.apache.coyote.http2.TestStreamProcessor.APR.txt-3-Header-[accept-ranges]-[bytes] TEST-org.apache.coyote.http2.TestStreamProcessor.APR.txt-3-Header-[etag]-[W/"957-1447269522000"] -- TEST-org.apache.coyote.http2.TestStreamProcessor.NIO.txt: FAILED TEST-org.apache.coyote.http2.TestStreamProcessor.NIO.txt-expected:<...3-Header-[:status]-[[304] TEST-org.apache.coyote.http2.TestStreamProcessor.NIO.txt-3-Header-[etag]-[W/"957-1447269522000"]] TEST-org.apache.coyote.http2.TestStreamProcessor.NIO.txt-3-Header-[date]-[W...> but was:<...3-Header-[:status]-[[200] TEST-org.apache.coyote.http2.TestStreamProcessor.NIO.txt-3-Header-[accept-ranges]-[bytes] TEST-org.apache.coyote.http2.TestStreamProcessor.NIO.txt-3-Header-[etag]-[W/"957-1447269522000"] -- TEST-org.apache.coyote.http2.TestStreamProcessor.NIO2.txt: FAILED TEST-org.apache.coyote.http2.TestStreamProcessor.NIO2.txt-expected:<...3-Header-[:status]-[[304] TEST-org.apache.coyote.http2.TestStreamProcessor.NIO2.txt-3-Header-[etag]-[W/"957-1447269522000"]] TEST-org.apache.coyote.http2.TestStreamProcessor.NIO2.txt-3-Header-[date]-[W...> but was:<...3-Header-[:status]-[[200] TEST-org.apache.coyote.http2.TestStreamProcessor.NIO2.txt-3-Header-[accept-ranges]-[bytes] TEST-org.apache.coyote.http2.TestStreamProcessor.NIO2.txt-3-Header-[etag]-[W/"957-1447269522000"] -- TEST-org.apache.tomcat.jni.TestSocketServer.NIO2.txt: FAILED TEST-org.apache.tomcat.jni.TestSocketServer.NIO2.txt-Socket.timeoutSet failed (<1s) [999760800] +-[400] TEST-org.apache.tomcat.jni.TestSocketServer.NIO2.txt-junit.framework.AssertionFailedError: Socket.timeoutSet failed (<1s) [999760800] +-[400] TEST-org.apache.tomcat.jni.TestSocketServer.NIO2.txt- at org.apache.tomcat.jni.TestSocketServer.testBlockingReadFromClientWithTimeout(TestSocketServer.java:111) TEST-org.apache.tomcat.jni.TestSocketServer.NIO2.txt- TEST-org.apache.tomcat.jni.TestSocketServer.NIO2.txt-Testcase: testPort took 0.001 sec - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Tomcat 10: Remove CGI Servlet
On 10/7/2019 8:14 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 10/7/19 11:10, Mark Thomas wrote: All, I recently gave a presentation on locking-down Apache Tomcat[1] and I briefly discussed the "sharp edges" present in Tomcat. Some of them are unnecessarily sharp and may be actually unnecessary. I'm going to make a few proposals to remove functions from Tomcat. Proposal: Remove CGI Servlet -1. Not a veto, just a -1. Fair enough. I didn't think I'd get 100% agreement. If anyone feels like this is is something worth keeping around, I'm happy to let the proposal drop. Is it possible to extract these removals (including the other proposals in this question) to an external repo in case someone wants to add them manually to his/her own deployment? That way if anyone depends on any of the removed items they can still add them. Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)
On 10/7/2019 7:46 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, I recently gave a presentation on locking-down Apache Tomcat[1] and I briefly discussed the "sharp edges" present in Tomcat. Some of them are unnecessarily sharp and may be actually unnecessary. I'm going to make a few proposals to remove functions from Tomcat. Proposal: Remove Server-Side Includes +1 Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.46
On 9/16/2019 11:46 AM, Mark Thomas wrote: The proposed Apache Tomcat 8.5.46 release is now available for voting. The proposed 8.5.46 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 8.5.46 Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.26
Mark, On 9/17/2019 1:56 PM, Mark Thomas wrote: On 17/09/2019 19:46, Igal Sapir wrote: On 9/16/2019 9:15 AM, Mark Thomas wrote: The proposed Apache Tomcat 9.0.26 release is now available for voting. [1] Testsuite: org.apache.catalina.core.TestAsyncContextImpl Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec Testcase: testBug50753 took 0.004 sec Caused an ERROR Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:748) That usually indicates an APR/native crash during Windows shutdown. It means we have a (possibly timing related) bug in the APR/native code we still haven't tracked down. That they aren't easy to reproduce makes fixing bugs like this tricky. In my user's home directory I have a build.properties file pointing to an older native lib: test.apr.loc=E:/Downloads/tomcat-native-1.2.21-openssl-1.1.1a-win32-bin/bin/x64 I will try to test again with the current version (1.2.23) in the coming days. Thanks, Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.26
On 9/16/2019 9:15 AM, Mark Thomas wrote: The proposed Apache Tomcat 9.0.26 release is now available for voting. The major changes compared to the 9.0.24 release are: - Update to Commons Daemon 1.2.1 to pick up fixes for regressions in Commons Daemon 1.2.0, most notably a failure to start when using a 32-bit JVM on Windows. - Avoid an NPE when accessing an https port using http. - Correct the invalid automatic module names for the embedded JARs. - Fix a potential hang when using HTTP/2 with the asynchronous Servlet API. The proposed 9.0.26 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 9.0.26 Tested with Ubuntu and Windows. On Windows I received an error on org.apache.catalina.core.TestAsyncContextImpl which tests bug 50753. I think it is a fluke in the test case though. Details below [1]. Igal [1] Testsuite: org.apache.catalina.core.TestAsyncContextImpl Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec Testcase: testBug50753 took 0.004 sec Caused an ERROR Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:748)
Re: [VOTE] Release Apache Tomcat 9.0.24
On Wed, Aug 14, 2019 at 2:45 PM Mark Thomas wrote: > > The proposed 9.0.24 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 9.0.24 > All unit tests passed successfully on Windows 10 and Ubuntu 18.04 Best, Igal > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [VOTE] Release Apache Tomcat 8.5.45
On Wed, Aug 14, 2019 at 3:48 PM Mark Thomas wrote: > > The tag is: > https://github.com/apache/tomcat/tree/8.5.45 > 46d444a14cdac3e7e1f011a02cbdac9e5a80631c > > The proposed 8.5.45 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 8.5.45 > All unit tests passed successfully on Windows 10 and Ubuntu 18.04 Best, Igal > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Graal and Tomcat Native
Rémy, At the risk of pointing out the obvious as I'm sure that you are much more familiar with this than I am: On 7/10/2019 11:42 AM, Rémy Maucherat wrote: Hi, I'm a bit stumped there, as I'm trying to get native to work in that rather special environment. JNI_OnLoad fails with: WARNING: The APR based Apache Tomcat Native library failed to load. The error reported was [Unsupported JNI version 0x, required by bin/libtcnative-1.so.0.2.23] java.lang.UnsatisfiedLinkError: Unsupported JNI version 0x, required by bin/libtcnative-1.so.0.2.23 at com.oracle.svm.jni.JNILibraryInitializer.initialize(JNILibraryLoadFeature.java:87) at com.oracle.svm.core.jdk.NativeLibrarySupport.loadLibrary0(NativeLibrarySupport.java:153) at com.oracle.svm.core.jdk.NativeLibrarySupport.loadLibrary(NativeLibrarySupport.java:98) at java.lang.ClassLoader.loadLibrary(Target_java_lang_ClassLoader.java:126) at java.lang.Runtime.load0(Runtime.java:809) at java.lang.Runtime.load(Runtime.java:241) at java.lang.System.load(System.java:366) at org.apache.tomcat.jni.Library.(Library.java:42) Although this looks weird, this is actually returning -1 and it's normal when it fails [it's a bad error message]. Most likely this doesn't work: if ((*vm)->GetEnv(vm, , JNI_VERSION_1_4)) { return JNI_ERR; } Any ideas ? From [1]: "JNI_OnLoad must return the JNI version needed by the native library". -1 is translated into 0x, which is the invalid result. From the snippet you posted I'm guessing that the returned value is supposed to be JNI_VERSION_1_4 or greater. Do you know what that snippet is trying to check? Igal [1] https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/invocation.html#JNJI_OnLoad - 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 9.0.22
Chris, On 7/10/2019 6:44 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, Yep, the APR library was the problem. For some reason, it did not load for a great many (all?) tests. I'll have to check my testing process. - -chris I would suspect an all or nothing thing here. Hard to imagine why it would load for some but not all. Do you point to the APR library with `test.apr.loc`? I expect the log output to show whether it was found or not. Best, Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Git repo for Tomcat Site
Mark, On 7/9/2019 1:45 AM, Mark Thomas wrote: On 09/07/2019 05:29, Igal Sapir wrote: Can we move the Tomcat site to Git? Yes. ASF infra supports both svnpubsub and gitpubsub for websites. There will need to be a little co-ordination with infra as we'd need to switch where the source for the site is pulled from. On the plus side, Tomcat site svn repo is not mirrored to git so we don't need to worry about any of that. I'll look into to the migration process and figure out exactly what is involved. ACK Possibly to a repo named "tomcat-site"? That makes sense. In terms of when, I'd suggest after the 9.0.x and 8.5.x releases have completed. There is usually a quietish period of ~3 weeks between releases when the website doesn't update that much. I think it makes sense to migrate then. All of this is assuming there are no objections to moving. If there are any objections please speak up now so we can discuss any concerns and figure out a way forward everyone is happy with. I'd be happy to make the required changes per prior emails so that we can publish the new design in time for ACNA. Migration to Git and a new design are two separate issues. I'd be happy to see both proceed but I suggest we discuss them separately. I suggest you start a new thread for the discussion about moving to a new design - perhaps with a link to a demo of the latest proposal so we can remind ourselves of what it looks like. True, but it is much easier for me to use Git so personally for me the two issues are not completely unrelated. As of the last communications on the matter the current proposal can be viewed at http://people.apache.org/~isapir/mockups/tomcat-site/ and the open issues are on the DEV mailing list, mostly in the thread https://www.mail-archive.com/dev@tomcat.apache.org/msg131745.html The last discussion on the subject was at https://www.mail-archive.com/dev@tomcat.apache.org/msg132281.html Best, Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Git repo for Tomcat Site
Can we move the Tomcat site to Git? Possibly to a repo named "tomcat-site"? I'd be happy to make the required changes per prior emails so that we can publish the new design in time for ACNA. Thoughts? Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Broken Download Links for Tomcat Native Binaries
The download page for the Tomcat Native Binaries [1] has broken links. Pretty much all of the links under "Binaries for Microsoft Windows", e.g. the one labeled "Native 1.2.23 Windows Binaries zip" [2] returns a 404. Were the binaries created at all? Perhaps at a different location? Igal [1] http://tomcat.apache.org/download-native.cgi [2] https://www-us.apache.org/dist/tomcat/tomcat-connectors/native/1.2.23/binaries/tomcat-native-1.2.23-openssl-1.0.2q-win32-bin.zip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.43
On 7/4/2019 2:19 PM, Mark Thomas wrote: The proposed Apache Tomcat 8.5.43 release is now available for voting. The proposed 8.5.43 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 8.5.43 Unit tests passed on Windows 10 and Ubuntu 18.04 with Java 8 Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.22
On 7/4/2019 12:33 PM, Mark Thomas wrote: The proposed Apache Tomcat 9.0.22 release is now available for voting. The proposed 9.0.22 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 9.0.22 Unit tests passed on Windows 10 and Ubuntu 18.04 with Java 8 Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Unit Tests and OpenSSL Ciphers
On 6/27/2019 8:56 AM, Mark Thomas wrote: The ciphers supported by Ubuntu have changed. You need to use: openssl ciphers -v ALL:eNULL to see all of them. The short version is that ARIA ciphers are now supported. test.openssl.unimplemented=IDEA should fix it. Thanks, Mark! The part that puzzled me was that `openssl ciphers -v` did not show those ciphers and yet they appeared in the `ant test` logs. Adding `ALL:eNULL` indeed shows the ARIA ciphers. Best, Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Unit Tests and OpenSSL Ciphers
While testing Tomcat Native 1.2.23 two unit tests failed on my system: TEST-org.apache.tomcat.util.net.openssl.ciphers.TestCipher.APR.txt TEST-org.apache.tomcat.util.net.openssl.ciphers.TestOpenSSLCipherConfigurationParser.APR.txt My build.properties includes the following: test.openssl.unimplemented=ARIA,IDEA Which adds any ciphers with the substring ARIA or IDEA in the name to the unimplemented list that should be ignored [1]. The failure message shows that the issue is with unexpected ciphers [2], e.g. ECDHE-ARIA128-GCM-SHA256+TLSv1.2, so the next thing I did was to check OpenSSL's version and ciphers. The version is the same as the build process shows in the logs, but I don't see ARIA ciphers there: $ openssl version OpenSSL 1.1.1 11 Sep 2018 $ openssl ciphers -v | grep ARIA Any ideas? Thanks, Igal [1] https://github.com/apache/tomcat/commit/a9c1a0661198 [2] Testcase: testOpenSSLCipherAvailability took 0.043 sec FAILED Unexpected cipher suites: ECDHE-ARIA128-GCM-SHA256+TLSv1.2 DHE-RSA-ARIA128-GCM-SHA256+TLSv1.2 DHE-DSS-ARIA256-GCM-SHA384+TLSv1.2 ECDHE-ECDSA-ARIA128-GCM-SHA256+TLSv1.2 ARIA256-GCM-SHA384+TLSv1.2 ECDHE-ARIA256-GCM-SHA384+TLSv1.2 DHE-RSA-ARIA256-GCM-SHA384+TLSv1.2 RSA-PSK-ARIA256-GCM-SHA384+TLSv1.2 ECDHE-ECDSA-ARIA256-GCM-SHA384+TLSv1.2 ARIA128-GCM-SHA256+TLSv1.2 RSA-PSK-ARIA128-GCM-SHA256+TLSv1.2 DHE-PSK-ARIA128-GCM-SHA256+TLSv1.2 DHE-DSS-ARIA128-GCM-SHA256+TLSv1.2 PSK-ARIA256-GCM-SHA384+TLSv1.2 DHE-PSK-ARIA256-GCM-SHA384+TLSv1.2 PSK-ARIA128-GCM-SHA256+TLSv1.2 expected:<0> but was:<16> junit.framework.AssertionFailedError: Unexpected cipher suites: ECDHE-ARIA128-GCM-SHA256+TLSv1.2 DHE-RSA-ARIA128-GCM-SHA256+TLSv1.2 DHE-DSS-ARIA256-GCM-SHA384+TLSv1.2 ECDHE-ECDSA-ARIA128-GCM-SHA256+TLSv1.2 ARIA256-GCM-SHA384+TLSv1.2 ECDHE-ARIA256-GCM-SHA384+TLSv1.2 DHE-RSA-ARIA256-GCM-SHA384+TLSv1.2 RSA-PSK-ARIA256-GCM-SHA384+TLSv1.2 ECDHE-ECDSA-ARIA256-GCM-SHA384+TLSv1.2 ARIA128-GCM-SHA256+TLSv1.2 RSA-PSK-ARIA128-GCM-SHA256+TLSv1.2 DHE-PSK-ARIA128-GCM-SHA256+TLSv1.2 DHE-DSS-ARIA128-GCM-SHA256+TLSv1.2 PSK-ARIA256-GCM-SHA384+TLSv1.2 DHE-PSK-ARIA256-GCM-SHA384+TLSv1.2 PSK-ARIA128-GCM-SHA256+TLSv1.2 expected:<0> but was:<16> at org.apache.tomcat.util.net.openssl.ciphers.TestCipher.testOpenSSLCipherAvailability(TestCipher.java:108)
Re: [VOTE] Release Apache Tomcat Native 1.2.23
On 6/26/2019 6:20 AM, Mark Thomas wrote: The Apache Tomcat Native 1.2.23 release is [X] Stable, go ahead and release [ ] Broken because of ... Built from source and ran unit tests with Tomcat 9.0.21 on Ubuntu 18.04 with Java 8u202. I got two failing tests but it looks like they failed due to the ARIA ciphers, which should be ignored on my system. Perhaps I missed something when I added [1], or new ciphers were added to the Debian distro. I will have to look into that: TEST-org.apache.tomcat.util.net.openssl.ciphers.TestCipher.APR.txt TEST-org.apache.tomcat.util.net.openssl.ciphers.TestOpenSSLCipherConfigurationParser.APR.txt Igal [1] https://github.com/apache/tomcat/commit/a9c1a0661198 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat-Native - Time to move to git?
On 6/17/2019 2:18 PM, Rainer Jung wrote: Am 17.06.2019 um 18:56 schrieb Mark Thomas: Hi, I'm starting to look at OCSP stapling for our OpenSSL based connectors and I suspect a Tomcat Native release will be required. Even if it isn't for this, it has been a while since the last Tomcat Native release so I expect we'll need to do one fairly soon anyway. The complication is the svn:external that picks up the org.apache.tomcat.jni package from 9.0.x. Now 9.0.x has moved to git, this no longer works. I looked at a workaround using the "GitHub makes itself look like svn" but that timed out for the Tomcat repo. I suspect due to size. I then looked at Git based solutions. sub-modules and sub-trees look to be the two options. Of the two, sub-trees looks better: - it is more suited to "read-only" importing - it doesn't require any additional commands to populate the imported code However, using sub-trees means moving Tomcat-Native to git. Before I start a formal vote to do so, are there any objections? The process would be: - ensure git mirror is up to date - break the svn->git mirror - start using git - update web site etc - move svn code to archive Given how the migration of the main repos went, I'm not expecting any major issues. +1 +1 Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.21
On 6/4/2019 1:50 PM, Mark Thomas wrote: The proposed 9.0.21 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 9.0.21 +1 Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.42
On 6/4/2019 2:06 PM, Mark Thomas wrote: The proposed 8.5.42 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 8.5.42 +1 Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.41
On 5/4/2019 2:56 AM, Mark Thomas wrote: The proposed Apache Tomcat 8.5.41 release is now available for voting. The proposed 8.5.41 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 8.5.41 Unit tests passed on Ubuntu and Windows with Java 8 and tc-native-1.2.21 Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.20
On 5/3/2019 3:52 PM, Mark Thomas wrote: The proposed Apache Tomcat 9.0.20 release is now available for voting. The proposed 9.0.20 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 9.0.20 Unit tests pass for NIO, NIO2, and APR on Ubuntu and Windows with Java 8 and tc-native-1.2.21 Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Remote attendance at Hackathon
On Thu, May 2, 2019 at 7:26 AM Christopher Schultz < ch...@christopherschultz.net> wrote: > > > > > I think that it's a great idea. I would have loved to attend in > > person but travelling on those dates didn't work for me. Doing so > > remotely would be great if possible. > > The schedule has us at the venue until 22:00 local time (ugh) for > Saturday, so we might even be able to see Igal during some non-crazy > tie for him (who, I believe is PDT, so 9 hours away from Brussels). > LOL. Yea, the time zone difference definitely adds a layer of complexity. It's totally understandable if it doesn't work out, so please don't go far out of your way trying to make it work. I will catch up with whoever comes to Vegas in September. Have fun, Igal
Re: Remote attendance at Hackathon
Mark, On Wed, May 1, 2019 at 2:03 PM Mark Thomas wrote: > Hi all, > > What to folks think about setting up a #Tomcat channel on the ASF slack > instance and using it during the hackathon to interact with folks that > want to be involved but can't travel? > > It would allow general chat as well as topic specific (video - if the > venue can stand the bandwidth) calls. > > I hope to be available for some of Saturday. > > We can also use the channel on an ongoing basis if we find it useful. > > Thoughts? > I think that it's a great idea. I would have loved to attend in person but travelling on those dates didn't work for me. Doing so remotely would be great if possible. Best, Igal
Re: [OT] Finally getting around to switching to Git
Chris, On 4/29/2019 12:18 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Igal, On 4/29/19 14:52, Igal Sapir wrote: Chris, On Thu, Apr 25, 2019 at 12:08 PM Christopher Schultz < ch...@christopherschultz.net> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Igal, On 4/25/19 14:42, Igal Sapir wrote: On 4/25/2019 11:30 AM, Coty Sutherland wrote: If you clone a single branch with no references such as `git clone apache/tomcat -b master --single-branch` then you get just the references/history for the master branch which results in about a 70M .git directory. So one needs to consider whether that added layer of complexity is worth the savings of 30M disk space, even when multiplied over 3 branches. Imagine the reclaimed space after deleting the local SVN directories ;) For Tomcat 8.5.x @ r1852558: $ du -hs .svn/ 41M.svn/ Are you sure that you have the whole history there? I am working ATM on my Ubuntu workstation where I have a copy of the Tomcat 8.5 SVN. The disk usage is mostly in the tags directory and not in the .svn: ux@u18:/workspace/src/tc8.5.x$ du -sh tags 1.2Gtags ux@u18:/workspace/src/tc8.5.x$ du -sh .svn 231M.svn ux@u18:/workspace/src/tc8.5.x$ du -sh . 1.5G. Oh, heavens no. Checking-out the root of a project in svn is almost never a good idea. I've literally never checked-out /svn/[project]. I always check-out /svn/[project]/trunk or /svn/[project]/tags/[branch]. Never even in private repositories, for the same reason: there is no reason ever to grab every tag and branch ever onto your own disk. Subversion is efficient on the server-side, but the client is dumb and will happily duplicate everything. Each "tag" takes about 35MB: ux@u18:/workspace/src/tc8.5.x$ du -sh tags/TOMCAT_8_5_25 35M tags/TOMCAT_8_5_25 ux@u18:/workspace/src/tc8.5.x$ du -sh tags/TOMCAT_8_5_24 35Mtags/TOMCAT_8_5_24 ux@u18:/workspace/src/tc8.5.x$ du -sh tags/TOMCAT_8_5_23 34M tags/TOMCAT_8_5_23 Yeah, you should never have grabbed those. It was a waste of time and disk space (and back-up time and disk space). And now I know ;) I was actually banned from the apache.org network at some point because downloading the whole Tomcat SVN repo used too many requests per day. But this was exactly my point when comparing SVN to Git. Your Git repository of 80MB includes all of the history with all of the branches and tags, so it's tiny compared to the gigabytes that SVN uses (1.5GB for only tc8.5). We are using Lightweight Tags [1] in Git so they barely take any disk space. Igal [1] https://git-scm.com/book/en/v2/Git-Basics-Tagging#_lightweight_tags - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [OT] Finally getting around to switching to Git
Chris, On Thu, Apr 25, 2019 at 12:08 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Igal, > > On 4/25/19 14:42, Igal Sapir wrote: > > On 4/25/2019 11:30 AM, Coty Sutherland wrote: > >> If you clone a single branch with no references such as `git > >> clone apache/tomcat -b master --single-branch` then you get just > >> the references/history for the master branch which results in > >> about a 70M .git directory. > > > > So one needs to consider whether that added layer of complexity is > > worth the savings of 30M disk space, even when multiplied over 3 > > branches. Imagine the reclaimed space after deleting the local SVN > > directories ;) > > For Tomcat 8.5.x @ r1852558: > > $ du -hs .svn/ > 41M.svn/ > > Are you sure that you have the whole history there? I am working ATM on my Ubuntu workstation where I have a copy of the Tomcat 8.5 SVN. The disk usage is mostly in the tags directory and not in the .svn: ux@u18:/workspace/src/tc8.5.x$ du -sh tags 1.2Gtags ux@u18:/workspace/src/tc8.5.x$ du -sh .svn 231M.svn ux@u18:/workspace/src/tc8.5.x$ du -sh . 1.5G. Each "tag" takes about 35MB: ux@u18:/workspace/src/tc8.5.x$ du -sh tags/TOMCAT_8_5_25 35Mtags/TOMCAT_8_5_25 ux@u18:/workspace/src/tc8.5.x$ du -sh tags/TOMCAT_8_5_24 35Mtags/TOMCAT_8_5_24 ux@u18:/workspace/src/tc8.5.x$ du -sh tags/TOMCAT_8_5_23 34Mtags/TOMCAT_8_5_23 Igal
Enabling Jasper when running in IDE
When running Tomcat (using 9.0.x with default settings) in an IDE I get an NPE when trying to access JSP files. I have traced it down to the fact that the JspFactory.setDefaultFactory() is never called and therefore getDefaultFactory() returns null. When launching using the catalina.sh script, WebappServiceLoader.load() finds two classes, org.apache.jasper.servlet.JasperInitializer and org.apache.tomcat.websocket.server.WsSci, via ServletContainerInitializer's (SCI), which loads and initializes them, and therefore they work properly. How can I initialize these when running in an IDE? Thanks, Igal
Re: [OT] Finally getting around to switching to Git
Chris, On 4/25/2019 12:08 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Igal, On 4/25/19 14:42, Igal Sapir wrote: On 4/25/2019 11:30 AM, Coty Sutherland wrote: If you clone a single branch with no references such as `git clone apache/tomcat -b master --single-branch` then you get just the references/history for the master branch which results in about a 70M .git directory. So one needs to consider whether that added layer of complexity is worth the savings of 30M disk space, even when multiplied over 3 branches. Imagine the reclaimed space after deleting the local SVN directories ;) For Tomcat 8.5.x @ r1852558: $ du -hs .svn/ 41M .svn/ Interesting. Maybe the tomcat-site SVN repo threw me off. I didn't bother to look at the breakdown of the project and the site: E:\Workspace\svn\tomcat\tomcat > du -sh . 85M E:\Workspace\svn\tomcat\tomcat > cd ../site E:\Workspace\svn\tomcat\site > du -sh . 1.4G Anyway, good to know. Thanks, Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Finally getting around to switching to Git
Chris, On 4/25/2019 12:07 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Igal, On 4/25/19 14:03, Igal Sapir wrote: Chris, On 4/25/2019 10:32 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Igal, On 4/23/19 12:52, Igal Sapir wrote: Another thing that I have changed in my workflow based on Mark's past suggestion, is that I keep a local repo for each major branch now. Okay, I have done the following: 1. Fork tomcat master to my own GitHub account Since you are a committer you don't need to this. That is useful though if you want to show a large update so that others can review it, but you can also do that in a new branch. 2. git clone URL 3. edit/add/commit/push 4. Create a PR I'm sure I can import the PR into tomcat-master. No problem. Now, when attempting to keep my fork current, I've always done something like: git remote add upstream master-url git checkout master git fetch upstream And I'm all up-to-date. When I did that, I ended up bringing-down the 7.0.x and 8.5.x branches as well. How can I limit the upstream to just the master? Or does my fork have to have everything, but I have to checkout a single branch? If so, I'm not sure how to do that. Your fork has the whole git repository, but fortunately git manages resources much better than Subversion, for example, so it's not too bad at all. You can see a list of the local branches and which branch you are currently on with the command, `git branch`, which will show something like this: git branch 7.0.x 8.5.x * master $ git branch * master So it looks like I forked the branch, which was the intent. To get this down to my local system, I just did a "git clone [my-repo-url]" and that's what I got. I'm pretty sure that you have the whole repository with all three branches, but only one local tracking branch (the default master branch). Try to run `git branch -a` and it should show you all of the branches, including remote ones. I have set up a new local repo to test (hopefully my new line characters are preserved in fixed font).: igal@localhost c:\Temp > git clone https://github.com/apache/tomcat Cloning into 'tomcat'... remote: Enumerating objects: 99, done. remote: Counting objects: 100% (99/99), done. remote: Compressing objects: 100% (50/50), done. remote: Total 342523 (delta 54), reused 75 (delta 40), pack-reused 342424 Receiving objects: 100% (342523/342523), 88.78 MiB | 7.71 MiB/s, done. Resolving deltas: 100% (225766/225766), done. Checking out files: 100% (4005/4005), done. igal@localhost c:\Temp > cd tomcat This is what you see now: igal@localhost c:\Temp\tomcat > git branch * master This shows the remote branches as well: igal@localhost c:\Temp\tomcat > git branch -a * master remotes/origin/7.0.x remotes/origin/8.5.x remotes/origin/HEAD -> origin/master remotes/origin/master Checking out a branch that exists remotely but not locally creates a local branch that tracks the remote one: igal@localhost c:\Temp\tomcat > git checkout 8.5.x Checking out files: 100% (1787/1787), done. *Branch '8.5.x' set up to track remote branch '8.5.x' from 'origin'.* Switched to a new branch '8.5.x' Listing the branches now shows the new local branch: igal@localhost c:\Temp\tomcat > git branch -a * 8.5.x master remotes/origin/7.0.x remotes/origin/8.5.x remotes/origin/HEAD -> origin/master remotes/origin/master The `*` denotes the current branch, so I am on the master branch. Switching to the 8.5.x branch with `git checkout 8.5.x` git checkout 8.5.x Checking out files: 100% (1787/1787), done. Switched to branch '8.5.x' Your branch is up to date with 'origin/8.5.x'. And then running again `git branch` will show the * next to 8.5.x: git branch 7.0.x * 8.5.x master In some projects it's easy to maintain a single repository and switch between branches, but I find the differences between 7.0.x and master to be so major that I chose to follow Mark's method and keep separate local copies where the IDE settings do not get mangled up each time I switch branches. Sounds good. What is Mark's Method™? Is it documented anywhere? Most git users, as well as myself until recently, use one repository and switch between branches as needed. You need to work on 7.0.x, you do `git checkout 7.0.x`, work on it, commit and push your changes, and then check out another branch to work on. The changes between 7.0.x and 8.5.x are so vast that switching between 7.0.x and the other two branches messed up my IDE, so what I refer to as Mark's Method™ is to have 3 local directories/repos (tomcat, tomcat-8.5.x, tomcat-7.0.x), one for each main branch. Each directory/repo stays on its own branch, and the branches are created . When I want to synchronize them, I do a push
Re: Finally getting around to switching to Git
Coty, On 4/25/2019 11:30 AM, Coty Sutherland wrote: On Thu, Apr 25, 2019 at 2:06 PM Igal Sapir wrote: On 4/25/2019 10:56 AM, Coty Sutherland wrote: On Thu, Apr 25, 2019 at 1:32 PM Christopher Schultz < ch...@christopherschultz.net> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Igal, On 4/23/19 12:52, Igal Sapir wrote: Another thing that I have changed in my workflow based on Mark's past suggestion, is that I keep a local repo for each major branch now. Okay, I have done the following: 1. Fork tomcat master to my own GitHub account 2. git clone URL 3. edit/add/commit/push 4. Create a PR I'm sure I can import the PR into tomcat-master. No problem. Now, when attempting to keep my fork current, I've always done something like: git remote add upstream master-url git checkout master git fetch upstream And I'm all up-to-date. When I did that, I ended up bringing-down the 7.0.x and 8.5.x branches as well. How can I limit the upstream to just the master? You can set the branch for your remote to master (or do it when you clone) which should ignore other branches: git remote set-branches upstream master Then optionally configure --no-tags in your git config (or use --no-tags each time you git-fetch): git config --add remote.upstream.tagOpt --no-tags Then try fetching to verify it worked: git fetch upstream [--dry-run] Or does my fork have to have everything, but I have to checkout a single branch? If so, I'm not sure how to do that. It doesn't, but by default a `git fetch` pulls down all new work that exists on the remote, but not your local clone. I am sure that Coty knows git better than I do, so if he says that it doesn't then I stand corrected. I don't know about that :) If you do a regular `git clone apache/tomcat` it will pull the master branch and then references/histories for all remote branches which for tomcat is about a 100M .git directory. If you clone a single branch with no references such as `git clone apache/tomcat -b master --single-branch` then you get just the references/history for the master branch which results in about a 70M .git directory. So one needs to consider whether that added layer of complexity is worth the savings of 30M disk space, even when multiplied over 3 branches. Imagine the reclaimed space after deleting the local SVN directories ;) I think that working with the https://github.com/apache/tomcat as the origin will make things much easier for Chris. Especially with keeping the local repo up to date with the origin since he wouldn't need to use his fork. Best, Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Finally getting around to switching to Git
On 4/25/2019 10:56 AM, Coty Sutherland wrote: On Thu, Apr 25, 2019 at 1:32 PM Christopher Schultz < ch...@christopherschultz.net> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Igal, On 4/23/19 12:52, Igal Sapir wrote: Another thing that I have changed in my workflow based on Mark's past suggestion, is that I keep a local repo for each major branch now. Okay, I have done the following: 1. Fork tomcat master to my own GitHub account 2. git clone URL 3. edit/add/commit/push 4. Create a PR I'm sure I can import the PR into tomcat-master. No problem. Now, when attempting to keep my fork current, I've always done something like: git remote add upstream master-url git checkout master git fetch upstream And I'm all up-to-date. When I did that, I ended up bringing-down the 7.0.x and 8.5.x branches as well. How can I limit the upstream to just the master? You can set the branch for your remote to master (or do it when you clone) which should ignore other branches: git remote set-branches upstream master Then optionally configure --no-tags in your git config (or use --no-tags each time you git-fetch): git config --add remote.upstream.tagOpt --no-tags Then try fetching to verify it worked: git fetch upstream [--dry-run] Or does my fork have to have everything, but I have to checkout a single branch? If so, I'm not sure how to do that. It doesn't, but by default a `git fetch` pulls down all new work that exists on the remote, but not your local clone. I am sure that Coty knows git better than I do, so if he says that it doesn't then I stand corrected. Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Finally getting around to switching to Git
Chris, On 4/25/2019 10:32 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Igal, On 4/23/19 12:52, Igal Sapir wrote: Another thing that I have changed in my workflow based on Mark's past suggestion, is that I keep a local repo for each major branch now. Okay, I have done the following: 1. Fork tomcat master to my own GitHub account Since you are a committer you don't need to this. That is useful though if you want to show a large update so that others can review it, but you can also do that in a new branch. 2. git clone URL 3. edit/add/commit/push 4. Create a PR I'm sure I can import the PR into tomcat-master. No problem. Now, when attempting to keep my fork current, I've always done something like: git remote add upstream master-url git checkout master git fetch upstream And I'm all up-to-date. When I did that, I ended up bringing-down the 7.0.x and 8.5.x branches as well. How can I limit the upstream to just the master? Or does my fork have to have everything, but I have to checkout a single branch? If so, I'm not sure how to do that. Your fork has the whole git repository, but fortunately git manages resources much better than Subversion, for example, so it's not too bad at all. You can see a list of the local branches and which branch you are currently on with the command, `git branch`, which will show something like this: > git branch 7.0.x 8.5.x * master The `*` denotes the current branch, so I am on the master branch. Switching to the 8.5.x branch with `git checkout 8.5.x` > git checkout 8.5.x Checking out files: 100% (1787/1787), done. Switched to branch '8.5.x' Your branch is up to date with 'origin/8.5.x'. And then running again `git branch` will show the * next to 8.5.x: > git branch 7.0.x * 8.5.x master In some projects it's easy to maintain a single repository and switch between branches, but I find the differences between 7.0.x and master to be so major that I chose to follow Mark's method and keep separate local copies where the IDE settings do not get mangled up each time I switch branches. I'm just *sure* I'm gonna love git once I get this all figured out. All the cool kids seem to love it, so it must be better, right? It is WAY better, and I'm not even cool (let alone a kid)! Best, Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Finally getting around to switching to Git
On 4/23/2019 8:48 AM, Martin Grigorov wrote: On Tue, Apr 23, 2019, 17:29 Christopher Schultz < ch...@christopherschultz.net> wrote: Setting up the account is needed. I failed to do it, and Mark told me I needed three green ticks there: https://gitbox.apache.org/setup/ Thanks. Looks like I'm not a part of the ASF-org on GitHub. Anyone with the Karma to do so, can I be added to ASF-org on GitHub? My GitHub username is ChristopherSchultz. Go to https://id.apache.org and enter your Github ID there. Right. You will also need to enable 2FA on GitHub (I am using the FreeOTP app which works well for me), and when pushing commits I was only able to use it with the https:// scheme and not with the git:// one. Another thing that I have changed in my workflow based on Mark's past suggestion, is that I keep a local repo for each major branch now. While in the past I would use a single local repo and just switch branches, I have found that it messes things up in the IDE etc. I therefore now keep 3 local directories, each set to a different major branch. It seemed contrary to most git workflows at first, but I find that switching between branches that have major changes in the development environment can get messy. Best, Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.19
I am getting a unit test failure: On Fri, Apr 12, 2019 at 7:48 AM Mark Thomas wrote: > The proposed Apache Tomcat 9.0.19 release is now available for voting. > 9.0.19 corrects a regression and a number of packaging errors in 9.0.18. > > The major changes compared to the 9.0.17 release are: > > - Fix for CVE-2019-0232 a RCE vulnerability on Windows > > - Add support for Java 11 to the JSP compiler. Java 12 and 13 are also > now supported if used with a ECJ version with support for those Java > versions > > - Various NIO2 stability improvements > > Along with lots of other bug fixes and improvements. > > For full details, see the changelog: > https://ci.apache.org/projects/tomcat/tomcat9/docs/changelog.html > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.19/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1210/ > The tag is: > https://github.com/apache/tomcat/tree/9.0.19 > 854f4dcf435a6d335576aa22402e2871c66f4fd9 > > The proposed 9.0.19 release is: > [ ] Broken - do not release > [ ] Stable - go ahead and release as 9.0.19 > > I am getting a failure on Ubuntu test cases, but not on Windows. That did not happen in 9.0.18. The failing test is org.apache.catalina.tribes.group.TestGroupChannelMemberArrival Full log below: Testsuite: org.apache.catalina.tribes.group.TestGroupChannelMemberArrival Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 8.079 sec - Standard Output --- 1555086368679 Listener-9:member added, has 1 members now. Member:[host: 127.0.1.1, port: 4004, id: 185.118.46.127.126.58.75.145.182.221.126.169.213.220.123.54, payload: Channel-3]; Thread:Membership-MemberAdded., hash:1258545020 1555086368679 Listener-6:member added, has 1 members now. Member:[host: 127.0.1.1, port: 4008, id: 47.37.31.85.54.172.66.150.184.132.56.120.49.5.38.228, payload: Channel-4]; Thread:Membership-MemberAdded., hash:1983451833 1555086368679 Listener-9:member added, has 2 members now. Member:[host: 127.0.1.1, port: 4008, id: 47.37.31.85.54.172.66.150.184.132.56.120.49.5.38.228, payload: Channel-4]; Thread:Membership-MemberAdded., hash:1258545020 1555086368679 Listener-8:member added, has 1 members now. Member:[host: 127.0.1.1, port: 4008, id: 47.37.31.85.54.172.66.150.184.132.56.120.49.5.38.228, payload: Channel-4]; Thread:Membership-MemberAdded., hash:588869387 1555086368679 Listener-2:member added, has 1 members now. Member:[host: 127.0.1.1, port: 4004, id: 185.118.46.127.126.58.75.145.182.221.126.169.213.220.123.54, payload: Channel-3]; Thread:Membership-MemberAdded., hash:1244130073 1555086368679 Listener-6:member added, has 2 members now. Member:[host: 127.0.1.1, port: 4004, id: 185.118.46.127.126.58.75.145.182.221.126.169.213.220.123.54, payload: Channel-3]; Thread:Membership-MemberAdded., hash:1983451833 1555086368679 Listener-8:member added, has 2 members now. Member:[host: 127.0.1.1, port: 4004, id: 185.118.46.127.126.58.75.145.182.221.126.169.213.220.123.54, payload: Channel-3]; Thread:Membership-MemberAdded., hash:588869387 1555086368679 Listener-2:member added, has 2 members now. Member:[host: 127.0.1.1, port: 4008, id: 47.37.31.85.54.172.66.150.184.132.56.120.49.5.38.228, payload: Channel-4]; Thread:Membership-MemberAdded., hash:1244130073 1555086368679 Listener-9:member added, has 3 members now. Member:[host: 127.0.1.1, port: 4007, id: 242.244.152.138.138.145.69.95.133.11.139.19.140.13.254.98, payload: Channel-7]; Thread:Membership-MemberAdded., hash:1258545020 1555086368679 Listener-8:member added, has 3 members now. Member:[host: 127.0.1.1, port: 4007, id: 242.244.152.138.138.145.69.95.133.11.139.19.140.13.254.98, payload: Channel-7]; Thread:Membership-MemberAdded., hash:588869387 1555086368679 Listener-6:member added, has 3 members now. Member:[host: 127.0.1.1, port: 4007, id: 242.244.152.138.138.145.69.95.133.11.139.19.140.13.254.98, payload: Channel-7]; Thread:Membership-MemberAdded., hash:1983451833 1555086368679 Listener-9:member added, has 4 members now. Member:[host: 127.0.1.1, port: 4005, id: 120.244.21.128.50.121.79.127.137.119.252.134.23.57.48.21, payload: Channel-2]; Thread:Membership-MemberAdded., hash:1258545020 1555086368679 Listener-2:member added, has 3 members now. Member:[host: 127.0.1.1, port: 4007, id: 242.244.152.138.138.145.69.95.133.11.139.19.140.13.254.98, payload: Channel-7]; Thread:Membership-MemberAdded., hash:1244130073 1555086368680 Listener-6:member added, has 4 members now. Member:[host: 127.0.1.1, port: 4005, id: 120.244.21.128.50.121.79.127.137.119.252.134.23.57.48.21, payload: Channel-2]; Thread:Membership-MemberAdded., hash:1983451833 1555086368679 Listener-8:member added, has 4 members now. Member:[host: 127.0.1.1, port: 4005, id: 120.244.21.128.50.121.79.127.137.119.252.134.23.57.48.21, payload: Channel-2]; Thread:Membership-MemberAdded., hash:588869387 1555086368680 Listener-2:member added, has 4 members now. Member:[host:
RE: [tomcat] branch master updated: Fixed false positives in unit tests on Windows
Mark, I just realized that you refactored my fix for the false positive unit test [1] a while ago. Unfortunately your refactoring still shows false positives if the path of the command prompt has a lower-cased driver letter, e.g. expected: but was: I pushed a different fix earlier, prior to noticing your refactoring (TBH I thought that I never pushed the fix in the first place), which does an equalsIgnoreCase() [2] The only unit tests where I experience this issue are TestAbstractArchiveResource.java and TestFileResource.java and the problem seems to be with the Driver Letter which appears in brackets, e.g. [E] vs. [e]. If you think that a full case-insensitive comparison is not right then I can modify only the drive letter if the pattern "jar:war:file:/[X]" is found. Any thoughts? Igal [1] https://github.com/apache/tomcat/commit/db71c925106915581f1b60b0fda9c352fcdd9138#diff-717001e0451788fe9f26d1176a4fff54 [2] https://github.com/apache/tomcat/commit/985d0086329c012a994c842f0a88a9b33989827c#diff-717001e0451788fe9f26d1176a4fff54R43 On Thu, Apr 11, 2019 at 11:28 AM wrote: > This is an automated email from the ASF dual-hosted git repository. > > isapir 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 985d008 Fixed false positives in unit tests on Windows > 985d008 is described below > > commit 985d0086329c012a994c842f0a88a9b33989827c > Author: Igal Sapir > AuthorDate: Thu Apr 11 08:45:22 2019 -0700 > > Fixed false positives in unit tests on Windows > > When the drive letter is lower cased in a Windows command prompt the > test cases were failing with > expected: but > was: > --- > .../org/apache/catalina/webresources/TestAbstractArchiveResource.java | 4 > ++-- > test/org/apache/catalina/webresources/TestFileResource.java | 2 > +- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git > a/test/org/apache/catalina/webresources/TestAbstractArchiveResource.java > b/test/org/apache/catalina/webresources/TestAbstractArchiveResource.java > index 9c59fd8..e573d91 100644 > --- > a/test/org/apache/catalina/webresources/TestAbstractArchiveResource.java > +++ > b/test/org/apache/catalina/webresources/TestAbstractArchiveResource.java > @@ -48,7 +48,7 @@ public class TestAbstractArchiveResource extends > TomcatBaseTest { > > expectedURL.append(docBase.getCanonicalFile().toURI().toURL().toString()); > > expectedURL.append("*/WEB-INF/lib/test.jar!/META-INF/resources/index.html"); > > -Assert.assertEquals(expectedURL.toString(), > webResource.getURL().toString()); > + > Assert.assertTrue(expectedURL.toString().equalsIgnoreCase(webResource.getURL().toString())); > } > > > @@ -71,7 +71,7 @@ public class TestAbstractArchiveResource extends > TomcatBaseTest { > > expectedURL.append(docBase.getCanonicalFile().toURI().toURL().toString()); > > expectedURL.append("WEB-INF/lib/test-lib.jar!/META-INF/tags/echo.tag"); > > -Assert.assertEquals(expectedURL.toString(), > webResource.getURL().toString()); > + > Assert.assertTrue(expectedURL.toString().equalsIgnoreCase(webResource.getURL().toString())); > } > > } > diff --git a/test/org/apache/catalina/webresources/TestFileResource.java > b/test/org/apache/catalina/webresources/TestFileResource.java > index 315212a..2bd7ef3 100644 > --- a/test/org/apache/catalina/webresources/TestFileResource.java > +++ b/test/org/apache/catalina/webresources/TestFileResource.java > @@ -40,6 +40,6 @@ public class TestFileResource extends TomcatBaseTest { > > // Build the expected location the same way the webapp base dir > is built > File f = new File("test/webapp/WEB-INF/classes"); > - > Assert.assertEquals(f.getCanonicalFile().toURI().toURL().toString(), > out.toString().trim()); > + > Assert.assertTrue(f.getCanonicalFile().toURI().toURL().toString().equalsIgnoreCase(out.toString().trim())); > } > } > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org >
Re: [VOTE] Release Apache Tomcat 8.5.40
On 4/10/2019 7:58 AM, Mark Thomas wrote: The proposed 8.5.40 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 8.5.40 Unit tests pass for NIO, NIO2, and APR on Windows 10 with Java 1.8u181 and TC-Native 1.2.21 and Ubuntu 18.04 with Java 1.8u202 and TC-Native 1.2.21 Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.18
On 4/10/2019 6:44 AM, Mark Thomas wrote: The proposed 9.0.18 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 9.0.18 Unit tests pass for NIO, NIO2, and APR on Ubuntu 18.04 with Java 1.8u202 and TC-Native 1.2.21 Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.94
On 4/10/2019 10:22 AM, Mark Thomas wrote: The proposed 7.0.94 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 7.0.94 Stable Unit tests pass for BIO, NIO, and APR on Ubuntu 18.04 with Java 1.6u45/1.7u80 and TC-Native-1.2.21 Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat Site Redesign
I have replied to Chris' email but will address here the rest of the points: On Mon, Mar 25, 2019 at 2:41 PM Konstantin Kolinko wrote: > Sorry that it takes so long, but I am rather overwhelmed nowadays, and > I need to set priorities... > Goes without saying and totally understandable. > > сб, 9 мар. 2019 г. в 00:15, Igal @ Lucee.org : > > > > All, > > > > On 3/7/2019 3:22 AM, Konstantin Kolinko wrote: > > > > > пн, 4 мар. 2019 г. в 09:02, Igal Sapir : > > >> I have uploaded the Tomcat site redesign to a temporary location for > review: > > >> http://people.apache.org/~isapir/mockups/tomcat-site/ > > > 1. Overall: Thank you for your effort, but I do not like it. At all. > > > > The effort to redesign the website was prompted by conversations with > > team members at TomcatCon in Montreal. > > OK, but what are the specific issues that were raised? > > (There is a rule at ASF is that "if it did not happen on a mailing > list, it did not happen". It means that offline discussions are OK, > but there needs to be some written summary.) > The only issue raised in the conversation was that the site has an older design and requires modernization. The rest was done here in the mailing list, though I could have made it clearer and mentioned that conversation. > > > Fair enough, but I wish you had expressed that two months ago when we > were > > going over the layout: > > https://www.mail-archive.com/dev@tomcat.apache.org/msg130453.html > > > > [,,,] > > > > I had to work with the constraints of ASF guidelines. There is a longer > > discussion about this in the thread mentioned above. > > Is there an ASF Guidelines document? > > (Maybe you have a link? There might be such document, but I do not > remember seeing it. I though that the previous thread had a link, but > I have not found such link there. A whimsy tool was mentioned, but the > tool checks for required contents. It is not about style guidelines. > What am I missing?) > https://whimsy.apache.org/site/ > It's not about the style per-se, but the fact that the required elements should be prominent, e.g. the ASF logo should be at the top, etc. I am only aware of what was mentioned in the other thread with the whimsy tool that you cited. > > If there is consensus in the team for keeping the layout with a vertical > > menu on the left then I can redesign that. > > I guess the same design will be later used for the Tomcat > Documentation web application, > http://tomcat.apache.org/tomcat-9.0-doc/index.html > > My main concern is that the documentation is printable and is easy to > use as a reference document. > > 1) Not being able to print is a show-stopper. (Really.) Anything else > is just a personal preference. > Agreed, and can be fixed as discussed in Chris' reply. > > 2) Left-side menu allows to navigate to a needed page with a single > click. I really like this feature of this menu. > > > It utilizes the Bootstrap 4 framework and is very trendy. > > One announcement that made a big impression for me in year 2018 was this > one: > https://twitter.com/mislav/status/1022058279000842240 > "We’re finally finished removing jQuery from http://GitHub.com frontend" > [...] > > Regarding concerns raised in a subsequent thread on this topic > "Tomcat Website Redesign" thread > https://www.mail-archive.com/dev@tomcat.apache.org/msg132281.html > > > a) Do nothing, i.e. keep the website as-is [1] for now > > > > [...] > > IMO option (a) is not good because the site is very outdated and not > mobile friendly. Many users nowadays view sites on their phones and/or > > tablets, which a modern design can address. > > The current site was redesigned several years ago. (See the log > history of "/xdocs/stylesheets/tomcat-site.xsl" file) I think it > should be mobile-friendly. > > What are the specific issues? > I made the navbar mobile-friendly but tables, images, font sizes, etc. are still not. It is also harder to make further improvements on top of the old design. Modernizing the site will allow for future improvements. I believe that the rest of the items on this email were addressed in Chris' reply and my reply to it. Best, Igal
Re: Tomcat Site Redesign
On Tue, Mar 26, 2019 at 6:12 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Konstantin, > > On 3/25/19 17:41, Konstantin Kolinko wrote: > > My main concern is that the documentation is printable and is easy > > to use as a reference document. > > > > 1) Not being able to print is a show-stopper. (Really.) Anything > > else is just a personal preference. > > @media print { > ... > } > > Ought to be able to handle any changes required for print media. The > menus never have to print. Never. Because they will never be navigable > on paper. So they can just be removed. Horizontal, vertical, 3D, > zooming, it doesn't matter. Just remove them when then are printed and > it's not an issue. > > The main body of the content is still a wall of text from top to > bottom. That should render just fine on a printer on in PDF. > Right. We can fix the printing and it can be rendered differently from the screen as Chris pointed out, so that's definitely fixable. I absolutely agree that Print is an important function. > > > 2) Left-side menu allows to navigate to a needed page with a > > single click. I really like this feature of this menu. > > Unless you scroll too far down the page. I've always been irritated > about this "feature" of the Tomcat documentation. Once you scroll away > from the menu, it's no longer "one click away". So if it could "stick" > to the top of the window (horizontal) or never scroll completely off > the top of the page, that would be a nice improvement. > The current proposal has a sticky navbar at the top so that is already implemented, unless I misunderstood something. > > >> It utilizes the Bootstrap 4 framework and is very trendy. > > > > One announcement that made a big impression for me in year 2018 was > > this one: https://twitter.com/mislav/status/1022058279000842240 > > "We’re finally finished removing jQuery from http://GitHub.com > > frontend" [...] > > IMO we should avoid javascript at all costs. Almost everything worth > doing can currently be done with CSS. > > Bootstrap can use jQuery, but it doesn't have to. > We can replace jQuery with newer JavaScript constructs as browsers nowadays conform to standards much better than they did a decade ago. jQuery simply makes it easier to develop. I'm not sure that we want to avoid JS altogether though. For example, the font-size widget that I added relies on JS. The current site also has some JS code. > > > Regarding concerns raised in a subsequent thread on this topic > > "Tomcat Website Redesign" thread > > https://www.mail-archive.com/dev@tomcat.apache.org/msg132281.html > > > >> a) Do nothing, i.e. keep the website as-is [1] for now > >> > >> [...] IMO option (a) is not good because the site is very > >> outdated and not mobile friendly. Many users nowadays view sites > >> on their phones and/or tablets, which a modern design can > >> address. > > > > The current site was redesigned several years ago. (See the log > > history of "/xdocs/stylesheets/tomcat-site.xsl" file) I think it > > should be mobile-friendly. > > > > What are the specific issues? > > > > Is it possible to make changes in small incremental reversible > > steps? > > IMO, this *was* fairly incremental. > IMO as well. The first update was done a while ago when I made the navbar on the left "responsive" for the current site. We can continue the incremental way only if stick to a vertical navbar. The horizontal navbar requires too many changes to the structure of the HTML. The problem with going the incremental way, though, is that it continues as a patch work so it creates inefficient spaghetti code which is much harder to refactor since we don't have the tooling that Java provides, for example. Igal
Re: Is it possible to modify the commit email template?
On Fri, Mar 22, 2019 at 10:07 AM Mark Thomas wrote: > You'll need to talk to infra. If you provide a patch I suspect it would > be accepted gratefully. > Awesome! Very efficient process, and they are very responsive on Slack. This [1] should be available in the next notification email. Thanks, Igal [1] https://github.com/apache/infrastructure-puppet/pull/1489/files https://ci.apache.org/builders/infrastructure-puppet-deployment/builds/4228 > > Mark > > > On 22/03/2019 16:40, Igal Sapir wrote: > > Is it possible to add a URL to the commit email templates so that it's > > easier to see the diff? > > > > For example, the email titled "[tomcat] branch 7.0.x updated: Generics: > > BasicDataSource" has a commit hash of 153757518621f906d3a223836b8d80 > > > > If we could prefix it as below it can become a link to a colorful diff > > which is much easier to read than the one in the email: > > > > > https://gitbox.apache.org/repos/asf?p=tomcat.git;a=commitdiff;h=153757518621f906d3a223836b8d80 > > > > Thanks, > > > > Igal > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Test Case Ciphers (was: Release Apache Tomcat 8.5.38)
Emmanuel, On Tue, Feb 5, 2019 at 11:45 AM Igal Sapir wrote: > On Tue, Feb 5, 2019 at 11:12 AM Emmanuel Bourg wrote: > >> Le 05/02/2019 à 19:02, Igal Sapir a écrit : >> >> > Do you get any "missing ciphers" errors or not even that? I always get >> > some test cases fail due to mismatching ciphers, which I accept as false >> > positives, so I wonder about that. >> >> Yes that's normal, some ciphers are disabled in Debian (IDEA and ARIA). >> There is a patch adjusting the tests accordingly: >> >> >> https://salsa.debian.org/java-team/tomcat8/blob/master/debian/patches/0021-dont-test-unsupported-ciphers.patch >> >> Emmanuel Bourg >> > > I see. That makes sense, thanks. > > What do you guys think if I add a system property like > `test.unimplementedciphers` with an empty default, which can be used, e.g.: > > test.unimplementedciphers=ARIA,IDEA > > Then any cipher that has in its name the substring ARIA or IDEA will be > skipped? > Please see https://github.com/apache/tomcat/commit/a9c1a0661198d9ba37c1facd8385fe05d538c4ad based on your input. Best, Igal
Is it possible to modify the commit email template?
Is it possible to add a URL to the commit email templates so that it's easier to see the diff? For example, the email titled "[tomcat] branch 7.0.x updated: Generics: BasicDataSource" has a commit hash of 153757518621f906d3a223836b8d80 If we could prefix it as below it can become a link to a colorful diff which is much easier to read than the one in the email: https://gitbox.apache.org/repos/asf?p=tomcat.git;a=commitdiff;h=153757518621f906d3a223836b8d80 Thanks, Igal
Re: Tomcat Website Redesign
On 3/20/2019 10:49 AM, Mark Thomas wrote: On 20/03/2019 16:01, Igal Sapir wrote: The way I see it we have the following options ATM: a) Do nothing, i.e. keep the website as-is [1] for now b) I can address the issues that were brought up and fix them for the current proposed design [2] c) I can propose a new design with a vertical menu bar instead of a horizontal one d) Someone else can propose a design and I will implement it with HTML5/CSS/JavaScript e) Someone else can do the whole thing IMO option (a) is not good because the site is very outdated and not mobile friendly. Many users nowadays view sites on their phones and/or tablets, which a modern design can address. I'd be happy to hear your thoughts. As you are the one doing the work I'll support whichever option you prefer (although I'll note I'm not a big fan of option a) Thanks, Mark! I personally prefer option b which will also be the fastest to complete at this point, but I know that Konstantin and IIRC Rémy didn't like the horizontal navbar so I proposed the other options. Igal Mark Best, Igal [1] http://tomcat.apache.org/ [2] http://people.apache.org/~isapir/mockups/tomcat-site/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Tomcat Website Redesign
Hi all, As you probably know I have been working on a redesign of the Tomcat website but it's a bit of a challenge to come up with a design that everyone likes. The way I see it we have the following options ATM: a) Do nothing, i.e. keep the website as-is [1] for now b) I can address the issues that were brought up and fix them for the current proposed design [2] c) I can propose a new design with a vertical menu bar instead of a horizontal one d) Someone else can propose a design and I will implement it with HTML5/CSS/JavaScript e) Someone else can do the whole thing IMO option (a) is not good because the site is very outdated and not mobile friendly. Many users nowadays view sites on their phones and/or tablets, which a modern design can address. I'd be happy to hear your thoughts. Best, Igal [1] http://tomcat.apache.org/ [2] http://people.apache.org/~isapir/mockups/tomcat-site/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 7, DBCP 1.x and generics
On 3/19/2019 6:34 AM, Mark Thomas wrote: On 19/03/2019 04:04, Igal Sapir wrote: On 3/18/2019 1:28 PM, Mark Thomas wrote: All, I started to work on cleaning up the DBCP generics warnings in 7.0.x before I remembered what "fun" it was when I did this for DBCP2. While some of it is straight-forward, some of it requires some refactoring. From memory, the refactoring did fix a few bugs along the way. Given that the changes aren't trivial, I wanted to get some feedback from the community as to the best approach here. Options include: a) No nothing b) Fix the trivial generics c) Fix all the generics including any necessary refactoring I actually enjoy refactoring code so I'd be happy to help with (b) or (c) if either is chosen. Thanks. I'll leave the thread open for a few days to see what folks think. I have a lot of the trivial fixes sat in a local branch so it will be the 'fun' ones that will need to be completed. Sounds good. Working on tasks like that will make me more familiar with the source code and prepare me for tackling bigger issues in the future, so it can be beneficial beyond just completing the tasks. Best, Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 7, DBCP 1.x and generics
On 3/18/2019 1:28 PM, Mark Thomas wrote: All, I started to work on cleaning up the DBCP generics warnings in 7.0.x before I remembered what "fun" it was when I did this for DBCP2. While some of it is straight-forward, some of it requires some refactoring. From memory, the refactoring did fix a few bugs along the way. Given that the changes aren't trivial, I wanted to get some feedback from the community as to the best approach here. Options include: a) No nothing b) Fix the trivial generics c) Fix all the generics including any necessary refactoring I actually enjoy refactoring code so I'd be happy to help with (b) or (c) if either is chosen. Best, Igal d) Something else Thoughts? mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Default Number of Test Threads
Chris, On Sat, Mar 16, 2019 at 8:22 AM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Igal, > > On 3/15/19 22:38, Igal Sapir wrote: > > Chris, > > > > On Fri, Mar 15, 2019 at 4:56 PM Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 > >> > >> Igal, > >> > >> On 3/15/19 16:45, Igal Sapir wrote: > >>> I looked deeper into build.xml and I found some > >>> interesting information and a simple solution for my issue. In > >>> build.xml we have the following: > >>> > >>> >>> file="build.properties"/> >>> file="build.properties.default"/> > >>> > >>> So I can place my settings for test.threads in > >>> ~/build.properties. > >>> > >>> The current order of precedence, however, gives > >>> ${user.home}/build.properties a higher priority than the one > >>> at {tomcat}/build.properties. > >>> > >>> That is wrong IMHO and should be the other way around, i.e. > >>> {tomcat}/build.properties should > >>> override${user.home}/build.properties . I would like to > >>> change that order if everyone agrees. > >> > >> I do not agree. The local configuration (~/build.properties) > >> should override the default configuration (build.properties). > >> That's why it's called "local configuration". > >> > >> Besides, if you implement your proposed switch, then you will be > >> UNABLE to use ~/build.properties to customize this configuration > >> that you don't like. > >> > > > > Perhaps I'm missing something, but I think that the term "Local" > > is ambiguous here, so I will avoid using it to prevent confusion. > > We have (applied in order): > > > > 1) Project Default Config.: {tomcat}/build.properties.default 2) > > Instance Config: {tomcat}/build.properties 3) System > > Config..: {user.home}/build.properties > > > > Tomcat only ships with the Project Default Config file. The other > > two are optional and can be created by the user. > > > > Suppose that I usually want to run tests with 8 threads. I can > > set `test.threads=8` in the System Config file and each time I > > download a new version of Tomcat I simply run `ant test` in the > > directory of that instance. It will run with 8 threads, resolving > > my original issue here. > > > > But, if now I download a version and want to run only that one with > > 4 threads (a more likely scenario would be to set different > > versions or paths for OpenSSL), I can not simply set the new value > > for the Instance Configuration, {tomcat}/build.properties, to > > affect only that instance -- I have to modify the System Config, > > which will change the settings for all other instances. > > > > The way I see it, the System Config is Default for the system, and > > each instance should be able to specify its own Instance > > Configuration which will override both the Project's Defaults and > > the System Defaults. My proposal is therefore that the order of > > applying the settings will be: > > > > 1) Project Default Config.: {tomcat}/build.properties.default 2) > > System Config..: {user.home}/build.properties 3) Instance > > Config: {tomcat}/build.properties > > > > That way I do not need to add an Instance Config anywhere unless a > > specific instance requires unique settings. I can set my System > > Config (~/build.properties) with the values that I normally use, > > and only override them with an Instance Config, i.e. > > {tomcat}/build.properties where needed. > > > > What am I missing? > > Just remember that ant properties are write-once, so all your orders > above are backward. If you want the instance config to override all > others, you'll have to load it first. > You are right. I tried to simplify my example with pseudo-config that has a "last value wins", but that probably caused more confusion, so I'll try to avoid that in the future. > > Nobody is going to agree on this, so maybe: > > {tomcat}/build.first.properties > {user.home}/build.properties (which is a really weird default, IMO) > {tomcat}/build.properties > {tomcat}/build.default.properties > > This preserves the current behavior in all environments and allows you > to have your new ty
Re: Default Number of Test Threads
Chris, On Fri, Mar 15, 2019 at 4:56 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Igal, > > On 3/15/19 16:45, Igal Sapir wrote: > > > > I looked deeper into build.xml and I found some interesting > > information and a simple solution for my issue. In build.xml we > > have the following: > > > > > file="build.properties"/> > file="build.properties.default"/> > > > > So I can place my settings for test.threads in ~/build.properties. > > > > The current order of precedence, however, gives > > ${user.home}/build.properties a higher priority than the one at > > {tomcat}/build.properties. > > > > That is wrong IMHO and should be the other way around, i.e. > > {tomcat}/build.properties should > > override${user.home}/build.properties . I would like to change > > that order if everyone agrees. > > I do not agree. The local configuration (~/build.properties) should > override the default configuration (build.properties). That's why it's > called "local configuration". > > Besides, if you implement your proposed switch, then you will be > UNABLE to use ~/build.properties to customize this configuration that > you don't like. > Perhaps I'm missing something, but I think that the term "Local" is ambiguous here, so I will avoid using it to prevent confusion. We have (applied in order): 1) Project Default Config.: {tomcat}/build.properties.default 2) Instance Config: {tomcat}/build.properties 3) System Config..: {user.home}/build.properties Tomcat only ships with the Project Default Config file. The other two are optional and can be created by the user. Suppose that I usually want to run tests with 8 threads. I can set `test.threads=8` in the System Config file and each time I download a new version of Tomcat I simply run `ant test` in the directory of that instance. It will run with 8 threads, resolving my original issue here. But, if now I download a version and want to run only that one with 4 threads (a more likely scenario would be to set different versions or paths for OpenSSL), I can not simply set the new value for the Instance Configuration, {tomcat}/build.properties, to affect only that instance -- I have to modify the System Config, which will change the settings for all other instances. The way I see it, the System Config is Default for the system, and each instance should be able to specify its own Instance Configuration which will override both the Project's Defaults and the System Defaults. My proposal is therefore that the order of applying the settings will be: 1) Project Default Config.: {tomcat}/build.properties.default 2) System Config..: {user.home}/build.properties 3) Instance Config: {tomcat}/build.properties That way I do not need to add an Instance Config anywhere unless a specific instance requires unique settings. I can set my System Config (~/build.properties) with the values that I normally use, and only override them with an Instance Config, i.e. {tomcat}/build.properties where needed. What am I missing? Thanks, Igal
Re: Default Number of Test Threads
Chris, On Fri, Mar 15, 2019 at 4:53 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > > > I think you are on Windows (?),. but maybe you could use this script: > > https://github.com/ChristopherSchultz/apache-tomcat-stuff/tree/master/bi > n > > (look for test-tomcat-release.sh) > > That script builds a custom build.properties and then runs everything. > It could trivially add a threads setting to build.properties. > Thanks! I use both Windows and Linux, but I can see some gems in that script that I can adopt. Best, Igal
Re: Wiki migration
On 3/15/2019 11:32 AM, Mark Thomas wrote: There also exists the following project, http://jspwiki.apache.org/ if we talk about "our own dog food". Infra has chosen Confluence. If we want to run jspwiki on our own VM that is an option but it needs *long term* volunteers to maintain the VM. Experience elsewhere in the ASF is that that usually doesn't work. I'm neither for nor against this option, but I am looking for ways to contribute more so if we go that route I'd be happy to volunteer for that ongoing task. Best, Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: buildbot failure in on tomcat-trunk
Is there a known issue with BuildBot? [concat] Testsuites with failed tests: [concat] TEST-org.apache.catalina.tribes.group.TestGroupChannelSenderConnections.NIO.txt I don't believe that my commit, adding an ant target [1], is related. 8.5 also failed, but with another unit test: [concat] Testsuites with failed tests: [concat] TEST-org.apache.catalina.connector.TestCoyoteOutputStream.NIO2.txt Thanks, Igal [1] https://github.com/apache/tomcat/commit/8a2f41bed80a On 3/15/2019 2:01 PM, build...@apache.org wrote: The Buildbot has detected a new failure on builder tomcat-trunk while building tomcat. Full details are available at: https://ci.apache.org/builders/tomcat-trunk/builds/4143 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: silvanus_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' triggered this build Build Source Stamp: [branch master] 8a2f41bed80a96bd6d711594ea8b6b7f0f1451da Blamelist: Igal Sapir BUILD FAILED: failed compile_1 Sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Default Number of Test Threads
On Fri, Mar 15, 2019 at 9:45 AM Konstantin Kolinko wrote: > чт, 14 мар. 2019 г. в 22:26, Igal Sapir : > > What is the use case? People verifying a release? CI servers that may > have different hardware? > The idea was more for testing new releases. On my laptop setting test.threads to 8 completes in about 10 minutes, while the default 1 thread takes more than 1 hour. I looked deeper into build.xml and I found some interesting information and a simple solution for my issue. In build.xml we have the following: So I can place my settings for test.threads in ~/build.properties. The current order of precedence, however, gives ${user.home}/build.properties a higher priority than the one at {tomcat}/build.properties. That is wrong IMHO and should be the other way around, i.e. {tomcat}/build.properties should override${user.home}/build.properties . I would like to change that order if everyone agrees. I added an ant target, echoproperties [1], which outputs the merged properties so it's easy to see the final values. Best, Igal [1] https://github.com/apache/tomcat/commit/8a2f41bed80a
Re: [VOTE] Release Apache Tomcat 8.5.39
On 3/14/2019 6:43 AM, Mark Thomas wrote: The proposed Apache Tomcat 8.5.39 release is now available for voting. The proposed 8.5.39 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 8.5.39 Tested on Windows 10 and Ubuntu 18.04 Best, Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Default Number of Test Threads
On 3/14/2019 12:51 PM, Mark Thomas wrote: On 14/03/2019 19:26, Igal Sapir wrote: Does test.threads default to 1 for a reason? Mostly historical. The tests weren't originally designed to run in parallel. If there is no objection, I would like to set the default to the number of available CPU Threads. It looks like that can be done with a custom Ant task which should be fairly simple to implement. I over-ride it locally so I'm not going to be directly affected. A custom Ant task seems a little over-engineered compared to setting a property in build.properties. I override it in build.properties as well, but I find myself doing it each time I download the sources for testing a tagged version, or at least copy the file from one version to another. If you're doing it in your dev directory and simply added "build.properties" to .gitignore then you are not affected by this. I do wonder about CI systems. It is potentially a big change that might take someone by surprise. We'll need to update some buildbot configuration for example. I have visions of a CI system with lots of cores running lots of builds in parallel suddenly grinding to a halt because a Tomcat build suddenly tries to use every CPU. But I don't know now likely that is. I doubt that CI systems are that fragile/vulnerable. AFAIK they launch a new VM to ensure isolation and a clean environment, or else they would fall apart any time someone pushes a build without considering the CI environment. I guess I'm -0. If it's just me then I can add a custom ENV variable to my profile, e.g. $ export ANT_OPTS=-Dtest.threads=8 but I thought that others are annoyed by this as well. Best, Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Default Number of Test Threads
Does test.threads default to 1 for a reason? If there is no objection, I would like to set the default to the number of available CPU Threads. It looks like that can be done with a custom Ant task which should be fairly simple to implement. Best, Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.17
On 3/13/2019 11:23 AM, Mark Thomas wrote: The proposed Apache Tomcat 9.0.17 release is now available for voting. The proposed 9.0.17 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 9.0.17 Tested on Ubuntu 18.04 and Windows 10 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: GitHub notifications show Mark Thomas as Sender
Oh wait, unless that action was made by Mark. I saw a few messages in a row and misunderstood. Please ignore the previous email. On Fri, Mar 8, 2019 at 12:58 PM Igal Sapir wrote: > I got some GitHub notifications and they have the following header: > > From: Mark Thomas > > If someone with permissions can change that please. > > Best, > > Igal > >
GitHub notifications show Mark Thomas as Sender
I got some GitHub notifications and they have the following header: From: Mark Thomas If someone with permissions can change that please. Best, Igal
Re: Tomcat Site Redesign
I made the text darker (#333) and pulled the date to the right as on the current site. On Thu, Mar 7, 2019 at 9:50 AM Igal Sapir wrote: > Konstantin, > > Thank you for your feedback: > > On Thu, Mar 7, 2019 at 3:29 AM Konstantin Kolinko > wrote: > >> пн, 4 мар. 2019 г. в 09:02, Igal Sapir : >> > >> > I have uploaded the Tomcat site redesign to a temporary location for >> review: >> > http://people.apache.org/~isapir/mockups/tomcat-site/ >> >> 1. Overall: Thank you for your effort, but I do not like it. At all. >> > > Fair enough, but I wish you had expressed that two months ago when we were > going over the layout: > https://www.mail-archive.com/dev@tomcat.apache.org/msg130453.html > > >> >> 2. Impressions: >> >> 1) The text is not as readable as the existing site. >> It is hard to read it because of color. It blurs with background. >> > > The color can be easily changed. It is common to use a dark gray color > rather than black though as it's easier on the eyes and considered more > readable. There was a discussion about the font size, which prompted me to > add a slider at the bottom that allows you to change the font size. > > >> >> 2) Advertisement steals important part of the page. >> Nobody likes advertisements, you know? Especially when it is thrown in >> one's face. >> >> Who are our clients? Why people come to the site and what do they expect >> to see? >> Newspapers like to throw ads like that and hide the real text, but >> they make money from that and people tolerate them (to a certain >> degree). >> > > The ad for ApacheCon is merely a placeholder to show how we can place > prominent news on the side on larger screens, and collapse it above the > body on smaller screens, i.e. phones. I'm not sure on what screen you saw > that. > > It was added per Mark's feedback. > > It can be moved or removed. > > >> >> 3) I do not like menu at the top. Those were popular some time ago, >> but I think that is a diminishing trend. >> >> (What is a concept behind such design element? It is not a material >> element, not something from real world. How do people operate with >> it?) >> > > This is a mobile-first responsive layout that changes according to your > screen size. If you tell me what size screen you saw it on then I would > understand better what you mean. > > It utilizes the Bootstrap 4 framework and is very trendy. > > Again, I wish you had expressed that 2 months ago. > > >> >> It does not make sense that the menu is flying at top when I scroll. >> This menu occupies precious space on the screen. A page title flying >> like that makes more sense. >> > > It doesn't have to be "sticky". That can be changed easily. > > >> >> 4) The "Apache Tomcat" in menu line is too prominent in font and >> color. It steals attention from the real page title and hurts eyes. >> > > Fonts and colors can be changed. > > I had to work with the constraints of ASF guidelines. There is a longer > discussion about this in the thread mentioned above. > > >> >> 3. Technically: >> 1) Printing =?. >> >> It is not printer-friendly! >> Browser -> Print preview. >> I see that it does not fit a paper page. >> > > That can be fixed > > >> >> 2) Accessibility =?. >> (Tab key navigation with keyboard. Accessing menus. Accessing links). >> >> Keyboard. How does one operate that menu with a keyboard? >> > > Keyboard shortcuts can be added > > >> >> Mouse. Why do I need two clicks to open anything through that menu? >> > > I can make the menu open on hover, but please keep in mind that not every > device has a "hover" capability. For example on mobile devices you don't > have that. > > >> >> 3) Titles and dates. >> >> "2019-02-21 Tomcat 7.0.93 Released" >> >> The dates should not be spelled like that if they are part of a >> sentence. How do you read that sentence aloud (in English)? >> >> (Actually, the dates should not be in the sentence. They are a >> separate auxiliary piece of information). >> > > That is part of the body of the pages and was not modified. It has been > like that on the Tomcat website for a long time now. > > >> >> 4) Search field (in menu bar): >> >> It is too small for any real text. >> > > The search field can expand wider, but on tablets and phones we are > limited in space. > > Thank you, > > Igal > >
Re: Tomcat Site Redesign
Konstantin, Thank you for your feedback: On Thu, Mar 7, 2019 at 3:29 AM Konstantin Kolinko wrote: > пн, 4 мар. 2019 г. в 09:02, Igal Sapir : > > > > I have uploaded the Tomcat site redesign to a temporary location for > review: > > http://people.apache.org/~isapir/mockups/tomcat-site/ > > 1. Overall: Thank you for your effort, but I do not like it. At all. > Fair enough, but I wish you had expressed that two months ago when we were going over the layout: https://www.mail-archive.com/dev@tomcat.apache.org/msg130453.html > > 2. Impressions: > > 1) The text is not as readable as the existing site. > It is hard to read it because of color. It blurs with background. > The color can be easily changed. It is common to use a dark gray color rather than black though as it's easier on the eyes and considered more readable. There was a discussion about the font size, which prompted me to add a slider at the bottom that allows you to change the font size. > > 2) Advertisement steals important part of the page. > Nobody likes advertisements, you know? Especially when it is thrown in > one's face. > > Who are our clients? Why people come to the site and what do they expect > to see? > Newspapers like to throw ads like that and hide the real text, but > they make money from that and people tolerate them (to a certain > degree). > The ad for ApacheCon is merely a placeholder to show how we can place prominent news on the side on larger screens, and collapse it above the body on smaller screens, i.e. phones. I'm not sure on what screen you saw that. It was added per Mark's feedback. It can be moved or removed. > > 3) I do not like menu at the top. Those were popular some time ago, > but I think that is a diminishing trend. > > (What is a concept behind such design element? It is not a material > element, not something from real world. How do people operate with > it?) > This is a mobile-first responsive layout that changes according to your screen size. If you tell me what size screen you saw it on then I would understand better what you mean. It utilizes the Bootstrap 4 framework and is very trendy. Again, I wish you had expressed that 2 months ago. > > It does not make sense that the menu is flying at top when I scroll. > This menu occupies precious space on the screen. A page title flying > like that makes more sense. > It doesn't have to be "sticky". That can be changed easily. > > 4) The "Apache Tomcat" in menu line is too prominent in font and > color. It steals attention from the real page title and hurts eyes. > Fonts and colors can be changed. I had to work with the constraints of ASF guidelines. There is a longer discussion about this in the thread mentioned above. > > 3. Technically: > 1) Printing =?. > > It is not printer-friendly! > Browser -> Print preview. > I see that it does not fit a paper page. > That can be fixed > > 2) Accessibility =?. > (Tab key navigation with keyboard. Accessing menus. Accessing links). > > Keyboard. How does one operate that menu with a keyboard? > Keyboard shortcuts can be added > > Mouse. Why do I need two clicks to open anything through that menu? > I can make the menu open on hover, but please keep in mind that not every device has a "hover" capability. For example on mobile devices you don't have that. > > 3) Titles and dates. > > "2019-02-21 Tomcat 7.0.93 Released" > > The dates should not be spelled like that if they are part of a > sentence. How do you read that sentence aloud (in English)? > > (Actually, the dates should not be in the sentence. They are a > separate auxiliary piece of information). > That is part of the body of the pages and was not modified. It has been like that on the Tomcat website for a long time now. > > 4) Search field (in menu bar): > > It is too small for any real text. > The search field can expand wider, but on tablets and phones we are limited in space. Thank you, Igal
Re: Tomcat Site Redesign
Chris, Thank you for the feedback: On Tue, Mar 5, 2019 at 11:49 AM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Igal, > > On 3/4/19 01:02, Igal Sapir wrote: > > I have uploaded the Tomcat site redesign to a temporary location > > for review: http://people.apache.org/~isapir/mockups/tomcat-site/ > > > > The source can be seen at https://github.com/isapir/tomcat-website > > > > This includes all of the pages for the website, but not the > > documentation for the different versions, connector, native, > > webapps, etc. as of yet. > > > > There are three things that I would like to discuss: > > > > 1) Feedback, especially if anything is broken or doesn't look > > right. > > If we have "Download | Changelog for x.y.z" for tcnative, we should > have it for Tomcat itself. The links are indeed there... they are just > buried in the text above the "Download" link. Let's be consistent if > possible. > +1 for consistency. I did not change the text of the pages, only the layout and L For example, the tables are now styled differently if you look at the Which Version page of the old and new site, and I've added a couple of icons e.g. Download and Bug. We can easily change the text later but I rather my commits be focused on the layout only (as much as possible). > > > 2) I can concatenate some resource files etc., but it would be much > > better> to switch to HTTP/2. > > Why, exactly? Scripting the forced-download of a few dependent > resources is more work than ... not doing that. > I'm not talking about Push, but simply HTTP/2 so that the resources can be downloaded over one connection via multiplexing. I actually made a video about this a few months ago [1]. It is a one time server configuration - no scripting needed. All of the major web servers, including httpd [2], support it. I just checked and even the main apache.org site is using http/1.1. I'm surprised that the Apache websites are not configured already for http/2. > > > 3) We should create a repo for the site, e.g. tomcat-site or > > tomcat-website. > > Do you mean in git? There is already a repo for the site in Subversion: > https://svn.apache.org/repos/asf/tomcat/site/trunk > > Yes, I mean in git. We discussed it last week in another thread. Best, Igal [1] https://youtu.be/jhqrRT4fvOA?t=61 [2] https://httpd.apache.org/docs/2.4/howto/http2.html > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlx+0tYACgkQHPApP6U8 > pFiTIQ/+Ly/+GhpBkPV61w7SdvFXxv8YCPofueEle6d3djYuQ7tSZGIaIVPopPux > XqmWxGF017EviNXVG0C67sKnqbqQEG9F3b20s4hBQc0HR9m9w8682dZRgzSpd7d3 > s2vJlYr/OQou5wEbA+ma4npLKSSHFVl8Skvk0pNCTpPfxL76rpKLbSRuwirel7zA > op3h80vVrODQgofZ2PaIWQKPEKxt4Re5Yk8/oqGZJ/z7YpNQr2511LPxE528ULPE > Lz0C9atD7hOByTTzf8L+UfZbIfIkh6uBidmRq25DYvXoMJ+c/uFYYvhsi9e22ztI > 70DjXKSRTp2E0STFFICsiN1BAhOYoXQ2WXv+xLpoBJ0klyRhpRCduvVuS6JhHecy > M2/s2D7k4lJjsZMtkp76nrXaYwEWj/s2xRMJ816WuDYWWzJ4mIW8rdpNoYHhvrB4 > Uc8ym6QI29IgLJXGsymv8FWFVsxzXgHVus3YilVX05lEDAi/KdX3CqNi3QhmzrOm > FWU+EOcn/CBS3EkDT5FVJCM6LZi5fLWtX/dOFqUEoRCo7tnADPFPS8NTRum6sa9T > K7rOXrmIMNiImRUaOVH7/R+5GJ69DEm2+aPj+AGVX0r6aX8IgfVCfFWaN2Faw/TQ > TfhRijPNtbT6WKjJWdARSRpLbSqZSTmN27wl4cERnGsLH9Z4xq4= > =nzbr > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Git Migration: What is the svn:eol-style equilvalent?
Coty, On Tue, Mar 5, 2019 at 6:23 AM Coty Sutherland wrote: > Hi, > > I updated the BUILDING and CONTRIBUTING documents so that GitHub users no > longer see instructions for SVN after our migration, however I had a few > questions. Does anyone know of a git equivalent to svn:eol-style that we > should be using? It is mentioned in the "git-svn quirks" section of > https://wiki.apache.org/general/GitAtApache, but before trying it I wanted > to get some feedback from everyone. > Do we use CRLF anywhere or do we always use LF everywhere and only adding the CRLF when archiving as .zip? If we do use CRLF anywhere, can there be a mixture of LF and CRLF in the same file? (I expect not) What about .bat files? I would expect those to always have CRLF, no? Git has a config file called .gitattributes [1] which allows to set the ending according to the file type (pattern), e.g. *.battext eol=crlf Another option to consider is core.eol [2]. Thanks, Igal [1] https://git-scm.com/docs/gitattributes [2] https://git-scm.com/docs/git-config#git-config-coreeol > > Secondly, the SVN references in MERGE.txt should be cleaned up at this > point, right? Is the git section still up to date (I see it was updated > last on Jan 29, so probably)? > > > > Thanks! > Coty >
Tomcat Site Redesign
I have uploaded the Tomcat site redesign to a temporary location for review: http://people.apache.org/~isapir/mockups/tomcat-site/ The source can be seen at https://github.com/isapir/tomcat-website This includes all of the pages for the website, but not the documentation for the different versions, connector, native, webapps, etc. as of yet. There are three things that I would like to discuss: 1) Feedback, especially if anything is broken or doesn't look right. 2) I can concatenate some resource files etc., but it would be much better to switch to HTTP/2. 3) We should create a repo for the site, e.g. tomcat-site or tomcat-website. @Mark - should I contact INFRA RE: 2 and/or 3? Best, Igal Feedback welcome.
Building and Testing Tomcat 7
Rainer, On Sat, Feb 16, 2019 at 2:42 PM Rainer Jung wrote: > Hi Igal, > > Am 16.02.2019 um 22:10 schrieb Igal Sapir: > > Violeta, > > > > On Sat, Feb 16, 2019 at 9:41 AM Violeta Georgieva > > wrote: > > > >> The proposed Apache Tomcat 7.0.93 release is now available for voting. > >> > >> > > I know that this is an issue with my environment, and not with Tomcat, > but > > I wonder how you get it to download the dependencies with Java 6 since > the > > ciphers in Java 6 are outdated (log excerpt below [1]). > > > > For the record, I downloaded JDK6, JDK7, and ANT1.8.4, set the path to > JDK7 > > in build.properties, and JAVA_HOME and ANT_HOME to JDK6 and ANT1.8.4 > > respectively. > > My workaround is currently somethin like: > > export JAVA_HOME=/usr/local/jdk1.7.0 > > export ANT_OPTS="-Djavax.net.ssl.trustStore=/path/to/cacerts > -Djavax.net.ssl.trustStorePassword=changeit > -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2" > > ant download-dist > ant download-validate > ant download-compile > ant download-test-compile > ant download-cobertura > ant extras-commons-logging-prepare > ant extras-webservices-prepare > > export JAVA_HOME=/usr/local/jdk1.6.0 > > export ANT_OPTS="-Djavax.net.ssl.trustStore=/path/to/cacerts > -Djavax.net.ssl.trustStorePassword=changeit" > > ant release > ant test > I updated the build.xml file [1] to make this a bit simpler. The "download-compile" target was both downloading (requiring Java 8) and building (requiring Java 6), so I separated the two actions. To use the new update, you can now download all of the dependencies using the new "download-deps" target using Java 8+: $ export JAVA_HOME=/path-to-jdk8 $ ant download-deps Then you can set JAVA_HOME to a Java 6 version, ANT_HOME to a ant 1.8.x version (because newer ant will not run with Java 8), and run `ant deploy` or `ant test`. The way I do it is along the lines of: $ export JAVA_HOME=/path-to-jdk6 $ export ANT_HOME=/path-to-ant1.8.x $ export ANT_OPTS="-Djava.7.home=/path-toj-jdk7" $ ant test HTH someone, though I'm pretty sure that it will help my future self with testing the next update of Tomcat 7. Best, Igal [1] https://github.com/apache/tomcat/commit/6e69455ab09b > Regards, > > Rainer > > > > [1] > > [get] Error getting > > https://repo.maven.apache.org/maven2/junit/junit/4.11/junit-4.11.jar to > > /home/ux/tomcat-build-libs/download-2104110046.tmp > > > > BUILD FAILED > > /home/ux/Downloads/apache-tomcat-7.0.93-src/build.xml:2702: The following > > error occurred while executing this line: > > /home/ux/Downloads/apache-tomcat-7.0.93-src/build.xml:3066: > > javax.net.ssl.SSLException: Received fatal alert: protocol_version > > at > com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190) > > at > com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:136) > > at > > > com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1822) > > at > > > com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1004) > > at > > > com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1188) > > at > > > com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1215) > > at > > > com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1199) > > at > > sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:434) > > at > > > sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166) > > at > > > sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:133) > > at > > org.apache.tools.ant.taskdefs.Get$GetThread.openConnection(Get.java:660) > > at org.apache.tools.ant.taskdefs.Get$GetThread.get(Get.java:579) > > at org.apache.tools.ant.taskdefs.Get$GetThread.run(Get.java:569) > > > > > > > > > > > >> It can be obtained from: > >> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.93/ > >> The Maven staging repo is: > >> > https://repository.apache.org/content/repositories/orgapachetomcat-1204/ > >> The svn tag is: > >> http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_93/ > >> > >> The proposed 7.0.93 release is: > >> [ ] Broken - do not release > >> [ ] Stable - go ahead and release as 7.0.93 Stable > >> > >> Regards, > >> Violeta >