[Bug 67065] Using "::1" to bind to all local addresses (IPV4 and IPV6)
https://bz.apache.org/bugzilla/show_bug.cgi?id=67065 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Mark Thomas --- Not possible with the Java Socket API. -- 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 65770] Make keys reload automatically
https://bz.apache.org/bugzilla/show_bug.cgi?id=65770 --- Comment #8 from Mark Thomas --- I've been discussing this with the users recently and came up with the following approach. - Lifecycle listener that ships with Tomcat - Every X minutes (driven by background process but customisable so checks don't happen every time the background process runs) - Checks expiry time of each cert. - For each cert with less than Y days reload TLS config - If cert still has less than Y days remaining, log a warning This listener would be disabled by default but available as part of the standard Tomcat distribution. -- 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 55477] Add a solution to map a realm name to a security role
https://bz.apache.org/bugzilla/show_bug.cgi?id=55477 Mark Thomas changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #23 from Mark Thomas --- *** This bug has been marked as a duplicate of bug 5 *** -- 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 66665] Provide option to supply role mapping from a properties file
https://bz.apache.org/bugzilla/show_bug.cgi?id=5 Mark Thomas changed: What|Removed |Added CC||ste...@mayr-stefan.de --- Comment #3 from Mark Thomas --- *** Bug 55477 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 56166] Suggestions for exception handling (avoid potential bugs)
https://bz.apache.org/bugzilla/show_bug.cgi?id=56166 Mark Thomas changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #4 from Mark Thomas --- Lets be realistic, this report isn't ever going to be addressed. Specific reports about actual bugs will be addressed. -- 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 67080] ImplicitObjectELResolverImpl.getValue() is slow
https://bz.apache.org/bugzilla/show_bug.cgi?id=67080 --- Comment #2 from Christopher Schultz --- I haven't studied what the Java compiler does with switch(String) statements, but I believe that numeric-based switch statements have two flavors: lookup vs table. One of them is faster but is only possible under certain circumstances. Introducing Strings likely complicates things further. If we just need to convert a String value into a number, there's a data structure pretty much purpose-built for that: a hash table. What if you implement the lookup as HashMap.get()? -- 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 67065] Using "::1" to bind to all local addresses (IPV4 and IPV6)
https://bz.apache.org/bugzilla/show_bug.cgi?id=67065 --- Comment #2 from Christopher Schultz --- :/ The "address" attribute for the AJP connector is documented[1] to have this behavior for the Java-based connectors. Is the documentation wrong, there, or it indeed possible to bind to "all local addresses" in the way described there? [1] https://tomcat.apache.org/tomcat-8.5-doc/config/ajp.html, search for "For servers with more than one IP address" -- 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 67065] Using "::1" to bind to all local addresses (IPV4 and IPV6)
https://bz.apache.org/bugzilla/show_bug.cgi?id=67065 --- Comment #3 from Mark Thomas --- :: and 0.0.0.0 are special cases for "all addresses". There is no equivalent for "all local addresses" -- 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 65770] Make keys reload automatically
https://bz.apache.org/bugzilla/show_bug.cgi?id=65770 --- Comment #9 from Christopher Schultz --- (In reply to Mark Thomas from comment #8) > I've been discussing this with the users recently and came up with the > following approach. > > - Lifecycle listener that ships with Tomcat > - Every X minutes (driven by background process but customisable so checks > don't happen every time the background process runs) > - Checks expiry time of each cert. > - For each cert with less than Y days reload TLS config Why have this "must be less than Y days-to-expiration" predicate? Why not just always-reload if e.g. the source timestamp has changed? There are many reasons to swap-out certificates that are not expiring. We probably should make sure the file is at least X ms old to prevent trying to reload a file that it in the process of being re-written. > - If cert still has less than Y days remaining, log a warning I think this will fill the logs. -- 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 67080] ImplicitObjectELResolverImpl.getValue() is slow
https://bz.apache.org/bugzilla/show_bug.cgi?id=67080
--- Comment #3 from John Engebretson ---
I used javap to examine the bytecode of the reproducer - the full output is
attached but the critical portion is below. In short, it hashes each constant
and switches based on that hash.
This is superior to binary search because it's constant-time and superior to
HashMap because there is no object instantiation/traversal.
protected void runNewTest();
descriptor: ()V
flags: (0x0004) ACC_PROTECTED
Code:
stack=5, locals=5, args_size=1
0: iconst_m1
1: istore_1
2: iconst_0
3: istore_2
4: goto 363
7: getstatic #40 // Field
TEST_SCOPES:[Ljava/lang/String;
10: iload_2
11: aaload
12: astore_3
13: aload_3
14: dup
15: astore4
17: invokevirtual #62 // Method
java/lang/String.hashCode:()I
20: lookupswitch { // 11
-1354757532: 120
-1221270899: 133
-697829026: 146
-272077475: 159
-214877152: 172
-10806556: 185
106436749: 198
872295685: 211
889144335: 224
1291689221: 237
2073857551: 250
default: 324
}
120: aload 4
122: ldc #18 // String cookie
124: invokevirtual #66 // Method
java/lang/String.equals:(Ljava/lang/Object;)Z
127: ifne 294
130: goto 324
133: aload 4
135: ldc #20 // String header
137: invokevirtual #66 // Method
java/lang/String.equals:(Ljava/lang/Object;)Z
140: ifne 283
143: goto 324
146: aload 4
--
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 67080] ImplicitObjectELResolverImpl.getValue() is slow
https://bz.apache.org/bugzilla/show_bug.cgi?id=67080 --- Comment #4 from John Engebretson --- Created attachment 38938 --> https://bz.apache.org/bugzilla/attachment.cgi?id=38938&action=edit decompiled reproducer -- 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 67065] Using "::1" to bind to all local addresses (IPV4 and IPV6)
https://bz.apache.org/bugzilla/show_bug.cgi?id=67065 --- Comment #4 from Christopher Schultz --- Aha. What if the enhancement request were to be re-worded to be "use ::1 as an alias for both ::1 and 127.0.0.1 as appropriate"? Instead of "all local addresses" which may be a little ambiguous. "Loopback" may be a better term to use, but the idea is to not have to configure two separate s. Is this possible? Or would it basically require Tomcat to clone the and bind each separately to the individual loopback addresses? That would be pretty cool, but there is always the possibility of a "competing" configured elsewhere and so it's better to solve this with (additional) configuration and not 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
[Bug 67080] ImplicitObjectELResolverImpl.getValue() is slow
https://bz.apache.org/bugzilla/show_bug.cgi?id=67080 Anurag Dubey changed: What|Removed |Added CC||anura...@amazon.com -- 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
