[GitHub] [tomcat] martin-g commented on pull request #395: Replace C-style array declaring with Java-style array declaring

2020-12-17 Thread GitBox


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



[tomcat] branch 8.5.x updated: docs: fix spelling (#392)

2020-12-17 Thread mgrigorov
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



[tomcat] branch 9.0.x updated: docs: fix spelling (#392)

2020-12-17 Thread mgrigorov
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



[GitHub] [tomcat] martin-g commented on pull request #392: docs: fix spelling

2020-12-17 Thread GitBox


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



[GitHub] [tomcat] martin-g merged pull request #392: docs: fix spelling

2020-12-17 Thread GitBox


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



[tomcat] branch master updated: docs: fix spelling (#392)

2020-12-17 Thread mgrigorov
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] lanicc opened a new pull request #395: Replace C-style array declaring with Java-style array declaring

2020-12-17 Thread GitBox


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



[GitHub] [tomcat] lanicc closed pull request #394: Replace C-style array declaring with Java-style array declaring

2020-12-17 Thread GitBox


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 #394: Replace C-style array declaring with Java-style array declaring

2020-12-17 Thread GitBox


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



[Bug 65001] HTTPNIO non-blocking IO servlet 3.1 API may fail to alert webapp that a request is complete

2020-12-17 Thread bugzilla
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



[Bug 65001] New: HTTPNIO non-blocking IO servlet 3.1 API may fail to alert webapp that a request is complete

2020-12-17 Thread bugzilla
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



[GitHub] [tomcat] jbampton opened a new pull request #392: docs: fix spelling

2020-12-17 Thread GitBox


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



Re: Objection to the deprecation of the tomcat-native/APR connector

2020-12-17 Thread Mladen Adamović
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] rmaucher commented on pull request #382: Add support for unix domain sockets.

2020-12-17 Thread GitBox


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

2020-12-17 Thread Rémy Maucherat
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
> >
> >
>


Re: [TCK] JSTL failure

2020-12-17 Thread Jonathan Gallimore
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

2020-12-17 Thread Mladen Adamović
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

2020-12-17 Thread Jonathan Gallimore
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

2020-12-17 Thread Michael Osipov

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



[TCK] JSTL failure

2020-12-17 Thread Jean-Louis MONTEIRO
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


[tomcat] branch 9.0.x updated: Optimize if condition

2020-12-17 Thread mgrigorov
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



[tomcat] branch master updated: Optimize if condition

2020-12-17 Thread mgrigorov
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



[GitHub] [tomcat] martin-g commented on pull request #391: Optimize if condition

2020-12-17 Thread GitBox


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



[GitHub] [tomcat] martin-g merged pull request #391: Optimize if condition

2020-12-17 Thread GitBox


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