Re: [VOTE] Apache Tomcat migration tool for Jakarta EE

2020-12-12 Thread Igal Sapir
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

2020-12-10 Thread Igal Sapir
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

2020-12-10 Thread Igal Sapir
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()

2020-12-03 Thread Igal Sapir
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

2020-12-03 Thread Igal Sapir
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

2020-12-03 Thread Igal Sapir
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

2020-12-03 Thread Igal Sapir
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

2020-12-03 Thread Igal Sapir
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

2020-12-03 Thread Igal Sapir
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

2020-11-15 Thread Igal Sapir
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

2020-11-15 Thread Igal Sapir
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

2020-11-15 Thread Igal Sapir
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

2020-10-31 Thread Igal Sapir
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

2020-10-29 Thread Igal Sapir
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

2020-10-28 Thread Igal Sapir
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

2020-10-07 Thread Igal Sapir
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

2020-10-07 Thread Igal Sapir
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

2020-10-07 Thread Igal Sapir
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

2020-10-07 Thread Igal Sapir
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

2020-08-16 Thread Igal Sapir
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

2020-08-16 Thread Igal Sapir
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

2020-08-16 Thread Igal Sapir
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

2020-08-11 Thread Igal Sapir
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

2020-08-10 Thread Igal Sapir
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?

2020-08-07 Thread Igal Sapir
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

2019-12-24 Thread Igal Sapir
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

2019-12-17 Thread Igal Sapir
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

2019-12-17 Thread Igal Sapir
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

2019-12-02 Thread Igal Sapir

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

2019-11-30 Thread Igal Sapir

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

2019-11-18 Thread Igal Sapir

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

2019-11-18 Thread Igal Sapir

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

2019-11-18 Thread Igal Sapir

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

2019-10-08 Thread Igal Sapir

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

2019-10-07 Thread Igal Sapir

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

2019-10-07 Thread Igal Sapir

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)

2019-10-07 Thread Igal Sapir

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

2019-09-17 Thread Igal Sapir

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

2019-09-17 Thread Igal Sapir

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

2019-09-17 Thread Igal Sapir

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

2019-08-15 Thread Igal Sapir
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

2019-08-15 Thread Igal Sapir
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

2019-07-10 Thread Igal Sapir

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

2019-07-10 Thread Igal Sapir

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

2019-07-09 Thread Igal Sapir

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

2019-07-08 Thread Igal Sapir

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

2019-07-08 Thread Igal Sapir
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

2019-07-08 Thread Igal Sapir

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

2019-07-08 Thread Igal Sapir

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

2019-06-27 Thread Igal Sapir

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

2019-06-26 Thread Igal Sapir
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

2019-06-26 Thread Igal Sapir

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?

2019-06-17 Thread Igal Sapir

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

2019-06-05 Thread Igal Sapir

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

2019-06-05 Thread Igal Sapir

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

2019-05-04 Thread Igal Sapir

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

2019-05-04 Thread Igal Sapir

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

2019-05-02 Thread Igal Sapir
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

2019-05-01 Thread Igal Sapir
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

2019-04-29 Thread Igal Sapir

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

2019-04-29 Thread Igal Sapir
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

2019-04-28 Thread Igal Sapir
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

2019-04-25 Thread Igal Sapir

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

2019-04-25 Thread Igal Sapir

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

2019-04-25 Thread Igal Sapir

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

2019-04-25 Thread Igal Sapir

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

2019-04-25 Thread Igal Sapir

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

2019-04-23 Thread Igal Sapir

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

2019-04-12 Thread Igal Sapir
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

2019-04-11 Thread Igal Sapir
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

2019-04-10 Thread Igal Sapir

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

2019-04-10 Thread Igal Sapir

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

2019-04-10 Thread Igal Sapir

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

2019-03-27 Thread Igal Sapir
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

2019-03-27 Thread Igal Sapir
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?

2019-03-23 Thread Igal Sapir
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)

2019-03-23 Thread Igal Sapir
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?

2019-03-22 Thread Igal Sapir
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

2019-03-20 Thread Igal Sapir

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

2019-03-20 Thread Igal Sapir

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

2019-03-20 Thread Igal Sapir

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

2019-03-18 Thread Igal Sapir

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

2019-03-17 Thread Igal Sapir
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

2019-03-15 Thread Igal Sapir
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

2019-03-15 Thread Igal Sapir
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

2019-03-15 Thread Igal Sapir

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

2019-03-15 Thread Igal Sapir

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

2019-03-15 Thread Igal Sapir
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

2019-03-14 Thread Igal Sapir

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

2019-03-14 Thread Igal Sapir

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

2019-03-14 Thread Igal Sapir

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

2019-03-14 Thread Igal Sapir

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

2019-03-08 Thread Igal Sapir
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

2019-03-08 Thread Igal Sapir
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

2019-03-07 Thread Igal Sapir
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

2019-03-07 Thread Igal Sapir
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

2019-03-05 Thread Igal Sapir
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?

2019-03-05 Thread Igal Sapir
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

2019-03-03 Thread Igal Sapir
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

2019-03-02 Thread Igal Sapir
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
>


  1   2   3   >