[Bug 66324] New: HttpServletRequest.getRequestURI returns null
https://bz.apache.org/bugzilla/show_bug.cgi?id=66324 Bug ID: 66324 Summary: HttpServletRequest.getRequestURI returns null Product: Tomcat 9 Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: critical Priority: P2 Component: Servlet Assignee: dev@tomcat.apache.org Reporter: arjun.cs...@gmail.com Target Milestone: - I'm not sure if this issue is caused by tomcat or by our internal code. But it seems like HttpServletRequest.getRequestURI returns null value. Is there any case it would throw a null value? Please assist. -- 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-jakartaee-migration] DanielThomas commented on pull request #36: Improve composability when using from other tools
DanielThomas commented on PR #36: URL: https://github.com/apache/tomcat-jakartaee-migration/pull/36#issuecomment-1291438441 Awesome, thanks much for the feedback! It's a much better PR for it. -- 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
[GitHub] [tomcat-jakartaee-migration] DanielThomas commented on a diff in pull request #36: Improve composability when using from other tools
DanielThomas commented on code in PR #36:
URL:
https://github.com/apache/tomcat-jakartaee-migration/pull/36#discussion_r1005164436
##
src/main/java/org/apache/tomcat/jakartaee/ManifestConverter.java:
##
@@ -48,20 +48,16 @@ public boolean accepts(String filename) {
}
@Override
-public void convert(String path, InputStream src, OutputStream dest,
EESpecProfile profile) throws IOException {
+public boolean convert(String path, InputStream src, OutputStream dest,
EESpecProfile profile) throws IOException {
Manifest srcManifest = new Manifest(src);
Manifest destManifest = new Manifest(srcManifest);
-boolean result = false;
-
-result = result | removeSignatures(destManifest);
+boolean result = removeSignatures(destManifest);
result = result | updateValues(destManifest, profile);
-if (result) {
-destManifest.write(dest);
-} else {
-srcManifest.write(dest);
Review Comment:
Pushed a new commit which should hopefully address these concerns:
https://github.com/apache/tomcat-jakartaee-migration/pull/36/commits/136c537e1e9d0274261d8749fe3a6747f6a9dc3c.
To clarify, the intention of `hasConverted` is not to indicate that no
changes were made, but that the source can be used and satisfy the selected
profile. Manifests still get modified, zip version compatibility changes, file
attributes are dropped, etc., that's unavoidable with the current
implementation. That makes it impossible to tell if you need to use a
destination file, which is why `hasConverted` exists.
--
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
[GitHub] [tomcat-jakartaee-migration] DanielThomas commented on a diff in pull request #36: Improve composability when using from other tools
DanielThomas commented on code in PR #36:
URL:
https://github.com/apache/tomcat-jakartaee-migration/pull/36#discussion_r1005164436
##
src/main/java/org/apache/tomcat/jakartaee/ManifestConverter.java:
##
@@ -48,20 +48,16 @@ public boolean accepts(String filename) {
}
@Override
-public void convert(String path, InputStream src, OutputStream dest,
EESpecProfile profile) throws IOException {
+public boolean convert(String path, InputStream src, OutputStream dest,
EESpecProfile profile) throws IOException {
Manifest srcManifest = new Manifest(src);
Manifest destManifest = new Manifest(srcManifest);
-boolean result = false;
-
-result = result | removeSignatures(destManifest);
+boolean result = removeSignatures(destManifest);
result = result | updateValues(destManifest, profile);
-if (result) {
-destManifest.write(dest);
-} else {
-srcManifest.write(dest);
Review Comment:
Pushed a new commit which should hopefully address these concerns:
https://github.com/apache/tomcat-jakartaee-migration/pull/36/commits/136c537e1e9d0274261d8749fe3a6747f6a9dc3c.
To clarify, the intention of `hasConverted` is not to indicate that no
changes were made, but that the source can be used and satisfy the selected
profile. Manifests still get modified, zip version compatibility changes, file
attributes are dropped, etc., that's unavoidable with the current
implementation, which makes it impossible to tell if you need to use a
destination file, which is why `hasConverted` needs to exist.
--
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
[GitHub] [tomcat-jakartaee-migration] DanielThomas commented on a diff in pull request #36: Improve composability when using from other tools
DanielThomas commented on code in PR #36:
URL:
https://github.com/apache/tomcat-jakartaee-migration/pull/36#discussion_r1005164436
##
src/main/java/org/apache/tomcat/jakartaee/ManifestConverter.java:
##
@@ -48,20 +48,16 @@ public boolean accepts(String filename) {
}
@Override
-public void convert(String path, InputStream src, OutputStream dest,
EESpecProfile profile) throws IOException {
+public boolean convert(String path, InputStream src, OutputStream dest,
EESpecProfile profile) throws IOException {
Manifest srcManifest = new Manifest(src);
Manifest destManifest = new Manifest(srcManifest);
-boolean result = false;
-
-result = result | removeSignatures(destManifest);
+boolean result = removeSignatures(destManifest);
result = result | updateValues(destManifest, profile);
-if (result) {
-destManifest.write(dest);
-} else {
-srcManifest.write(dest);
Review Comment:
Pushed a new commit which should hopefully address these concerns:
https://github.com/apache/tomcat-jakartaee-migration/pull/36/commits/136c537e1e9d0274261d8749fe3a6747f6a9dc3c.
To clarify, the intention of `hasConverted` is not to indicate that no
changes were made, but that the source can be used and satisfy the selected
profile. Manifests still get modified, zip version compatibility changes, file
attributes are dropped, etc., that's unavoidable with the current
implementation.
--
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
[GitHub] [tomcat-jakartaee-migration] DanielThomas commented on a diff in pull request #36: Improve composability when using from other tools
DanielThomas commented on code in PR #36:
URL:
https://github.com/apache/tomcat-jakartaee-migration/pull/36#discussion_r1005164436
##
src/main/java/org/apache/tomcat/jakartaee/ManifestConverter.java:
##
@@ -48,20 +48,16 @@ public boolean accepts(String filename) {
}
@Override
-public void convert(String path, InputStream src, OutputStream dest,
EESpecProfile profile) throws IOException {
+public boolean convert(String path, InputStream src, OutputStream dest,
EESpecProfile profile) throws IOException {
Manifest srcManifest = new Manifest(src);
Manifest destManifest = new Manifest(srcManifest);
-boolean result = false;
-
-result = result | removeSignatures(destManifest);
+boolean result = removeSignatures(destManifest);
result = result | updateValues(destManifest, profile);
-if (result) {
-destManifest.write(dest);
-} else {
-srcManifest.write(dest);
Review Comment:
Pushed a new commit which should address these concerns:
https://github.com/apache/tomcat-jakartaee-migration/pull/36/commits/136c537e1e9d0274261d8749fe3a6747f6a9dc3c.
--
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
[GitHub] [tomcat-jakartaee-migration] DanielThomas commented on a diff in pull request #36: Improve composability when using from other tools
DanielThomas commented on code in PR #36:
URL:
https://github.com/apache/tomcat-jakartaee-migration/pull/36#discussion_r1005151612
##
src/main/java/org/apache/tomcat/jakartaee/ManifestConverter.java:
##
@@ -48,20 +48,16 @@ public boolean accepts(String filename) {
}
@Override
-public void convert(String path, InputStream src, OutputStream dest,
EESpecProfile profile) throws IOException {
+public boolean convert(String path, InputStream src, OutputStream dest,
EESpecProfile profile) throws IOException {
Manifest srcManifest = new Manifest(src);
Manifest destManifest = new Manifest(srcManifest);
-boolean result = false;
-
-result = result | removeSignatures(destManifest);
+boolean result = removeSignatures(destManifest);
result = result | updateValues(destManifest, profile);
-if (result) {
-destManifest.write(dest);
-} else {
-srcManifest.write(dest);
Review Comment:
> some jars are converted, some are not, but information for the unconverted
jars is changed
`Attributes` is a `HashMap` so in many cases, reading and writing the
manifest in this way is causing the key order to change, which is why I
switched to always writing `destManifest`. If the intention was to write the
manifest unchanged, we'd write the original bytes instead, and use another way
to determine if only implementation version was changed for the conversion
return value.
Edit: In fact, I'll do just that and it occurs to me that signatures should
get the same handling. Let me get another commit up and see what you think.
--
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
[GitHub] [tomcat-jakartaee-migration] DanielThomas commented on a diff in pull request #36: Improve composability when using from other tools
DanielThomas commented on code in PR #36:
URL:
https://github.com/apache/tomcat-jakartaee-migration/pull/36#discussion_r1005151612
##
src/main/java/org/apache/tomcat/jakartaee/ManifestConverter.java:
##
@@ -48,20 +48,16 @@ public boolean accepts(String filename) {
}
@Override
-public void convert(String path, InputStream src, OutputStream dest,
EESpecProfile profile) throws IOException {
+public boolean convert(String path, InputStream src, OutputStream dest,
EESpecProfile profile) throws IOException {
Manifest srcManifest = new Manifest(src);
Manifest destManifest = new Manifest(srcManifest);
-boolean result = false;
-
-result = result | removeSignatures(destManifest);
+boolean result = removeSignatures(destManifest);
result = result | updateValues(destManifest, profile);
-if (result) {
-destManifest.write(dest);
-} else {
-srcManifest.write(dest);
Review Comment:
> some jars are converted, some are not, but information for the unconverted
jars is changed
`Attributes` is a `HashMap` so in many cases, reading and writing the
manifest in this way is causing the key order to change, which is why I
switched to always writing `destManifest`. If the intention was to write the
manifest unchanged, we'd write the original bytes instead, and use another way
to determine if only implementation version was changed for the conversion
return value.
--
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
[GitHub] [tomcat-jakartaee-migration] DanielThomas commented on a diff in pull request #36: Improve composability when using from other tools
DanielThomas commented on code in PR #36:
URL:
https://github.com/apache/tomcat-jakartaee-migration/pull/36#discussion_r1005151612
##
src/main/java/org/apache/tomcat/jakartaee/ManifestConverter.java:
##
@@ -48,20 +48,16 @@ public boolean accepts(String filename) {
}
@Override
-public void convert(String path, InputStream src, OutputStream dest,
EESpecProfile profile) throws IOException {
+public boolean convert(String path, InputStream src, OutputStream dest,
EESpecProfile profile) throws IOException {
Manifest srcManifest = new Manifest(src);
Manifest destManifest = new Manifest(srcManifest);
-boolean result = false;
-
-result = result | removeSignatures(destManifest);
+boolean result = removeSignatures(destManifest);
result = result | updateValues(destManifest, profile);
-if (result) {
-destManifest.write(dest);
-} else {
-srcManifest.write(dest);
Review Comment:
> some jars are converted, some are not, but information for the unconverted
jars is changed
`Attributes` is a `HashMap` so many cases, reading and writing the manifest
in this way is causing the key order to change, which is why I switched to
always writing `destManifest`. If the intention was to write the manifest
unchanged, we'd write original bytes instead, and use another way to determine
if only implementation version was changed for the conversion return value.
--
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
[GitHub] [tomcat-jakartaee-migration] DanielThomas commented on a diff in pull request #36: Improve composability when using from other tools
DanielThomas commented on code in PR #36:
URL:
https://github.com/apache/tomcat-jakartaee-migration/pull/36#discussion_r1005151612
##
src/main/java/org/apache/tomcat/jakartaee/ManifestConverter.java:
##
@@ -48,20 +48,16 @@ public boolean accepts(String filename) {
}
@Override
-public void convert(String path, InputStream src, OutputStream dest,
EESpecProfile profile) throws IOException {
+public boolean convert(String path, InputStream src, OutputStream dest,
EESpecProfile profile) throws IOException {
Manifest srcManifest = new Manifest(src);
Manifest destManifest = new Manifest(srcManifest);
-boolean result = false;
-
-result = result | removeSignatures(destManifest);
+boolean result = removeSignatures(destManifest);
result = result | updateValues(destManifest, profile);
-if (result) {
-destManifest.write(dest);
-} else {
-srcManifest.write(dest);
Review Comment:
> some jars are converted, some are not, but information for the unconverted
jars is changed
`Attributes` is a `HashMap` so in the majority of cases, reading and writing
the manifest in this way is causing the key order to change, which is why I
switched to always writing `destManifest`. If the intention was to write the
manifest unchanged, we'd write original bytes instead, and use another way to
determine if only implementation version was changed for the conversion return
value.
--
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
[GitHub] [tomcat-jakartaee-migration] aooohan commented on a diff in pull request #36: Improve composability when using from other tools
aooohan commented on code in PR #36:
URL:
https://github.com/apache/tomcat-jakartaee-migration/pull/36#discussion_r1005142148
##
src/main/java/org/apache/tomcat/jakartaee/ManifestConverter.java:
##
@@ -48,20 +48,16 @@ public boolean accepts(String filename) {
}
@Override
-public void convert(String path, InputStream src, OutputStream dest,
EESpecProfile profile) throws IOException {
+public boolean convert(String path, InputStream src, OutputStream dest,
EESpecProfile profile) throws IOException {
Manifest srcManifest = new Manifest(src);
Manifest destManifest = new Manifest(srcManifest);
-boolean result = false;
-
-result = result | removeSignatures(destManifest);
+boolean result = removeSignatures(destManifest);
result = result | updateValues(destManifest, profile);
-if (result) {
-destManifest.write(dest);
-} else {
-srcManifest.write(dest);
Review Comment:
Here it is still necessary to revert, as the conversion is fine for the
specified jar, but for directory migration via the migrator, the manifest of
some jars here will be affected(some jars are converted, some are not, but
information for the unconverted jars is changed), even if the jar is not
converted.
--
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: [DISCUSS] EOL date for 8.5.x
> On Oct 21, 2022, at 12:12 PM, Christopher Schultz > wrote: > > I'm wondering if I should migrate my applications to 9.0 or 10.x and start > re-writing imports. The flexibility of Tomcat 10.x is just incredible. I'm > kind of leaning toward skipping 9.x. Do it! :) -David smime.p7s Description: S/MIME cryptographic signature
Re: [DISCUSS] EOL date for 8.5.x
> On Oct 7, 2022, at 2:27 AM, Mark Thomas wrote: > > Hi all, > > I don't think there is a need to make a decision on this quickly, but based > on past experience and the current discussions about Jakarta EE 11 I think > this is something we need to start thinking about. > > Some key facts: > > - Tomcat 7.0.x reached EOL on 31 March 2021 > - EOL dates for major versions tend to be 3-4 years apart > - We aim to support 3 major versions in parallel - currently 8.5.x, > 9.0.x and 10.1.x. > - Tomcat 11 will implement Jakarta EE 11 > - Current Jakarta EE discussions are around a release in ~1 year > - Ideally, Tomcat 8.5.x EOL would be just after Tomcat 11 is declared > stable > > Based on the above I think EOL for 8.5.x should be either 31 March 2024 or 30 > Sept 2024 depending on when we think Jakarta EE 11 will be released. > > Jakarta EE releases have tendency to slip so I think the 30 Sept 2024 is > probably the more likely. However, it is much easier to delay an EOL date > than to bring to bring it forward so my current thinking is to announce 31 > March 2024 as the EOL date for 8.5.x and keep in mind that we can extend that > if we want to. > > Thoughts? Sounds good to me. From a TomEE perspective, the only release streams that'd be affected are TomEE 7.1 and 7.0. Both of those already have unmaintained dependencies with CVEs, so releases of them have already stopped. -David smime.p7s Description: S/MIME cryptographic signature
[GitHub] [tomcat-jakartaee-migration] DanielThomas commented on a diff in pull request #36: Improve composability when using from other tools
DanielThomas commented on code in PR #36:
URL:
https://github.com/apache/tomcat-jakartaee-migration/pull/36#discussion_r1005100601
##
src/main/java/org/apache/tomcat/jakartaee/ManifestConverter.java:
##
@@ -112,7 +107,7 @@ private boolean updateValues(Attributes attributes,
EESpecProfile profile) {
if (attributes.containsKey(Attributes.Name.IMPLEMENTATION_VERSION)) {
String newValue =
attributes.get(Attributes.Name.IMPLEMENTATION_VERSION) + "-" +
Info.getVersion();
attributes.put(Attributes.Name.IMPLEMENTATION_VERSION, newValue);
-result = true;
+// Purposefully avoid setting result
Review Comment:
This is metadata and would cause every file with an implementation version
attribute (which is practically everything) to be considered converted, even if
no interesting conversions took place. The destination manifest is written
regardless with this change, so this doesn't prevent the updated implementation
version from hitting the destination file. Omitting this is what allows
`hasConverted()` to 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.
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
[GitHub] [tomcat-jakartaee-migration] DanielThomas commented on a diff in pull request #36: Improve composability when using from other tools
DanielThomas commented on code in PR #36:
URL:
https://github.com/apache/tomcat-jakartaee-migration/pull/36#discussion_r1005100601
##
src/main/java/org/apache/tomcat/jakartaee/ManifestConverter.java:
##
@@ -112,7 +107,7 @@ private boolean updateValues(Attributes attributes,
EESpecProfile profile) {
if (attributes.containsKey(Attributes.Name.IMPLEMENTATION_VERSION)) {
String newValue =
attributes.get(Attributes.Name.IMPLEMENTATION_VERSION) + "-" +
Info.getVersion();
attributes.put(Attributes.Name.IMPLEMENTATION_VERSION, newValue);
-result = true;
+// Purposefully avoid setting result
Review Comment:
This is metadata and would cause every file to be considered converted, even
if no interesting conversions took place. The destination manifest is written
regardless with this change, so this doesn't prevent the updated implementation
version from hitting the destination file. Omitting this is what allows
`hasConverted()` to 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.
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
[GitHub] [tomcat-jakartaee-migration] DanielThomas commented on a diff in pull request #36: Improve composability when using from other tools
DanielThomas commented on code in PR #36:
URL:
https://github.com/apache/tomcat-jakartaee-migration/pull/36#discussion_r1005100601
##
src/main/java/org/apache/tomcat/jakartaee/ManifestConverter.java:
##
@@ -112,7 +107,7 @@ private boolean updateValues(Attributes attributes,
EESpecProfile profile) {
if (attributes.containsKey(Attributes.Name.IMPLEMENTATION_VERSION)) {
String newValue =
attributes.get(Attributes.Name.IMPLEMENTATION_VERSION) + "-" +
Info.getVersion();
attributes.put(Attributes.Name.IMPLEMENTATION_VERSION, newValue);
-result = true;
+// Purposefully avoid setting result
Review Comment:
This is metadata and would cause every file to be considered converted, even
if no interesting conversions took place. The destination manifest is written
regardless with this change. Omitting this is what allows `hasConverted()` to
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.
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 66323] New: JDK_JAVA_OPTIONS grows unboundedly if webapp restarts Tomcat
https://bz.apache.org/bugzilla/show_bug.cgi?id=66323 Bug ID: 66323 Summary: JDK_JAVA_OPTIONS grows unboundedly if webapp restarts Tomcat Product: Tomcat 9 Version: 9.0.65 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: martin.do...@hitachivantara.com Target Milestone: - The code at: https://github.com/apache/tomcat/blob/09193e0514ac449df454184941bba492d9b20a85/bin/catalina.sh#L294 ... that starts appending to JDK_JAVA_OPTIONS with: JDK_JAVA_OPTIONS="$JDK_JAVA_OPTIONS --add-opens=java.base/java.lang=ALL-UNNAMED" ... eventually causes an error like: [exec] /opt/smu/tomcat/bin/catalina.sh: 1: eval: /opt/smu/javaTools/java/bin/java: Argument list too long ... if the Tomcat webapp restarts Tomcat enough times (on the order of 553) to break a 128 KiB limit on the length of a single environment variable that the shell is perhaps imposing. I think this code was originally from Tomcat 9.0.0.M23 2017-07-03 in https://github.com/apache/tomcat/commit/4ad5264746e667a9874d6a56f6d52a7faa051b09 but was backported to Tomcat 8.5.24 2017-10-02 with https://github.com/apache/tomcat/commit/c3f3260481f14a9107994a6ee18f9e5ccc48c692. We'll solve it without changing Tomcat, not least as our wrapper code is doing something similar with another environment variable, but I would have found the diagnosis easier if my web search for E2BIG "Argument list too long" catalina.sh had shown me the way, so I wanted to report 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
Re: November release round
On Tue, Oct 25, 2022 at 5:52 PM Mark Thomas wrote: > > Hi all, > > I've just seen the heads up from the OpenSSL project that there will be > a 3.0.7 release on 2022-12-01 that will address a critical > vulnerability. We won't know the details of the vulnerability until the > release announcement. Given that it may trigger a Tomcat Native release > my current thinking is: > > - prep for November releases as normal > - review the OpenSSL issue once public > - roll a Tomcat Native release if necessary > - update to the new Tomcat Native release of there is one > - roll the Tomcat releases > > Do we want to pick up an updated migration tool as well? Maybe, we're in the process of integrating a PR for the tool. The submitter says it makes it run faster. Rémy > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
November release round
Hi all, I've just seen the heads up from the OpenSSL project that there will be a 3.0.7 release on 2022-12-01 that will address a critical vulnerability. We won't know the details of the vulnerability until the release announcement. Given that it may trigger a Tomcat Native release my current thinking is: - prep for November releases as normal - review the OpenSSL issue once public - roll a Tomcat Native release if necessary - update to the new Tomcat Native release of there is one - roll the Tomcat releases Do we want to pick up an updated migration tool as well? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Migrating away from Travis CI
On Tue, Oct 25, 2022 at 10:01 AM Mark Thomas wrote: > > Hi all, > > Infra have notified us that we need to migrate off Travis CI. The > recommended replacement is GitHub actions. > > We are already using GitHub actions as a smoke test and we also have > BuiltBot and Gump providing CI. > > Travis provides access to ARM64, s390x and ppc64le which do not appear > to be available in any of our current CI systems. > > The ASF Jenkins service does appear to have a ppc64le node. There also > appears to be an ARM64 node but it is currently unavailable. > > We need to remove the configuration for the Travis builds. That is easy > to do. The question is do we want to replace the builds for these > additional platforms? > > I don't recall any instances of platform specific issues detected by > these CI systems. Travis has been so unreliable at times, I have > contemplated removing the Travis builds entirely irrespective of this > migration request from the infrastructure team. I am therefore leaning > towards the simple solution of not replacing the Travis builds. Should > we have a platform specific bug reported then we can, as we have done in > the past, figure out a way to get access to a suitable test environment. > > Thoughts? Given history, we should be fine with only GH actions and the main Apache CI. Sure having more platforms is always a good bonus, but if it is no longer easy to have it's likely not worth the effort. Rémy > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat-jakartaee-migration] rmaucher commented on pull request #36: Improve composability when using from other tools
rmaucher commented on PR #36: URL: https://github.com/apache/tomcat-jakartaee-migration/pull/36#issuecomment-1290577491 This looks like a very good improvement overall. -- 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
Migrating away from Travis CI
Hi all, Infra have notified us that we need to migrate off Travis CI. The recommended replacement is GitHub actions. We are already using GitHub actions as a smoke test and we also have BuiltBot and Gump providing CI. Travis provides access to ARM64, s390x and ppc64le which do not appear to be available in any of our current CI systems. The ASF Jenkins service does appear to have a ppc64le node. There also appears to be an ARM64 node but it is currently unavailable. We need to remove the configuration for the Travis builds. That is easy to do. The question is do we want to replace the builds for these additional platforms? I don't recall any instances of platform specific issues detected by these CI systems. Travis has been so unreliable at times, I have contemplated removing the Travis builds entirely irrespective of this migration request from the infrastructure team. I am therefore leaning towards the simple solution of not replacing the Travis builds. Should we have a platform specific bug reported then we can, as we have done in the past, figure out a way to get access to a suitable test environment. Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat-jakartaee-migration] aooohan commented on a diff in pull request #36: Improve composability when using from other tools
aooohan commented on code in PR #36:
URL:
https://github.com/apache/tomcat-jakartaee-migration/pull/36#discussion_r1004090783
##
src/main/java/org/apache/tomcat/jakartaee/ManifestConverter.java:
##
@@ -48,20 +48,16 @@ public boolean accepts(String filename) {
}
@Override
-public void convert(String path, InputStream src, OutputStream dest,
EESpecProfile profile) throws IOException {
+public boolean convert(String path, InputStream src, OutputStream dest,
EESpecProfile profile) throws IOException {
Manifest srcManifest = new Manifest(src);
Manifest destManifest = new Manifest(srcManifest);
-boolean result = false;
-
-result = result | removeSignatures(destManifest);
+boolean result = removeSignatures(destManifest);
result = result | updateValues(destManifest, profile);
-if (result) {
-destManifest.write(dest);
-} else {
-srcManifest.write(dest);
Review Comment:
This change raises the problem that if `IMPLEMENTATION_VERSION` exists, it
must not be the original version content, even if the rest of the content has
not been converted.
--
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
[GitHub] [tomcat-jakartaee-migration] aooohan commented on a diff in pull request #36: Improve composability when using from other tools
aooohan commented on code in PR #36:
URL:
https://github.com/apache/tomcat-jakartaee-migration/pull/36#discussion_r1004090783
##
src/main/java/org/apache/tomcat/jakartaee/ManifestConverter.java:
##
@@ -48,20 +48,16 @@ public boolean accepts(String filename) {
}
@Override
-public void convert(String path, InputStream src, OutputStream dest,
EESpecProfile profile) throws IOException {
+public boolean convert(String path, InputStream src, OutputStream dest,
EESpecProfile profile) throws IOException {
Manifest srcManifest = new Manifest(src);
Manifest destManifest = new Manifest(srcManifest);
-boolean result = false;
-
-result = result | removeSignatures(destManifest);
+boolean result = removeSignatures(destManifest);
result = result | updateValues(destManifest, profile);
-if (result) {
-destManifest.write(dest);
-} else {
-srcManifest.write(dest);
Review Comment:
This change raises the problem that if a version number exists, it must not
be the original version number, even if the rest of the content has not been
converted.
--
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 66320] NPE in checkResources
https://bz.apache.org/bugzilla/show_bug.cgi?id=66320 Mark Thomas changed: What|Removed |Added Resolution|--- |INVALID Status|REOPENED|RESOLVED --- Comment #3 from Mark Thomas --- The information provided in the description indicates that the root cause is a configuration error. Support for configuration errors is provided on the mailing lists, not in Bugzilla. Given the flexibility and extensibility of Apache Tomcat, the code does not aim to handle every possible user error by catching the exception and providing an error message. In many cases, such as this, the default exception and stack trace provides all the information required. Given the tone of comment #2 I strongly recommend you read https://www.apache.org/foundation/policies/conduct.html before you ask for support on the users mailing list. I also recommend http://www.catb.org/~esr/faqs/smart-questions.html -- 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-jakartaee-migration] aooohan commented on a diff in pull request #36: Improve composability when using from other tools
aooohan commented on code in PR #36:
URL:
https://github.com/apache/tomcat-jakartaee-migration/pull/36#discussion_r1004088967
##
src/main/java/org/apache/tomcat/jakartaee/ManifestConverter.java:
##
@@ -112,7 +107,7 @@ private boolean updateValues(Attributes attributes,
EESpecProfile profile) {
if (attributes.containsKey(Attributes.Name.IMPLEMENTATION_VERSION)) {
String newValue =
attributes.get(Attributes.Name.IMPLEMENTATION_VERSION) + "-" +
Info.getVersion();
attributes.put(Attributes.Name.IMPLEMENTATION_VERSION, newValue);
-result = true;
+// Purposefully avoid setting result
Review Comment:
Changing the version also counts as a conversion, so here need to revert.
--
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
