Re: [Git migration] Merge strategy

[Rémy Maucherat]

On Mon, Jan 22, 2018 at 10:16 PM, Mark Thomas  wrote:

> The plan when we migrate to git is to migrate to single git repo with
> the following branches:
>
> master - 9.0.x development
> tc8.5  - 8.5.x development
> tc8.0  - 8.0.x development
> tc7.0  - 7.0.x development
>
> We need to decide how we are going to handle a fix that applies to
> multiple versions.
>
> I can see two options:
>
> 1. Make the change in master and cherry-pick as required to earlier
>versions. This is, essentially, what we do now in svn.
>
> 2. Make the change in the earliest applicable version and them merge
>forward. This appears to be the more natural git way of doing things.
>

I've not seen 2 being done yet, to be honest.

Rémy


>
> These options are based on my fairly limited understanding of git.
> Suggestions for other approaches welcome.
>
> Thoughts? Comments?
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [Git migration] Merge strategy

[Martin Grigorov]

On Mon, Jan 22, 2018 at 10:45 PM, Mark Thomas  wrote:

> On 22/01/18 21:37, Martin Grigorov wrote:
> > Hi Mark,
> >
> > On Mon, Jan 22, 2018 at 10:16 PM, Mark Thomas  wrote:
> >
> >> The plan when we migrate to git is to migrate to single git repo with
> >> the following branches:
> >>
> >> master - 9.0.x development
> >> tc8.5  - 8.5.x development
> >> tc8.0  - 8.0.x development
> >> tc7.0  - 7.0.x development
> >>
> >> We need to decide how we are going to handle a fix that applies to
> >> multiple versions.
> >>
> >> I can see two options:
> >>
> >> 1. Make the change in master and cherry-pick as required to earlier
> >>versions. This is, essentially, what we do now in svn.
> >>
> >
> > I think this will not work.
> > "git merge" needs to know the common parent of the two HEADs to be able
> to
> > decide what to merge.
> > I am not sure how smart svn-to-git is these days but I doubt it will be
> > that smart.
>
> If by "this" in "this will not work" you mean forward merging, we can
>

Yes, I meant 1).


> make this work if we want to based on my limited testing. It requires a
> few extra commits to get the meta-data to the point where git thinks all
> previous changes have been merged. From that point it should work (with
> the odd merge conflict, as now).
>
> The tricky part for me is new features. These naturally get implemented
> against master and then we decide how far back to port them. That
> requires a new way of thinking if we do forward merging.
>
> > Wicket was also converted several years ago from SVN to Git and there we
> > use cherry-picking.
>
> That seems the obvious choice but I'm wary of taking the "that is how we
> have always done it in svn" approach if there is a better way in git -
> especially if I don't know about it.
>
> > For smaller projects which were started with Git I use git merge!
> > For feature branches (at work) I even use "git rebase" insteaf of merge.
> > But this also means you have to use "git push --force" to the remote of
> the
> > feature branch. But for feature branches this usually is OK.
>
> Feature branches is almost a whole other question but probably one that
> needs to be discussed on this thread.
>
> Mark
>
> >
> >
> >>
> >> 2. Make the change in the earliest applicable version and them merge
> >>forward. This appears to be the more natural git way of doing things.
> >>
> >> These options are based on my fairly limited understanding of git.
> >> Suggestions for other approaches welcome.
> >>
> >> Thoughts? Comments?
> >>
> >> 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: [Git migration] Merge strategy

[jean-frederic clere]

On 22/01/18 22:16, Mark Thomas wrote:
> 1. Make the change in master and cherry-pick as required to earlier
>versions. This is, essentially, what we do now in svn.

That is what most of the github "hosted" projects are doing, so +1 for it.

Additionally it prevents forgetting fixing master...

Cheers

Jean-Frederic

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

Re: [Git migration] Merge strategy

[Violeta Georgieva]

2018-01-22 23:16 GMT+02:00 Mark Thomas :
>
> The plan when we migrate to git is to migrate to single git repo with
> the following branches:
>
> master - 9.0.x development
> tc8.5  - 8.5.x development
> tc8.0  - 8.0.x development
> tc7.0  - 7.0.x development
>
> We need to decide how we are going to handle a fix that applies to
> multiple versions.
>
> I can see two options:
>
> 1. Make the change in master and cherry-pick as required to earlier
>versions. This is, essentially, what we do now in svn.

+1 cherry-pick

Regard,
Violeta

> 2. Make the change in the earliest applicable version and them merge
>forward. This appears to be the more natural git way of doing things.
>
> These options are based on my fairly limited understanding of git.
> Suggestions for other approaches welcome.
>
> Thoughts? Comments?
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

Re: [Git migration] Merge strategy

[Huxing Zhang]

+1 on Option 1.
Our internal Tomcat fork has basically the same structure, and we use option 1.
I can't find an easy way to implement option 2.

On Tue, Jan 23, 2018 at 5:16 AM, Mark Thomas  wrote:
> The plan when we migrate to git is to migrate to single git repo with
> the following branches:
>
> master - 9.0.x development
> tc8.5  - 8.5.x development
> tc8.0  - 8.0.x development
> tc7.0  - 7.0.x development
>
> We need to decide how we are going to handle a fix that applies to
> multiple versions.
>
> I can see two options:
>
> 1. Make the change in master and cherry-pick as required to earlier
>versions. This is, essentially, what we do now in svn.
>
> 2. Make the change in the earliest applicable version and them merge
>forward. This appears to be the more natural git way of doing things.
>
> These options are based on my fairly limited understanding of git.
> Suggestions for other approaches welcome.
>
> Thoughts? Comments?
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>



-- 
Best Regards！
Huxing

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

Re: [Git migration] Merge strategy

[Mark Thomas]

On 22/01/18 21:37, Martin Grigorov wrote:
> Hi Mark,
> 
> On Mon, Jan 22, 2018 at 10:16 PM, Mark Thomas  wrote:
> 
>> The plan when we migrate to git is to migrate to single git repo with
>> the following branches:
>>
>> master - 9.0.x development
>> tc8.5  - 8.5.x development
>> tc8.0  - 8.0.x development
>> tc7.0  - 7.0.x development
>>
>> We need to decide how we are going to handle a fix that applies to
>> multiple versions.
>>
>> I can see two options:
>>
>> 1. Make the change in master and cherry-pick as required to earlier
>>versions. This is, essentially, what we do now in svn.
>>
> 
> I think this will not work.
> "git merge" needs to know the common parent of the two HEADs to be able to
> decide what to merge.
> I am not sure how smart svn-to-git is these days but I doubt it will be
> that smart.

If by "this" in "this will not work" you mean forward merging, we can
make this work if we want to based on my limited testing. It requires a
few extra commits to get the meta-data to the point where git thinks all
previous changes have been merged. From that point it should work (with
the odd merge conflict, as now).

The tricky part for me is new features. These naturally get implemented
against master and then we decide how far back to port them. That
requires a new way of thinking if we do forward merging.

> Wicket was also converted several years ago from SVN to Git and there we
> use cherry-picking.

That seems the obvious choice but I'm wary of taking the "that is how we
have always done it in svn" approach if there is a better way in git -
especially if I don't know about it.

> For smaller projects which were started with Git I use git merge!
> For feature branches (at work) I even use "git rebase" insteaf of merge.
> But this also means you have to use "git push --force" to the remote of the
> feature branch. But for feature branches this usually is OK.

Feature branches is almost a whole other question but probably one that
needs to be discussed on this thread.

Mark

> 
> 
>>
>> 2. Make the change in the earliest applicable version and them merge
>>forward. This appears to be the more natural git way of doing things.
>>
>> These options are based on my fairly limited understanding of git.
>> Suggestions for other approaches welcome.
>>
>> Thoughts? Comments?
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>
> 


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

Re: [VOTE] Release Apache Tomcat 7.0.84

[Mark Thomas]

On 19/01/18 15:41, Violeta Georgieva wrote:
> The proposed Apache Tomcat 7.0.84 release is now available for voting.
> 
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.84/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1168/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_84/
> 
> The proposed 7.0.84 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 7.0.84 Stable

Unit tests pass for BIO, NIO and APR/native on Windows, Linux and OSX.

Mark

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

Re: [Git migration] Merge strategy

[Martin Grigorov]

Hi Mark,

On Mon, Jan 22, 2018 at 10:16 PM, Mark Thomas  wrote:

> The plan when we migrate to git is to migrate to single git repo with
> the following branches:
>
> master - 9.0.x development
> tc8.5  - 8.5.x development
> tc8.0  - 8.0.x development
> tc7.0  - 7.0.x development
>
> We need to decide how we are going to handle a fix that applies to
> multiple versions.
>
> I can see two options:
>
> 1. Make the change in master and cherry-pick as required to earlier
>versions. This is, essentially, what we do now in svn.
>

I think this will not work.
"git merge" needs to know the common parent of the two HEADs to be able to
decide what to merge.
I am not sure how smart svn-to-git is these days but I doubt it will be
that smart.
Wicket was also converted several years ago from SVN to Git and there we
use cherry-picking.
For smaller projects which were started with Git I use git merge!
For feature branches (at work) I even use "git rebase" insteaf of merge.
But this also means you have to use "git push --force" to the remote of the
feature branch. But for feature branches this usually is OK.


>
> 2. Make the change in the earliest applicable version and them merge
>forward. This appears to be the more natural git way of doing things.
>
> These options are based on my fairly limited understanding of git.
> Suggestions for other approaches welcome.
>
> Thoughts? Comments?
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

[Git migration] Merge strategy

[Mark Thomas]

The plan when we migrate to git is to migrate to single git repo with
the following branches:

master - 9.0.x development
tc8.5  - 8.5.x development
tc8.0  - 8.0.x development
tc7.0  - 7.0.x development

We need to decide how we are going to handle a fix that applies to
multiple versions.

I can see two options:

1. Make the change in master and cherry-pick as required to earlier
   versions. This is, essentially, what we do now in svn.

2. Make the change in the earliest applicable version and them merge
   forward. This appears to be the more natural git way of doing things.

These options are based on my fairly limited understanding of git.
Suggestions for other approaches welcome.

Thoughts? Comments?

Mark

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

Re: [Git migration] Existing PRs

[Mark Thomas]

On 19/01/18 10:38, Violeta Georgieva wrote:
> 2018-01-18 22:40 GMT+02:00 Mark Thomas :
>>
>> Hi,
>>
>> This issue might have resolved itself. We currently only have open PRs
>> on the apache/tomcat github repo. Assuming that repo would be made
>> read/write (I'm checking with infra) then there isn't a problem.

Confirmed that this is the case.

>> If anyone opnes a PR on one of the other repos between now and migration
>> we can simply ask then to redo the PR against apache/tomcat
> 
> +1

I'm going to resolve this issue as described.

Mark

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

[Bug 62033] Required SSLHostConfig named _default_

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=62033

Coty Sutherland  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #1 from Coty Sutherland  ---
Derp, scratch that. I think that the way we're doing it is pretty sensible. The
message even tells you that defaultSSLHostConfigName is missing. Maybe it isn't
obvious enough?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 62033] New: Required SSLHostConfig named _default_

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=62033

Bug ID: 62033
   Summary: Required SSLHostConfig named _default_
   Product: Tomcat 9
   Version: 9.0.2
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Util
  Assignee: dev@tomcat.apache.org
  Reporter: csuth...@apache.org
  Target Milestone: -

When using an SSLHostConfig in your SSL Connector there has to be one named
"_default_". If there isn't, you will get the following exception:

~~~
Caused by: java.lang.IllegalArgumentException: No SSLHostConfig element was
found with the hostName [_default_] to match the defaultSSLHostConfigName for
the connector [https-openssl-nio-8443]
~~~

and the Connector will fail to start. This behavior can be reproduced using the
following Connector configuration:

~~~





~~~

Is that really necessary? I've seen a few users try to specify "localhost" as
the hostName on the config to tie certificates to (I assume), which causes this
failure and forces them to remove hostName or use "_default_", but tomcat
doesn't behave that way with any other configuration elements. Could we do
something like httpd does with VirtualHost and make the first one listed (or
the auto-generated one from SSLHostConfig attributes placed in a Connector
element) be the default?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1821943 - /tomcat/tc7.0.x/trunk/test/org/apache/catalina/authenticator/TestSSOnonLoginAndBasicAuthenticator.java

[markt]

Author: markt
Date: Mon Jan 22 20:37:15 2018
New Revision: 1821943

URL: http://svn.apache.org/viewvc?rev=1821943&view=rev
Log:
Back-port robustness change after I observed a failure on one connector on OSX 
(the system was under load at the time).

Modified:

tomcat/tc7.0.x/trunk/test/org/apache/catalina/authenticator/TestSSOnonLoginAndBasicAuthenticator.java

Modified: 
tomcat/tc7.0.x/trunk/test/org/apache/catalina/authenticator/TestSSOnonLoginAndBasicAuthenticator.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/test/org/apache/catalina/authenticator/TestSSOnonLoginAndBasicAuthenticator.java?rev=1821943&r1=1821942&r2=1821943&view=diff
==
--- 
tomcat/tc7.0.x/trunk/test/org/apache/catalina/authenticator/TestSSOnonLoginAndBasicAuthenticator.java
 (original)
+++ 
tomcat/tc7.0.x/trunk/test/org/apache/catalina/authenticator/TestSSOnonLoginAndBasicAuthenticator.java
 Mon Jan 22 20:37:15 2018
@@ -95,9 +95,8 @@ public class TestSSOnonLoginAndBasicAuth
 
 // now compute some delays - beware of the units!
 private static final int EXTRA_DELAY_SECS = 5;
-private static final long REASONABLE_MSECS_TO_EXPIRY =
-(((MANAGER_SCAN_INTERVAL_SECS * MANAGER_EXPIRE_SESSIONS_FAST)
-+ EXTRA_DELAY_SECS) * 1000);
+private static final int TIMEOUT_WAIT_SECS =  EXTRA_DELAY_SECS +
+(MANAGER_SCAN_INTERVAL_SECS * MANAGER_EXPIRE_SESSIONS_FAST) * 5;
 
 private static final String CLIENT_AUTH_HEADER = "authorization";
 private static final String SERVER_AUTH_HEADER = "WWW-Authenticate";
@@ -163,7 +162,7 @@ public class TestSSOnonLoginAndBasicAuth
  * Wait until the SSO session times-out, then try to re-access
  * the resource. This should be rejected with SC_FORBIDDEN 401 status.
  *
- * Note: this test will run for slightly more than 1 minute.
+ * Note: this test should run for ~10 seconds.
  */
 @Test
 public void testBasicAccessAndSessionTimeout() throws Exception {
@@ -306,7 +305,7 @@ public class TestSSOnonLoginAndBasicAuth
  *
  * (see bugfix https://bz.apache.org/bugzilla/show_bug.cgi?id=52303)
  *
- * Note: this test will run for slightly more than 3 minutes.
+ * Note: this test should run for ~20 seconds.
  */
 @Test
 public void testBasicExpiredAcceptProtectedWithCookies() throws Exception {
@@ -597,13 +596,27 @@ public class TestSSOnonLoginAndBasicAuth
 // leave it to be expired by the manager
 }
 }
+
+
 try {
-Thread.sleep(REASONABLE_MSECS_TO_EXPIRY);
+Thread.sleep(EXTRA_DELAY_SECS * 1000);
 } catch (InterruptedException ie) {
 // ignored
 }
 
-// paranoid verification that active sessions have now gone
+// Paranoid verification that active sessions have now gone
+int count = 0;
+sessions = manager.findSessions();
+while (sessions.length != 0 && count < TIMEOUT_WAIT_SECS) {
+try {
+Thread.sleep(1000);
+} catch (InterruptedException e) {
+// Ignore
+}
+sessions = manager.findSessions();
+count++;
+}
+
 sessions = manager.findSessions();
 Assert.assertTrue(sessions.length == 0);
 }



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

[Bug 62032] New: NPE caused by Connector and SSLHostConfig

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=62032

Bug ID: 62032
   Summary: NPE caused by Connector and SSLHostConfig
   Product: Tomcat 9
   Version: 9.0.2
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Util
  Assignee: dev@tomcat.apache.org
  Reporter: csuth...@redhat.com
  Target Milestone: -

This behavior was noted on a users list thread, but I think a BZ is in order to
make a more useful message for users.

Here is the Connector and SSLHostConfig that causes the problem:

~~~





~~~

The issue is that we're using sslProtocol on the Connector (which creates a
_default_ SSLHostConfig object; this could be any SSLHostConfig attribute) AND
defining an SSLHostConfig (with a name other than _default_ so they don't
clash). This causes the _default_ SSLHostConfig object to be created which then
tries to use a non-existent default PEM file and throws the NPE. The user knows
nothing of this and is confused because they provided a certificateKeystoreFile
in the configuration above, not a PEM file.

We need to catch and wrap this NPE in something more informative.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn propchange: r1807277 - svn:log

[rjung]

Author: rjung
Revision: 1807277
Modified property: svn:log

Modified: svn:log at Mon Jan 22 20:01:43 2018
--
--- svn:log (original)
+++ svn:log Mon Jan 22 20:01:43 2018
@@ -1,3 +1,6 @@
 Add support for OpenSSLConf to storeconfig.
 
 Backport of r1805550 from trunk.
+
+Completed by r1821935 adding the forgotten class
+"org.apache.catalina.storeconfig.OpenSSLConfSF".


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

svn commit: r1821935 - in /tomcat/tc8.5.x/trunk: ./ java/org/apache/catalina/storeconfig/OpenSSLConfSF.java

[rjung]

Author: rjung
Date: Mon Jan 22 19:53:29 2018
New Revision: 1821935

URL: http://svn.apache.org/viewvc?rev=1821935&view=rev
Log:
Add storeconfig class "org.apache.catalina.storeconfig.OpenSSLConfSF"
forgotten in r1807277.

Backport of r1821932 from trunk.

Added:
tomcat/tc8.5.x/trunk/java/org/apache/catalina/storeconfig/OpenSSLConfSF.java
  - copied unchanged from r1821932, 
tomcat/trunk/java/org/apache/catalina/storeconfig/OpenSSLConfSF.java
Modified:
tomcat/tc8.5.x/trunk/   (props changed)

Propchange: tomcat/tc8.5.x/trunk/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Mon Jan 22 19:53:29 2018
@@ -1,2 +1,2 @@
 /tomcat/tc8.0.x/trunk:1809644
-/tomcat/trunk:1734785,1734799,1734845,1734928,1735041,1735044,1735480,1735577,1735597,1735599-1735600,1735615,1736145,1736162,1736209,1736280,1736297,1736299,1736489,1736646,1736703,1736836,1736849,1737104-1737105,1737112,1737117,1737119-1737120,1737155,1737157,1737192,1737280,1737339,1737632,1737664,1737715,1737748,1737785,1737834,1737860,1737903,1737959,1738005,1738007,1738014-1738015,1738018,1738022,1738039,1738043,1738059-1738060,1738147,1738149,1738174-1738175,1738261,1738589,1738623-1738625,1738643,1738816,1738850,1738855,1738946-1738948,1738953-1738954,1738979,1738982,1739079-1739081,1739087,1739113,1739153,1739172,1739176,1739191,1739474,1739492,1739726,1739762,1739775,1739814,1739817-1739818,1739975,1740131,1740324,1740465,1740495,1740508-1740509,1740520,1740535,1740707,1740803,1740810,1740969,1740980,1740991,1740997,1741015,1741033,1741036,1741058,1741060,1741080,1741147,1741159,1741164,1741173,1741181,1741190,1741197,1741202,1741208,1741213,1741221,1741225,1741232,1741409
 
,1741501,1741677,1741892,1741896,1741984,1742023,1742042,1742071,1742090,1742093,1742101,1742105,1742111,1742139,1742146,1742148,1742166,1742181,1742184,1742187,1742246,1742248-1742251,1742263-1742264,1742268,1742276,1742369,1742387,1742448,1742509-1742512,1742917,1742919,1742933,1742975-1742976,1742984,1742986,1743019,1743115,1743117,1743124-1743125,1743134,1743425,1743554,1743679,1743696-1743698,1743700-1743701,1744058,1744064-1744065,1744125,1744149,1744194,1744229,1744270,1744323,1744432,1744684,1744697,1744705,1744713,1744760,1744786,1745083,1745142-1745143,1745145,1745177,1745179-1745180,1745227,1745248,1745254,1745337,1745467,1745473,1745535,1745576,1745735,1745744,1746304,1746306-1746307,1746319,1746327,1746338,1746340-1746341,1746344,1746427,1746441,1746473,1746490,1746492,1746495-1746496,1746499-1746501,1746503-1746507,1746509,1746549,1746551,1746554,1746556,1746558,1746584,1746620,1746649,1746724,1746939,1746989,1747014,1747028,1747035,1747210,1747225,1747234,1747253,1747
 
404,1747506,1747536,1747924,1747980,1747993,1748001,1748253,1748452,1748547,1748629,1748676,1748715,1749287,1749296,1749328,1749373,1749465,1749506,1749508,1749665-1749666,1749763,1749865-1749866,1749898,1749978,1749980,1750011,1750015,1750056,1750480,1750617,1750634,1750692,1750697,1750700,1750703,1750707,1750714,1750718,1750723,1750774,1750899,1750975,1750995,1751061,1751097,1751173,1751438,1751447,1751463,1751702,1752212,1752737,1752745,1753078,1753080,1753358,1753363,1754111,1754140-1754141,1754281,1754310,1754445,1754467,1754494,1754496,1754528,1754532-1754533,1754613,1754714,1754874,1754941,1754944,1754950-1754951,1755005,1755007,1755009,1755132,1755180-1755181,1755185,1755190,1755204-1755206,1755208,1755214,1755224,1755227,1755230,1755629,1755646-1755647,1755650,1755653,1755675,1755680,1755683,1755693,1755717,1755731-1755737,1755812,1755828,1755884,1755890,1755918-1755919,1755942,1755958,1755960,1755970,1755993,1756013,1756019,1756039,1756056,1756083-1756114,1756175,1756288-1
 
756289,1756408-1756410,1756778,1756798,1756878,1756898,1756939,1757123-1757124,1757126,1757128,1757132-1757133,1757136,1757145,1757167-1757168,1757175,1757180,1757182,1757195,1757271,1757278,1757347,1757353-1757354,1757363,1757374,1757399,1757406,1757408,1757485,1757495,1757499,1757527,1757578,1757684,1757722,1757727,1757790,1757799,1757813,1757853,1757883,1757903,1757976,1757997,1758000,1758058,1758072-1758075,1758078-1758079,1758223,1758257,1758261,1758276,1758292,1758369,1758378-1758383,1758421,1758423,1758425-1758427,1758430,1758443,1758448,1758459,1758483,1758486-1758487,1758499,1758525,1758556,1758580,1758582,1758584,1758588,1758842,1759019,1759212,1759224,1759227,1759252,1759274,1759513-1759516,1759611,1759757,1759785-1759790,1760005,1760022,1760109-1760110,1760135,1760200-1760201,1760227,1760300,1760397,1760446,1760454,1760640,1760648,1761057,1761422,1761491,1761498,1761500-1761501,1761550,1761553,1761572,1761574,1761625-1761626,1761628,1761682,1761740,1761752,1762051-176205
 
3,1762123,1762168,1762172,1762182,1762201-1762202,1762204,1762208,1762288,1762296,1762324,1762348,1762353,1762362,1762374,1762492,1762503,1762505,1762541,1762608,1762710,1762753,1762766,1762769,1762944,1762947,1762953,1763167,1763179,1763232,1763259,1763271

svn propchange: r1805550 - svn:log

[rjung]

Author: rjung
Revision: 1805550
Modified property: svn:log

Modified: svn:log at Mon Jan 22 19:45:44 2018
--
--- svn:log (original)
+++ svn:log Mon Jan 22 19:45:44 2018
@@ -1 +1,4 @@
 Add support for OpenSSLConf to storeconfig.
+
+Completed by r1821932 adding the forgotten class
+"org.apache.catalina.storeconfig.OpenSSLConfSF".


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

svn commit: r1821932 - /tomcat/trunk/java/org/apache/catalina/storeconfig/OpenSSLConfSF.java

[rjung]

Author: rjung
Date: Mon Jan 22 19:44:09 2018
New Revision: 1821932

URL: http://svn.apache.org/viewvc?rev=1821932&view=rev
Log:
Add storeconfig class "org.apache.catalina.storeconfig.OpenSSLConfSF"
forgotten in r1805550.

Added:
tomcat/trunk/java/org/apache/catalina/storeconfig/OpenSSLConfSF.java   
(with props)

Added: tomcat/trunk/java/org/apache/catalina/storeconfig/OpenSSLConfSF.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/storeconfig/OpenSSLConfSF.java?rev=1821932&view=auto
==
--- tomcat/trunk/java/org/apache/catalina/storeconfig/OpenSSLConfSF.java (added)
+++ tomcat/trunk/java/org/apache/catalina/storeconfig/OpenSSLConfSF.java Mon 
Jan 22 19:44:09 2018
@@ -0,0 +1,45 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.catalina.storeconfig;
+
+import java.io.PrintWriter;
+
+import org.apache.tomcat.util.net.openssl.OpenSSLConf;
+import org.apache.tomcat.util.net.openssl.OpenSSLConfCmd;
+
+/**
+ * Store OpenSSLConf
+ */
+public class OpenSSLConfSF extends StoreFactoryBase {
+
+/**
+ * Store nested OpenSSLConfCmd elements.
+ * {@inheritDoc}
+ */
+@Override
+public void storeChildren(PrintWriter aWriter, int indent, Object 
aOpenSSLConf,
+StoreDescription parentDesc) throws Exception {
+if (aOpenSSLConf instanceof OpenSSLConf) {
+OpenSSLConf openSslConf = (OpenSSLConf) aOpenSSLConf;
+// Store nested  elements
+OpenSSLConfCmd[] openSSLConfCmds = 
openSslConf.getCommands().toArray(new OpenSSLConfCmd[0]);
+storeElementArray(aWriter, indent + 2, openSSLConfCmds);
+}
+}
+
+}

Propchange: tomcat/trunk/java/org/apache/catalina/storeconfig/OpenSSLConfSF.java
--
svn:eol-style = native

Propchange: tomcat/trunk/java/org/apache/catalina/storeconfig/OpenSSLConfSF.java
--
svn:keywords = Author Date Id Revision



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

Re: CPU security fixes and performance

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rémy,

On 1/21/18 2:17 PM, Rémy Maucherat wrote:
> On Sat, Jan 20, 2018 at 5:42 PM, Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> Rémy,
> 
> On 1/19/18 11:18 AM, Rémy Maucherat wrote:
 I had a look at performance with the CPU security fixes on
 my Fedora 27. Although it is a bit early for final
 conclusions, I can report that they have an impact for
 Tomcat, but it doesn't seem it's as much as my initial
 measurements. I chose to use HTTP/2 this time, it's more
 complex.
 
 h2load -n 10 -c 10
 
 PTI on:
 
 docs/changelog.html NIO2: 17200 (sendfile, without it it is 
 slightly below NIO) NIO: 9000 APR: 14450
 
 /tomcat.gif NIO2: 52000 NIO: 47000 APR: 55000
 
 PTI off:
 
 docs/changelog.html NIO2: 19000 (sendfile) NIO: 9500
 APR:16000
 
 /tomcat.gif NIO2: 57000 NIO: 51000 APR: 59000
 
 The APR connector performs very well here, especially on the
 large file test.
> 
> This is all HTTPS, right (http/2 implies HTTPS). For NIO/NIO2,
> were you using OpenSSL or JSSE?
> 
> 
>> It's unencrypted h2c, I added that support to be able to use
>> h2load with Tomcat.
> 
> 
> 
> The numbers shown above are ... requests/sec?
> 
> 
>> Yes, but it doesn't matter much ;)

Well, it would make a big difference if it was total request time
(1.g. 10k requests). It would flip the logic around and make it look
like a CPU performance improvement ;)

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlpmLlUdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjT6hAAujEkGVqV0JkdpVgB
zPFP3goMJYRXgfXSs8MytF0Ma2Jgn2D0wXbbb6AJq1ScnwuMDQEnhL1Pcmx/sTHj
2dJO/H3fV0uv4kGikXrEyAonUnJdKXbrEWI6l4Ehq0YpIGa7KPB7vrFXLNOzr7fJ
p8dbDkecdQH9f1Rl+g8YP+am3IeIkEw4eoM1SdYRsiNmadal+nZRx3uOYDWyET/w
z/ePa2yLdecHSATv2fi2neQk31bMU32nVvpoG9bctc1W3vzgdgh/v419c2sEglcF
DZ6yyTOaUZnlBIyfDXw/yRK0df//91s6NVKetCDnvKUYjALEsoh0C82BXgRKpcCH
WlmxXaSi2+ISbnu0nHh3TIUh6l1GQrQVfpVb7peg1D6Y+71PkQntaBuXFFE0JllX
aTtdLDdgtSmhuPfR6DRFqJfeiPy7+XAFLh8+lx5d3MGxArxm1WUfTSeVESZXuhae
lZjjxTvbAHuOIulfNwEnCwufrn5e3GC2Ffgsw2SbPj3IhfWUBxEg4q8vtRamDUy3
2EQztoamSIGLOBTmUNK0Sq9/YbMHIw/LL0MmOFbd2PEUuB4p0Ch9Odea9I8LpeEH
Z6XLFVVdQ60t4cqk3CmnCj33D9cB32ojHi2RR1u3cyacYRKqTx9zhG7qhJajQMOz
67qQoO6yDwljT6NaKMEwYa0Ss2c=
=rEWW
-END PGP SIGNATURE-

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

[Bug 62023] Tomcat crashes when SSLprotocol value is defined

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=62023

--- Comment #10 from joe.fletc...@sscinc.com ---
Might this be in any way related to problems creating a JSSE configuration?
I ran into what looked like
https://bz.apache.org/bugzilla/show_bug.cgi?id=59910 when attempting to use a
keystore based on a CA wildcard certificate.
It seems to insist on using an alias of "tomcat" but even with a single entry
in the keystore with that alias it complains there is no valid certificate.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 62023] Tomcat crashes when SSLprotocol value is defined

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=62023

--- Comment #9 from Rainer Jung  ---
(In reply to Coty Sutherland from comment #7)
> I can reproduce this by adding any SSLHostConfig attribute to the Connector
> (namely `SSLVerifyClient="optional"`). The problem here is that when using
> APR and specifying Connector configuration which creates two '_default_'
> SSLHostConfig objects, tomcat-native crashes without providing any
> indication of what happened. That is not a great user experience :( This
> happens because org.apache.tomcat.util.net.AprEndpoint.releaseSSLContext()
> tries to release a zero context that tomcat-native asserts is non-zero (see
> tomcat-native native/src/sslcontext.c:363). After doing some tracing, it
> looks like AprEndpoint's releaseSSLContext method calls
> sslHostConfig.getOpenSslContext() and sslHostConfig.getOpenSslConfContext()
> which always seem to return 0. Is that correct behavior? It seems a bit
> buggy to me.
> 
> I was able to correct this behavior by adding two zero checks to the
> releaseSSLContext method in AprEndpoint:
> 
>  629 @Override
>  630 protected void releaseSSLContext(SSLHostConfig sslHostConfig) {
>  631 Long ctx = sslHostConfig.getOpenSslContext();
>  632 if (ctx != null && ctx != 0) {
>  633 SSLContext.free(ctx.longValue());
>  634 sslHostConfig.setOpenSslContext(null);
>  635 }
>  636 Long cctx = sslHostConfig.getOpenSslConfContext();
>  637 if (cctx != null && cctx != 0) {
>  638 SSLConf.free(cctx.longValue());
>  639 sslHostConfig.setOpenSslConfContext(null);
>  640 }
>  641 }
> 
> This causes the correct behavior to occur (at least it does the same thing
> as NioEndpoint and prints the endpoint.duplicateSslHostName message). I was
> going to push this, but given that I'm not sure how this OpenSSLContext
> stuff is supposed to work and the lack of javadocs in the new classes, I
> thought it best to get someone's opinion first.

Yes, the aded check against 0 instead of only checking against null looks OK.
The native pointer here is wrapper by a Long and the native null pointer would
be a (Long)0.

Regards,

Rainer

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 62023] Tomcat crashes when SSLprotocol value is defined

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=62023

--- Comment #8 from Remy Maucherat  ---
Yes, something is wrong as there are null checks, yet, the
sslHostConfig.getOpenSslContext() (same for the conf) return value cannot be
null (the default is Long 0). Hummm, I would standardize on null as the new
default value, so that if there's a problem it'll likely cause a NPE rather
than a crash.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 62023] Tomcat crashes when SSLprotocol value is defined

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=62023

--- Comment #7 from Coty Sutherland  ---
I can reproduce this by adding any SSLHostConfig attribute to the Connector
(namely `SSLVerifyClient="optional"`). The problem here is that when using APR
and specifying Connector configuration which creates two '_default_'
SSLHostConfig objects, tomcat-native crashes without providing any indication
of what happened. That is not a great user experience :( This happens because
org.apache.tomcat.util.net.AprEndpoint.releaseSSLContext() tries to release a
zero context that tomcat-native asserts is non-zero (see tomcat-native
native/src/sslcontext.c:363). After doing some tracing, it looks like
AprEndpoint's releaseSSLContext method calls sslHostConfig.getOpenSslContext()
and sslHostConfig.getOpenSslConfContext() which always seem to return 0. Is
that correct behavior? It seems a bit buggy to me.

I was able to correct this behavior by adding two zero checks to the
releaseSSLContext method in AprEndpoint:

 629 @Override
 630 protected void releaseSSLContext(SSLHostConfig sslHostConfig) {
 631 Long ctx = sslHostConfig.getOpenSslContext();
 632 if (ctx != null && ctx != 0) {
 633 SSLContext.free(ctx.longValue());
 634 sslHostConfig.setOpenSslContext(null);
 635 }
 636 Long cctx = sslHostConfig.getOpenSslConfContext();
 637 if (cctx != null && cctx != 0) {
 638 SSLConf.free(cctx.longValue());
 639 sslHostConfig.setOpenSslConfContext(null);
 640 }
 641 }

This causes the correct behavior to occur (at least it does the same thing as
NioEndpoint and prints the endpoint.duplicateSslHostName message). I was going
to push this, but given that I'm not sure how this OpenSSLContext stuff is
supposed to work and the lack of javadocs in the new classes, I thought it best
to get someone's opinion first.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1821876 - /tomcat/tc8.5.x/trunk/webapps/docs/changelog.xml

[markt]

Author: markt
Date: Mon Jan 22 15:09:26 2018
New Revision: 1821876

URL: http://svn.apache.org/viewvc?rev=1821876&view=rev
Log:
Add release date for 8.5.27

Modified:
tomcat/tc8.5.x/trunk/webapps/docs/changelog.xml

Modified: tomcat/tc8.5.x/trunk/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc8.5.x/trunk/webapps/docs/changelog.xml?rev=1821876&r1=1821875&r2=1821876&view=diff
==
--- tomcat/tc8.5.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc8.5.x/trunk/webapps/docs/changelog.xml Mon Jan 22 15:09:26 2018
@@ -54,7 +54,7 @@
 
   
 
-
+
   
 
   



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

svn commit: r24357 - /dev/tomcat/tomcat-8/v8.5.27/ /release/tomcat/tomcat-8/v8.5.27/

[markt]

Author: markt
Date: Mon Jan 22 15:08:23 2018
New Revision: 24357

Log:
Release 8.5.27

Added:
release/tomcat/tomcat-8/v8.5.27/
  - copied from r24356, dev/tomcat/tomcat-8/v8.5.27/
Removed:
dev/tomcat/tomcat-8/v8.5.27/


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

[RESULT][VOTE] Release Apache Tomcat 8.5.27

[Mark Thomas]

The following votes were cast:

Stable:
+1 (binding): remm, csutherl, violetagg, huxing, markt

The vote therefore passes.

Thank you to everyone who contributed to this release.

Mark

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

svn commit: r1821874 - /tomcat/trunk/webapps/docs/changelog.xml

[markt]

Author: markt
Date: Mon Jan 22 14:53:28 2018
New Revision: 1821874

URL: http://svn.apache.org/viewvc?rev=1821874&view=rev
Log:
Add release date for 9.0.4

Modified:
tomcat/trunk/webapps/docs/changelog.xml

Modified: tomcat/trunk/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1821874&r1=1821873&r2=1821874&view=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Mon Jan 22 14:53:28 2018
@@ -54,7 +54,7 @@
 
   
 
-
+
   
 
   



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

svn commit: r24356 - /dev/tomcat/tomcat-9/v9.0.4/ /release/tomcat/tomcat-9/v9.0.4/

[markt]

Author: markt
Date: Mon Jan 22 14:51:01 2018
New Revision: 24356

Log:
Release 9.0.4

Added:
release/tomcat/tomcat-9/v9.0.4/
  - copied from r24355, dev/tomcat/tomcat-9/v9.0.4/
Removed:
dev/tomcat/tomcat-9/v9.0.4/


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

[RESULT][VOTE] Release Apache Tomcat 9.0.4

[Mark Thomas]

The following votes were cast:

Stable:
+1 binding: remm, csutherl, violetagg, huxing, markt

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this round of releases.

Mark


On 18/01/18 20:14, Mark Thomas wrote:
> The proposed Apache Tomcat 9.0.4 release is now available for voting.
> 
> The major changes compared to the 9.0.2 release are:
> 
> - Modify the Default and WebDAV Servlets so that a 405 status code is
>   returned for PUT and DELETE requests when disabled via the readonly
>   initialisation parameter.
> 
> - Add support for GZIP compression with HTTP/2
> 
> - Expand the TLS functionality exposed via the Manager application
> 
> - Return a simple, plain text error message if a client attempts to make
>   a plain text HTTP connection to a TLS enabled NIO or NIO2 Connector.
> 
> 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.4/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1166/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_9_0_4/
> 
> The proposed 9.0.4 release is:
> [ ] Broken - do not release
> [ ] Alpha  - go ahead and release as 9.0.4
> [ ] Beta   - go ahead and release as 9.0.4
> [ ] Stable - go ahead and release as 9.0.4
> 
> -
> 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.0.49

[Mark Thomas]

On 19/01/18 21:08, Violeta Georgieva wrote:
> The proposed Apache Tomcat 8.0.49 release is now available for voting.
> 
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.49/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1169/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc8.0.x/tags/TOMCAT_8_0_49/
> 
> The proposed 8.0.49 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 8.0.49

Unit tests pass for BIO, NIO, NIO2 and APR/native with Tomcat Native
1.2.16 on OSX, Linux and Windows.

Mark

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

Re: Maven plugin for code-singing. Where to host?

[Mark Thomas]

On 19/01/18 10:56, Robert Munteanu wrote:
> On Fri, 2018-01-19 at 09:27 +, Mark Thomas wrote:
>> On 18/01/18 21:48, Robert Munteanu wrote:
>>> Hi,
>>>
>>> (Please keep me in CC, I'm not subscribed to this list)
>>>  
>>> I have developed a Maven plugin to use with Symantec's code
>>> signing.
>>> Currently it is hosted by the Apache Sling project at [1] but
>>> that's
>>> not a proper home for it.
>>>
>>> The code is a blatant copy-paste of the Tomcat Ant task with a
>>> couple
>>> of fixes, so in the future I hope to unify them - but first I'd
>>> like to
>>> find the best location for it for the code.
>>>
>>> I don't think Tomcat is necessarily the best place to host the code
>>> that's potentially useful ASF-wide, but it does not hurt to ask for
>>> opinions :-)
>>
>> I'd agree not here since we wouldn't use the plug-in.
>>
>> Given the code (plug-in and my Ant task) is pretty much done
>> (although
>> I'm sure there is plenty of scope to improve the code I wrote) and
>> there
>> have only been 2 developers I'm not sure a TLP is viable. However, a
>> TLP
>> probably needs to be involved as releases are required.
>>
>> I guess there is some work to extract the common code and provide the
>> Ant task and the Maven plug-in in a single JAR.
>>
>> Hmm.
>>
>> Maven plug-in. Ant task. Written in Java. Used by multiple projects.
>> Mature code. Ideally needs to be released. Primary audience is Apache
>> projects.
>>
>> How about Commons? It isn't a perfect fit but it looks to be the best
>> fit.
> 
> Commons sounds good to me. For the sake of completeness, Brian Demers
> suggested Creadur on users@infra .

This main issue with Creadur is that the code signing would be out of
scope (scope is set by the board resolution that establishes the PMC).

> Commons sounds good to me, just like Creadur. I would slightly incline
> towards Commons, since - as you mentioned - the audience is primarily
> Apache projects, but not exclusively.
> 
> How would this contribution proceeed? One way would be for Tomcat to
> contribute the current implementation and then I could refactor that
> into a reusable component  and submit the Maven plugin as well.

If you aren't already, subscribe to dev@commons.a.o. I'll raise this
there shortly.

Starting with the Tomcat class and then refactoring would work for me.

Mark

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

Re: [VOTE] Release Apache Tomcat 8.5.27

[Mark Thomas]

On 18/01/18 20:43, Mark Thomas wrote:



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

Unit tests pass for NIO, NIO2 and APR/native with Tomcat Native 1.2.16
on OSX, Linux and Windows.

Mark

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

Re: [VOTE] Release Apache Tomcat 8.0.49

[Coty Sutherland]

On Fri, Jan 19, 2018 at 4:08 PM, Violeta Georgieva  wrote:
> The proposed Apache Tomcat 8.0.49 release is now available for voting.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.49/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1169/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc8.0.x/tags/TOMCAT_8_0_49/
>
> The proposed 8.0.49 release is:
> [ ] Broken - do not release
> [x] Stable - go ahead and release as 8.0.49

+1

> Regards,
> Violeta

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

[Coty Sutherland]

On Fri, Jan 19, 2018 at 10:41 AM, Violeta Georgieva
 wrote:
> The proposed Apache Tomcat 7.0.84 release is now available for voting.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.84/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1168/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_84/
>
> The proposed 7.0.84 release is:
> [ ] Broken - do not release
> [x] Stable - go ahead and release as 7.0.84 Stable

+1

> Regards,
> Violeta

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

[Mark Thomas]

On 18/01/18 20:14, Mark Thomas wrote:



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

Unit tests pass for NIO, NIO2 and APR/native with Tomcat Native 1.2.16
on OSX, Linux and Windows.

Mark

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

svn commit: r1821838 - /tomcat/trunk/test/org/apache/tomcat/jni/TestSocketServerAnyLocalAddress.java

[markt]

Author: markt
Date: Mon Jan 22 11:28:17 2018
New Revision: 1821838

URL: http://svn.apache.org/viewvc?rev=1821838&view=rev
Log:
Improve failure message to aid debugging

Modified:
tomcat/trunk/test/org/apache/tomcat/jni/TestSocketServerAnyLocalAddress.java

Modified: 
tomcat/trunk/test/org/apache/tomcat/jni/TestSocketServerAnyLocalAddress.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/tomcat/jni/TestSocketServerAnyLocalAddress.java?rev=1821838&r1=1821837&r2=1821838&view=diff
==
--- 
tomcat/trunk/test/org/apache/tomcat/jni/TestSocketServerAnyLocalAddress.java 
(original)
+++ 
tomcat/trunk/test/org/apache/tomcat/jni/TestSocketServerAnyLocalAddress.java 
Mon Jan 22 11:28:17 2018
@@ -96,7 +96,7 @@ public class TestSocketServerAnyLocalAdd
 } else if (buf[0] == 'Z') {
 // NO-OP - connection closing
 } else {
-Assert.fail("Unexpected data");
+Assert.fail("Unexpected data [" + (char) buf[0] + "]");
 }
 }
 



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

[Huxing Zhang]

Hi, 

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

Unit test passed.
Examples ok.
Our test web application works fine.

--
Violeta Georgieva 
2018 Jan 21 (Sun) 22:21
Tomcat Developers List 
Re: [VOTE] Release Apache Tomcat 8.5.27


2018-01-18 22:43 GMT+02:00 Mark Thomas :
>
> The proposed Apache Tomcat 8.5.27 release is now available for voting.
>
> The major changes compared to the 8.5.24 release are:
>
> - Add support for GZIP compression with HTTP/2
>
> - Expand the TLS functionality exposed via the Manager application
>
> - Return a simple, plain text error message if a client attempts to make
>   a plain text HTTP connection to a TLS enabled NIO or NIO2 Connector.
>
> - Add a new system property
>   (org.apache.jasper.runtime.BodyContentImpl.BUFFER_SIZE) to control the
>   size of the buffer used by Jasper when buffering tag bodies.
>
>
> 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.27/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1167/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc8.5.x/tags/TOMCAT_8_5_27/
>
> The proposed 8.5.27 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 8.5.27

+1

Regards,
Violeta

[Bug 62028] New: Server Sent Event closed connection throws IOException

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=62028

Bug ID: 62028
   Summary: Server Sent Event closed connection throws IOException
   Product: Tomcat 9
   Version: unspecified
  Hardware: PC
Status: NEW
  Severity: normal
  Priority: P2
 Component: WebSocket
  Assignee: dev@tomcat.apache.org
  Reporter: arturogarciamar...@gmail.com
  Target Milestone: -

Created attachment 35693
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=35693&action=edit
Tomcat 9 log, regarding Server Sent Events

Hi.

Dealing with Server Sent Events, by using Spring server-side, I've realized
that clients (JavaScript apps) do NOT send a "closing" signal for example when
user decides to change from one page to another.
This "human" behaviour leads to an "IllegalStateException" throwed by Tomcat
whenever Spring-based server-side app tries to communicate with the client,
because "it's a client app".

What seems to happen it that client side, the web app opens the connection, the
browser tells Tomcat to keep opened an asynchronous connection, the client and
the server apps keep talking, but, when the client app decides to "move", no
one tell neither Tomcat nor Spring to "close" the connection.

The next time the server app tries to send something to the client, the
connection does NOT EXIST! so...  (see attached file)


Also, as you could see in the attached log file, there is another error raising
when Tomcat still keeps an asynchronous connection open and the Tomcat server
shuts down. This time is a NullPointerException, but also related with the same
origin.

I've been talking with Anne van Kesteren, from Mozilla ( see:
https://github.com/whatwg/html/issues/3380#issuecomment-359262402 ) but I have
got not a clear response...

Thanks all.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

JDK 10 Early Access b40 & JDK 8u172 Early Access b02 are available on jdk.java.net

[Rory O'Donnell]

 Hi Mark,

Happy New Year!

*OpenJDK builds - *JDK 10 Early Access build 40 is available at 
http://jdk.java.net/10/


 * These early-access, open-source builds are provided under the GNU
   General Public License, version 2, with the Classpath Exception
   .
 * Summary of changes :-
   https://download.java.net/java/jdk10/archive/40/jdk-10+40.html

*JDK 10 will enter Rampdown Phase Two on Thursday the 18th of January, 
2018. *


 * More details , see Mark Reinhold's email to jdk-dev mailing list [1]
 * The Rampdown Phase Two process will be similar to that of JDK 9 [2].
 * JDK 10 Schedule, Status & Features are available [3]

*JDK **8u172 Early-Access build 03*is available at :- 
http://jdk.java.net/8/


 * Summary of Changes here :-
   https://download.java.net/java/jdk8u172/changes/jdk8u172-b02.html




Regards,
Rory

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000416.html
[2] http://openjdk.java.net/projects/jdk/10/rdp-2
[3] http://openjdk.java.net/projects/jdk/10/

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland

Re: [VOTE] Release Apache Tomcat 7.0.84

[Rémy Maucherat]

On Fri, Jan 19, 2018 at 4:41 PM, Violeta Georgieva 
wrote:

> The proposed Apache Tomcat 7.0.84 release is now available for voting.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.84/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1168/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_84/
>
> The proposed 7.0.84 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 7.0.84 Stable
>
> Rémy

Re: [VOTE] Release Apache Tomcat 8.0.49

[Rémy Maucherat]

On Fri, Jan 19, 2018 at 10:08 PM, Violeta Georgieva 
wrote:

> The proposed Apache Tomcat 8.0.49 release is now available for voting.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.49/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1169/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc8.0.x/tags/TOMCAT_8_0_49/
>
> The proposed 8.0.49 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 8.0.49
>
> Rémy