[GitHub] [tomcat] martin-g merged pull request #391: Optimize if condition
martin-g merged pull request #391: URL: https://github.com/apache/tomcat/pull/391 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] martin-g commented on pull request #391: Optimize if condition
martin-g commented on pull request #391: URL: https://github.com/apache/tomcat/pull/391#issuecomment-747288205 Thank you, @lanicc ! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch master updated: Optimize if condition
This is an automated email from the ASF dual-hosted git repository.
mgrigorov pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/master by this push:
new 92eabe5 Optimize if condition
new 588410c Merge pull request #391 from lanicc/lanicc-patch-1
92eabe5 is described below
commit 92eabe5b666f3a6c699ef70bb64be0e8716d006a
Author: lan
AuthorDate: Thu Dec 17 10:37:21 2020 +0800
Optimize if condition
---
java/org/apache/coyote/AbstractProtocol.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/java/org/apache/coyote/AbstractProtocol.java
b/java/org/apache/coyote/AbstractProtocol.java
index 239ae2c..d4d2d55 100644
--- a/java/org/apache/coyote/AbstractProtocol.java
+++ b/java/org/apache/coyote/AbstractProtocol.java
@@ -593,7 +593,7 @@ public abstract class AbstractProtocol implements
ProtocolHandler,
* is triggered independently of the socket read/write timeouts.
*/
protected void startAsyncTimeout() {
-if (timeoutFuture == null || (timeoutFuture != null &&
timeoutFuture.isDone())) {
+if (timeoutFuture == null || timeoutFuture.isDone()) {
if (timeoutFuture != null && timeoutFuture.isDone()) {
// There was an error executing the scheduled task, get it and
log it
try {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 9.0.x updated: Optimize if condition
This is an automated email from the ASF dual-hosted git repository.
mgrigorov pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/9.0.x by this push:
new 67c37e4 Optimize if condition
67c37e4 is described below
commit 67c37e414c3c3f242818c28cfa3d6dc448e32a5c
Author: lan
AuthorDate: Thu Dec 17 10:37:21 2020 +0800
Optimize if condition
(cherry picked from commit 92eabe5b666f3a6c699ef70bb64be0e8716d006a)
---
java/org/apache/coyote/AbstractProtocol.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/java/org/apache/coyote/AbstractProtocol.java
b/java/org/apache/coyote/AbstractProtocol.java
index 092fcf3..79b4a87 100644
--- a/java/org/apache/coyote/AbstractProtocol.java
+++ b/java/org/apache/coyote/AbstractProtocol.java
@@ -616,7 +616,7 @@ public abstract class AbstractProtocol implements
ProtocolHandler,
* is triggered independently of the socket read/write timeouts.
*/
protected void startAsyncTimeout() {
-if (timeoutFuture == null || (timeoutFuture != null &&
timeoutFuture.isDone())) {
+if (timeoutFuture == null || timeoutFuture.isDone()) {
if (timeoutFuture != null && timeoutFuture.isDone()) {
// There was an error executing the scheduled task, get it and
log it
try {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[TCK] JSTL failure
Hi, I have been using Tomcat Taglib (shaded with Xalan and Serializer). Works quite well on TomEE but I have one failure I'd like to discuss with you before possibly opening a challenge. https://tck.work/tomee/tests?path=com.sun.ts.tests.jstl&build=1608116575927&status=FAILED I have fixed 4 or the 5, but com.sun.ts.tests.jstl.spec.core.urlresource.importtag.JSTLClient is still failing and I don't understand how to fix it. Here is the JSP https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/web/jstl/spec/core/urlresource/importtag/positiveImportEncodingNotSpecifiedTest.jsp Here is the expected result https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/web/jstl/spec/core/urlresource/importtag/positiveImportEncodingNotSpecifiedTest.gf The first file imported is https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/web/jstl/spec/core/urlresource/importtag/encoding/Encoding.jsp And the second https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/web/jstl/spec/core/urlresource/importtag/import-encoded.txt In the golden file, there seems to be 2 extra characters. Here is the full log file for the test run https://tck.work/tomee/api/testlog/1218/1608116849515 Any thoughts? The result from Tomcat looks ok to me unless I missed something. -- Jean-Louis
Re: Objection to the deprecation of the tomcat-native/APR connector
Am 2020-12-16 um 16:38 schrieb Emmanuel Bourg: Le 11/12/2020 à 17:56, Michael Osipov a écrit : Well, isn't that really a OS vendor problem not ours? We can provide grace periods, but that's pretty much it. They need to solve that, not us on a volunteer basis. Note that (most) Debian Developers are volunteers too. This makes siauation even worse to sit on old version and continue back porting for downstream. FreeBSD's port of libtcnative is uptodate. I provide patches on regular basis. Vendors like Debian or Red Hat lag years behind. I don't know the state in Red Hat, but in Debian tomcat-native is up-to-date [1]. For the stable release there are backports with more recent versions available. Thanks for the info, wasn't aware of that. Guess it takes the maintainer do that otherwise it will stick to very old versions. I am horribly surprised for RHEL 7: $ yum info tomcat-native 2>&- | grep Version Version: 1.2.23 in contrast: $ yum info curl 2>&- | grep Version Version: 7.29.0 This is unusable. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [TCK] JSTL failure
I opened both the import-encoded.txt, and the positiveImportEncodingNotSpecifiedTest.gf file in a hex editor. I don't know if this mailing list allows attachments, but I can send a screenshot if that helps. In both cases, right before the word "output from text file", there's a sequence of 4 bytes 0xFE, 0xFF, 0x00, 0x6F. The 0x6F is the "o" on "output", so it looks like the 0xFF 0xFE is being dropped somewhere. The test sounds ok (although maybe not straightforward to understand). On the TomEE side, I think we need to understand whether this is an issue with our use of shading to include Xalan, or whether we'd still see this issue if we included Xalan etc manually without shading. Jon On Thu, Dec 17, 2020 at 8:27 AM Jean-Louis MONTEIRO wrote: > Hi, > > I have been using Tomcat Taglib (shaded with Xalan and Serializer). > Works quite well on TomEE but I have one failure I'd like to discuss with > you before possibly opening a challenge. > > > https://tck.work/tomee/tests?path=com.sun.ts.tests.jstl&build=1608116575927&status=FAILED > > I have fixed 4 or the 5, > but com.sun.ts.tests.jstl.spec.core.urlresource.importtag.JSTLClient is > still failing and I don't understand how to fix it. > > Here is the JSP > > https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/web/jstl/spec/core/urlresource/importtag/positiveImportEncodingNotSpecifiedTest.jsp > > Here is the expected result > > https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/web/jstl/spec/core/urlresource/importtag/positiveImportEncodingNotSpecifiedTest.gf > > The first file imported is > > https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/web/jstl/spec/core/urlresource/importtag/encoding/Encoding.jsp > > And the second > > https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/web/jstl/spec/core/urlresource/importtag/import-encoded.txt > > In the golden file, there seems to be 2 extra characters. > Here is the full log file for the test run > > https://tck.work/tomee/api/testlog/1218/1608116849515 > > Any thoughts? > The result from Tomcat looks ok to me unless I missed something. > > > > -- > Jean-Louis >
Re: Objection to the deprecation of the tomcat-native/APR connector
Hi everyone, TLTR: after switching from APR to Nio2 our processor usage went down. Longer version: Recently we had a production problem which was noticeable years ago, but it became a real problem recently. In our tests 0.75% of connection requests weren't served. I have recently posted in Tomcat-Users email list thread "native connector, server problems with "No data received" after migrating from APR to Nio2 connector, the problem was still there. It turned out that the upgrade from 8.5.5 to 9.0.41 solved the f..ine issue (!), it is a pitty that bug existed in Tomcat for years even in 2014. But what I have discovered from migrating from APR to Nio2 that our processor usage went down. We never tried Nio2, I have setup APR back in 2014 as I've read it has a better performance. So I don't see a reason why APR should stay as users can easily migrate to NIO2... On Thu, Dec 17, 2020 at 11:41 AM Michael Osipov wrote: > Am 2020-12-16 um 16:38 schrieb Emmanuel Bourg: > > Le 11/12/2020 à 17:56, Michael Osipov a écrit : > > > >> Well, isn't that really a OS vendor problem not ours? We can provide > >> grace periods, but that's pretty much it. They need to solve that, not > >> us on a volunteer basis. > > > > Note that (most) Debian Developers are volunteers too. > > This makes siauation even worse to sit on old version and continue back > porting for downstream. > > >> FreeBSD's port of libtcnative is uptodate. I provide patches on regular > >> basis. Vendors like Debian or Red Hat lag years behind. > > > > I don't know the state in Red Hat, but in Debian tomcat-native is > > up-to-date [1]. For the stable release there are backports with more > > recent versions available. > > Thanks for the info, wasn't aware of that. Guess it takes the maintainer > do that otherwise it will stick to very old versions. > > I am horribly surprised for RHEL 7: > > $ yum info tomcat-native 2>&- | grep Version > > Version: 1.2.23 > > in contrast: > > $ yum info curl 2>&- | grep Version > > Version: 7.29.0 > > This is unusable. > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [TCK] JSTL failure
Looking at this again, those characters are a BOM, and having that in the middle of the output seems a little strange. I'd suggest asking on the spec list. Jon On Thu, Dec 17, 2020 at 10:51 AM Jonathan Gallimore < jonathan.gallim...@gmail.com> wrote: > I opened both the import-encoded.txt, and the > positiveImportEncodingNotSpecifiedTest.gf file in a hex editor. I don't > know if this mailing list allows attachments, but I can send a screenshot > if that helps. In both cases, right before the word "output from text > file", there's a sequence of 4 bytes 0xFE, 0xFF, 0x00, 0x6F. The 0x6F is > the "o" on "output", so it looks like the 0xFF 0xFE is being dropped > somewhere. The test sounds ok (although maybe not straightforward to > understand). On the TomEE side, I think we need to understand whether this > is an issue with our use of shading to include Xalan, or whether we'd still > see this issue if we included Xalan etc manually without shading. > > Jon > > On Thu, Dec 17, 2020 at 8:27 AM Jean-Louis MONTEIRO > wrote: > >> Hi, >> >> I have been using Tomcat Taglib (shaded with Xalan and Serializer). >> Works quite well on TomEE but I have one failure I'd like to discuss with >> you before possibly opening a challenge. >> >> >> https://tck.work/tomee/tests?path=com.sun.ts.tests.jstl&build=1608116575927&status=FAILED >> >> I have fixed 4 or the 5, >> but com.sun.ts.tests.jstl.spec.core.urlresource.importtag.JSTLClient is >> still failing and I don't understand how to fix it. >> >> Here is the JSP >> >> https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/web/jstl/spec/core/urlresource/importtag/positiveImportEncodingNotSpecifiedTest.jsp >> >> Here is the expected result >> >> https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/web/jstl/spec/core/urlresource/importtag/positiveImportEncodingNotSpecifiedTest.gf >> >> The first file imported is >> >> https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/web/jstl/spec/core/urlresource/importtag/encoding/Encoding.jsp >> >> And the second >> >> https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/web/jstl/spec/core/urlresource/importtag/import-encoded.txt >> >> In the golden file, there seems to be 2 extra characters. >> Here is the full log file for the test run >> >> https://tck.work/tomee/api/testlog/1218/1608116849515 >> >> Any thoughts? >> The result from Tomcat looks ok to me unless I missed something. >> >> >> >> -- >> Jean-Louis >> >
Re: Objection to the deprecation of the tomcat-native/APR connector
On Thu, Dec 17, 2020 at 12:12 PM Mladen Adamović wrote: > But what I have discovered from migrating from APR to Nio2 that our > processor usage went down. We never tried Nio2, I have setup APR back in > 2014 as I've read it has a better performance. > I would still say the APR connector is faster, just like the java.io connector was the fastest overall. But it can depend on what you are doing, maybe if your use case uses the poller more, then it could be significantly less efficient. The main problems are that it is crash prone (and it's expensive and complex to make it safe), and it doesn't have feature parity with NIO. About NIO2, Oracle has started updating and fixing NIO again. NIO2 is now lagging a bit in features (no inherited channel, no UDP - NIO just got fully rewritten support -, and now no domain socket support). The IO API war is not over yet though. Rémy > > So I don't see a reason why APR should stay as users can easily migrate to > NIO2... > > > > On Thu, Dec 17, 2020 at 11:41 AM Michael Osipov > wrote: > > > Am 2020-12-16 um 16:38 schrieb Emmanuel Bourg: > > > Le 11/12/2020 à 17:56, Michael Osipov a écrit : > > > > > >> Well, isn't that really a OS vendor problem not ours? We can provide > > >> grace periods, but that's pretty much it. They need to solve that, not > > >> us on a volunteer basis. > > > > > > Note that (most) Debian Developers are volunteers too. > > > > This makes siauation even worse to sit on old version and continue back > > porting for downstream. > > > > >> FreeBSD's port of libtcnative is uptodate. I provide patches on > regular > > >> basis. Vendors like Debian or Red Hat lag years behind. > > > > > > I don't know the state in Red Hat, but in Debian tomcat-native is > > > up-to-date [1]. For the stable release there are backports with more > > > recent versions available. > > > > Thanks for the info, wasn't aware of that. Guess it takes the maintainer > > do that otherwise it will stick to very old versions. > > > > I am horribly surprised for RHEL 7: > > > $ yum info tomcat-native 2>&- | grep Version > > > Version: 1.2.23 > > > > in contrast: > > > $ yum info curl 2>&- | grep Version > > > Version: 7.29.0 > > > > This is unusable. > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > >
[GitHub] [tomcat] rmaucher commented on pull request #382: Add support for unix domain sockets.
rmaucher commented on pull request #382: URL: https://github.com/apache/tomcat/pull/382#issuecomment-747467253 I am not convinced about adding that feature to the APR endpoint ... Anyway: - The changes to IntrospectionUtils are too much given the actual use, strings could be used and the endpoint is the only place that actually deals with the two types so it seems enough - I don't get the idea behind the "permissions", since I don't think Tomcat is the party that is supposed to be creating the socket The UDS feature should already work with NIO and Java 16 EA by using an inherited channel. The limitation is that there is only one endpoint that can use a UDS. I'm ok with adding full UDS support to NIO using the compat package (the amount of reflection needed does not seem too bad so I may try it to see how that would work). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Objection to the deprecation of the tomcat-native/APR connector
Perhaps for some users APR is significantly faster than NIO or NIO2, but Graham Leggett didn't bring some examples like: - company ZZZ reports 39% of higher CPU usage with APR for their project - company XXX which is an Apache gold sponsor reports 43% of higher CPU usage for APR for their project Lulu. If the reason to keep it is that users need to change one line in the server.xml is to keep it up, it could probably be done in the code automatically switch to NIO if APR config is given. (sounds like an if-else statement in the code). On Thu, Dec 17, 2020 at 1:20 PM Rémy Maucherat wrote: > On Thu, Dec 17, 2020 at 12:12 PM Mladen Adamović < > mladen.adamo...@gmail.com> > wrote: > > > But what I have discovered from migrating from APR to Nio2 that our > > processor usage went down. We never tried Nio2, I have setup APR back in > > 2014 as I've read it has a better performance. > > > > I would still say the APR connector is faster, just like the java.io > connector was the fastest overall. But it can depend on what you are doing, > maybe if your use case uses the poller more, then it could be significantly > less efficient. The main problems are that it is crash prone (and it's > expensive and complex to make it safe), and it doesn't have feature parity > with NIO. > > About NIO2, Oracle has started updating and fixing NIO again. NIO2 is now > lagging a bit in features (no inherited channel, no UDP - NIO just got > fully rewritten support -, and now no domain socket support). The IO API > war is not over yet though. > > Rémy > > > > > > So I don't see a reason why APR should stay as users can easily migrate > to > > NIO2... > > > > > > > > On Thu, Dec 17, 2020 at 11:41 AM Michael Osipov > > wrote: > > > > > Am 2020-12-16 um 16:38 schrieb Emmanuel Bourg: > > > > Le 11/12/2020 à 17:56, Michael Osipov a écrit : > > > > > > > >> Well, isn't that really a OS vendor problem not ours? We can provide > > > >> grace periods, but that's pretty much it. They need to solve that, > not > > > >> us on a volunteer basis. > > > > > > > > Note that (most) Debian Developers are volunteers too. > > > > > > This makes siauation even worse to sit on old version and continue back > > > porting for downstream. > > > > > > >> FreeBSD's port of libtcnative is uptodate. I provide patches on > > regular > > > >> basis. Vendors like Debian or Red Hat lag years behind. > > > > > > > > I don't know the state in Red Hat, but in Debian tomcat-native is > > > > up-to-date [1]. For the stable release there are backports with more > > > > recent versions available. > > > > > > Thanks for the info, wasn't aware of that. Guess it takes the > maintainer > > > do that otherwise it will stick to very old versions. > > > > > > I am horribly surprised for RHEL 7: > > > > $ yum info tomcat-native 2>&- | grep Version > > > > Version: 1.2.23 > > > > > > in contrast: > > > > $ yum info curl 2>&- | grep Version > > > > Version: 7.29.0 > > > > > > This is unusable. > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > > > > >
[GitHub] [tomcat] jbampton opened a new pull request #392: docs: fix spelling
jbampton opened a new pull request #392: URL: https://github.com/apache/tomcat/pull/392 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65001] New: HTTPNIO non-blocking IO servlet 3.1 API may fail to alert webapp that a request is complete
https://bz.apache.org/bugzilla/show_bug.cgi?id=65001 Bug ID: 65001 Summary: HTTPNIO non-blocking IO servlet 3.1 API may fail to alert webapp that a request is complete Product: Tomcat 9 Version: 9.0.41 Hardware: PC OS: Mac OS X 10.1 Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: frraj...@cisco.com Target Milestone: - Created attachment 37624 --> https://bz.apache.org/bugzilla/attachment.cgi?id=37624&action=edit Test servlet Under certain IO error conditions, tomcat will fail to alert that an asynchronous request is completed and destroyed. Both the AsyncListener's onComplete method and ServletRequestListener's requestDestroyed method are not called. This may cause a webapp to believe that a request is still valid while tomcat has already recycled the objects. I was able to reproduce this issue using a WriteListener (non-blocking IO servlet API 3.1) with the httpnio connector on the latest tomcat release (9.0.41). This appears to be caused when an IOException is raised while attempting to write to the ServletOutputChannel during the WriteListener's onWritePossible callback. It also seems possible to trigger this issue by manually throwing an exception in the onWritePossible callback. The following exception can also be seen in the logs: java.lang.IllegalStateException: Calling [asyncPostProcess()] is not valid for a request with Async state [ERROR] I've attached a test servlet that demonstrates this issue. To simulate IO errors, an http request is aborted before the full response body is read. The servlet then records various async callbacks it receives and it can be seen that some callbacks are not always called, i.e. the AsyncListener's onComplete callback and ServletRequestListener's requestDestroyed callback. The servlet compares synchronous requests, asynchronous requests, and asynchronous requests with non-blocking IO. -- 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 65001] HTTPNIO non-blocking IO servlet 3.1 API may fail to alert webapp that a request is complete
https://bz.apache.org/bugzilla/show_bug.cgi?id=65001 frraj...@cisco.com changed: What|Removed |Added OS|Mac OS X 10.1 |All Hardware|PC |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
[GitHub] [tomcat] lanicc opened a new pull request #394: Replace C-style array declaring with Java-style array declaring
lanicc opened a new pull request #394: URL: https://github.com/apache/tomcat/pull/394 Replace the C-style parameter declaring of the method `Catalina.load(String args[])` with Java-style `load(String[] args)` This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] lanicc closed pull request #394: Replace C-style array declaring with Java-style array declaring
lanicc closed pull request #394: URL: https://github.com/apache/tomcat/pull/394 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] lanicc opened a new pull request #395: Replace C-style array declaring with Java-style array declaring
lanicc opened a new pull request #395: URL: https://github.com/apache/tomcat/pull/395 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch master updated: docs: fix spelling (#392)
This is an automated email from the ASF dual-hosted git repository. mgrigorov pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/master by this push: new e8dbc19 docs: fix spelling (#392) e8dbc19 is described below commit e8dbc1919a7c44a4632664f6a593856a72d62559 Author: John Bampton AuthorDate: Fri Dec 18 17:11:00 2020 +1000 docs: fix spelling (#392) --- webapps/docs/config/context.xml | 2 +- webapps/docs/config/listeners.xml | 6 +++--- webapps/docs/monitoring.xml | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/webapps/docs/config/context.xml b/webapps/docs/config/context.xml index 5dfcbcf..9f8d2b1 100644 --- a/webapps/docs/config/context.xml +++ b/webapps/docs/config/context.xml @@ -460,7 +460,7 @@ When set to true annotation scanning will be performed using the utility executor. It will allow processing scanning in -parrallel which may improve deployment type at the expense of higher +parallel which may improve deployment type at the expense of higher server load. If not specified, the default of false is used. diff --git a/webapps/docs/config/listeners.xml b/webapps/docs/config/listeners.xml index ea5ac06..3a512bf 100644 --- a/webapps/docs/config/listeners.xml +++ b/webapps/docs/config/listeners.xml @@ -522,15 +522,15 @@ -Group is the Multicast IP to boardcast messages to HTTPD, default 224.0.1.105 +Group is the Multicast IP to broadcast messages to HTTPD, default 224.0.1.105 -Multiport is the Multicast port to boardcast messages to HTTPD, default 23364 +Multiport is the Multicast port to broadcast messages to HTTPD, default 23364 -Ttl is the TTL for the boardcast messages, default 16 +Ttl is the TTL for the broadcast messages, default 16 diff --git a/webapps/docs/monitoring.xml b/webapps/docs/monitoring.xml index a97b0b9..b8698b2 100644 --- a/webapps/docs/monitoring.xml +++ b/webapps/docs/monitoring.xml @@ -100,7 +100,7 @@ controlRole tomcat]]> Tip: The password file should be read-only and only accessible by the operating system user Tomcat is running as. -Alterantively, you can configure a JAAS login module with: +Alternatively, you can configure a JAAS login module with: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] martin-g merged pull request #392: docs: fix spelling
martin-g merged pull request #392: URL: https://github.com/apache/tomcat/pull/392 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] martin-g commented on pull request #392: docs: fix spelling
martin-g commented on pull request #392: URL: https://github.com/apache/tomcat/pull/392#issuecomment-747913681 Thank you, @jbampton ! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 9.0.x updated: docs: fix spelling (#392)
This is an automated email from the ASF dual-hosted git repository. mgrigorov pushed a commit to branch 9.0.x in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/9.0.x by this push: new 8223515 docs: fix spelling (#392) 8223515 is described below commit 82235159f96dcab4e6c681a3ad21cb154b037fb1 Author: John Bampton AuthorDate: Fri Dec 18 17:11:00 2020 +1000 docs: fix spelling (#392) (cherry picked from commit e8dbc1919a7c44a4632664f6a593856a72d62559) --- webapps/docs/config/context.xml | 2 +- webapps/docs/config/listeners.xml | 6 +++--- webapps/docs/monitoring.xml | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/webapps/docs/config/context.xml b/webapps/docs/config/context.xml index 3816736..1b9252a 100644 --- a/webapps/docs/config/context.xml +++ b/webapps/docs/config/context.xml @@ -430,7 +430,7 @@ When set to true annotation scanning will be performed using the utility executor. It will allow processing scanning in -parrallel which may improve deployment type at the expense of higher +parallel which may improve deployment type at the expense of higher server load. If not specified, the default of false is used. diff --git a/webapps/docs/config/listeners.xml b/webapps/docs/config/listeners.xml index f37dbaf..67b3c68 100644 --- a/webapps/docs/config/listeners.xml +++ b/webapps/docs/config/listeners.xml @@ -534,15 +534,15 @@ -Group is the Multicast IP to boardcast messages to HTTPD, default 224.0.1.105 +Group is the Multicast IP to broadcast messages to HTTPD, default 224.0.1.105 -Multiport is the Multicast port to boardcast messages to HTTPD, default 23364 +Multiport is the Multicast port to broadcast messages to HTTPD, default 23364 -Ttl is the TTL for the boardcast messages, default 16 +Ttl is the TTL for the broadcast messages, default 16 diff --git a/webapps/docs/monitoring.xml b/webapps/docs/monitoring.xml index a97b0b9..b8698b2 100644 --- a/webapps/docs/monitoring.xml +++ b/webapps/docs/monitoring.xml @@ -100,7 +100,7 @@ controlRole tomcat]]> Tip: The password file should be read-only and only accessible by the operating system user Tomcat is running as. -Alterantively, you can configure a JAAS login module with: +Alternatively, you can configure a JAAS login module with: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 8.5.x updated: docs: fix spelling (#392)
This is an automated email from the ASF dual-hosted git repository. mgrigorov pushed a commit to branch 8.5.x in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/8.5.x by this push: new eed7776 docs: fix spelling (#392) eed7776 is described below commit eed77765c83b29a10b7b22a176cb164c58d725d7 Author: John Bampton AuthorDate: Fri Dec 18 17:11:00 2020 +1000 docs: fix spelling (#392) (cherry picked from commit e8dbc1919a7c44a4632664f6a593856a72d62559) --- webapps/docs/monitoring.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/webapps/docs/monitoring.xml b/webapps/docs/monitoring.xml index a97b0b9..b8698b2 100644 --- a/webapps/docs/monitoring.xml +++ b/webapps/docs/monitoring.xml @@ -100,7 +100,7 @@ controlRole tomcat]]> Tip: The password file should be read-only and only accessible by the operating system user Tomcat is running as. -Alterantively, you can configure a JAAS login module with: +Alternatively, you can configure a JAAS login module with: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] martin-g commented on pull request #395: Replace C-style array declaring with Java-style array declaring
martin-g commented on pull request #395: URL: https://github.com/apache/tomcat/pull/395#issuecomment-747917997 There are many of those. A quick search shows around 400 occurrences of the C-style. I am not sure this is worth it. It will make backporting very hard. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
