Re: [VOTE] Release Apache Tomcat 9.0.37

2020-07-04 Thread Emmanuel Bourg
Le 30/06/2020 à 22:41, Mark Thomas a écrit :

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

+1, tested in Debian

Emmanuel Bourg



signature.asc
Description: OpenPGP digital signature


Re: Changing the name of the default branch in our git repos

2020-06-19 Thread Emmanuel Bourg
Le 16/06/2020 à 10:02, Mark Thomas a écrit :

> Thoughts?

I'd prefer the status-quo and keep "master", I've always understood this
as the 'master record' (I know it might be historically wrong) and I
haven't seen evidences it has ever offended or deterred anyone from
contributing.

If there is a consensus to change I suggest waiting to see what GitHub
plans to do. The "master" name is a de-facto standard for Git
repositories, and I think we should remain consistent with the new name
that will be popularized by GitHub.

That said, I have a preference for "main".

Emmanuel Bourg

-
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 migration tool for Jakarta EE 0.0.2

2020-06-08 Thread Emmanuel Bourg
The following votes were cast:

Binding:
+1: remm, mgrigorov, markt, ebourg

No other votes were cast.

The vote therefore passes.

Thank you to everyone who contributed to this release.



signature.asc
Description: OpenPGP digital signature


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

2020-06-06 Thread Emmanuel Bourg
Le 04/06/2020 à 15:08, Emmanuel Bourg a écrit :

> The proposed 0.0.2 release is:
> [ ] Broken - do not release
> [X] Beta   - go ahead and release as 0.0.2
> 

+1

Emmanuel Bourg



signature.asc
Description: OpenPGP digital signature


[VOTE] Release Apache Tomcat migration tool for Jakarta EE 0.0.2

2020-06-04 Thread Emmanuel Bourg
I'd like to call for a vote to release the version 0.0.2 of the
Jakarta EE migration tool.

This will be a "tag only" release with no distribution of the binaries
(neither from Apache nor from Maven Central).

The notable changes compared to 0.0.1 are:

- An Ant task has been added

- Inplace file migration is now supported

- EC signatures are now removed from the migrated jar files

- Better log formatting when running from the command line

- New '-verbose' option for the command line


Tag:
https://gitbox.apache.org/repos/asf?p=tomcat-jakartaee-migration.git;a=commit;h=45d354c1835a1583baf0be02ae77e70fd290f2da

Source:
https://gitbox.apache.org/repos/asf?p=tomcat-jakartaee-migration.git


The proposed 0.0.2 release is:
[ ] Broken - do not release
[ ] Beta   - go ahead and release as 0.0.2



signature.asc
Description: OpenPGP digital signature


Re: [VOTE] Release Apache Tomcat 9.0.36

2020-06-04 Thread Emmanuel Bourg
Le 03/06/2020 à 20:06, Mark Thomas a écrit :

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

Tests are ok on Debian with OpenJDK 11.0.7, Tomcat Native 1.2.24 and
OpenSSL 1.1.1g.

Emmanuel Bourg

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



Re: Jakarta EE migration tool improvements

2020-04-07 Thread Emmanuel Bourg
Le 07/04/2020 à 13:50, Rémy Maucherat a écrit :

> I would want to keep the basic tool available.

Of course, this is in addition to the command line tool.


> Ideally it is nice to avoid having too many options.

I hardly imagine more than 10 options for this kind of tool.

Emmanuel Bourg

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



Re: Jakarta EE migration tool improvements

2020-04-07 Thread Emmanuel Bourg
Le 07/04/2020 à 12:41, Mark Thomas a écrit :

>> - Use a CLI parsing library (picocli, jcommander or commons-cli) to ease
>> the addition of command line options. It may also bring help/manpage
>> generation, tab completion, colored messages.

> Are we at the point where we need one?

The lack of proper command line parsing will quickly become a deterrent
to the addition of new features. I hesitated to add the -verbose option
due to this. We'll probably need a -force flag to confirm inplace
migration, a -quiet flag wouldn't be unusual. The main method will
quickly turn into spaghetti code without a library.


> I'd opt for Commons CLI if I had to choose but I'm not really familiar 
> with any of the options to judge relative pros/cons.

Having maintained Commons CLI some time ago I know it well, it's quite
compact but it shows its age now compared to more recent alternatives.
JCommander is annotation based and more concise. Picocli is the most
advanced I think, it supports help usage and manpage generation, tab
completion and ANSI coloring. But it's a 350K dependency, so harder to
sell I guess.


>> - Support in-place migration of directories. I've implemented it for
>> single files but it looks a bit dangerous for whole directories. I think
>> it'd be safer to ask the user to confirm first.
> 
> I'd be happy to allow this for a build system without confirmation. I'm
> not sure I'd want to allow it at all outside of that (including single
> files). The opportunity for shooting yourself in the foot if the
> migration fails is significant. I'd rather the tool forced a safe
> approach of writing the migrated content to a new location.

What about safe by default, and a command line option to allow it?


>> - In memory buffering. The converters read and write directly to the
>> disk, writing first to memory and then to the disk speeds up the
>> migration (on my system it halved the migration time of the Tomcat
>> source tree).
> 
> I'm wondering about buffer size vs performance benefit. Is there a point
> where a larger buffer doesn't help much more? I'm thinking about memory
> constrained systems and whether there is a sensible fixed buffer size we
> can use, or whether the buffer size should be configurable and if so,
> with what default?

I'm thinking about a mixed approach, with buffering for small files
(let's say under 1MB) and direct write for the others, so the heap usage
remains moderate.

Emmmanuel Bourg

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



Re: [tomcat-jakartaee-migration] branch master updated (397ff8a -> c4e5c18)

2020-04-07 Thread Emmanuel Bourg
Le 07/04/2020 à 12:24, Mark Thomas a écrit :

> +1 to all of the above.

Thank you for the review.


>>  new 3618367  Renamed NoOpConverter to PassThroughConverter
> 
> What problem does this commit address and/or what new feature does it
> add? It looks more like a personal preference for a different name to me.

I've found "NoOp" to be confusing, at first glance based on the name I
thought it was an empty implementation of the Converter interface, and I
was wrong since it actually copies the source unmodified. I think the
term "pass-through" better describes the behavior of the converter.


> I think there is less likelihood of conflict if there is a technical
> justification for a change, and, if the justification is not / might not
> be obvious then mention it in the commit message.

Ok, I tend to write concise commit messages but I'll try to elaborate in
this kind of situation.


> This tests creates a file but doesn't remove it afterwards. Tests that
> create files should remove those files on completion. It might be worth
> considering creating such files in a temporary location rather than in
> the source tree.

I agree this can be improved.


> Generally, the code was clean (no IDE warnings) and the aim is to keep
> it this way as it enables errors to be spotted more easily. This is no
> longer the case after the above changes. The unused charset parameter is
> flagged as a warning.

Sorry, for some reason my IDE was misconfigured and no longer
highlighted unused code. I'll fix that.

Emmanuel Bourg

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



Jakarta EE migration tool improvements

2020-04-07 Thread Emmanuel Bourg
Hi,

So I've started working on the Jakarta EE migration tool. I've some
enhancements in mind but I'd like to ensure there is a consensus before
proceeding.

Here are my suggestions:

- Turn the tool into a plugin for the main build systems (Maven, Gradle,
Ant) to easily post process the jar/war files generated by a project.
I've some experience on this side with my jsign project
(https://github.com/ebourg/jsign) and I suggest adopting a similar multi
module structure with separate artifacts.

- Use a CLI parsing library (picocli, jcommander or commons-cli) to ease
the addition of command line options. It may also bring help/manpage
generation, tab completion, colored messages.

- Parallel processing of directories, and maybe of archives too but
that's trickier.

- Support in-place migration of directories. I've implemented it for
single files but it looks a bit dangerous for whole directories. I think
it'd be safer to ask the user to confirm first.

- In memory buffering. The converters read and write directly to the
disk, writing first to memory and then to the disk speeds up the
migration (on my system it halved the migration time of the Tomcat
source tree).

What do you think?

Emmanuel Bourg

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



Jakarta EE migration tool release

2020-04-07 Thread Emmanuel Bourg
Hi all,

I'd like to start packaging the Jakarta EE migration tool for Debian
since it's now a prerequisite to build Tomcat 10. For that I'd need a
recent tag, do you think we could tag the current code as 0.0.2? Do we
need a formal vote at this stage?

Emmanuel Bourg

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



Re: [tomcat-jakartaee-migration] 01/03: Replaced NonClosing{In, Out}putStream with the equivalent classes from Commons IO

2020-04-07 Thread Emmanuel Bourg
Le 07/04/2020 à 09:41, Rémy Maucherat a écrit :

> Reimplemeting ... It was already done, and this was a better trivial
> solution. This is a veto (unlike Mark I will not withdraw it), so please
> revert this commit.

Remy, this is honestly more a rant on an insignificant detail than a
reasonably justified veto. It doesn't affect the correctness, the
performance or the maintainability of the tool. I'm tempted to translate
this as "Don't touch my project" and an incitation to go work on
something else.

The dependency graph of this tool is very likely to grow as its features
expand (think about adding a CLI parser, providing the tool as a
Maven/Gradle plugin or an Ant task), and I wouldn't be surprised to see
Commons IO brought to the classpath sooner or later anyway (or the
overhead diluted).

Emmanuel Bourg

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



Re: [tomcat-jakartaee-migration] branch master updated (5c96c0b -> 61ba095)

2020-04-07 Thread Emmanuel Bourg
Le 07/04/2020 à 10:12, Mark Thomas a écrit :

> The dependencies are only embedded to create a single JAR to make it
> easier for users to use on the command line. If the code was re-used I'd
> expect the "standard" JAR to be used and leave the decision on how to
> handle the dependencies up to the integrator.

Ok, I assumed the shaded jar was the main artifact. As long as it isn't
published to Maven Central I'm fine with removing the relocation.

Emmanuel Bourg

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



Re: [tomcat-jakartaee-migration] branch master updated (5c96c0b -> 61ba095)

2020-04-06 Thread Emmanuel Bourg
Le 06/04/2020 à 18:33, Mark Thomas a écrit :

> OK. But that is still 7.2k of classes rather than 2.4k of classes for
> zero benefit.
> 
> I'll withdraw my -1 because we are approaching the point where the
> differences aren't worth the time spent discussing them but I still
> don't like this change.

I've removed the duplicated Apache license in the shaded jar, so the
difference is now near zero.

I agree this change is trivial and doesn't bring significant changes.
Apache Commons was created to share and reuse common code used at the
ASF, I always feel a bit sad when the code produced there isn't reused.


> And the relocation of the dependencies? At the moment, I only see a
> downside (harder debugging). What is the benefit?

Relocating embedded dependencies is a best practice to prevent classpath
conflicts. If the tools ends up being integrated in a bigger software it
could clash with another version of BCEL on the classpath.

Emmanuel Bourg

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



Re: [tomcat-jakartaee-migration] branch master updated (5c96c0b -> 61ba095)

2020-04-06 Thread Emmanuel Bourg
Le 06/04/2020 à 17:50, Mark Thomas a écrit :

>> from 5c96c0b  Ignore the IntelliJ project files
>>  new 29ea189  Replaced NonClosing{In,Out}putStream with the equivalent 
>> classes from Commons IO
> 
> -1. It adds 220k of bloat for no benefit.

No the dependencies are shaded with the minimizeJar option enabled, only
the classes used are kept in the final jar.


>>  new 528ccfa  Made the internal classes package private
> 
> I am close to -1 on this change.
> 
> I would rather these were left public at this stage in the development
> of this tool to make it as easy as possible for folks to tinker with
> this code, re-using the bits that work for them. Longer term I had the
> possibility in mind that users might need to register custom Converters
> so making that package private seems very out of place.
> 
> I get that we can always relax visibility rules later but this change
> looks premature to me.

Ok sounds fair, I've reverted it.

Emmanuel Bourg

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



Re: [tomcat-jakartaee-migration] 01/03: Replaced NonClosing{In, Out}putStream with the equivalent classes from Commons IO

2020-04-06 Thread Emmanuel Bourg
Le 06/04/2020 à 15:38, Rémy Maucherat a écrit :

> commit 29ea1891489060f3b3e40259098def5ae47645ef
> Author: Emmanuel Bourg mailto:ebo...@apache.org>>
> AuthorDate: Mon Apr 6 15:24:35 2020 +0200
> 
>     Replaced NonClosing{In,Out}putStream with the equivalent classes
> from Commons IO
> 
> 
> Ah, the beauty of having Maven. Actual benefit: zero. Trouble with
> updating dependencies: one. Possible incompatibilities: one.
> So I think it's a total of -2 for the commit.

Sorry but I'm not sure to understand your objection. Commons IO is dead
stable, these classes have been around for over 10 years and haven't
changed much since. There is really no point reimplementing them.

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 10.0.0-M4

2020-04-06 Thread Emmanuel Bourg
Le 03/04/2020 à 13:28, Mark Thomas a écrit :

> The proposed 10.0.0-M4 release is:
> [ ] Broken - do not release
> [X] Alpha  - go ahead and release as 10.0.0-M4

Good in Debian with OpenJDK 11. Just got taglibs related test failures
because the jars haven't been migrated yet.

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 9.0.34

2020-04-05 Thread Emmanuel Bourg
Le 03/04/2020 à 14:49, Mark Thomas a écrit :

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

All good in Debian.

Emmanuel Bourg

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



Re: git-fu is weak

2020-02-24 Thread Emmanuel Bourg
Le 24/02/2020 à 17:33, Christopher Schultz a écrit :

> Any ideas?

I guess you are cherry picking the merge commit, instead of the actual
commit(s) from the PR branch.

Emmanuel Bourg


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



Re: [VOTE] Tomcat 7.0.x EOL as 31 March 2021

2020-02-24 Thread Emmanuel Bourg
Debian 8 is the last release to ship Tomcat 7 and the extended support
will end in June 2020.

Ubuntu 16.04 LTS also has Tomcat 7 and support will stop in April 2021.

The proposed date looks good to me.

+1

Emmanuel Bourg

Le 21/02/2020 à 10:52, Mark Thomas a écrit :
> All,
> 
> This has been mentioned in various threads and I don't recall any
> objections. I think it is time for a vote so we can formally announce this.
> 
> Announce the EOL date for 7.0.x as 31 March 2021
> 
> [ ] Yes
> [ ] No, because...
> 
> Thanks,
> 
> Mark
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 


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



Re: [VOTE] Private branches in the official Tomcat git repository

2019-10-11 Thread Emmanuel Bourg
Le 11/10/2019 à 16:20, Rémy Maucherat a écrit :

> Should private branches be allowed in the official Tomcat git repository ?
> [X] Yes
> [ ] No

+1

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 9.0.27

2019-10-07 Thread Emmanuel Bourg
Le 07/10/2019 à 13:51, Mark Thomas a écrit :

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

Tested on Debian with OpenJDK 11.0.5+6, OpenSSL 1.1.1d and Tomcat Native
1.2.23. No failure on the 3 test suites.

Emmanuel Bourg

-
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 Emmanuel Bourg


>> Yes, basically I think we should remove both CGI and SSI, *but* actually
>> keep them in a separate JAR. For CGI this is harder as it is directly in
>> the servlets package, so it would have to be moved to servlets.cgi for
>> Tomcat 10.

+1, these things could be modularized and shared between Tomcat
versions. Or even with other webapp containers if they don't really need
to leverage Tomcat internal code.

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 9.0.26

2019-09-17 Thread Emmanuel Bourg
Le 16/09/2019 à 18:15, Mark Thomas a écrit :

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

Tested on Debian with OpenJDK 11.0.5+6, OpenSSL 1.1.1d and Tomcat Native
1.2.23. No failure on the 3 test suites.

Emmanuel Bourg



signature.asc
Description: OpenPGP digital signature


Re: CI is back

2019-07-19 Thread Emmanuel Bourg
Le 19/07/2019 à 13:20, Rémy Maucherat a écrit :

> But we want to build an installer for Windows using it. Does that
> actually work with your Linux package ?

Yes it does. At work I build all my NSIS Windows installers from a CI
server running on Debian.

Emmanuel Bourg

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



Re: CI is back

2019-07-19 Thread Emmanuel Bourg
Le 16/07/2019 à 10:39, Mark Thomas a écrit :
> On July 15, 2019 11:08:22 PM UTC, "Rémy Maucherat"  wrote:
> 
> That is by design. NSIS 3.x wasn't compatible with the version of WINE 
> available on the CI server. That might have changed with the OS upgrade.
> 
> From memory (I only have my phone and a poor internet connection  at present) 
> the properties are overridden in the buildbot config file we can edit.

Is WINE really necessary? NSIS is also available on Linux, if the CI
server uses Debian or Ubuntu a package is even available [1].

Emmanuel Bourg

[1] https://tracker.debian.org/pkg/nsis

-
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-18 Thread Emmanuel Bourg
Le 17/06/2019 à 18:56, Mark Thomas a écrit :

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

Has it been considered to move the org.apache.tomcat.jni package from
tomcat to tomcat-native? Since these Java classes are the counterpart of
the native code, always evolving in sync, it would be sensible to have
them in the same project.


> 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

What is the workflow to use git subtrees? I googled quickly yesterday
and it didn't seem that simple, but maybe I'm missing something. My
understanding is that the subtree has to be explicitly configured with
non trivial commands after a 'git clone'.

Emmanuel Bourg

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



Re: javax.tools based JSP compiler

2019-05-13 Thread Emmanuel Bourg
Le 13/05/2019 à 12:17, Mark Thomas a écrit :

> If I am understanding this all correctly, the proposed way forward is to
> (eventually) replace the Ant compiler with the JSR199 based Javac
> compiler? If so, then +1 from me.

I mostly aim at providing an easy way to use the new language features
in JSPs, removing the legacy Ant compiler is a bonus. This perspective
raises a couple of questions:

- When the Ant compiler could be deprecated/removed? Should we deprecate
in Tomcat 9.0.x and remove in 10, or deprecate in Tomcat 10 and remove
in 11?

- What should be done with the JspServlets configured to use Ant once
the compiler is deprecated/removed? Throw an error or redirect to the
new javac compiler?

Emmanuel Bourg

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



Re: javax.tools based JSP compiler

2019-05-11 Thread Emmanuel Bourg
Le 11/05/2019 à 00:46, Emmanuel Bourg a écrit :

> - I'm not sure about the performance, ECJ was known to be faster than
> javac in the past but I don't know if it's still true today.

I ran a quick test on an old Core 2 Duo with a SSD, compiling Tomcat and
another Ant based project of mine. The Eclipse compiler is still faster
than javac, by ~40%.

Emmanuel Bourg

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



Re: javax.tools based JSP compiler

2019-05-10 Thread Emmanuel Bourg
Le 09/05/2019 à 00:34, Mark Thomas a écrit :

> +1
> 
> Need to remove the @author tags and add some info on how to configure
> jasper to use them.

Ok will do.


> A few daft questions:
> 
> 1. If we used the JSR199Complier by default would that allow us to
> remove the Eclipse compiler as a dependency?

The JSR199 compiler has some drawbacks :
- It requires a full JDK (the Eclipse compiler just needs a JRE). This
will be less of an issue in the future since there is no JRE anymore
after Java 8.
- It doesn't reuse an existing classloader, it builds its classpath from
a list of files. I haven't checked if it works with non-expanded war
files, but I guess it doesn't. And it's probably slower (but that may be
negligible compared to the compilation time).
- I'm not sure about the performance, ECJ was known to be faster than
javac in the past but I don't know if it's still true today.

So no I don't think it can replace the Eclipse compiler yet.


> 2. Why would anyone use the JavacCompiler in preference to JSR199Complier?

The JSR199 compiler will indeed render the Ant based one obsolete. It'll
make javac directly usable without the Ant dependency.

Emmanuel Bourg

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



Applet in the documentation

2019-05-08 Thread Emmanuel Bourg
Hi,

We have a clock applet in the documentation illustrating the use of the
 tag. Applet support has been removed from all
browsers now, it's unlikely to be useful anymore.

Any objection to drop this example from the documentation?

Emmanuel Bourg

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



Re: javax.tools based JSP compiler

2019-05-08 Thread Emmanuel Bourg
Hi all,

I've rebased the javax.tools JSP compiler on top of the current master
branch :

  https://github.com/ebourg/tomcat/tree/jasper-javax-tools-support

Please let me know how you feel about this stuff and if it's worth merging.

Emmanuel Bourg


Le 09/04/2018 à 17:28, Emmanuel Bourg a écrit :
> 
> I've just completed an initial implementation:
> 
>   https://github.com/ebourg/tomcat/commit/1272a1b
> 
> I tested with Java 8 and 10 on Windows and it worked fine with the JSP
> examples shipped with Tomcat. It allowed me to use the new 'var' syntax
> with Java 10.
> 
> Unlike ECJ the javax.tools API cannot take an existing ClassLoader but
> expects a list of files. So it is probably slower, and I guess it
> doesn't support non unpacked war files. The javax.tools API also
> requires the JDK (the JRE has the API but not the underlying
> implementation).
> 
> So this compiler is quite equivalent to the Ant based compiler, but at
> least it doesn't require an additional jar.
> 
> Emmanuel Bourg
> 


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



Re: Jakarta package change

2019-05-07 Thread Emmanuel Bourg
Le 07/05/2019 à 09:05, Rémy Maucherat a écrit :

> - Maintain a Tomcat 9.x "forever" with Servlet 4.0. As a result, all the
> APIs in Tomcat 9 can remain javax.* and users with "old" applications will
> still have an up to date fully compatible container for them.

+1

> - Have a Tomcat 10 with all API packages renamed to jakarta.*, which would
> provide a container for users who want to move to the new "incompatible"
> Jakarta specifications.

+1 for deferring the package changes to Tomcat 10.

The actual impact isn't clear though, the specifications may evolve in a
way that maintains a form of backward compatibility as outlined by Mark
Struberg (for example jakarta.* classes the extending javax.* ones).
It's a bit early to know how this could be handled in Tomcat 10.

Once we know how the specs will evolve, I suggest releasing a prototype
as soon as possible so everyone can start experimenting with the new
namespace. The return of Jakarta Tomcat ;)

I wonder if the specifications could be slightly refactored in the
process to erase some mistakes, for example renaming
ServletRequest.getContentLengthLong() to getContentLength(). The package
change could be a great opportunity to tidy up the APIs.


> This way, there's an appropriate container for everyone. Mark Struberg
> proposed more elaborate strategies using classloader tricks on the ASF
> members list, but I'm not sure this is even needed for Tomcat.

Would such a classloader work with a native application using GraalVM ?
If not I guess we'll rather see build time tools doing the bytecode
processing than runtime tools. In this case the actual conversion would
indeed be out of scope for Tomcat.


> Comments ?

Not really happy to waste so much time for a silly trademark policy...
Let's hope Oracle's lawyers don't impose the same mess to OpenJDK someday.

Emmanuel Bourg

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



Re: Tomcat 7, Checkstyle and Gump

2019-03-22 Thread Emmanuel Bourg
Le 20/03/2019 à 23:51, Mark Thomas a écrit :

> Any suggestions?

Maybe disable Checkstyke for Tomcat 7? It isn't that important for old
code in maintenance mode. Backported code is unlikely to have a wildly
different formatting style 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.39

2019-03-18 Thread Emmanuel Bourg
Le 14/03/2019 à 14:43, Mark Thomas a écrit :

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

+1, tested on Debian 10 with OpenJDK 11.0.3+1 and OpenSSL 1.1.1b

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 9.0.17

2019-03-18 Thread Emmanuel Bourg
Le 13/03/2019 à 19:23, Mark Thomas a écrit :

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

+1, tested on Debian 10 with OpenJDK 11.0.3+1 and OpenSSL 1.1.1b

Emmanuel Bourg



signature.asc
Description: OpenPGP digital signature


Re: New git based merging workflow?

2019-02-28 Thread Emmanuel Bourg
Le 28/02/2019 à 16:19, Rémy Maucherat a écrit :

> Nice try ! :D

:P

We could also just have a pom.xml file to be used as a mere project
descriptor for the IDE, and retain the main build with Ant.

Emmanuel Bourg

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



Re: New git based merging workflow?

2019-02-28 Thread Emmanuel Bourg
Le 28/02/2019 à 15:25, Mark Thomas a écrit :

> The main reason I don't do that is that I want to have each branch setup
> correctly (Java version, dependencies, etc.) in an IDE. Eclipse, at
> least, doesn't cope well with that.

That sounds like a good reason to use Maven. IntelliJ detects the
changes to the pom and then adapts the dependencies and the language
level. I don't think this is possible with an Ant based project.

Emmanuel Bourg

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



Re: New git based merging workflow?

2019-02-28 Thread Emmanuel Bourg
Le 28/02/2019 à 11:47, Rainer Jung a écrit :
> Thanks a bunch. Looks like what I was searching for, will try it.
> 
> Rainer

You could play with a single repository too:

  # Initial setup
  cd ~/repos
  git clone g...@github.com:apache/tomcat.git

  # Commit...
  cd ~/repos/tomcat
  # edit files
  git commit -a -m "Some message"
  git push

  # ...and backport
  git checkout 8.5.x
  git cherry-pick 
  git push origin 8.5.x

  git checkout master

Emmanuel Bourg

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



Re: [VOTE] Migrate to git

2019-02-21 Thread Emmanuel Bourg
Le 21/02/2019 à 17:13, Mark Thomas a écrit :

> [X] +1 Go ahead with the migration
> [ ] -1 Postpone the migration because...

Thank you Mark.

Emmanuel Bourg

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



Re: Git migration: new branch/tag naming scheme

2019-02-18 Thread Emmanuel Bourg
Le 16/02/2019 à 16:09, Michael Osipov a écrit :

> The given approach, for whatsoever reason, performs an uppercase and
> replaces dots with underscores. This reduces readability, but also
> requires people (esp. package maintainers) to perform sed(1) magic to
> convert back and forth.

I agree this is cumbersome, we are doing this kind of manipulation in
Debian too to compare the version packaged with the latest upstream release.

If I remember well this convention is inherited from the CVS era, dots
were not allowed in tag names and thus commonly replaced by underscores
or dashes.


> Approch 1: It will reuse the branch name of the current major version,
> excluding master. Thus, we will have the following prefixes: tomcat90-,
> tomcat85-, and tomcat70-. Since JDBC Pool remains in place and if it is
> released separately the prefix would be jdbc-pool-. The version itself
> would remain as-is and simply appended, e.g., 8.5.40, 9.0.25, etc.

-0

> Approach 2: A simpler, less redundant approach would be naming the
> branches master, 7.0.x, 8.5.x, etc. and get rid of the "tomcat" prefix
> at all. The tags would simply be the versions as-is: 8.5.40, 9.0.25,
> etc. The Git autocompletion will work here too.

+1

Emmanuel Bourg

-
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-02-05 Thread Emmanuel Bourg
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

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

2019-02-05 Thread Emmanuel Bourg
Le 05/02/2019 à 13:22, Mark Thomas a écrit :

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

Tested on Debian with OpenJDK 11.0.2, OpenSSL 1.1.1a and Tomcat Native
1.2.21. No failure on the 3 test suites.

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 9.0.16

2019-02-05 Thread Emmanuel Bourg
Le 04/02/2019 à 18:00, Mark Thomas a écrit :

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

Tested on Debian with OpenJDK 11.0.2, OpenSSL 1.1.1a and Tomcat Native
1.2.21. No failure on the 3 test suites.

Emmanuel Bourg

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



Re: New design for the Tomcat website

2019-01-03 Thread Emmanuel Bourg
Le 03/01/2019 à 02:59, Igal Sapir a écrit :

> I am working on a new design for the Tomcat website and wanted some
> preliminary feedback.
> 
> You can see the first mockup at
> http://people.apache.org/~isapir/mockups/tomcat-site-1/
> 
> Please let me know your thoughts.

I miss the left menu, I know it isn't the current trend but it allows
quick access to the main resources of the site (and since the last
redesign it folds into a hamburger button when there isn't enough space).

Also the font is bigger and reduces the number of lines visible.

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

2018-12-17 Thread Emmanuel Bourg
Le 12/12/2018 à 14:22, Mark Thomas a écrit :
> The proposed Apache Tomcat 8.5.37 release is now available for voting.
> 
> The major changes compared to the 8.5.35 release are:
> 
> - Implement the requirements of section 8.2.2 2.c of the Servlet
>   specification and prevent a web application from deploying if it has
>   fragments with duplicate names and is configured to use relative
>   ordering of fragments.
> 
> - The default Servlet no longer overrides a previously set content-type.
> 
> - Update the packaged version of the Tomcat Native Library to 1.2.19 to
>   pick up the latest Windows binaries built with APR 1.6.5 and OpenSSL
>   1.1.1a.
> 
> Along with lots of other bug fixes and improvements.

I've tested on Debian Sid with OpenJDK 11.0.1+13 and OpenSSL 1.1.1a, and
I've noticed two test failures in TestClientCertTls13 with the three
connectors. Is this expected?

Testcase: testClientCertPost took 0.77 sec
Caused an ERROR
Received fatal alert: protocol_version
javax.net.ssl.SSLHandshakeException: Received fatal alert: protocol_version
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)
at 
java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279)
at 
java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
at 
java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
at 
java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
at 
java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
at 
java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567)
at 
java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at 
java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:163)
at 
org.apache.catalina.startup.TomcatBaseTest.postUrl(TomcatBaseTest.java:782)
at 
org.apache.catalina.startup.TomcatBaseTest.postUrl(TomcatBaseTest.java:748)
at 
org.apache.catalina.startup.TomcatBaseTest.postUrl(TomcatBaseTest.java:722)
at 
org.apache.tomcat.util.net.TestClientCertTls13.testClientCertPost(TestClientCertTls13.java:61)
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)

Testcase: testClientCertGet took 0.038 sec
Caused an ERROR
Received fatal alert: protocol_version
javax.net.ssl.SSLHandshakeException: Received fatal alert: protocol_version
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)
at 
java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279)
at 
java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
at 
java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
at 
java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
at 
java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
at 
java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567)
at 
java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at 
java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:163)
at 
org.apache.catalina.startup.TomcatBaseTest.methodUrl(TomcatBaseTest.java:689)
at 
org.apache.catalina.startup.TomcatBaseTest.methodUrl(TomcatBaseTest.java:663)
at 
org.apache.catalina.startup.TomcatBaseTest.getUrl(TomcatBaseTest.java:657)
at 
org.apache.catalina.startup.TomcatBaseTest.getUrl(TomcatBaseTest.java:651)
at 
org.apache.catalina.startup.TomcatBaseTest.getUrl(TomcatBaseTest.java:636)
at 
org.apache.catalina.startup.TomcatBaseTest.getUrl(TomcatBaseTest.java:630)
at 
org.apache.tomcat.util.net.TestClientCertTls13.testClientCertGet(TestClientCertTls13.java:45)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 

Re: [VOTE] Release Apache Tomcat 9.0.14

2018-12-10 Thread Emmanuel Bourg
+1, tested on Debian 10 with OpenJDK 11.0.1 and OpenSSL 1.1.1a

Emmanuel Bourg


Le 06/12/2018 à 22:37, Mark Thomas a écrit :
> The proposed Apache Tomcat 9.0.14 release is now available for voting.
> 
> The major changes compared to the 9.0.13 release are:
> 
> - Significant expansion of localisation support with the addition of
>   Brazilian Portuguese, Korean and Chinese (simplified) as well as
>   the expansion of coverage for existing languages
> 
> - Refactor back ground processing and various independent thread pools
>   to use a common executor
> 
> - Update the packaged version of the Tomcat Native Library to 1.2.19 to
>   pick up the latest Windows binaries built with APR 1.6.5 and OpenSSL
>   1.1.1a.
> 
> Along with lots of other bug fixes and improvements.
> 
> For full details, see the changelog:
> http://svn.apache.org/repos/asf/tomcat/trunk/webapps/docs/changelog.xml
> 
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.14/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1199/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_9_0_14/
> 
> The proposed 9.0.14 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 9.0.14
> 
> -
> 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: L10n / I18n

2018-11-08 Thread Emmanuel Bourg
Le 08/11/2018 à 15:47, Mark Thomas a écrit :

> is that a reason to drop attempts to provide i10n or
> is it an indication we aren't doing nearly enough?

We can always do more, but considering our limited resources I think
it's wise to focus first on the most important areas (ie. messages
displayed in web pages vs internal log messages).


> Seriously, we (well, those in the community that speak French
> fluently - not me) could look to improve those.

FTR I did start working on the French translation for jasper this summer
but I got dragged to other duties. When looking around the other
resource bundles I really wondered if it made sense to translate very
technical messages though.


> But that brings us back to your original question of whether the
> translations are worth it. If (and it is a fairly big if) the
> translations were mostly complete and mostly of good quality, would that
> change your view? I'm thinking try and improve the translations as a
> first step and, if things don't improve, then decide what to do next.

If the translations were nearly complete and of good quality I would
definitely not suggest dropping them. Yet, I think I'd still configure
Tomcat to run in English instead of French because I'm used to the
English terminology.


> Removing the translations (apart from the UI) feels to be too big a step
> to me. That said, I can see how they would be a hindrance rather than a
> help to some. Perhaps separating the l10n JARs into user facing and
> external would give more options. Admins could remove the translated JAR
> for the internal messages and get those messages in English if they
> prefer. Or we could ship less or even no translations for internal
> messages by default and provide them as a separate download.

I don't think rearranging the JARs is necessary, it isn't difficult to
run Tomcat with a different locale. I'm more concerned about the
maintenance burden and the actual value vs the time invested.

Emmanuel Bourg

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



Re: L10n / I18n

2018-11-07 Thread Emmanuel Bourg
Le 07/11/2018 à 23:36, Mark Thomas a écrit :

> WDYT?

What about simplifying the issue by dropping the translations of the
internal messages and retaining only the user facing messages (things
like HTTP error messages that can appear in a normal request) ?

I think it's worth considering because:
- The target audience of Tomcat is mainly developers and administrators
which are used to read English text.
- The coverage of the translations is rather low.
- Maintaining the translations, the quality and the consistency is
difficult and time consuming.
- Sometimes the translation of the technical terms are a bit unusual and
not as clear as the English counterpart. For example in French it isn't
obvious that "gestionnaire de protocole" relates to ProtocolHandler
which is an internal Tomcat concept. Other translations are even funny
like "enrobeur de conteneur" for "wrapper container" (a pastry concept
applied to a freight container?). This issue is so common with the
French translation that many messages carry the English terms in
parentheses to clarify the meaning.

Emmanuel Bourg

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



Re: Release script for Tomcat 8.5.x

2018-11-07 Thread Emmanuel Bourg
Le 07/11/2018 à 10:28, Konstantin Kolinko a écrit :

> If I cannot do something with a batch script, I write a shell (bash)
> script and run it with git-bash from Git for Windows.

There is also that thing named Ant that was designed to replace batch
and shell scripts to build Java projects on any platform ;)

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

2018-11-06 Thread Emmanuel Bourg
Le 03/11/2018 à 18:55, Mark Thomas a écrit :

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

+1

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

2018-11-06 Thread Emmanuel Bourg
Le 06/11/2018 à 12:44, Mark Thomas a écrit :

> Should be fixed now.

> There were some robustness fixes in 9.0.x that had not been back-ported.
> I've just done that.

I confirm it works, thank you.

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

2018-11-06 Thread Emmanuel Bourg
I got two issues when building Tomcat 8.5.35 with OpenJDK 11
and OpenSSL 1.1.1 in Debian.

1. testClientCertPost and testClientCertGet in TestClientCertTls13
   failed with the three NIO/NIO2/APR connectors:

  javax.net.ssl.SSLHandshakeException: Received fatal alert: protocol_version
  at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
  at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
  at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)
  at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279)
  at 
java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)
  at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
  at 
java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
  at 
java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
  at 
java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
  at 
java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567)
  at 
java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
  at 
java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:163)
  at 
org.apache.catalina.startup.TomcatBaseTest.postUrl(TomcatBaseTest.java:782)
  at 
org.apache.catalina.startup.TomcatBaseTest.postUrl(TomcatBaseTest.java:748)
  at 
org.apache.catalina.startup.TomcatBaseTest.postUrl(TomcatBaseTest.java:722)
  at 
org.apache.tomcat.util.net.TestClientCertTls13.testClientCertPost(TestClientCertTls13.java:75)


2. testAbortedUploadLimitedNoSwallow and testAbortedPOST413NoSwallow
   failed with NIO only:

  Testcase: testAbortedUploadLimitedNoSwallow took 0.106 sec
  FAILED
  Limited upload with swallow disabled does not generate client exception
  junit.framework.AssertionFailedError: Limited upload with swallow disabled 
does not generate client exception
  at 
org.apache.catalina.core.TestSwallowAbortedUploads.testAbortedUploadLimitedNoSwallow(TestSwallowAbortedUploads.java:130)
  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)

  Testcase: testAbortedPOST413NoSwallow took 0.036 sec
  FAILED
  Limited upload with swallow disabled does not generate client exception
  junit.framework.AssertionFailedError: Limited upload with swallow disabled 
does not generate client exception
  at 
org.apache.catalina.core.TestSwallowAbortedUploads.testAbortedPOST413NoSwallow(TestSwallowAbortedUploads.java:176)
  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)


Emmanuel Bourg


Le 03/11/2018 à 18:55, Mark Thomas a écrit :
> The proposed Apache Tomcat 8.5.35 release is now available for voting.
> 
> The major changes compared to the 8.5.34 release are:
> 
> - support for TLSv1.3 when used with a JRE or OpenSSl version that
>   supports it
> 
> - multiple improvements to the RewriteValve
> 
> - correct several regressions in the JSP compiler
> 
> 
> Along with lots of other bug fixes and improvements.
> 
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.35/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1197/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc8.5.x/tags/TOMCAT_8_5_35/
> 
> The proposed 8.5.35 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 8.5.35
> 
> -
> 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 8.5.34

2018-09-10 Thread Emmanuel Bourg
Le 05/09/2018 à 00:52, Mark Thomas a écrit :

> [X] Stable - go ahead and release as 8.5.34

+1, tested NIO/NIO2/APR on Debian with OpenJDK 10 and OpenSSL 1.1.1

Emmanuel Bourg



signature.asc
Description: OpenPGP digital signature


Re: tomcat-native trunk

2018-09-03 Thread Emmanuel Bourg
Le 03/09/2018 à 11:41, Mark Thomas a écrit :

> No strong views on which build system to use but I will say that Gradle
> might be worth a look.

With my Debian maintainer hat on I have to say that Gradle is a real
hindrance and I hope the Tomcat components will stay out of it. Gradle
itself is a behemoth that is very difficult to maintain, as a build
system it has little respect for backward compatibility, and its
imperative nature quickly turns build files into a non standard, project
specific, mess.

Gradle is barely an improvement over Ant IMHO, but at least Ant is
stable and really cares about backward compatibility. Beyond Ant I think
a declarative build system like Maven is a saner choice.

The tomcat-native fork maintained by netty [1] is built with Maven,
maybe we could get some inspiration from it.

Emmanuel Bourg

[1] https://github.com/netty/netty-tcnative

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



Re: ant problems

2018-08-09 Thread Emmanuel Bourg
Le 09/08/2018 à 11:18, jean-frederic clere a écrit :

> I have problems while building trunk:
> /home/jfclere/TMP/tomcat/build.xml:693: javac doesn't support the
> "release" attribute
> 
> Is that  expected I have tried java11 and java8 (openjdk)?

No that's not expected, Java 9+ supports the new --release parameter,
but Ant simply ignores it if you use an older version. What's your
version of Ant?

Emmanuel Bourg

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



Timestamps in the manifests

2018-08-06 Thread Emmanuel Bourg
Hi all,

We have 4 timestamps in the manifest of our jar files:
 DSTAMP: 20180806
 TSTAMP: 1443
 TODAY: August 6 2018
 Bnd-LastModified: 1533578685288

Are they really necessary? This doesn't help making the generated files
reproducible [1]. Any objection to remove the DSTAMP, TSTAMP and TODAY
attributes?

Emmanuel Bourg

[1] https://reproducible-builds.org

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



Re: Message files encoding

2018-08-01 Thread Emmanuel Bourg
Le 01/08/2018 à 16:34, Mark Thomas a écrit :

> I think there is a little more work to be done. Currently the files are
> corrupted when I look at them in an IDE. I've tried playing with
> svn:mimetype without much luck.

With IntelliJ the encoding is automatically detected as UTF-8, but I had
to restart the IDE otherwise it kept seeing them as ISO-8859-1 files and
started corrupting them. Invalidating the caches may also help ("File ->
Invalidate Caches / Restart" in IntelliJ). If it doesn't work there is a
per-project encoding for properties files that can be configured from
File -> Settings -> Editor -> File Encodings -> Properties Files.
Ironically I just noticed the 'Transparent native-to-ascii conversion'
checkbox there.

Emmanuel Bourg

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



Re: Message files encoding

2018-08-01 Thread Emmanuel Bourg
Le 01/08/2018 à 14:12, Mark Thomas a écrit :

> That solves the complexity problem. It looks like all that would be
> required is a change from copying the file to using native2ascii with
> appropriate src and destinations.
> 
> No objections here.

Ok it's committed (r1837237 and r1837238 for the build part, and
r1837239 for the properties conversion).

This revealed some typos in the French translation, I'm going to run the
files through a spell checker now.

Should we backport this change?

Emmanuel Bourg

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



Re: Message files encoding

2018-08-01 Thread Emmanuel Bourg
Le 01/08/2018 à 14:08, Martin Grigorov a écrit :

> I hope the following changes your mind:
> 
> 1) Bulgarian translations in XML format:
> https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/Application_bg.properties.xml
> 2) Czech translation in ascii format:
> https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/Application_cs.properties
> 
> I can easily read 1) (bulgarian, is my native lang).
> I know some Czech but the \u0xyz makes it really hard / imposible to read
> it as is.

I know, that's exactly why I'm suggesting to switch to UTF-8 and ditch
the unicode escape sequences. Sorry if this wasn't clear.

Emmanuel Bourg

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



Re: svn commit: r1837219 - /tomcat/trunk/java/org/apache/naming/LocalStrings.properties

2018-08-01 Thread Emmanuel Bourg
Le 01/08/2018 à 13:17, Konstantin Kolinko a écrit :

> Proper written spelling is "Cannot".  ("Can't" is for spoken
> language.) So that you can remove the apostrophe altogether.

Thank you for the suggestion, I replaced a handful of occurrences.

Emmanuel Bourg

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



Re: Message files encoding

2018-08-01 Thread Emmanuel Bourg
Le 01/08/2018 à 13:16, Martin Grigorov a écrit :

> What about using the XML version of Java Properties ?
> https://docs.oracle.com/javase/7/docs/api/java/util/Properties.html#loadFromXML(java.io.InputStream)
> This way the encoding could be specified in the XML file itself and there
> is no need to use native2ascii at all.

I'm not really fond of XML properties files, the plain text format is
more compact and easier to browse in my opinion. XML files are
interesting when structured with different levels, but properties files
even in XML format have a flat layout.

Emmanuel Bourg

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



Re: Message files encoding

2018-08-01 Thread Emmanuel Bourg
Le 01/08/2018 à 13:08, Mark Thomas a écrit :

> I like the idea but that will make building with later versions of Java
> problematic - or at least more complex - since native2ascii has been
> removed in Java 9 onwards.

Good point, I wasn't aware of native2ascii removal. I checked the Ant
code and Stefan actually re-implemented native2ascii two years ago to
work around this issue [1]. The feature was released in Ant 1.9.8.

Emmanuel Bourg

[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=59855

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



Message files encoding

2018-08-01 Thread Emmanuel Bourg
Hi all,

The LocalString*.properties files are ASCII encoded which renders the
modification of the non-english messages rather inconvenient.
Contributors either need a specialized resource editor or go through a
native2ascii roundtrip.

How do feel about converting the message files to UTF-8 to facilitate
the modifications and transform them with native2ascii at build time?

Emmanuel Bourg

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



Re: svn commit: r1837219 - /tomcat/trunk/java/org/apache/naming/LocalStrings.properties

2018-08-01 Thread Emmanuel Bourg
Le 01/08/2018 à 12:36, Mark Thomas a écrit :

> For the benefit of the archives this change is correct but we do need to
> be careful.
> 
> Any string that includes substitutions (i.e. {0}, {1}, etc.) requires
> that any ' characters are escaped as '' due to how MessageFormat.format
> behaves.

Yes that's what I'm reviewing currently. I've grepped extensively the
message files and found several inconsistencies, either messages with
parameter and single quotes, or messages without parameters and double
quotes. I wonder if code analysis tools like Findbugs can spot these
issues automatically.

Emmanuel Bourg

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



Re: Tomcat source layout (was: JDK 11 EA 18)

2018-06-26 Thread Emmanuel Bourg
Le 26/06/2018 à 05:21, William L. Thomson Jr. a écrit :

> Because I am crazy :)

I personally would support a move to a Maven directory layout even if we
stick to Ant as the main build system for now. I think it's good to use
a standard project layout, it looks immediately familiar to newcomers.

That said, I don't really understand why you can't use Ant to build
Tomcat in Gentoo. Ant is rather reasonably easy to bootstrap and we have
no problem using it to build Tomcat from sources in Debian/Ubuntu.

Emmanuel Bourg

-
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

2018-06-21 Thread Emmanuel Bourg
Le 21/06/2018 à 16:25, Rémy Maucherat a écrit :

> Is the Ant of the build platform upgradeable already ?

I thought so [1] but it seems there is still an issue.

Emmanuel Bourg

[1] https://issues.apache.org/jira/browse/INFRA-16673

-
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

2018-06-21 Thread Emmanuel Bourg
Le 21/06/2018 à 14:31, Mark Thomas a écrit :

> We are going to need to be careful with this. The older Tomcat branches
> need to build on old Java versions so we need to look at Ant / Java
> version compatibility as well.
> 
> /me heads off to check the Ant docs for minimum Java versions

Ant 1.9.x preserves the Java 5 compatibility. The required JDK only
changed with the 1.10.x line to Java 8.

I suggest sticking to Ant 1.9.x for all supported Tomcat versions until
Tomcat 8.5 is EOLed.

Emmanuel Bourg

-
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

2018-06-21 Thread Emmanuel Bourg
Le 21/06/2018 à 14:14, Gav a écrit :
> Wierd, it passed on the same machine only 2 hours earlier:--
> 
> https://ci.apache.org/builders/tomcat-trunk/builds/3378

This build fetched r1833989, but the issue is with r1833994 which used
an Ant feature requiring at least the version 1.9.8.

Emmanuel Bourg

-
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

2018-06-21 Thread Emmanuel Bourg
Le 21/06/2018 à 14:00, Mark Thomas a écrit :

> Infra ticket.

Ok: https://issues.apache.org/jira/browse/INFRA-16673


> And please revert the change until it is updated so the CI system
> continues to work.

Done in r1834001

Thank you for the guidance.

Emmanuel Bourg

-
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

2018-06-21 Thread Emmanuel Bourg
Le 21/06/2018 à 13:01, build...@apache.org a écrit :
> The Buildbot has detected a new failure on builder tomcat-trunk while 
> building . Full details are available at:
> https://ci.apache.org/builders/tomcat-trunk/builds/3379

It looks like Ant needs an upgrade on the builders. Is there a way to
configure the version of Ant used to build Tomcat, or should I open an
Infra ticket to get it updated?

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 Native 1.2.17

2018-06-12 Thread Emmanuel Bourg
+1

Tested on Debian Sid with OpenJDK 10, OpenSSL 1.1.0h and GCC 7.3

Emmanuel Bourg


Le 07/06/2018 à 17:50, jean-frederic clere a écrit :
> Version 1.2.17 includes the following changes compared to 1.2.16:
> 
> - Windows binaries built with OpenSSL 1.0.2o and APR 1.6.3
> 
> 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.17 is
>  [ ] Stable, go ahead and release
>  [ ] Broken because of ...
> 
> Thanks,
> 
> Jean-Frederic
> 
> 
> [1]
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/native/1.2.17/
> [2] https://svn.apache.org/repos/asf/tomcat/native/tags/TOMCAT_NATIVE_1_2_17
> 
> -
> 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 8.5.30

2018-04-11 Thread Emmanuel Bourg
Le 12/04/2018 à 07:08, Rainer Jung a écrit :

> These errors are strange and not expected. With which version of
> tcnative was this tested, and which version of OpenSSL does that
> tcnative use?

That was tcnative 1.2.16 with OpenSSL 1.1.0h

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



Re: javax.tools based JSP compiler

2018-04-09 Thread Emmanuel Bourg
Le 04/04/2018 à 09:54, Mark Thomas a écrit :

> I like the idea of simplifying the integration of javac - irrespective
> of the reasoning for wanting to use javac. I guess it is something to
> look at in Tomcat 10. Whether or not it gets back-ported is a different
> question. I guess it depends what the solution ends up looking like.

I've just completed an initial implementation:

  https://github.com/ebourg/tomcat/commit/1272a1b

I tested with Java 8 and 10 on Windows and it worked fine with the JSP
examples shipped with Tomcat. It allowed me to use the new 'var' syntax
with Java 10.

Unlike ECJ the javax.tools API cannot take an existing ClassLoader but
expects a list of files. So it is probably slower, and I guess it
doesn't support non unpacked war files. The javax.tools API also
requires the JDK (the JRE has the API but not the underlying
implementation).

So this compiler is quite equivalent to the Ant based compiler, but at
least it doesn't require an additional jar.

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

2018-04-06 Thread Emmanuel Bourg
Le 03/04/2018 à 22:36, Mark Thomas a écrit :

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

Tested on Debian sid with OpenJDK 9.

I got a couple of test failures in TestOpenSSLConf
but that doesn't seem critical:

Testcase: testOpenSSLConfCmdCipher took 0.481 sec
FAILED
Wrong HostConfig ciphers
Expected: is ["AES256-SHA256"]
 but: was ["TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8", 
"TLS_ECDHE_ECDSA_WITH_AES_256_CCM", "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384", 
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384", "TLS_ECDHE_RSA_WITH_AES_256_CBC_$
junit.framework.AssertionFailedError: Wrong HostConfig ciphers
Expected: is ["AES256-SHA256"]
 but: was ["TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8", 
"TLS_ECDHE_ECDSA_WITH_AES_256_CCM", "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384", 
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384", "TLS_ECDHE_RSA_WITH_AES_256_CBC_$
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at 
org.apache.tomcat.util.net.openssl.TestOpenSSLConf.testOpenSSLConfCmdCipher(TestOpenSSLConf.java:85)
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)

Testcase: testOpenSSLConfCmdProtocol took 0.008 sec
FAILED
Protocol TLSv1 is not allowed
junit.framework.AssertionFailedError: Protocol TLSv1 is not allowed
at 
org.apache.tomcat.util.net.openssl.TestOpenSSLConf.testOpenSSLConfCmdProtocol(TestOpenSSLConf.java:105)
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)

Emmanuel Bourg

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



javax.tools based JSP compiler

2018-04-04 Thread Emmanuel Bourg
Hi all,

Has anyone considered using the javax.tools API (JSR 199) to compile the
JSPs yet? This could provide a unified API to compile the JSPs since ECJ
also implements this API, and it would simplify the integration of javac
with Tomcat (no need to copy the Ant jars). With the new Java release
schedule I think more people will consider switching to javac to benefit
from the new language features before ECJ implements them, better
integrating javac would help this use case.

Emmanuel Bourg

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



Re: svn commit: r1825106 [5/5] - in /tomcat/site/trunk: docs/security-7.html docs/security-8.html docs/security-9.html xdocs/security-7.xml xdocs/security-8.xml xdocs/security-9.xml

2018-02-22 Thread Emmanuel Bourg
Le 23/02/2018 à 01:25, ma...@apache.org a écrit :
> +This issue was by the Apache Tomcat Security on 1 February 2018 and 
> made
> +   public on 23 February 2018.

The word "identified" is missing in this sentence.

Emmanuel Bourg

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



Re: [Git migration] How to handle svn:external used by Tomcat Native

2018-02-20 Thread Emmanuel Bourg
Le 20/02/2018 à 13:42, Mark Thomas a écrit :

> But they'd be in the source bundle. Isn't that sufficient to build off-line?

Yes it is, and that's fine for Debian (Although currently the Debian
package doesn't use the source bundle but checks out from SVN, but this
can be changed).

> I'm not clear on what Debian needs here. There clearer you can be, the
> more likely we are to pick a solution that works for Debian as well as
> Tomcat.

I see two options:
1) Turn Tomcat Native into a "standard" dependency (bundled in its own
jar downloaded from Maven Central)
2) Add an independent Ant target that downloads the Tomcat Native source
files into the Tomcat source tree, the commit hash or tag being
specified in a build property.

Emmanuel Bourg

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



Re: [Git migration] How to handle svn:external used by Tomcat Native

2018-02-19 Thread Emmanuel Bourg
Le 14/02/2018 à 13:11, Rainer Jung a écrit :

> I guess we would bundle the Java sources in any source distribution we
> provide. So only people wanting to do a release would need to run that
> "grab Java files from Tomcat" step. The step would be done by the
> release script.

Copying the source files at release time will not be enough since they
are required to build the project even outside any release activity.

Also, someone checking out a previous tag will have to fetch the version
of tcnative that was used at this time instead of the current HEAD of
the repository. So this means the right hash/tag expected will have to
be specified in the build properties.

Emmanuel Bourg

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



Re: [Git migration] How to handle svn:external used by Tomcat Native

2018-02-14 Thread Emmanuel Bourg
Le 11/02/2018 à 21:36, Mark Thomas a écrit :

> Thoughts? comments?

I'd like to suggest an alternative: what about packaging the Java part
of tomcat-native into a jar (and potentially publishing it to Maven
Central) and then adding it to the Tomcat dependencies?

Emmanuel Bourg

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



Re: [Git migration] How to handle svn:external used by Tomcat Native

2018-02-14 Thread Emmanuel Bourg
Le 12/02/2018 à 19:43, Christopher Schultz a écrit :

> Is there also option 3) amend the build process to fetch the source
> from svn?

This would be a bit inconvenient for Linux distributions like Debian
that build Tomcat in offline mode.

Emmanuel Bourg

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



Re: [Git migration] trunk or master

2018-01-09 Thread Emmanuel Bourg
Le 08/01/2018 à 15:33, Mark Thomas a écrit :

> Thoughts?

+1 for master

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



Re: Dynamic reloading of SSL certificates

2018-01-02 Thread Emmanuel Bourg
Le 02/01/2018 à 09:40, Romain Manni-Bucau a écrit :
> up?

I haven't got much time to look into this yet. However since Let's
Encrypt client implementations in Java are starting to appear [1] I
wonder if the certificate renewal process could be directly integrated
into Tomcat instead of relying on an external client such as certbot.

Emmanuel Bourg

[1] https://github.com/shred/acme4j

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



Re: svn commit: r1816418 - in /tomcat/trunk: java/javax/websocket/WebSocketContainer.java java/org/apache/tomcat/websocket/WsWebSocketContainer.java test/org/apache/tomcat/websocket/TestWsWebSocketCon

2017-12-10 Thread Emmanuel Bourg
Le 27/11/2017 à 11:33, ma...@apache.org a écrit :

> Modified: tomcat/trunk/java/javax/websocket/WebSocketContainer.java
> URL: 
> http://svn.apache.org/viewvc/tomcat/trunk/java/javax/websocket/WebSocketContainer.java?rev=1816418=1816417=1816418=diff
> ==
> --- tomcat/trunk/java/javax/websocket/WebSocketContainer.java (original)
> +++ tomcat/trunk/java/javax/websocket/WebSocketContainer.java Mon Nov 27 
> 10:33:22 2017
> @@ -33,9 +33,20 @@ public interface WebSocketContainer {
>   * Set the default timeout for sending a message asynchronously.
>   * @param timeout The new default timeout in milliseconds. A non-positive
>   *value means an infinite timeout.
> + *
> + * @deprecated This will be removed in Tomcat 9.
> + * Use {@link #setDefaultAsyncSendTimeout(long)}
>   */
> +@Deprecated
>  void setAsyncSendTimeout(long timeout);
>  
> +/**
> + * Set the default timeout for sending a message asynchronously.
> + * @param timeout The new default timeout in milliseconds. A non-positive
> + *value means an infinite timeout.
> + */
> +void setDefaultAsyncSendTimeout(long timeout);
> +

Hi Mark,

The extra setDefaultAsyncSendTimeout method in WebSocketContainer isn't
defined in the WebSocket API 1.1. Is this divergence with the
specification intended? In Debian the tomcat-websocket-api artifact is
used as the reference WebSocket API and this change caused a couple of
packages to fail to build.

Emmanuel Bourg

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



Re: Migrating to git

2017-12-05 Thread Emmanuel Bourg
Le 05/12/2017 à 21:03, Mark Thomas a écrit :

> and then migrate /trunk, /tags and /branches to git, leaving the rest in
> place. Most will stay there. Some components may move to git in the future.

The goal is to put all Tomcat versions in the same Git repository right?
Would that make the svn tags available as git tags or git branches? Is
svn2git able to aggregate several tags directories (tags/tc7.0.x/*,
tags/tc8.0.x/, etc) ? If not the tags could probably be merged in the
same directory before the migration.

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

2017-11-27 Thread Emmanuel Bourg
Le 27/11/2017 à 14:46, Mark Thomas a écrit :

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

+1, I successfully ran the 3 test suites on Debian with OpenJDK 8.
With OpenJDK 9 I got an illegal reflective access warning in
WebappClassLoaderBase and a test failure with TestStandardJarScanner:

Testcase: testWebappClassPath took 0.059 sec
FAILED
Unexpected class loader type: jdk.internal.loader.ClassLoaders$AppClassLoader
junit.framework.AssertionFailedError: Unexpected class loader type: 
jdk.internal.loader.ClassLoaders$AppClassLoader
at 
org.apache.tomcat.util.scan.TestStandardJarScanner.testWebappClassPath(TestStandardJarScanner.java:74)
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)

Emmanuel Bourg

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



Re: Java 9, modularisation and build systems

2017-10-09 Thread Emmanuel Bourg
Le 9/10/2017 à 10:23, Mark Thomas a écrit :

> - Back-ports would become more difficult unless all currently supported
>   versions were also back-ported (which increases the costs of
>   transition)

This is an important point. Maybe the older versions of Tomcat could
just adopt the new source layout (/src/main/java) but keep Ant
as the build system. Thus, the patches could be backported without
changing the paths.


> - If we change the layout of the currently supported versions, that will
>   create costs for downstream packagers

As far as Debian is concerned, switching to Maven shouldn't be that
disruptive, the tool is well supported now. Ubuntu folks on the other
hand may be less happy because they didn't include Maven in their main
repository yet, unlike Tomcat and Ant. Changing the build system would
force them to officially support Maven, which isn't a bad thing in 2017
anyway.


> - We'd need to write a code-signing plug-in for Maven

I did write a code-signing plug-in for Maven, maybe it could be extended
to work with the Symantec service used by Tomcat?

https://ebourg.github.io/jsign/


> - We'd need to write a plug-in to use NSIS or continue to use Ant for
>   the Windows Installer

No need to write a plug-in for this I think, NSIS could be invoked with
the maven-antrun-plugin.

Emmanuel Bourg

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



Re: Java 9, modularisation and build systems

2017-10-06 Thread Emmanuel Bourg
Le 6/10/2017 à 13:10, Martin Grigorov a écrit :

> I personally prefer Maven because it is more consistent.
> With free-style build tools like Ant, Gradle, sbt one has to invest some
> time to understand the build and be able to make changes.

+1, the standardized project structure brought by Maven makes it easy
for newcomers to jump into the project. Gradle builds tend to be just as
messy as the Ant ones.

Emmanuel Bourg

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



Preventing security reports on Bugzilla

2017-09-20 Thread Emmanuel Bourg
Hi,

What about creating a 'security' component for Tomcat in Bugzilla with
an all caps description explaining it should go to
secur...@tomcat.apache.org instead? This may prevent some accidental
reports sent to Bugzilla.

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

2017-09-18 Thread Emmanuel Bourg
Le 13/09/2017 à 23:02, Mark Thomas a écrit :

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

Unit tests passed on Debian with OpenJDK 8.

Emmanuel Bourg



signature.asc
Description: OpenPGP digital signature


Re: [VOTE] Release Apache Tomcat 8.5.19

2017-07-28 Thread Emmanuel Bourg
Le 25/07/2017 à 01:22, Mark Thomas a écrit :

> [X] Stable - go ahead and release as 8.5.19
+1, tested on Debian

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

2017-07-05 Thread Emmanuel Bourg
Le 4/07/2017 à 10:40, Mark Thomas a écrit :

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

+1, tested on Debian with OpenJDK 8u131.

Emmanuel Bourg

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



Re: [VOTE] 8.0.x EOL - 30 June 2018

2017-06-26 Thread Emmanuel Bourg
Le 24/06/2017 à 17:25, Mark Thomas a écrit :

> If 8.5.x was a drop-in replacement would that make a difference?

Yes that would help.


> And as a follow-up, what would need to change so 8.5.x was viewed a
> drop-in replacement?

The removal of the BIO connectors was the main issue reported. It broke
tomcatjss [1][2], dogtag [3][4] and jglobus [5].


> Anything else?

I can't remember of other issues with the transition to 8.5.

Emmanuel Bourg


[1] https://github.com/dogtagpki/tomcatjss
[2] https://bugs.debian.org/846677
[3] http://pki.fedoraproject.org
[4] https://bugs.debian.org/846714
[5] https://bugs.debian.org/846723

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



Re: [VOTE] 8.0.x EOL - 30 June 2018

2017-06-23 Thread Emmanuel Bourg
Le 23/06/2017 à 21:15, Christopher Schultz a écrit :

> The idea was to encourage package repository maintainers to migrate to
> Tomcat 8.5. If we never sundown Tomcat 8.0, they'll never move (witness
> the presence of Tomcat 6.0 still lurking around half the Internet).

As far as Debian is concerned, the migration to Tomcat 8.5 did happen in
Debian 9. But Debian 8 users are stuck with Tomcat 8.0.x until June
2020. Tomcat 8.5 isn't a drop-in replacement for Tomcat 8.0
unfortunately, so it's a bit difficult to push this upgrade in a stable
distribution.

Emmanuel Bourg

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



Re: [VOTE] 8.0.x EOL - 30 June 2018

2017-06-23 Thread Emmanuel Bourg
Le 23/06/2017 à 16:29, Christopher Schultz a écrit :

> Can you clarify: you voted to NOT ANNOUNCE Tomcat 8.0 EOL now, but it's
> not very kind to consumers to surprise them in 2018 by saying "security
> patches only" sometime later.
> 
> Why not state NOW that we will be EOLing Tomcat 8.0 in 2018 and starting
> NOW we will only provide security patches for it?

My concern is to keep having security support for Tomcat 8.0.x because
it will still be used by Linux distributions beyond June 2018 (and
probably others). Tomcat 8.0.x will be only 4 years old at this date,
that's a rather short life by Tomcat standards.

I wouldn't mind if feature updates stopped right now and if 8.0.x
received only security updates from now on (be it EOLed next year or
not). That would simplify the maintenance and encourage people to
upgrade to 8.5.

Emmanuel Bourg

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



Re: [VOTE] 8.0.x EOL - 30 June 2018

2017-06-22 Thread Emmanuel Bourg
Le 22/06/2017 à 17:18, Mark Thomas a écrit :

> [X] -1 We should not announce 8.0.x EOL at this time

I'd prefer security only releases for Tomcat 8.0.x beyond 30 June 2018
(or even sooner).

Emmanuel Bourg

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



Re: Timescale for 8.0.x EOL

2017-06-05 Thread Emmanuel Bourg
Le 5/06/2017 à 15:51, Mark Thomas a écrit :

> +1, for #1 and #3 assuming that we make this 30 June 2018.
> 
> I'm neutral on #2 since it is unlikely to be me doing the releases. I've
> no objection to monthly releases if someone wants to take that on. I
> suspect every 2 to 3 months would be sufficient.

On the Debian side we'll have to support Tomcat 8.0.x until April 2020
(end of Debian 8 "Jessie" LTS). Tomcat 8.0.x is also part of Ubuntu
16.04 LTS which is supported until April 2021. So if we can at least
backport the security fixes a bit longer that would be nice (I can help
with the backporting if necessary).

Emmanuel Bourg

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



Re: Proposal to remove AjpApr connector

2017-05-30 Thread Emmanuel Bourg
On 05/26/2017 01:46 PM, Mark Thomas wrote:

> It feels a bit late to do this for 9.0.x although we code if we wanted
> to. It is more of an option for 10.0.x.

Tomcat 9 is still in an alpha stage and not widely deployed yet. I
wouldn't be shocked if APR was dropped in this release.

Emmanuel Bourg

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



Re: Proposal to remove AjpApr connector

2017-05-30 Thread Emmanuel Bourg
On 05/30/2017 08:01 PM, Christopher Schultz wrote:

> Unless OpenSSL starts providing a JNI binding, we'll always have to
> have a wrapper for it.

Unless JNA is used. Has anyone experimented with this yet?

Emmanuel Bourg

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



Re: svn commit: r1794651 [1/3] - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/ant/ java/org/apache/catalina/ant/jmx/ java/org/apache/catalina/authenticator/ java/org/apache/cat

2017-05-10 Thread Emmanuel Bourg
Le 10/05/2017 à 12:04, Mark Thomas a écrit :

> No need to apologise. Doing that had been on my wish list for a long
> time but I hadn't found an easy way to do it. What it you use? Regexp?

I started with a regexp and then switched to the structural search and
replace feature of IntelliJ.


> I'm not very good at doing it myself but my experience of it is that
> back-porting code clean-up (i.e. non-functional changes) is worth doing
> for exactly that reason.

On the other hand code clean-up on the stable branches hurts the
backporting of security fixes to the versions maintained by the Linux
distributions. So with my Debian maintainer hat I'm a bit hesitating.

Emmanuel Bourg


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



  1   2   >