Re: [VOTE] Release Apache Tomcat 7.0.93

[Huxing Zhang]

Hi,

On Sun, Feb 17, 2019 at 1:41 AM Violeta Georgieva  wrote:
>
> The proposed Apache Tomcat 7.0.93 release is now available for voting.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.93/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1204/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_93/
>

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

Signatures and hashes are good for the source release.
Unit test passed.
Example web application works fine.

>
> Regards,
> Violeta



-- 
Best Regards！
Huxing

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

[Bug 63184] SSI documentation is incomplete

[bugzilla]

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

--- Comment #3 from resea...@nightwatchcybersecurity.com ---
Pull request here:
https://github.com/apache/tomcat/pull/138

-- 
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: r1853828 - /tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java

[markt]

Author: markt
Date: Mon Feb 18 22:20:34 2019
New Revision: 1853828

URL: http://svn.apache.org/viewvc?rev=1853828&view=rev
Log:
Fix SpotBugs warning
(also thread safety)

Modified:
tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java

Modified: 
tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java?rev=1853828&r1=1853827&r2=1853828&view=diff
==
--- tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java 
(original)
+++ tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java 
Mon Feb 18 22:20:34 2019
@@ -472,7 +472,6 @@ public class TestNonBlockingAPI extends
 private static final long serialVersionUID = 1L;
 private final boolean async;
 private final boolean ignoreIsReady;
-public volatile TestReadListener listener;
 
 public NBReadServlet(boolean ignoreIsReady, boolean async) {
 this.async = async;
@@ -512,6 +511,7 @@ public class TestNonBlockingAPI extends
 });
 // step 2 - notify on read
 ServletInputStream in = req.getInputStream();
+TestReadListener listener;
 if (async) {
 listener = new TestAsyncReadListener(actx, false, 
ignoreIsReady);
 } else {



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

svn commit: r1853827 - /tomcat/trunk/java/org/apache/catalina/mbeans/JmxRemoteLifecycleListener.java

[markt]

Author: markt
Date: Mon Feb 18 21:43:10 2019
New Revision: 1853827

URL: http://svn.apache.org/viewvc?rev=1853827&view=rev
Log:
Extending SSLHostConfig makes this class Serializable so fix the resulting 
Spotbugs warning.

Modified:
tomcat/trunk/java/org/apache/catalina/mbeans/JmxRemoteLifecycleListener.java

Modified: 
tomcat/trunk/java/org/apache/catalina/mbeans/JmxRemoteLifecycleListener.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/mbeans/JmxRemoteLifecycleListener.java?rev=1853827&r1=1853826&r2=1853827&view=diff
==
--- 
tomcat/trunk/java/org/apache/catalina/mbeans/JmxRemoteLifecycleListener.java 
(original)
+++ 
tomcat/trunk/java/org/apache/catalina/mbeans/JmxRemoteLifecycleListener.java 
Mon Feb 18 21:43:10 2019
@@ -82,7 +82,7 @@ public class JmxRemoteLifecycleListener
 protected String accessFile = null;
 protected boolean useLocalPorts = false;
 
-protected JMXConnectorServer csPlatform = null;
+protected transient JMXConnectorServer csPlatform = null;
 
 /**
  * Get the inet address on which the Platform RMI server is exported.



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

svn commit: r1853826 - /tomcat/trunk/test/org/apache/tomcat/buildutil/translate/TestFixedStrings.java

[markt]

Author: markt
Date: Mon Feb 18 21:39:46 2019
New Revision: 1853826

URL: http://svn.apache.org/viewvc?rev=1853826&view=rev
Log:
Fix a couple of Spotbugs warnings

Modified:

tomcat/trunk/test/org/apache/tomcat/buildutil/translate/TestFixedStrings.java

Modified: 
tomcat/trunk/test/org/apache/tomcat/buildutil/translate/TestFixedStrings.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/tomcat/buildutil/translate/TestFixedStrings.java?rev=1853826&r1=1853825&r2=1853826&view=diff
==
--- 
tomcat/trunk/test/org/apache/tomcat/buildutil/translate/TestFixedStrings.java 
(original)
+++ 
tomcat/trunk/test/org/apache/tomcat/buildutil/translate/TestFixedStrings.java 
Mon Feb 18 21:39:46 2019
@@ -38,11 +38,14 @@ public class TestFixedStrings {
 File fileEn = new File(dir, Constants.L10N_PREFIX + 
Constants.L10N_SUFFIX);
 Properties propsEn = Utils.load(fileEn);
 
-for (File file : dir.listFiles()) {
-String fileName = file.getName();
-if (fileName.startsWith(Constants.L10N_PREFIX)) {
-if (Utils.getLanguage(fileName) != "en") {
-doTestStartsFile(file, propsEn, text);
+File[] files = dir.listFiles();
+if (files != null) {
+for (File file : files) {
+String fileName = file.getName();
+if (fileName.startsWith(Constants.L10N_PREFIX)) {
+if (!Utils.getLanguage(fileName).equals("en")) {
+doTestStartsFile(file, propsEn, text);
+}
 }
 }
 }



-
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

[Michael Osipov]

Am 2019-02-18 um 15:19 schrieb Igal Sapir:

On Mon, Feb 18, 2019 at 2:03 AM Mark Thomas  wrote:


On 18/02/2019 09:13, Rémy Maucherat wrote:

On Sat, Feb 16, 2019 at 4:09 PM Michael Osipov 

wrote:



Folks,

given that we are currently in the process of migrating to Git I'd like
to propose a more readible and with the branch names consistent tag
naming scheme.

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.

There are bascially two approaches I'd like to discuss:

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.

Finally it would be tomcat85-8.5.40, tomcat90-9.0.25. Another benefit
would be autocompletion in Git CLI. I could simply say: "git checkout
tomcat85" or "git checkout tomcat85-" and grab the specific version
I want.

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.

I personally opt for approach 2 because it is consistent, concise and
removes redundancy on always used prefixes.



I guess it's hard to argue against option 2.

The main downside is that it comes late and Mark already did the work and
lots of testing for his proposed plan.


The current, community agreed proposal for branch naming is "master,
tc8.5 and tc7.0"



That's fine by me.




There were strong views on the branch naming but "master, 8.5.x and
7.0.x" would be consistent with those views. I'm not sure I see much
difference between either approach. If there is a strong preference for
one over the other - or a good reason to choose one over the other -
please make those views known in the next few days.



No good reason.  Based on the OP I thought that we are comparing to a more
verbose scheme like "tomcat-90-xxx" (without the standard "master" branch).

I actually prefer "tc8.5" and "tc7.0" for the branches (over "8.5.x" and
"7.0.x").  If tags will only use the numeric versions then this will make
it easy to differentiate between branches and tags.


tc8.5 could also misread as 8.5 release. 8.5.x implies that this is in 
development. This a common scheme in many many repos.
Where is the benefit keeping the prefix? Git autocompletion will stop at 
"8.5." and you choose either 'x' or a patch release.


Michael


-
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

[Michael Osipov]

Am 2019-02-18 um 11:03 schrieb Mark Thomas:

On 18/02/2019 09:13, Rémy Maucherat wrote:

On Sat, Feb 16, 2019 at 4:09 PM Michael Osipov  wrote:


Folks,

given that we are currently in the process of migrating to Git I'd like
to propose a more readible and with the branch names consistent tag
naming scheme.

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.

There are bascially two approaches I'd like to discuss:

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.

Finally it would be tomcat85-8.5.40, tomcat90-9.0.25. Another benefit
would be autocompletion in Git CLI. I could simply say: "git checkout
tomcat85" or "git checkout tomcat85-" and grab the specific version
I want.

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.

I personally opt for approach 2 because it is consistent, concise and
removes redundancy on always used prefixes.



I guess it's hard to argue against option 2.

The main downside is that it comes late and Mark already did the work and
lots of testing for his proposed plan.


The current, community agreed proposal for branch naming is "master,
tc8.5 and tc7.0"

There were strong views on the branch naming but "master, 8.5.x and
7.0.x" would be consistent with those views. I'm not sure I see much
difference between either approach. If there is a strong preference for
one over the other - or a good reason to choose one over the other -
please make those views known in the next few days.


The current proposal, community agreed proposal for tags is to continue
with the current naming scheme. Switching to using the version as-is
(9.0.1, 9.0.2, etc) is doable. It is just a little more work during the
migration. If the as-is naming scheme makes it easier for downstream
users then that strikes me as a good reason to change it. Are there any
objections to doing so?


I'd be happy if we could clean that up..


-
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

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 2/18/19 05:03, Mark Thomas wrote:
> On 18/02/2019 09:13, Rémy Maucherat wrote:
>> On Sat, Feb 16, 2019 at 4:09 PM Michael Osipov
>>  wrote:
>> 
>>> Folks,
>>> 
>>> given that we are currently in the process of migrating to Git
>>> I'd like to propose a more readible and with the branch names
>>> consistent tag naming scheme.
>>> 
>>> 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.
>>> 
>>> There are bascially two approaches I'd like to discuss:
>>> 
>>> 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.
>>> 
>>> Finally it would be tomcat85-8.5.40, tomcat90-9.0.25. Another
>>> benefit would be autocompletion in Git CLI. I could simply say:
>>> "git checkout tomcat85" or "git checkout tomcat85-" and
>>> grab the specific version I want.
>>> 
>>> 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.
>>> 
>>> I personally opt for approach 2 because it is consistent,
>>> concise and removes redundancy on always used prefixes.
>>> 
>> 
>> I guess it's hard to argue against option 2.
>> 
>> The main downside is that it comes late and Mark already did the
>> work and lots of testing for his proposed plan.
> 
> The current, community agreed proposal for branch naming is
> "master, tc8.5 and tc7.0"
> 
> There were strong views on the branch naming but "master, 8.5.x
> and 7.0.x" would be consistent with those views. I'm not sure I see
> much difference between either approach. If there is a strong
> preference for one over the other - or a good reason to choose one
> over the other - please make those views known in the next few
> days.
> 
> 
> The current proposal, community agreed proposal for tags is to
> continue with the current naming scheme. Switching to using the
> version as-is (9.0.1, 9.0.2, etc) is doable. It is just a little
> more work during the migration. If the as-is naming scheme makes it
> easier for downstream users then that strikes me as a good reason
> to change it. Are there any objections to doing so?

No objections, here.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxrC9sACgkQHPApP6U8
pFiQ7g/9FwNkmK6aIGRCKIzeinQid1+umxHdOgobludzhnZcIObJKF9oALquyCgB
UivQfAU+Tcx1eoSwkKx7JDxq5MxkktfsKXzT9+L2eDfgMwyfaVjTtsq0Ia0Qmay6
OgDTspP95XZQlDoMhWNYS6zVqP/Yf4YIF6NxnA9ax+GGv6r4K6mED7oDbjHGXiq+
XqeFHibx0ynCai2L7S88UpIGiUWY70/l79+bZ3zOXfqmCRv4TotwuBoBh68RbYJB
A1x4VMs22OfuM9LF7K2kzAjtaEA4XNVn7sC1tYuwpr6LUx7gwlB1xB70F5oYiQlI
PhxYcSiFVnbiuROyU1cF1rOl6QuIQxhMYodABilEARrmoxk5vjG7f8ToOuUm0Wd1
yU02dt6B+rm3PHu5eFp5iRwHJiarYDFubO47Qwj0c+bkvn3R+u4XJ6CXMfV1j2SW
u7HjAjILU9iSAsVEIaYj04Ksv8A+6v6Czg4m/f8KWy+KX8nb50wfjfUiXfjdRB8m
saEOq03tjmlGfKipYPaNO3qUEP64S5EqJCyJj9acQ1ravd+8k1GteiUYuOWHFMzm
bNSAcb6YqKsqB//hSFRlIgsVTrr9/mx2FzhCzp/9a3RLzIsvA81Bxg6BHcJ91/cV
AVofdNE4X/WNsXoHDEx8FpgL/wCVbr3ODpt43SEv8f4XtsIrym0=
=gZ8p
-END PGP SIGNATURE-

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

[Bug 63184] SSI documentation is incomplete

[bugzilla]

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

--- Comment #2 from Christopher Schultz  ---
Patches are always welcome, including documentation patches.

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

buildbot success in on tomcat-trunk

[buildbot]

The Buildbot has detected a restored build on builder tomcat-trunk while 
building . Full details are available at:
https://ci.apache.org/builders/tomcat-trunk/builds/4057

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' 
triggered this build
Build Source Stamp: [branch tomcat/trunk] 1853811
Blamelist: remm

Build succeeded!

Sincerely,
 -The Buildbot




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

svn commit: r1853811 - /tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java

[remm]

Author: remm
Date: Mon Feb 18 16:01:34 2019
New Revision: 1853811

URL: http://svn.apache.org/viewvc?rev=1853811&view=rev
Log:
Restore NIO2 test skip

Modified:
tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java

Modified: 
tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java?rev=1853811&r1=1853810&r2=1853811&view=diff
==
--- tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java 
(original)
+++ tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java 
Mon Feb 18 16:01:34 2019
@@ -48,6 +48,7 @@ import javax.servlet.http.HttpServletReq
 import javax.servlet.http.HttpServletResponse;
 
 import org.junit.Assert;
+import org.junit.Assume;
 import org.junit.Ignore;
 import org.junit.Test;
 
@@ -97,6 +98,8 @@ public class TestNonBlockingAPI extends
 Tomcat tomcat = getTomcatInstance();
 Connector connector = tomcat.getConnector();
 // Skip for NIO2
+Assume.assumeFalse("This test may fail for NIO2",
+connector.getProtocolHandlerClassName().contains("Nio2"));
 doTestNonBlockingRead(false, true);
 }
 



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

svn commit: r1853810 - in /tomcat/trunk/test/org/apache/catalina/nonblocking: TestNonBlockingAPI.java TesterAjpNonBlockingClient.java

[remm]

Author: remm
Date: Mon Feb 18 16:00:03 2019
New Revision: 1853810

URL: http://svn.apache.org/viewvc?rev=1853810&view=rev
Log:
Missed constructor

Modified:
tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java

tomcat/trunk/test/org/apache/catalina/nonblocking/TesterAjpNonBlockingClient.java

Modified: 
tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java?rev=1853810&r1=1853809&r2=1853810&view=diff
==
--- tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java 
(original)
+++ tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java 
Mon Feb 18 16:00:03 2019
@@ -48,7 +48,6 @@ import javax.servlet.http.HttpServletReq
 import javax.servlet.http.HttpServletResponse;
 
 import org.junit.Assert;
-import org.junit.Assume;
 import org.junit.Ignore;
 import org.junit.Test;
 
@@ -98,8 +97,6 @@ public class TestNonBlockingAPI extends
 Tomcat tomcat = getTomcatInstance();
 Connector connector = tomcat.getConnector();
 // Skip for NIO2
-Assume.assumeFalse("This test may fail for NIO2",
-connector.getProtocolHandlerClassName().contains("Nio2"));
 doTestNonBlockingRead(false, true);
 }
 

Modified: 
tomcat/trunk/test/org/apache/catalina/nonblocking/TesterAjpNonBlockingClient.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/nonblocking/TesterAjpNonBlockingClient.java?rev=1853810&r1=1853809&r2=1853810&view=diff
==
--- 
tomcat/trunk/test/org/apache/catalina/nonblocking/TesterAjpNonBlockingClient.java
 (original)
+++ 
tomcat/trunk/test/org/apache/catalina/nonblocking/TesterAjpNonBlockingClient.java
 Mon Feb 18 16:00:03 2019
@@ -48,7 +48,7 @@ public class TesterAjpNonBlockingClient
 
 Map> resHeaders = new HashMap<>();
 ByteChunk out = new ByteChunk();
-int rc = postUrl(true, new DataWriter(2000), "http://localhost"; +
+int rc = postUrl(true, new DataWriter(2000, 5), "http://localhost"; +
 "/examples/servlets/nonblocking/bytecounter",
 out, resHeaders, null);
 



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

svn commit: r1853809 - in /tomcat/trunk/java/org/apache: catalina/manager/host/ catalina/mbeans/ catalina/tribes/membership/ coyote/http2/ tomcat/websocket/pojo/ tomcat/websocket/server/

[woonsan]

Author: woonsan
Date: Mon Feb 18 15:40:01 2019
New Revision: 1853809

URL: http://svn.apache.org/viewvc?rev=1853809&view=rev
Log:
Importing the latest 10 Korean translations from POEditor

Modified:

tomcat/trunk/java/org/apache/catalina/manager/host/LocalStrings_ko.properties
tomcat/trunk/java/org/apache/catalina/mbeans/LocalStrings_ko.properties

tomcat/trunk/java/org/apache/catalina/tribes/membership/LocalStrings_ko.properties
tomcat/trunk/java/org/apache/coyote/http2/LocalStrings_ko.properties

tomcat/trunk/java/org/apache/tomcat/websocket/pojo/LocalStrings_ko.properties

tomcat/trunk/java/org/apache/tomcat/websocket/server/LocalStrings_ko.properties

Modified: 
tomcat/trunk/java/org/apache/catalina/manager/host/LocalStrings_ko.properties
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/manager/host/LocalStrings_ko.properties?rev=1853809&r1=1853808&r2=1853809&view=diff
==
--- 
tomcat/trunk/java/org/apache/catalina/manager/host/LocalStrings_ko.properties 
[UTF-8] (original)
+++ 
tomcat/trunk/java/org/apache/catalina/manager/host/LocalStrings_ko.properties 
[UTF-8] Mon Feb 18 15:40:01 2019
@@ -15,6 +15,7 @@
 
 hostManagerServlet.add=추가: 호스트 [{0}]을(를) 추가합니다.
 hostManagerServlet.addFailed=실패 - 호스트 [{0}]을(를) 추가하지 못했습니다.
+hostManagerServlet.addSuccess=OK - 호스트 [{0}]이(가) 추가되었습니다.
 hostManagerServlet.alreadyHost=실패 - 이름이 [{0}]인 호스트가 이미 존재합니다.
 hostManagerServlet.alreadyStarted=실패 - 호스트 [{0}]은(는) 이미 시작되었습니다.
 hostManagerServlet.alreadyStopped=실패 - 호스트 [{0}]은(는) 이미 중지되었습니다.
@@ -38,6 +39,7 @@ hostManagerServlet.persisted=OK - 설정
 hostManagerServlet.postCommand=실패 - GET 요청을 통해 명령 [{0}]을(를) 사용하려 시도했지만, POST 
메소드가 필수적입니다.
 hostManagerServlet.remove=제거: 호스트 [{0}]을(를) 제거합니다.
 hostManagerServlet.removeFailed=실패 - 호스트 [{0}]을(를) 제거하지 못했습니다.
+hostManagerServlet.removeSuccess=OK - 호스트 [{0}]을(를) 제거했습니다.
 hostManagerServlet.start=시작: 이름이 [{0}]인 호스트를 시작합니다.
 hostManagerServlet.startFailed=실패 - 호스트 [{0}]을(를) 시작하지 못했습니다.
 hostManagerServlet.started=OK - 호스트 [{0}](이)가 시작되었습니다.

Modified: 
tomcat/trunk/java/org/apache/catalina/mbeans/LocalStrings_ko.properties
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/mbeans/LocalStrings_ko.properties?rev=1853809&r1=1853808&r2=1853809&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/mbeans/LocalStrings_ko.properties 
[UTF-8] (original)
+++ tomcat/trunk/java/org/apache/catalina/mbeans/LocalStrings_ko.properties 
[UTF-8] Mon Feb 18 15:40:01 2019
@@ -27,6 +27,7 @@ jmxRemoteLifecycleListener.createRegistr
 jmxRemoteLifecycleListener.createServerFailed=JMX connector 서버가 생성될 수 없었거나, 
[{0}] 서버를 위해 시작되지 못했습니다.
 jmxRemoteLifecycleListener.destroyServerFailed=[{0}] 서버를 위해, JMX connector 서버가 
중지될 수 없었습니다.
 jmxRemoteLifecycleListener.invalidRmiBindAddress=유효하지 않은 RMI 바인딩 주소 [{0}]
+jmxRemoteLifecycleListener.invalidSSLConfiguration=SSL 설정 오류
 jmxRemoteLifecycleListener.invalidURL=[{0}] 서버에 요청하는 JMX 서비스 URL [{1}]은(는) 
유효하지 않습니다.
 jmxRemoteLifecycleListener.start=[{2}] 서버를 위하여, JMX 원격 리스너가 포트 [{0}]에 레지스트리를 
설정했으며, 포트 [{1}]에 서버를 설정했습니다.
 

Modified: 
tomcat/trunk/java/org/apache/catalina/tribes/membership/LocalStrings_ko.properties
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/membership/LocalStrings_ko.properties?rev=1853809&r1=1853808&r2=1853809&view=diff
==
--- 
tomcat/trunk/java/org/apache/catalina/tribes/membership/LocalStrings_ko.properties
 [UTF-8] (original)
+++ 
tomcat/trunk/java/org/apache/catalina/tribes/membership/LocalStrings_ko.properties
 [UTF-8] Mon Feb 18 15:40:01 2019
@@ -62,4 +62,5 @@ staticMembershipProvider.replyRequest.ig
 staticMembershipProvider.startMembership.noReplies=응답을 하나도 받지 못했습니다. 아마도 제한 시간 
초과된 듯합니다.
 staticMembershipProvider.stopMembership.sendFailed=멤버십 중지 메시지를 보낼 수 없습니다.
 
+staticMembershipService.noLocalMember=정적 멤버 리스트 내에 로컬 멤버가 하나도 없습니다.
 staticMembershipService.stopFail=정적 멤버십 서비스를 중지시킬 수 없습니다. 레벨: [{0}]

Modified: tomcat/trunk/java/org/apache/coyote/http2/LocalStrings_ko.properties
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http2/LocalStrings_ko.properties?rev=1853809&r1=1853808&r2=1853809&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http2/LocalStrings_ko.properties 
[UTF-8] (original)
+++ tomcat/trunk/java/org/apache/coyote/http2/LocalStrings_ko.properties 
[UTF-8] Mon Feb 18 15:40:01 2019
@@ -91,6 +91,7 @@ stream.header.unknownPseudoHeader=연결
 stream.inputBuffer.copy=[{0}] 바이트를 inBuffer에서 outBuffer로 복사합니다.
 stream.inputBuffer.dispatch=readInterest가 등록될 때, 데이터가 inBuffer에 추가되었습니다. 읽기 
디스패치를 개시합니다.
 stream.inputBuffer.empty=스트림의 입력 버퍼가 비어 있습니다. 더 많은 데이터를 기다립니다.
+stream.inputBuffer.readTimeout=클라이언트로부터 데이터를 읽기를 일정 시간 동안 기다리

svn commit: r1853807 - in /tomcat/trunk/java: javax/el/ javax/servlet/ org/apache/catalina/authenticator/ org/apache/catalina/authenticator/jaspic/ org/apache/catalina/connector/ org/apache/catalina/c

[woonsan]

Author: woonsan
Date: Mon Feb 18 15:33:17 2019
New Revision: 1853807

URL: http://svn.apache.org/viewvc?rev=1853807&view=rev
Log:
set charset to UTF-8 on newly added cs/es bundles

Modified:
tomcat/trunk/java/javax/el/LocalStrings_cs.properties   (props changed)
tomcat/trunk/java/javax/servlet/LocalStrings_cs.properties   (props changed)

tomcat/trunk/java/org/apache/catalina/authenticator/LocalStrings_cs.properties  
 (props changed)

tomcat/trunk/java/org/apache/catalina/authenticator/jaspic/LocalStrings_cs.properties
   (props changed)
tomcat/trunk/java/org/apache/catalina/connector/LocalStrings_cs.properties  
 (props changed)
tomcat/trunk/java/org/apache/catalina/core/LocalStrings_cs.properties   
(props changed)
tomcat/trunk/java/org/apache/catalina/deploy/LocalStrings_cs.properties   
(props changed)
tomcat/trunk/java/org/apache/catalina/filters/LocalStrings_cs.properties   
(props changed)

tomcat/trunk/java/org/apache/catalina/ha/authenticator/LocalStrings_cs.properties
   (props changed)

tomcat/trunk/java/org/apache/catalina/ha/authenticator/LocalStrings_es.properties
   (props changed)
tomcat/trunk/java/org/apache/catalina/ha/deploy/LocalStrings_cs.properties  
 (props changed)
tomcat/trunk/java/org/apache/catalina/ha/session/LocalStrings_cs.properties 
  (props changed)
tomcat/trunk/java/org/apache/catalina/ha/tcp/LocalStrings_cs.properties   
(props changed)
tomcat/trunk/java/org/apache/catalina/loader/LocalStrings_cs.properties   
(props changed)
tomcat/trunk/java/org/apache/catalina/manager/LocalStrings_cs.properties   
(props changed)

tomcat/trunk/java/org/apache/catalina/manager/host/LocalStrings_cs.properties   
(props changed)
tomcat/trunk/java/org/apache/catalina/mapper/LocalStrings_cs.properties   
(props changed)
tomcat/trunk/java/org/apache/catalina/realm/LocalStrings_cs.properties   
(props changed)
tomcat/trunk/java/org/apache/catalina/servlets/LocalStrings_cs.properties   
(props changed)
tomcat/trunk/java/org/apache/catalina/session/LocalStrings_cs.properties   
(props changed)
tomcat/trunk/java/org/apache/catalina/startup/LocalStrings_cs.properties   
(props changed)

tomcat/trunk/java/org/apache/catalina/tribes/group/LocalStrings_cs.properties   
(props changed)

tomcat/trunk/java/org/apache/catalina/tribes/group/interceptors/LocalStrings_cs.properties
   (props changed)
tomcat/trunk/java/org/apache/catalina/tribes/io/LocalStrings_cs.properties  
 (props changed)

tomcat/trunk/java/org/apache/catalina/tribes/membership/LocalStrings_cs.properties
   (props changed)

tomcat/trunk/java/org/apache/catalina/tribes/membership/cloud/LocalStrings_cs.properties
   (props changed)

tomcat/trunk/java/org/apache/catalina/tribes/tipis/LocalStrings_cs.properties   
(props changed)

tomcat/trunk/java/org/apache/catalina/tribes/transport/LocalStrings_cs.properties
   (props changed)

tomcat/trunk/java/org/apache/catalina/tribes/transport/bio/LocalStrings_cs.properties
   (props changed)

tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/LocalStrings_cs.properties
   (props changed)

tomcat/trunk/java/org/apache/catalina/tribes/util/LocalStrings_cs.properties   
(props changed)
tomcat/trunk/java/org/apache/catalina/users/LocalStrings_cs.properties   
(props changed)
tomcat/trunk/java/org/apache/catalina/util/LocalStrings_cs.properties   
(props changed)
tomcat/trunk/java/org/apache/catalina/valves/LocalStrings_cs.properties   
(props changed)

tomcat/trunk/java/org/apache/catalina/webresources/LocalStrings_cs.properties   
(props changed)

tomcat/trunk/java/org/apache/catalina/webresources/LocalStrings_es.properties   
(props changed)
tomcat/trunk/java/org/apache/coyote/LocalStrings_cs.properties   (props 
changed)
tomcat/trunk/java/org/apache/coyote/ajp/LocalStrings_cs.properties   (props 
changed)
tomcat/trunk/java/org/apache/coyote/http11/LocalStrings_cs.properties   
(props changed)

tomcat/trunk/java/org/apache/coyote/http11/filters/LocalStrings_cs.properties   
(props changed)

tomcat/trunk/java/org/apache/coyote/http11/upgrade/LocalStrings_cs.properties   
(props changed)
tomcat/trunk/java/org/apache/coyote/http2/LocalStrings_cs.properties   
(props changed)
tomcat/trunk/java/org/apache/jasper/resources/LocalStrings_cs.properties   
(props changed)
tomcat/trunk/java/org/apache/naming/LocalStrings_cs.properties   (props 
changed)
tomcat/trunk/java/org/apache/naming/factory/LocalStrings_cs.properties   
(props changed)
tomcat/trunk/java/org/apache/tomcat/util/LocalStrings_cs.properties   
(props changed)
tomcat/trunk/java/org/apache/tomcat/util/compat/LocalStrings_cs.properties  
 (props changed)

tomcat/trunk/java/org/apache/tomcat/util/descriptor/web/LocalStrings_cs.properties
   (props changed)
tomcat/trunk/java/org/apache/tomcat/util/http/LocalStrings_cs.properties   
(props changed

buildbot failure in on tomcat-trunk

[buildbot]

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/4054

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' 
triggered this build
Build Source Stamp: [branch tomcat/trunk] 1853802
Blamelist: remm

BUILD FAILED: failed compile_1

Sincerely,
 -The Buildbot




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

Re: Git migration: new branch/tag naming scheme

[Igal Sapir]

On Mon, Feb 18, 2019 at 2:03 AM Mark Thomas  wrote:

> On 18/02/2019 09:13, Rémy Maucherat wrote:
> > On Sat, Feb 16, 2019 at 4:09 PM Michael Osipov 
> wrote:
> >
> >> Folks,
> >>
> >> given that we are currently in the process of migrating to Git I'd like
> >> to propose a more readible and with the branch names consistent tag
> >> naming scheme.
> >>
> >> 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.
> >>
> >> There are bascially two approaches I'd like to discuss:
> >>
> >> 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.
> >>
> >> Finally it would be tomcat85-8.5.40, tomcat90-9.0.25. Another benefit
> >> would be autocompletion in Git CLI. I could simply say: "git checkout
> >> tomcat85" or "git checkout tomcat85-" and grab the specific version
> >> I want.
> >>
> >> 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.
> >>
> >> I personally opt for approach 2 because it is consistent, concise and
> >> removes redundancy on always used prefixes.
> >>
> >
> > I guess it's hard to argue against option 2.
> >
> > The main downside is that it comes late and Mark already did the work and
> > lots of testing for his proposed plan.
>
> The current, community agreed proposal for branch naming is "master,
> tc8.5 and tc7.0"
>

That's fine by me.


>
> There were strong views on the branch naming but "master, 8.5.x and
> 7.0.x" would be consistent with those views. I'm not sure I see much
> difference between either approach. If there is a strong preference for
> one over the other - or a good reason to choose one over the other -
> please make those views known in the next few days.
>

No good reason.  Based on the OP I thought that we are comparing to a more
verbose scheme like "tomcat-90-xxx" (without the standard "master" branch).

I actually prefer "tc8.5" and "tc7.0" for the branches (over "8.5.x" and
"7.0.x").  If tags will only use the numeric versions then this will make
it easy to differentiate between branches and tags.



>
> The current proposal, community agreed proposal for tags is to continue
> with the current naming scheme. Switching to using the version as-is
> (9.0.1, 9.0.2, etc) is doable. It is just a little more work during the
> migration. If the as-is naming scheme makes it easier for downstream
> users then that strikes me as a good reason to change it. Are there any
> objections to doing so?
>

Git tags are very lightweight, they are just pointers to other commits, so
if it's easier, we can do the migration as-is and then write some script to
generate new tags with the new naming convention, it shouldn't be too hard
IMO.  The old tags can remain or be removed at a later time.  They hardly
take any space.

Best,

Igal

svn commit: r1853802 - /tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java

[remm]

Author: remm
Date: Mon Feb 18 14:09:37 2019
New Revision: 1853802

URL: http://svn.apache.org/viewvc?rev=1853802&view=rev
Log:
Add test for 63182, which is probably valid, skip for NIO2

Modified:
tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java

Modified: 
tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java?rev=1853802&r1=1853801&r2=1853802&view=diff
==
--- tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java 
(original)
+++ tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java 
Mon Feb 18 14:09:37 2019
@@ -48,10 +48,12 @@ import javax.servlet.http.HttpServletReq
 import javax.servlet.http.HttpServletResponse;
 
 import org.junit.Assert;
+import org.junit.Assume;
 import org.junit.Ignore;
 import org.junit.Test;
 
 import org.apache.catalina.Context;
+import org.apache.catalina.connector.Connector;
 import org.apache.catalina.startup.BytesStreamer;
 import org.apache.catalina.startup.TesterServlet;
 import org.apache.catalina.startup.Tomcat;
@@ -87,23 +89,34 @@ public class TestNonBlockingAPI extends
 
 @Test
 public void testNonBlockingRead() throws Exception {
-doTestNonBlockingRead(false);
+doTestNonBlockingRead(false, false);
+}
+
+
+@Test
+public void testNonBlockingReadAsync() throws Exception {
+Tomcat tomcat = getTomcatInstance();
+Connector connector = tomcat.getConnector();
+// Skip for NIO2
+Assume.assumeFalse("This test may fail for NIO2",
+connector.getProtocolHandlerClassName().contains("Nio2"));
+doTestNonBlockingRead(false, true);
 }
 
 
 @Test(expected=IOException.class)
 public void testNonBlockingReadIgnoreIsReady() throws Exception {
-doTestNonBlockingRead(true);
+doTestNonBlockingRead(true, false);
 }
 
 
-private void doTestNonBlockingRead(boolean ignoreIsReady) throws Exception 
{
+private void doTestNonBlockingRead(boolean ignoreIsReady, boolean async) 
throws Exception {
 Tomcat tomcat = getTomcatInstance();
 
 // No file system docBase required
 Context ctx = tomcat.addContext("", null);
 
-NBReadServlet servlet = new NBReadServlet(ignoreIsReady);
+NBReadServlet servlet = new NBReadServlet(ignoreIsReady, async);
 String servletName = NBReadServlet.class.getName();
 Tomcat.addServlet(ctx, servletName, servlet);
 ctx.addServletMappingDecoded("/", servletName);
@@ -111,8 +124,8 @@ public class TestNonBlockingAPI extends
 tomcat.start();
 
 Map> resHeaders = new HashMap<>();
-int rc = postUrl(true, new DataWriter(500), "http://localhost:"; +
-getPort() + "/", new ByteChunk(), resHeaders, null);
+int rc = postUrl(true, new DataWriter(async ? 0 : 500, async ? 100 
: 5),
+"http://localhost:"; + getPort() + "/", new ByteChunk(), 
resHeaders, null);
 
 Assert.assertEquals(HttpServletResponse.SC_OK, rc);
 }
@@ -408,24 +421,25 @@ public class TestNonBlockingAPI extends
 
 
 public static class DataWriter implements BytesStreamer {
-private static final int MAX = 5;
+int max = 5;
 int count = 0;
 long delay = 0;
 byte[] b = "WANTMORE".getBytes(StandardCharsets.ISO_8859_1);
 byte[] f = "FINISHED".getBytes(StandardCharsets.ISO_8859_1);
 
-public DataWriter(long delay) {
+public DataWriter(long delay, int max) {
 this.delay = delay;
+this.max = max;
 }
 
 @Override
 public int getLength() {
-return b.length * MAX;
+return b.length * max;
 }
 
 @Override
 public int available() {
-if (count < MAX) {
+if (count < max) {
 return b.length;
 } else {
 return 0;
@@ -434,7 +448,7 @@ public class TestNonBlockingAPI extends
 
 @Override
 public byte[] next() {
-if (count < MAX) {
+if (count < max) {
 if (count > 0)
 try {
 if (delay > 0)
@@ -442,7 +456,7 @@ public class TestNonBlockingAPI extends
 } catch (Exception x) {
 }
 count++;
-if (count < MAX)
+if (count < max)
 return b;
 else
 return f;
@@ -456,10 +470,12 @@ public class TestNonBlockingAPI extends
 @WebServlet(asyncSupported = true)
 public class NBReadServlet extends TesterServlet {
 private static final long serialVersionUID = 1L;
+private final boolean async;
 private final boolean ignoreIsReady;
   

[Bug 63182] Servlet 3.1 ReadListener.onDataAvailable being invoked by the container even ServletInputStream.isReady returns true, when NIO2 connector being used and the read operation performed outsid

[bugzilla]

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

--- Comment #6 from Remy Maucherat  ---
The bugzilla is properly entered, you don't need to ping about it or update it
anymore.

That being said, the pattern used is at best inefficient, unlike writes where
it can have uses.

-- 
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 12: First Release Candidate available

[Rory O'Donnell]

 Hi Mark,

**OpenJDK builds *- JDK 12 Early Access build 32 **is now available **at 
: - jdk.java.net/12/*

**JDK 12:  First Release Candidate [1]**

 * Per the JDK 12 schedule [2], we are now in Release Candidate Phase.
 * The stabilization repository, jdk/jdk12, is open for P1 bug fixes
   per the JDK Release Process (JEP 3) [3].
 * All changes require approval via the Fix-Request Process [4].
 *
   Release note additions since last email

 o
   Build 31 - can_pop_frame and can_force_early_return capabilities
   are disabled if JVMCI compiler is used (JDK-8218025
   ) The JVMTI
   |can_pop_frame| and |can_force_early_return| capabilities are
   disabled if a JVMCI compiler (like Graal) is used. As a result
   the corresponding functionality (|PopFrame| and
   |ForceEarlyReturnXXX| functions) is not available to JVMTI
   agents. This issue is being fixed via JDK-8218885
   
   [https://bugs.openjdk.java.net/browse/JDK-8218885
   ].

 o Build 28: JDK-8212233
    : javadoc
   fails on jdk12 with "The code being documented uses modules but
   the packages defined in $URL are in the unnamed module."
 * Changes in this build.
   


**OpenJDK builds *- JDK 13 Early Access build 8 is **now available **at 
: - jdk.java.net/13/*


 * These early-access, open-source builds are provided under the
 o GNU General Public License, version 2, with the Classpath
   Exception .
 * Release Notes updates
 * Build 8
 o GraphicsEnvironment.getCenterPoint()/getMaximumWindowBounds()
   are unified across the platforms (JDK-8214918
   )
 o The experimental FIPS 140 compliant mode has been removed from
   the SunJSSE provider. (JDK-8217835
   )
 * Build 7
 o Change DOM parser to not resolve EntityReference and add Text
   node with
   DocumentBuilderFactory.setExpandEntityReferences(false)
   (JDK-8206132 )
 * Build 6
 o Base64.Encoder and Base64.Decoder methods can throw
   OutOfMemoryError (JDK-8210583
   )
 * Changes in this build
   

 * FOSS Bugs fixed in recent builds
 o Build 6 : JDK-8216970
    : condy
   causes JVM crash
 o Build 7: JDK-8215577
    : Remove
   javadoc support for HTML 4


Rgds,Rory

[1] 
https://mail.openjdk.java.net/pipermail/jdk-dev/2019-February/002623.html

[2] http://openjdk.java.net/projects/jdk/12/#Schedule
[3] http://openjdk.java.net/jeps/3
[4] http://openjdk.java.net/jeps/3#Fix-Request-Process

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

Re: Git migration: new branch/tag naming scheme

[Mark Thomas]

On 18/02/2019 09:13, Rémy Maucherat wrote:
> On Sat, Feb 16, 2019 at 4:09 PM Michael Osipov  wrote:
> 
>> Folks,
>>
>> given that we are currently in the process of migrating to Git I'd like
>> to propose a more readible and with the branch names consistent tag
>> naming scheme.
>>
>> 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.
>>
>> There are bascially two approaches I'd like to discuss:
>>
>> 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.
>>
>> Finally it would be tomcat85-8.5.40, tomcat90-9.0.25. Another benefit
>> would be autocompletion in Git CLI. I could simply say: "git checkout
>> tomcat85" or "git checkout tomcat85-" and grab the specific version
>> I want.
>>
>> 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.
>>
>> I personally opt for approach 2 because it is consistent, concise and
>> removes redundancy on always used prefixes.
>>
> 
> I guess it's hard to argue against option 2.
> 
> The main downside is that it comes late and Mark already did the work and
> lots of testing for his proposed plan.

The current, community agreed proposal for branch naming is "master,
tc8.5 and tc7.0"

There were strong views on the branch naming but "master, 8.5.x and
7.0.x" would be consistent with those views. I'm not sure I see much
difference between either approach. If there is a strong preference for
one over the other - or a good reason to choose one over the other -
please make those views known in the next few days.


The current proposal, community agreed proposal for tags is to continue
with the current naming scheme. Switching to using the version as-is
(9.0.1, 9.0.2, etc) is doable. It is just a little more work during the
migration. If the as-is naming scheme makes it easier for downstream
users then that strikes me as a good reason to change it. Are there any
objections to doing so?

Mark

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

[Bug 63182] Servlet 3.1 ReadListener.onDataAvailable being invoked by the container even ServletInputStream.isReady returns true, when NIO2 connector being used and the read operation performed outsid

[bugzilla]

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

xax...@gmail.com changed:

   What|Removed |Added

Summary|Servlet 3.1 ReadListener|Servlet 3.1
   |got exception(sometime) |ReadListener.onDataAvailabl
   |when invoking   |e being invoked by the
   |servletinputstream.read |container even
   |method, after isReady   |ServletInputStream.isReady
   |returns true.   |returns true, when NIO2
   ||connector being used and
   ||the read operation
   ||performed outside the
   ||onDataAvailable method.

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

Re: Git migration: new branch/tag naming scheme

[Rémy Maucherat]

On Sat, Feb 16, 2019 at 4:09 PM Michael Osipov  wrote:

> Folks,
>
> given that we are currently in the process of migrating to Git I'd like
> to propose a more readible and with the branch names consistent tag
> naming scheme.
>
> 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.
>
> There are bascially two approaches I'd like to discuss:
>
> 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.
>
> Finally it would be tomcat85-8.5.40, tomcat90-9.0.25. Another benefit
> would be autocompletion in Git CLI. I could simply say: "git checkout
> tomcat85" or "git checkout tomcat85-" and grab the specific version
> I want.
>
> 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.
>
> I personally opt for approach 2 because it is consistent, concise and
> removes redundancy on always used prefixes.
>

I guess it's hard to argue against option 2.

The main downside is that it comes late and Mark already did the work and
lots of testing for his proposed plan.

Rémy


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

[Bug 63182] Servlet 3.1 ReadListener got exception(sometime) when invoking servletinputstream.read method, after isReady returns true.

[bugzilla]

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

xax...@gmail.com changed:

   What|Removed |Added

 Status|NEEDINFO|NEW

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

Re: Git migration: new branch/tag naming scheme

[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