(tomcat-native) branch 1.3.x updated: Fix comment
This is an automated email from the ASF dual-hosted git repository. michaelo pushed a commit to branch 1.3.x in repository https://gitbox.apache.org/repos/asf/tomcat-native.git The following commit(s) were added to refs/heads/1.3.x by this push: new 5998cbf84 Fix comment 5998cbf84 is described below commit 5998cbf8484e0b65dbb4a1fc17a5da9f5190b8b1 Author: Michael Osipov AuthorDate: Thu Apr 18 08:24:42 2024 +0200 Fix comment --- native/src/ssl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/native/src/ssl.c b/native/src/ssl.c index 56304ee29..5ca7c0781 100644 --- a/native/src/ssl.c +++ b/native/src/ssl.c @@ -653,7 +653,7 @@ TCN_IMPLEMENT_CALL(jint, SSL, fipsModeGet)(TCN_STDARGS) const char *name; UNREFERENCED(o); -// Maps the OpenSSL 3. x onwards behaviour to theOpenSSL 1.x API +// Maps the OpenSSL 3.x onwards behaviour to the OpenSSL 1.x API // Checks that FIPS is the default provider md = EVP_MD_fetch(NULL, "SHA-512", NULL); - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat-native) branch main updated: Fix comment
This is an automated email from the ASF dual-hosted git repository. michaelo pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/tomcat-native.git The following commit(s) were added to refs/heads/main by this push: new 43ddd1e80 Fix comment 43ddd1e80 is described below commit 43ddd1e8059528454110198ca0d7d191322beeaf Author: Michael Osipov AuthorDate: Thu Apr 18 08:24:42 2024 +0200 Fix comment --- native/src/ssl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/native/src/ssl.c b/native/src/ssl.c index 7f4ca7e78..7624a4e67 100644 --- a/native/src/ssl.c +++ b/native/src/ssl.c @@ -405,7 +405,7 @@ TCN_IMPLEMENT_CALL(jint, SSL, fipsModeGet)(TCN_STDARGS) const char *name; UNREFERENCED(o); -// Maps the OpenSSL 3. x onwards behaviour to theOpenSSL 1.x API +// Maps the OpenSSL 3.x onwards behaviour to the OpenSSL 1.x API // Checks that FIPS is the default provider md = EVP_MD_fetch(NULL, "SHA-512", NULL); - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat-native) branch main updated: Fix APR version check in M4 macro
This is an automated email from the ASF dual-hosted git repository.
michaelo pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat-native.git
The following commit(s) were added to refs/heads/main by this push:
new 49d1a3a5b Fix APR version check in M4 macro
49d1a3a5b is described below
commit 49d1a3a5baf3bd50a3d4761ceb96d3efa9c05159
Author: Michael Osipov
AuthorDate: Thu Apr 18 08:20:08 2024 +0200
Fix APR version check in M4 macro
---
native/build/tcnative.m4 | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/native/build/tcnative.m4 b/native/build/tcnative.m4
index 272eac47f..11789e5b5 100644
--- a/native/build/tcnative.m4
+++ b/native/build/tcnative.m4
@@ -38,9 +38,9 @@ AC_DEFUN([TCN_FIND_APR],[
set $sapr_version
IFS=$tc_save_IFS
decimal_apr_version=`printf %02d%02d%03d ${1} ${2} ${3}`
- if test "${decimal_apr_version}" -lt "0104003"
+ if test "${decimal_apr_version}" -lt "0107000"
then
-AC_MSG_ERROR(Found APR $sapr_version. You need version 1.4.3 or newer
installed.)
+AC_MSG_ERROR(Found APR $sapr_version. You need version 1.7.0 or newer
installed.)
fi
AC_MSG_NOTICE(APR $sapr_version detected.)
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 68909] JSP compilation error due to classpath problems
https://bz.apache.org/bugzilla/show_bug.cgi?id=68909 --- Comment #5 from Chris --- You are absolutely right. Setting a SystemProperty within a web application is not a desired approach. The circumstances of our web application are rather homogeneous: it is always installed as the one and only web application in Tomcat 9.0.* using Java 8 as a requirement. We are relying on some parsing features of woodstox and always instantiate their factory in our own code. But we call some libraries that themselves use "XMLInputFactory.newFactory()". We had issues in some class loader constellations that these libraries did not find the "/META-INF/services/javax.xml.stream.XMLInputFactory" of woodstox in the classpath and hence loaded the java sun default Implementation. We saw the SystemProperty as the only way to "enforce" the usage of woodstox throughout our entire web application. -- 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: Some remarks on panama libssl loading
чт, 18 апр. 2024 г. в 00:46, Rainer Jung :
>
> Hi Konstantin,
>
> Am 17.04.24 um 21:44 schrieb Konstantin Kolinko:
> > ср, 17 апр. 2024 г. в 17:21, Rainer Jung :
> >>
> >> Am 17.04.24 um 15:34 schrieb Michael Osipov:
> >>> Rainer, I do not fully understand the problem here. We use libtool to
> >>> solve exactly this problem with versioned SONAMEs. It will create
> >>> symlinks to the SONAME.
> >>> Do you expect anyone even with dlopen() to load libfoo.o.{SOVERSION}
> >>> unless it is strictly needed?
> >>>
> >>> E.g.:
> >>> lrwxr-xr-x 1 root wheel26 2024-03-22 10:20
> >>> /usr/lib/libcrypto.so@ -> ../../lib/libcrypto.so.111
> >>> lrwxr-xr-x 1 root wheel 13 2024-03-22 10:20 /usr/lib/libssl.so@
> >>> -> libssl.so.111
> >>> -r--r--r-- 1 root wheel 608008 2024-03-22 10:20 /usr/lib/libssl.so.111
> >>> and so on...
> >>
> >> Yes, I expect that! anyone is the JVM :(
> >>
> >> The problem is, that the Java API does not care about these well thought
> >> native traditions. You can not open libssl.so.3 using
> >> System.loadlibrary(String name), because whatever you give it as "name"
> >> parameter it will always try to open libname.so. It always prepends
> >> "lib" to name and always suffixes it with plain ".so".
> >>
> >> Yes, it might exist as the first in your list of symlinks, but on most
> >> linux distributions this link is not installed by default, because it is
> >> only needed when doing compilations. So it is only installed when you
> >> install development packages for libs.
> >
> > There are two methods,
> > System.loadLibrary(libname)
> > System.load(filename)
> > or the same methods in Runtime.
> >
> > The second method accepts an absolute path and apparently does no
> > manipulation on the name.
> >
> > There is also System.mapLibraryName().
> >
> > Note that o.a.t.jni.Library constructor uses all those three methods.
> > A code that was added several years ago uses mapLibraryName() and
> > load() to load a library from "catalina.home/bin". It then falls back
> > to the old algorithm that uses loadLibrary().
> >
> >
> > https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/System.html
> > https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Runtime.html
>
> thanks for your valuable input as always. I am referring to
> java/org/apache/tomcat/util/openssl/openssl_h.java, which only contains
> which on Mac does
>
> System.loadLibrary("ssl");
> SYMBOL_LOOKUP =
> SymbolLookup.loaderLookup().or(Linker.nativeLinker().defaultLookup());
>
> and else
>
> SYMBOL_LOOKUP = SymbolLookup.libraryLookup(System.mapLibraryName("ssl"),
> LIBRARY_ARENA)
> .or(SymbolLookup.loaderLookup())
> .or(Linker.nativeLinker().defaultLookup());
>
> I *think* both attempts do not allow to use a versioned SONAME.
>
> I have not experimented with System.load(filename) and how to combine it
> with SymbolLookup. o.a.t.jni.Library does not use SymbolLookup. But it
> seems SymbolLookup is not restricted to the development library names.
> So there's hope we can improve!
>
> https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/foreign/SymbolLookup.html
Thank you for the references.
Those lines of code are not generated, but are written by Remy.
A comment referencing "https://github.com/sergot/openssl/issues/81"; was a clue.
See the changes in February 2024 (starting with 2024-02-08).
SymbolLookup has two methods, just like the pair of methods in System/Runtime:
libraryLookup(String, Arena)
libraryLookup(Path, Arena).
The second method accepts a full path to a library file.
Interesting is that this new API allows unloading the library - that
is what the Arena argument is for.
As we do not plan to unload the library, I think it makes sense to use
the "good old" System.load() / loadLibrary() methods to load the
library, and use the SymbolLookup loaderLookup() factory method.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Some remarks on panama libssl loading
Hi Konstantin,
Am 17.04.24 um 21:44 schrieb Konstantin Kolinko:
ср, 17 апр. 2024 г. в 17:21, Rainer Jung :
Am 17.04.24 um 15:34 schrieb Michael Osipov:
Rainer, I do not fully understand the problem here. We use libtool to solve
exactly this problem with versioned SONAMEs. It will create symlinks to the
SONAME.
Do you expect anyone even with dlopen() to load libfoo.o.{SOVERSION} unless it
is strictly needed?
E.g.:
lrwxr-xr-x 1 root wheel26 2024-03-22 10:20 /usr/lib/libcrypto.so@ ->
../../lib/libcrypto.so.111
lrwxr-xr-x 1 root wheel 13 2024-03-22 10:20 /usr/lib/libssl.so@ ->
libssl.so.111
-r--r--r-- 1 root wheel 608008 2024-03-22 10:20 /usr/lib/libssl.so.111
and so on...
Yes, I expect that! anyone is the JVM :(
The problem is, that the Java API does not care about these well thought
native traditions. You can not open libssl.so.3 using
System.loadlibrary(String name), because whatever you give it as "name"
parameter it will always try to open libname.so. It always prepends
"lib" to name and always suffixes it with plain ".so".
Yes, it might exist as the first in your list of symlinks, but on most
linux distributions this link is not installed by default, because it is
only needed when doing compilations. So it is only installed when you
install development packages for libs.
There are two methods,
System.loadLibrary(libname)
System.load(filename)
or the same methods in Runtime.
The second method accepts an absolute path and apparently does no
manipulation on the name.
There is also System.mapLibraryName().
Note that o.a.t.jni.Library constructor uses all those three methods.
A code that was added several years ago uses mapLibraryName() and
load() to load a library from "catalina.home/bin". It then falls back
to the old algorithm that uses loadLibrary().
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/System.html
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Runtime.html
thanks for your valuable input as always. I am referring to
java/org/apache/tomcat/util/openssl/openssl_h.java, which only contains
which on Mac does
System.loadLibrary("ssl");
SYMBOL_LOOKUP =
SymbolLookup.loaderLookup().or(Linker.nativeLinker().defaultLookup());
and else
SYMBOL_LOOKUP = SymbolLookup.libraryLookup(System.mapLibraryName("ssl"),
LIBRARY_ARENA)
.or(SymbolLookup.loaderLookup())
.or(Linker.nativeLinker().defaultLookup());
I *think* both attempts do not allow to use a versioned SONAME.
I have not experimented with System.load(filename) and how to combine it
with SymbolLookup. o.a.t.jni.Library does not use SymbolLookup. But it
seems SymbolLookup is not restricted to the development library names.
So there's hope we can improve!
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/foreign/SymbolLookup.html
Best regards,
Rainer
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Some remarks on panama libssl loading
Am 17.04.24 um 22:46 schrieb Michael Osipov:
On 2024/04/17 14:21:06 Rainer Jung wrote:
Am 17.04.24 um 15:34 schrieb Michael Osipov:
Rainer, I do not fully understand the problem here. We use libtool to solve
exactly this problem with versioned SONAMEs. It will create symlinks to the
SONAME.
Do you expect anyone even with dlopen() to load libfoo.o.{SOVERSION} unless it
is strictly needed?
E.g.:
lrwxr-xr-x 1 root wheel26 2024-03-22 10:20 /usr/lib/libcrypto.so@ ->
../../lib/libcrypto.so.111
lrwxr-xr-x 1 root wheel 13 2024-03-22 10:20 /usr/lib/libssl.so@ ->
libssl.so.111
-r--r--r-- 1 root wheel 608008 2024-03-22 10:20 /usr/lib/libssl.so.111
and so on...
Yes, I expect that! anyone is the JVM :(
The problem is, that the Java API does not care about these well thought
native traditions. You can not open libssl.so.3 using
System.loadlibrary(String name), because whatever you give it as "name"
parameter it will always try to open libname.so. It always prepends
"lib" to name and always suffixes it with plain ".so".
Yes, it might exist as the first in your list of symlinks, but on most
linux distributions this link is not installed by default, because it is
only needed when doing compilations. So it is only installed when you
install development packages for libs.
Ah, now I see your problem, but it looks like a downstream problem of your
distro of choice, no? I wonder how you compile then custom software if .so
isn't present and the linker cannot find it with -L? What if you install the
devel package to have .so link?
I think it is not a distro problem, but a explicit decision I like. I
find it normal, that you separate development packages from production
packages and only install development packages on development systems,
not on production system. Here a development file is needed for a
production process :(
In old times for instance it was forbidden to install a compiler on a
production system. Yeah I know, once Java kicked in this rule was no
longer possible in the Java world. But in the native world it is often
still followed. So if there is no native compiler, you don't need the
devel version of the libraries as well.
Best regards,
Rainer
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Some remarks on panama libssl loading
On 2024/04/17 14:21:06 Rainer Jung wrote:
> Am 17.04.24 um 15:34 schrieb Michael Osipov:
> > Rainer, I do not fully understand the problem here. We use libtool to solve
> > exactly this problem with versioned SONAMEs. It will create symlinks to the
> > SONAME.
> > Do you expect anyone even with dlopen() to load libfoo.o.{SOVERSION} unless
> > it is strictly needed?
> >
> > E.g.:
> > lrwxr-xr-x 1 root wheel26 2024-03-22 10:20 /usr/lib/libcrypto.so@
> > -> ../../lib/libcrypto.so.111
> > lrwxr-xr-x 1 root wheel 13 2024-03-22 10:20 /usr/lib/libssl.so@ ->
> > libssl.so.111
> > -r--r--r-- 1 root wheel 608008 2024-03-22 10:20 /usr/lib/libssl.so.111
> > and so on...
>
> Yes, I expect that! anyone is the JVM :(
>
> The problem is, that the Java API does not care about these well thought
> native traditions. You can not open libssl.so.3 using
> System.loadlibrary(String name), because whatever you give it as "name"
> parameter it will always try to open libname.so. It always prepends
> "lib" to name and always suffixes it with plain ".so".
>
> Yes, it might exist as the first in your list of symlinks, but on most
> linux distributions this link is not installed by default, because it is
> only needed when doing compilations. So it is only installed when you
> install development packages for libs.
Ah, now I see your problem, but it looks like a downstream problem of your
distro of choice, no? I wonder how you compile then custom software if .so
isn't present and the linker cannot find it with -L? What if you install the
devel package to have .so link?
M
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Some remarks on panama libssl loading
ср, 17 апр. 2024 г. в 17:21, Rainer Jung :
>
> Am 17.04.24 um 15:34 schrieb Michael Osipov:
> > Rainer, I do not fully understand the problem here. We use libtool to solve
> > exactly this problem with versioned SONAMEs. It will create symlinks to the
> > SONAME.
> > Do you expect anyone even with dlopen() to load libfoo.o.{SOVERSION} unless
> > it is strictly needed?
> >
> > E.g.:
> > lrwxr-xr-x 1 root wheel26 2024-03-22 10:20 /usr/lib/libcrypto.so@
> > -> ../../lib/libcrypto.so.111
> > lrwxr-xr-x 1 root wheel 13 2024-03-22 10:20 /usr/lib/libssl.so@ ->
> > libssl.so.111
> > -r--r--r-- 1 root wheel 608008 2024-03-22 10:20 /usr/lib/libssl.so.111
> > and so on...
>
> Yes, I expect that! anyone is the JVM :(
>
> The problem is, that the Java API does not care about these well thought
> native traditions. You can not open libssl.so.3 using
> System.loadlibrary(String name), because whatever you give it as "name"
> parameter it will always try to open libname.so. It always prepends
> "lib" to name and always suffixes it with plain ".so".
>
> Yes, it might exist as the first in your list of symlinks, but on most
> linux distributions this link is not installed by default, because it is
> only needed when doing compilations. So it is only installed when you
> install development packages for libs.
There are two methods,
System.loadLibrary(libname)
System.load(filename)
or the same methods in Runtime.
The second method accepts an absolute path and apparently does no
manipulation on the name.
There is also System.mapLibraryName().
Note that o.a.t.jni.Library constructor uses all those three methods.
A code that was added several years ago uses mapLibraryName() and
load() to load a library from "catalina.home/bin". It then falls back
to the old algorithm that uses loadLibrary().
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/System.html
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Runtime.html
HTH
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 68911] Newly introduced ConfigurationSource doesn't respect environment variables
https://bz.apache.org/bugzilla/show_bug.cgi?id=68911 --- Comment #2 from Remy Maucherat --- I will review next week. It is very convoluted so it's possible something is missing. -- 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: [PR] Re-adding support for fractional seconds in access log [tomcat]
jose-galvez commented on PR #720: URL: https://github.com/apache/tomcat/pull/720#issuecomment-2061838297 > Why not use `%D` which is in milliseconds (Tomcat <10) or microseconds (Tomcat >= 10)? I wanted to keep parity on the behavior here with previous versions, especially because in our case we have scripts that use this value for monitoring and are expecting this format. Updating them could be complicated since we would need to support both the Tomcat 9 and Tomcat 10+ format, and also some of our customers have their own scripts that would need to be updated too so it makes things complicated -- 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. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org 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: [PR] Re-adding support for fractional seconds in access log [tomcat]
jose-galvez commented on PR #720:
URL: https://github.com/apache/tomcat/pull/720#issuecomment-2061821679
> From memory that change was to align Tomcat's access log configuration
with httpd. It may well be that the correct fix here is to correct the
documentation. Separately, comparing this PR and the original code I suspect
that, if we did want to merge something along these lines, that there would be
performance concerns with the current proposal. As a minimum we'd need to see
some performance figures for the proposed formatting.
The documentation from Tomcat 9 does indicate that there will be
consolidation but it indicates that it only affects AccessLogValve, not the
ExtendedAccessLogValve (see [this
doc](https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Access_Log_Valve)
for %T param).
I could make the change for it to look closer to what it used to do in
Tomcat 9, but I felt this was easier to read and follow while at the same time
wouldn't make a huge performance impact but if that'a a concern I could set it
to do it this way:
```
buf.append(Long.toString(time / 10));
buf.append('.');
int remains = (int) (time % 10);
buf.append(Long.toString(remains / 1));
remains = remains % 1;
buf.append(Long.toString(remains / 1000));
buf.append(Long.toString(remains % 1000));
```
--
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.
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
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 68911] Newly introduced ConfigurationSource doesn't respect environment variables
https://bz.apache.org/bugzilla/show_bug.cgi?id=68911 Christopher Schultz changed: What|Removed |Added OS||All Status|NEW |NEEDINFO --- Comment #1 from Christopher Schultz --- ConfigurationSource is 5 years old. TOMCAT_HOME has never been an environment variable used by Tomcat. The system property "user.dir" is essentially the same as the CWD of the process when it was started. It's not the same as the user's home directory. The only time "user.dir" is used is if the code initializing Tomcat doesn't give it any specific information about where to load the configuration files from. Do you have a situation where Tomcat is actually doing something incorrect/unexpected or is this a complaint filed after reading the source code? -- 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: [PR] Re-adding support for fractional seconds in access log [tomcat]
ChristopherSchultz commented on PR #720: URL: https://github.com/apache/tomcat/pull/720#issuecomment-2061771435 Why not use `%D` which is in milliseconds (Tomcat <10) or microseconds (Tomcat >= 10)? -- 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. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org 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 68911] New: Newly introduced ConfigurationSource doesn't respect environment variables
https://bz.apache.org/bugzilla/show_bug.cgi?id=68911 Bug ID: 68911 Summary: Newly introduced ConfigurationSource doesn't respect environment variables Product: Tomcat 9 Version: 9.0.x Hardware: PC Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: 7elem...@mail.bg Target Milestone: - Newly introduced ConfigurationSource doesn't respect environment variables used for so long to point to tomcat configuration and resources like CATALINA_BASE and TOMCAT_HOME. It switches to statically used system property user.dir. If user.dir is empty ConfigurationSource uses OS provided current dir which is dynamic. Plus user.dir can be used for other purposes by the system and to change it IMHO ConfigurationSource should use old environment variables. First as a backward compatibility Second as a more static way to set configuration Third docker images use environment variables instead of system properties to the processes and moving away of a good practice that was followed for so long Also note that this applies to tomcat 10.x as well -- 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 68909] JSP compilation error due to classpath problems
https://bz.apache.org/bugzilla/show_bug.cgi?id=68909 --- Comment #4 from Konstantin Kolinko --- (In reply to Chris from comment #2) > > System.setProperty(javax.xml.stream.XMLInputFactory.class.getName(), > WstxInputFactory.class.getName()); > The above line of code affects the whole JVM, not just your web application, breaking Tomcat and any other web applications that may be deployed in parallel. A web application by design is not allowed to change System properties. There are proper ways to reconfigure your environment, if you are really re-configuring your environment. (The conf/catalina.properties file and placing the shared classes into the lib/ directory, or any other directory specified via the "common.loader" property). -- 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: [PR] Re-adding support for fractional seconds in access log [tomcat]
markt-asf commented on PR #720: URL: https://github.com/apache/tomcat/pull/720#issuecomment-2061540617 From memory that change was to align Tomcat's access log configuration with httpd. It may well be that the correct fix here is to correct the documentation. Separately, comparing this PR and the original code I suspect that, if we did want to merge something along these lines, that there would be performance concerns with the current proposal. As a minimum we'd need to see some performance figures for the proposed formatting. -- 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. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org 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 68910] Improve LibreSSL version check in tcnative.m4
https://bz.apache.org/bugzilla/show_bug.cgi?id=68910 --- Comment #2 from Michael Osipov --- (In reply to Christopher Schultz from comment #1) > (In reply to Michael Osipov from comment #0) > > since we also do support LibreSSL [...] > > Note: Support for LibreSSL is more of an aspiration and less of a > requirement. We don't technically advertise support for LibreSSL, but I > would like to be able to support it. Right, let me rephrase: best effort. Still at least here we can present a better message and may a warning that LibreSSL is best effort. -- 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 68909] JSP compilation error due to classpath problems
https://bz.apache.org/bugzilla/show_bug.cgi?id=68909 --- Comment #3 from Christopher Schultz --- :( Sorry about that. We'll re-evaluate our solution to the opposite problem, which is ClassLoader-pinning when the webapp's ClassLoader is used to obtain the XMLInputFactory. -- 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 68910] Improve LibreSSL version check in tcnative.m4
https://bz.apache.org/bugzilla/show_bug.cgi?id=68910 --- Comment #1 from Christopher Schultz --- (In reply to Michael Osipov from comment #0) > since we also do support LibreSSL [...] Note: Support for LibreSSL is more of an aspiration and less of a requirement. We don't technically advertise support for LibreSSL, but I would like to be able to support it. -- 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
[PR] Re-adding support for fractional seconds in access log [tomcat]
jose-galvez opened a new pull request, #720: URL: https://github.com/apache/tomcat/pull/720 commit [a8575ef](https://github.com/apache/tomcat/commit/a8575efbc1de64fe58c8fd99e53a0011b59a8e86) removed support for seconds with floating point for the Extended Access Log Valve and made it only seconds. The documentation for Tomcat 10 says this should be seconds with fractions so this change brings back that behavior -- 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. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org 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: Some remarks on panama libssl loading
Am 17.04.24 um 15:34 schrieb Michael Osipov:
Rainer, I do not fully understand the problem here. We use libtool to solve
exactly this problem with versioned SONAMEs. It will create symlinks to the
SONAME.
Do you expect anyone even with dlopen() to load libfoo.o.{SOVERSION} unless it
is strictly needed?
E.g.:
lrwxr-xr-x 1 root wheel26 2024-03-22 10:20 /usr/lib/libcrypto.so@ ->
../../lib/libcrypto.so.111
lrwxr-xr-x 1 root wheel 13 2024-03-22 10:20 /usr/lib/libssl.so@ ->
libssl.so.111
-r--r--r-- 1 root wheel 608008 2024-03-22 10:20 /usr/lib/libssl.so.111
and so on...
Yes, I expect that! anyone is the JVM :(
The problem is, that the Java API does not care about these well thought
native traditions. You can not open libssl.so.3 using
System.loadlibrary(String name), because whatever you give it as "name"
parameter it will always try to open libname.so. It always prepends
"lib" to name and always suffixes it with plain ".so".
Yes, it might exist as the first in your list of symlinks, but on most
linux distributions this link is not installed by default, because it is
only needed when doing compilations. So it is only installed when you
install development packages for libs.
Best regards,
Rainer
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Some remarks on panama libssl loading
Rainer, I do not fully understand the problem here. We use libtool to solve
exactly this problem with versioned SONAMEs. It will create symlinks to the
SONAME.
Do you expect anyone even with dlopen() to load libfoo.o.{SOVERSION} unless it
is strictly needed?
E.g.:
lrwxr-xr-x 1 root wheel26 2024-03-22 10:20 /usr/lib/libcrypto.so@ ->
../../lib/libcrypto.so.111
lrwxr-xr-x 1 root wheel 13 2024-03-22 10:20 /usr/lib/libssl.so@ ->
libssl.so.111
-r--r--r-- 1 root wheel 608008 2024-03-22 10:20 /usr/lib/libssl.so.111
and so on...
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 68876] serverStartup.pdf missing sources
https://bz.apache.org/bugzilla/show_bug.cgi?id=68876 --- Comment #2 from Mark Thomas --- I've converted the original mdl file to six SCG files and added those to the main branch. I've also fixed the "warpper" typo. They still need quite a bit of clean up including: - cleaning up the layout so elements don't overlap - reviewing the diagrams for alignment with current code (given these were written for Tomcat 5.0.x) - remove the PDF and use the SVG files in its place (or regenerate the PDF from the SVG files) -- 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
(tomcat) 02/02: Fix typo
This is an automated email from the ASF dual-hosted git repository. markt pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/tomcat.git commit 15d192a944580be723fa1df53e7e7d9cb68f762d Author: Mark Thomas AuthorDate: Wed Apr 17 12:56:17 2024 +0100 Fix typo --- webapps/docs/architecture/startup/6_catalina_start_4.svg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/webapps/docs/architecture/startup/6_catalina_start_4.svg b/webapps/docs/architecture/startup/6_catalina_start_4.svg index 74e24e2927..3595e8f2de 100644 --- a/webapps/docs/architecture/startup/6_catalina_start_4.svg +++ b/webapps/docs/architecture/startup/6_catalina_start_4.svg @@ -629,7 +629,7 @@ >createWarpper() // Invoked by a WebWrapperRule (not Directly by the Digester)createWrapper() // Invoked by a WebWrapperRule (not Directly by the Digester)
(tomcat) branch main updated (79009baf0a -> 15d192a944)
This is an automated email from the ASF dual-hosted git repository. markt pushed a change to branch main in repository https://gitbox.apache.org/repos/asf/tomcat.git from 79009baf0a Align NioChannel and SecureNioChannel new f6d0e9cfa8 Convert original Rational Rose mdl file to svgs new 15d192a944 Fix typo The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../docs/architecture/startup/1_catalina_load.svg | 523 ++ .../architecture/startup/2_catalina_initliaze.svg | 333 + .../architecture/startup/3_catalina_start_1.svg| 762 + .../architecture/startup/4_catalina_start_2.svg| 559 +++ .../architecture/startup/5_catalina_start_3.svg| 394 +++ .../architecture/startup/6_catalina_start_4.svg| 723 +++ 6 files changed, 3294 insertions(+) create mode 100644 webapps/docs/architecture/startup/1_catalina_load.svg create mode 100644 webapps/docs/architecture/startup/2_catalina_initliaze.svg create mode 100644 webapps/docs/architecture/startup/3_catalina_start_1.svg create mode 100644 webapps/docs/architecture/startup/4_catalina_start_2.svg create mode 100644 webapps/docs/architecture/startup/5_catalina_start_3.svg create mode 100644 webapps/docs/architecture/startup/6_catalina_start_4.svg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[I] activemq 5.16.x not working after converting javax to jakarta using tomcat transformer [tomcat-jakartaee-migration]
ilapavuluri opened a new issue, #55: URL: https://github.com/apache/tomcat-jakartaee-migration/issues/55 I am using tomcat transformer for javax to jakarta conversion, in the similar lines I converted my activemq-all 5.16.7 into jakarta using the same tomcat transformer, no errors during compilation, but while running the application it is not returning from below line: "ConnectionFactory.createConnection()" means it is not able to establish the connection with broker. Appreciate any help. -- 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. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org.apache.org 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
Some remarks on panama libssl loading
Hi there, I did some small tests using OpenSSL/Panama with TC 10.1.23 for running the unit tests. First: they seem to work well using JDK 22 with OpenSSL 3.0.13, 3.1.5, 3.2.1 and 3.3.0. For JDK 23 the tests are still running, but also look good up to now. But some things around native library loading in the JVM seem to be nasty in principle: 1) Library file name First some (well-known) background info about shared library loading in Linux in general: When one *compiles* a binary or shared object against a library using "-lsomelib" the compile time linker looks for a file named libsomelib.so. It tries to resolve all symbols needed but not defined in the object to compile in these libs. If all goes well, it records the library dependency in the resulting object as NEEDED. This record does not refer to "libsomelib.so" as a name, but instead the so called SONAME of libsomelib.so. That's an internal name of the library often reflecting an API stability version. For example for OpenSSL 3.x the SONAME of libssl.so is libssl.so.3. Now during runtime of the compiled object the runtime linker notices the need for the recorded SONAME (NEEDED libssl.so.3). It then searches a file with *that* name. In the OpenSSL example it is libssl.so.3, not (!) libssl.so. On a "normal" linux system, libssl.so is therefore not installed, only libssl.so.3 (if OpenSSL 3 is installed at all). The file libssl.so (or better the symlink) is only part of the devel package typically installed on development systems, because it is only needed during compile time, not during runtime. Now back to the JVM: The Java API to load a native library (for example System.loadLibrary(String name)) gets the library name as a String parameter. What is this library name? Unfortunately the JVM devs did not do a good job. If you pass the API the String "somelib", they simply prepend it with "lib" and append ".so" and try to load that file. For example when you pass "ssl", they look for libssl.so. There is no way to tell Java to look for libssl.so.3 using this API. On a normal system, the file libssl.so does not exist and should not exist, because it is a development file. As a workaround one has to provide libssl.so, at least as a symlink to libssl.so.3. 2) Indirect dependencies Normally libssl.so(.3) has dependencies itself, e.g. for libcrypto.so.3 (NEEDED libcrypto.so.3). These dependencies are not longer loaded via the Java API but implicitly by the runtime linker. So now, you do not need a file libcrypto.so - you can't even make that work - you really need the file libcrypto.so.3. Very confusing for newbies and pretty inconsistent. 3) java.library.path The system property java.library.path is only used by the JVM when loading the libs requested via the Java API, so here libssl.so. The runtime linker looking then for libcrypto.so.3 is not set up to use java.library.path. So if the libs are not installed in a default system location, you need to set LD_LIBRARY_PATH to point to your libcrypto. If libssl is in the same directory (pretty much always), you then won't need java.library.path at all, because LD_LIBRARY_PATH also influences the search of libssl.so by the Java API. Again confusing. None of this is Tomcat's fault. They are all deficiencies of the (old) Java APIs which were IMHO misdesigned. It might be different on Windows or Macs. Just wanted to mention it in case others run into the same nits. We might want to document something though before raising more awareness for using OpenSSL via panama. Best regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 68876] serverStartup.pdf missing sources
https://bz.apache.org/bugzilla/show_bug.cgi?id=68876 Mark Thomas changed: What|Removed |Added Severity|normal |enhancement --- Comment #1 from Mark Thomas --- It was created using Rational Rose. It looks like the original mdl file is in svn: https://svn.apache.org/viewvc/tomcat/archive/tc5.0.x/trunk/container/webapps/docs/architecture/requestProcess/roseModel.mdl?view=log The request process diagrams were updated as part of BZ 57282. I'd be happy to see that converted to png like the request process diagrams. -- 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-10.1.x
Build status: Build succeeded! Worker used: bb_worker2_ubuntu URL: https://ci2.apache.org/#builders/44/builds/1222 Blamelist: Mark Thomas Build Text: build successful Status Detected: restored build Build Source Stamp: [branch 10.1.x] 474701d1c4872bcd9e530444d61677863d8bc09d Steps: worker_preparation: 0 git: 0 shell: 0 shell_1: 0 shell_2: 0 shell_3: 0 shell_4: 0 shell_5: 0 compile: 1 shell_6: 0 shell_7: 0 shell_8: 0 shell_9: 0 Rsync docs to nightlies.apache.org: 0 shell_10: 0 Rsync RAT to nightlies.apache.org: 0 compile_1: 1 shell_11: 0 Rsync Logs to nightlies.apache.org: 0 -- ASF Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Buildbot success in on tomcat-11.0.x
Build status: Build succeeded! Worker used: bb_worker2_ubuntu URL: https://ci2.apache.org/#builders/112/builds/1038 Blamelist: Mark Thomas Build Text: build successful Status Detected: restored build Build Source Stamp: [branch main] 79009baf0af9e0f2b02753a352e31e5bb3f85396 Steps: worker_preparation: 0 git: 0 shell: 0 shell_1: 0 shell_2: 0 shell_3: 0 shell_4: 0 shell_5: 0 shell_6: 0 compile: 1 shell_7: 0 shell_8: 0 shell_9: 0 shell_10: 0 Rsync docs to nightlies.apache.org: 0 shell_11: 0 Rsync RAT to nightlies.apache.org: 0 compile_1: 1 shell_12: 0 Rsync Logs to nightlies.apache.org: 0 -- ASF Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 68910] Improve LibreSSL version check in tcnative.m4
https://bz.apache.org/bugzilla/show_bug.cgi?id=68910 Michael Osipov changed: What|Removed |Added CC||micha...@apache.org -- 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 68910] New: Improve LibreSSL version check in tcnative.m4
https://bz.apache.org/bugzilla/show_bug.cgi?id=68910 Bug ID: 68910 Summary: Improve LibreSSL version check in tcnative.m4 Product: Tomcat Native Version: 2.0.7 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P2 Component: Library Assignee: dev@tomcat.apache.org Reporter: micha...@apache.org Target Milestone: --- Note: Applies to 1.3.x as well and is a followup to 29f0cc900310b1982b462b16fc308cbfeade79d4. since we also do support LibreSSL I see a few problems here: > AC_MSG_CHECKING(OpenSSL library version >= 3.0.0) Does not reflect the minimum LibreSSL version (3.5.2) Guarantees: * from 2.2.2 LIBRESSL_VERSION_NUMBER is bumped with each release: https://github.com/libressl/portable/blob/64e0f7c5d644e55e0bbbf985335e42c4f59e615d/ChangeLog#L2761-L2762 * from 2.3.2 LIBRESSL_VERSION_NUMBER matches the output format of OPENSSL_VERSION_NUMBER: https://github.com/libressl/portable/blob/64e0f7c5d644e55e0bbbf985335e42c4f59e615d/ChangeLog#L2589-L2591 So I believe https://github.com/apache/tomcat-native/blob/d1cc229db7416b59f7d6ba2d7bcb8188b5ebffc6/native/build/tcnative.m4#L228-L239 can/should be rewritten to properly print the actual reqiured version number instead of hardcoded 3.0.0. If you run LibreSSL 3.4.x the error output would be confusing. -- 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: [VOTE] Release Apache Tomcat 10.1.23
On 16/04/2024 14:11, Christopher Schultz wrote: The proposed 10.1.23 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 10.1.23 Unit tests pass on Linux, Windows and MacOS (M1). Build is reproducible. Mark PS I am still unable to test on MacOS (Intel) as it is a $dayjob provided laptop and the mandatory AV software is slowing the tests down to the point that lots of them fail. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat) branch main updated: Align NioChannel and SecureNioChannel
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new 79009baf0a Align NioChannel and SecureNioChannel
79009baf0a is described below
commit 79009baf0af9e0f2b02753a352e31e5bb3f85396
Author: Mark Thomas
AuthorDate: Wed Apr 17 10:42:29 2024 +0100
Align NioChannel and SecureNioChannel
Skipping empty writes can provide a performance improvement for some
frameworks - typically those that call flush() more than they need to
---
java/org/apache/tomcat/util/net/NioChannel.java | 4
webapps/docs/changelog.xml | 4
2 files changed, 8 insertions(+)
diff --git a/java/org/apache/tomcat/util/net/NioChannel.java
b/java/org/apache/tomcat/util/net/NioChannel.java
index 6ddf5637f0..c350577a4b 100644
--- a/java/org/apache/tomcat/util/net/NioChannel.java
+++ b/java/org/apache/tomcat/util/net/NioChannel.java
@@ -115,6 +115,10 @@ public class NioChannel implements ByteChannel,
ScatteringByteChannel, Gathering
@Override
public int write(ByteBuffer src) throws IOException {
checkInterruptStatus();
+if (!src.hasRemaining()) {
+// Nothing left to write
+return 0;
+}
return sc.write(src);
}
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 0cf84d9b86..8ef77e52aa 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -130,6 +130,10 @@
Add OpenSSL FFM classes to tomcat-embed-core.jar. (remm)
+
+Align non-secure and secure writes with NIO and skip the write attempt
+when there are no bytes to be written. (markt)
+
-
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: Align NioChannel and SecureNioChannel
This is an automated email from the ASF dual-hosted git repository.
markt 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 72823b4ea0 Align NioChannel and SecureNioChannel
72823b4ea0 is described below
commit 72823b4ea06b68ece3663d8d8d998359967673b0
Author: Mark Thomas
AuthorDate: Wed Apr 17 10:42:29 2024 +0100
Align NioChannel and SecureNioChannel
Skipping empty writes can provide a performance improvement for some
frameworks - typically those that call flush() more than they need to
---
java/org/apache/tomcat/util/net/NioChannel.java | 4
webapps/docs/changelog.xml | 8
2 files changed, 12 insertions(+)
diff --git a/java/org/apache/tomcat/util/net/NioChannel.java
b/java/org/apache/tomcat/util/net/NioChannel.java
index 96493ed75a..da0d165d1b 100644
--- a/java/org/apache/tomcat/util/net/NioChannel.java
+++ b/java/org/apache/tomcat/util/net/NioChannel.java
@@ -133,6 +133,10 @@ public class NioChannel implements ByteChannel,
ScatteringByteChannel, Gathering
@Override
public int write(ByteBuffer src) throws IOException {
checkInterruptStatus();
+if (!src.hasRemaining()) {
+// Nothing left to write
+return 0;
+}
return sc.write(src);
}
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index d24e2b190a..de4e1b77a2 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -127,6 +127,14 @@
+
+
+
+Align non-secure and secure writes with NIO and skip the write attempt
+when there are no bytes to be written. (markt)
+
+
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat) branch 10.1.x updated: Align NioChannel and SecureNioChannel
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 10.1.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/10.1.x by this push:
new 474701d1c4 Align NioChannel and SecureNioChannel
474701d1c4 is described below
commit 474701d1c4872bcd9e530444d61677863d8bc09d
Author: Mark Thomas
AuthorDate: Wed Apr 17 10:42:29 2024 +0100
Align NioChannel and SecureNioChannel
Skipping empty writes can provide a performance improvement for some
frameworks - typically those that call flush() more than they need to
---
java/org/apache/tomcat/util/net/NioChannel.java | 4
webapps/docs/changelog.xml | 4
2 files changed, 8 insertions(+)
diff --git a/java/org/apache/tomcat/util/net/NioChannel.java
b/java/org/apache/tomcat/util/net/NioChannel.java
index 6ddf5637f0..c350577a4b 100644
--- a/java/org/apache/tomcat/util/net/NioChannel.java
+++ b/java/org/apache/tomcat/util/net/NioChannel.java
@@ -115,6 +115,10 @@ public class NioChannel implements ByteChannel,
ScatteringByteChannel, Gathering
@Override
public int write(ByteBuffer src) throws IOException {
checkInterruptStatus();
+if (!src.hasRemaining()) {
+// Nothing left to write
+return 0;
+}
return sc.write(src);
}
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 423e024c74..ff466e8bdd 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -135,6 +135,10 @@
Add OpenSSL FFM classes to tomcat-embed-core.jar. (remm)
+
+Align non-secure and secure writes with NIO and skip the write attempt
+when there are no bytes to be written. (markt)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 68908] Tomcat feints death, there is no ClientPoller thread in the stack information
https://bz.apache.org/bugzilla/show_bug.cgi?id=68908 --- Comment #2 from Mark Thomas --- *** Bug 68878 has been marked as a duplicate of this bug. *** -- 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 68878] Tomcat feints death, there is no ClientPoller thread in the stack information
https://bz.apache.org/bugzilla/show_bug.cgi?id=68878 Mark Thomas changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #1 from Mark Thomas --- *** This bug has been marked as a duplicate of bug 68908 *** -- 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 64839] HTTP2: Exception in thread "http-nio-x.y.z-1090-ClientPoller" java.lang.NullPointerException
https://bz.apache.org/bugzilla/show_bug.cgi?id=64839 Mark Thomas changed: What|Removed |Added CC||huangzeling8...@dingtalk.co ||m --- Comment #18 from Mark Thomas --- *** Bug 68908 has been marked as a duplicate of this bug. *** -- 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 68908] Tomcat feints death, there is no ClientPoller thread in the stack information
https://bz.apache.org/bugzilla/show_bug.cgi?id=68908 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED OS||All Resolution|--- |DUPLICATE --- Comment #1 from Mark Thomas --- *** This bug has been marked as a duplicate of bug 64839 *** -- 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 68909] JSP compilation error due to classpath problems
https://bz.apache.org/bugzilla/show_bug.cgi?id=68909 --- Comment #2 from Chris --- Yeah, it comes down to these changes: https://github.com/apache/tomcat/commit/a2167e13c19115aecd220cd3be19d43d36126f3b https://github.com/apache/tomcat/commit/3b8f277a7ffc1193ed6c6d4fff85db6dc7327e39 We set a fixed "javax.xml.stream.XMLInputFactory" System.setProperty(javax.xml.stream.XMLInputFactory.class.getName(), WstxInputFactory.class.getName()); Before the change, the ContextClassLoader of our WebApplication was used to load the class. Now the ContextClassLoader is forced to the EncodingDetector.class.getClassLoader(). Was this anticipated? -- 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 68909] JSP compilation error due to classpath problems
https://bz.apache.org/bugzilla/show_bug.cgi?id=68909 Chris changed: What|Removed |Added OS||All --- Comment #1 from Chris --- I located the problem further: The WebApplication uses "woodstox-core-6.6.0.jar" which has a /META-INF/services/javax.xml.stream.XMLInputFactory pointing to com.ctc.wstx.stax.WstxInputFactory The Tomcat now seems to recognize this class but after the change in 9.0.88 is of cause not able to load this instance, since its in the parent (catalina) classloader. -- 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 68909] New: JSP compilation error due to classpath problems
https://bz.apache.org/bugzilla/show_bug.cgi?id=68909 Bug ID: 68909 Summary: JSP compilation error due to classpath problems Product: Tomcat 9 Version: 9.0.88 Hardware: PC Status: NEW Severity: normal Priority: P2 Component: Jasper Assignee: dev@tomcat.apache.org Reporter: c...@stl.gmbh Target Milestone: - Hi, we upgraded to tomcat-9.0.88 last night and our application is broken. We reverted to tomcat-9.0.87 and everything works fine. We use Ubuntu 22 LTS and Temurin OpenJDK jdk8u402. Looking at the stack trace, I think this changelog is relevant: https://tomcat.apache.org/tomcat-9.0-doc/changelog.html#Tomcat_9.0.88_(remm) Prevent the web application's ClassLoader from being pinned by the JSP compiler if an application uses a custom XMLInputFactory. Based upon a suggestion from Simon Niederberger. (schultz) We apply a custom XMLInputFactory and I think it is a classloader related problem. --- Here are the Stack Traces: 2024-04-17 06:24:27.904 ERROR 4q001b G5U001 ecadia.ecadia.GUIController.ActionServlet Unexpected Exception javax.servlet.ServletException: javax.xml.stream.FactoryConfigurationError: Provider com.ctc.wstx.stax.WstxInputFactory not found at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:332) at javax.servlet.http.HttpServlet.service(HttpServlet.java:623) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:200) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:144) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:169) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:144) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:641) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:415) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:347) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:284) at GUIController.ActionServlet.httpResponse(ActionServlet.java:1186) at GUIController.ActionServlet.doPost(ActionServlet.java:786) at GUIController.ActionServlet.doGet(ActionServlet.java:265) at javax.servlet.http.HttpServlet.service(HttpServlet.java:529) at javax.servlet.http.HttpServlet.service(HttpServlet.java:623) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:200) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:144) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:169) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:144) at ecadia.servlet.filters.RedirectFilter.doFilter(RedirectFilter.java:104) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:169) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:144) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:168) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:90) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:481) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:130) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:93) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:670) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:346) at org.apache.coyote.ajp.AjpProcessor.service(AjpProcessor.java:424) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:63) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:928) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1786) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52) at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191) at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:63) at java.lang.Thread.run(Thread.java:750) Caused by: javax.xml.stream.FactoryConfigurationError: Provider com.ctc.wstx.stax
