[tomcat-jakartaee-migration] branch main updated: Recalculate the CRC value after converting to avoid CRC checksum failures when the entry type is STORED
This is an automated email from the ASF dual-hosted git repository.
lihan pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git
The following commit(s) were added to refs/heads/main by this push:
new d39df40 Recalculate the CRC value after converting to avoid CRC
checksum failures when the entry type is STORED
d39df40 is described below
commit d39df404eb7285c8482759626c5fc2e751a08000
Author: lihan
AuthorDate: Fri Aug 26 17:23:59 2022 +0800
Recalculate the CRC value after converting to avoid CRC checksum failures
when the entry type is STORED
---
CHANGES.md | 1 +
.../org/apache/tomcat/jakartaee/Migration.java | 75 --
2 files changed, 69 insertions(+), 7 deletions(-)
diff --git a/CHANGES.md b/CHANGES.md
index 1db82aa..51640b7 100644
--- a/CHANGES.md
+++ b/CHANGES.md
@@ -1,6 +1,7 @@
# Tomcat Migration Tool for Jakarta EE - Changelog
## 1.0.2 (in progress)
+- Fix [#29](https://github.com/apache/tomcat-jakartaee-migration/issues/29) by
recalculating the CRC value of the entry type is SORTED after converting (lihan)
## 1.0.1
- Fix [#19](https://github.com/apache/tomcat-jakartaee-migration/issues/19).
Add support for converting `.groovy` files.
diff --git a/src/main/java/org/apache/tomcat/jakartaee/Migration.java
b/src/main/java/org/apache/tomcat/jakartaee/Migration.java
index 3d87d1a..bd18767 100644
--- a/src/main/java/org/apache/tomcat/jakartaee/Migration.java
+++ b/src/main/java/org/apache/tomcat/jakartaee/Migration.java
@@ -32,8 +32,11 @@ import java.util.Set;
import java.util.concurrent.TimeUnit;
import java.util.logging.Level;
import java.util.logging.Logger;
+import java.util.zip.CRC32;
+import java.util.zip.ZipEntry;
import java.util.zip.ZipException;
+import org.apache.commons.compress.archivers.ArchiveEntry;
import org.apache.commons.compress.archivers.zip.ZipArchiveEntry;
import org.apache.commons.compress.archivers.zip.ZipArchiveInputStream;
import org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream;
@@ -211,8 +214,8 @@ public class Migration {
private void migrateArchiveStreaming(InputStream src, OutputStream dest)
throws IOException {
-try (ZipArchiveInputStream srcZipStream = new
ZipArchiveInputStream(new CloseShieldInputStream(src));
-ZipArchiveOutputStream destZipStream = new
ZipArchiveOutputStream(new CloseShieldOutputStream(dest))) {
+try (ZipArchiveInputStream srcZipStream = new
ZipArchiveInputStream(CloseShieldInputStream.wrap(src));
+CrcZipArchiveOutputStream destZipStream = new
CrcZipArchiveOutputStream(CloseShieldOutputStream.wrap(dest))) {
ZipArchiveEntry srcZipEntry;
while ((srcZipEntry = srcZipStream.getNextZipEntry()) != null) {
String srcName = srcZipEntry.getName();
@@ -221,7 +224,7 @@ public class Migration {
continue;
}
String destName = profile.convert(srcName);
-RenamableZipArchiveEntry destZipEntry = new
RenamableZipArchiveEntry(srcZipEntry);
+MigrationZipArchiveEntry destZipEntry = new
MigrationZipArchiveEntry(srcZipEntry, false);
destZipEntry.setName(destName);
destZipStream.putArchiveEntry(destZipEntry);
migrateStream(srcName, srcZipStream, destZipStream);
@@ -251,7 +254,7 @@ public class Migration {
continue;
}
String destName = profile.convert(srcName);
-RenamableZipArchiveEntry destZipEntry = new
RenamableZipArchiveEntry(srcZipEntry);
+MigrationZipArchiveEntry destZipEntry = new
MigrationZipArchiveEntry(srcZipEntry, true);
destZipEntry.setName(destName);
destZipStream.putArchiveEntry(destZipEntry);
migrateStream(srcName, srcZipFile.getInputStream(srcZipEntry),
destZipStream);
@@ -316,10 +319,31 @@ public class Migration {
return false;
}
-private static class RenamableZipArchiveEntry extends ZipArchiveEntry {
-
-public RenamableZipArchiveEntry(ZipArchiveEntry entry) throws
ZipException {
+private static class MigrationZipArchiveEntry extends ZipArchiveEntry {
+protected final CRC32 crc = new CRC32();
+protected long size = 0;
+protected boolean needResetCrc;
+public MigrationZipArchiveEntry(ZipArchiveEntry entry, boolean
inMemory) throws ZipException {
super(entry);
+// No recalculation required, when in memory mode and not of type
SORTED
+needResetCrc = !inMemory && entry.getMethod() == ZipEntry.STORED;
+}
+
+@Override
+public long getSize() {
+return needResetCrc ? size : super.getSize();
+}
+
+@Override
+public long getCrc() {
+return needReset
[GitHub] [tomcat-jakartaee-migration] aooohan commented on pull request #30: Exception in thread "main" java.util.zip.ZipException: Bad CRC checksum for entry
aooohan commented on PR #30: URL: https://github.com/apache/tomcat-jakartaee-migration/pull/30#issuecomment-1228271046 Merge manually -- 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 closed pull request #30: Exception in thread "main" java.util.zip.ZipException: Bad CRC checksum for entry
aooohan closed pull request #30: Exception in thread "main" java.util.zip.ZipException: Bad CRC checksum for entry URL: https://github.com/apache/tomcat-jakartaee-migration/pull/30 -- 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 closed issue #29: Exception in thread "main" java.util.zip.ZipException: Bad CRC checksum for entry META-INF/MANIFEST.MF
aooohan closed issue #29: Exception in thread "main" java.util.zip.ZipException: Bad CRC checksum for entry META-INF/MANIFEST.MF URL: https://github.com/apache/tomcat-jakartaee-migration/issues/29 -- 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
[tomcat-jakartaee-migration] branch main updated (d39df40 -> 9e88142)
This is an automated email from the ASF dual-hosted git repository. lihan pushed a change to branch main in repository https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git from d39df40 Recalculate the CRC value after converting to avoid CRC checksum failures when the entry type is STORED add 9e88142 Remove duplicate property No new revisions were added by this update. Summary of changes: src/main/resources/org/apache/tomcat/jakartaee/LocalStrings.properties | 1 - 1 file changed, 1 deletion(-) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66240] New: "Invalid octet [-1]. The valid range for IPv4 octets is 0 to 255." error when subdomain is 4294967295
https://bz.apache.org/bugzilla/show_bug.cgi?id=66240 Bug ID: 66240 Summary: "Invalid octet [-1]. The valid range for IPv4 octets is 0 to 255." error when subdomain is 4294967295 Product: Tomcat 9 Version: 9.0.x Hardware: All Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: junh...@gmail.com Target Milestone: - my coworker found this bug reproduce in /etc/hosts add ``` 4294967295.localhost 127.0.0.1 ``` run tomcat (9.0.65) ``` $ docker run -it --rm -p :8080 tomcat:9.0 ``` open browser and connect to http://4294967295.localhost: log ``` 26-Aug-2022 12:23:11.063 INFO [http-nio-8080-exec-1] org.apache.coyote.AbstractProcessor.parseHost The host [4294967295.localhost:] is not valid Note: further occurrences of request parsing errors will be logged at DEBUG level. java.lang.IllegalArgumentException: Invalid octet [-1]. The valid range for IPv4 octets is 0 to 255. at org.apache.tomcat.util.http.parser.HttpParser.readHostIPv4(HttpParser.java:731) at org.apache.tomcat.util.http.parser.Host.parse(Host.java:73) at org.apache.tomcat.util.http.parser.Host.parse(Host.java:45) at org.apache.coyote.AbstractProcessor.parseHost(AbstractProcessor.java:298) at org.apache.coyote.http11.Http11Processor.prepareRequest(Http11Processor.java:793) at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:375) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:890) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1789) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) 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:61) at java.base/java.lang.Thread.run(Thread.java:833) ``` -- 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 66209] CPU regression when classpath Bloom filters are active
https://bz.apache.org/bugzilla/show_bug.cgi?id=66209 --- Comment #11 from Rahul Jaisimha --- I'm working with John on the updated patch. I'm going to go ahead with updating the "UseBloomFilterForArchives" setting to something similar to what Christopher mentioned: > I think it makes sense to re-name/alias the current setting to something > more clear such as "archiveIndexing" with values like "simple", "bloom" and > now "purged-bloom" or whatever. Do we know of a similar change that was made in the past? -- 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 66209] CPU regression when classpath Bloom filters are active
https://bz.apache.org/bugzilla/show_bug.cgi?id=66209 --- Comment #12 from Mark Thomas --- A related issue: it should probably be on the WebResourceRoot rather than the context. trimSpaces for JSPs did something similar (boolean -> String). -- 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 66240] "Invalid octet [-1]. The valid range for IPv4 octets is 0 to 255." error when subdomain is 4294967295
https://bz.apache.org/bugzilla/show_bug.cgi?id=66240 Stefan Mayr changed: What|Removed |Added OS||All --- Comment #1 from Stefan Mayr --- Interesting find. https://github.com/apache/tomcat/blob/831a674f7c12351cc3b537e899e7f20cb4d954ad/java/org/apache/tomcat/util/http/parser/Host.java#L65-L84 does not completely follow RFC 1123 Section 2.1 has this paragraph: If a dotted-decimal number can be entered without such identifying delimiters, then a full syntactic check must be made, because a segment of a host domain name is now allowed to begin with a digit and could legally be entirely numeric (see Section 6.1.2.4). However, a valid host name can never have the dotted-decimal form #.#.#.#, since at least the highest-level component label will be alphabetic. Looking at https://github.com/apache/tomcat/blob/831a674f7c12351cc3b537e899e7f20cb4d954ad/java/org/apache/tomcat/util/http/parser/HttpParser.java#L718-L719 rings a bell 4294967295 is 0x which should be -1 for Java int. That explains why it passes the condition in https://github.com/apache/tomcat/blob/831a674f7c12351cc3b537e899e7f20cb4d954ad/java/org/apache/tomcat/util/http/parser/HttpParser.java#L734 to throw that exception instead of following the else to fall back to readHostDomainName -- 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 66240] "Invalid octet [-1]. The valid range for IPv4 octets is 0 to 255." error when subdomain is 4294967295
https://bz.apache.org/bugzilla/show_bug.cgi?id=66240 --- Comment #2 from Stefan Mayr --- This also work for other values like 8589934591 (0x1) which result in an int overflow and produces 0x (-1) as a result -- 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] mayrstefan opened a new pull request, #548: Avoid int overflow when parsing octet
mayrstefan opened a new pull request, #548: URL: https://github.com/apache/tomcat/pull/548 When parsing an octet stop when value exceeds 255. Should fix [bug 66240](https://bz.apache.org/bugzilla/show_bug.cgi?id=66240) -- 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
