Re: [I] Configuration System Initialization Failure with PublishTrimmed in .NET 8 (logging-log4net)
FreeAndNil commented on issue #165: URL: https://github.com/apache/logging-log4net/issues/165#issuecomment-2406623392 @hhxdestiny nobody said otherwise. In case you have a sample application which reproduces the problem, feel free to reopen (or create a new issue). -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[I] log4j2.script.enableLanguages or log4j2.scriptEnableLanguages? (logging-log4j2)
martin-dorey-hv opened a new issue, #3079: URL: https://github.com/apache/logging-log4j2/issues/3079 ## Description Yeah, it doesn't functionally matter. I know. Now. If the rule is to follow camelCaseNames, then shouldn't new source set a good example? ## Configuration 2.24.0 ## Logs ## Reproduction https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.scriptEnableLanguages says it's log4j2.scriptEnableLanguages. We're told earlier, by https://logging.apache.org/log4j/2.x/manual/systemproperties.html that: > Since Log4j 2.10 all the property names follow a common naming scheme: > `log4j2.camelCasePropertyName` So scriptEnableLanguages then - simple, clear, good. It does go on to say: > To provide backward compatibility with versions older than 2.10 a certain number of additional property names is also supported using a fuzzy matching algorithm. (There's a plural agreement problem there - "is" should be "are".) However, the notes for a release later than 2.10, https://logging.apache.org/log4j/2.x/release-notes.html#release-notes-2-17-2, say: > Require log4j2.Script.enableLanguages to be specified to enable scripting for specific languages. ([LOG4J2-2486](https://issues.apache.org/jira/browse/LOG4J2-2486)) ... and that different name is indeed the only name to be found in the source, at least the parts that aren't documentation, at https://github.com/search?q=repo%3Aapache%2Flogging-log4j2+enableLanguages&type=code. It wasn't until I found https://github.com/apache/logging-log4j2/blob/2.x/log4j-api/src/main/java/org/apache/logging/log4j/util/PropertySource.java#L135 that I became convinced that this wasn't the cause of my problems. Tidying up old source code, that's somewhat risky and no fun, but shouldn't new code follow the new rules? -- 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: notifications-unsubscr...@logging.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [I] Configuration System Initialization Failure with PublishTrimmed in .NET 8 (logging-log4net)
hhxdestiny commented on issue #165: URL: https://github.com/apache/logging-log4net/issues/165#issuecomment-2406600025 The problem still exists on 3.0.1 -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [I] (Closeable)ThreadContext putAll removes entire context (logging-log4j2)
vy closed issue #2946: (Closeable)ThreadContext putAll removes entire context URL: https://github.com/apache/logging-log4j2/issues/2946 -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Fix Android-related issues in Log4j Core (logging-log4j2)
ppkarwasz commented on PR #3071: URL: https://github.com/apache/logging-log4j2/pull/3071#issuecomment-2404871719 @vy, I added a FAQ entry in https://github.com/apache/logging-log4j2/pull/3071/commits/fbd4ea0c048ec66902f2dd6e13318636cb99966c. Since this PR can not be tested, until we publish a snapshot and the external [`android-test.yaml`](https://github.com/apache/logging-log4j-samples/actions/workflows/android-test.yaml) action succeeds, I am merging this PR. Feel free to improve the doc on `2.x`. -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Fix Android-related issues in Log4j Core (logging-log4j2)
ppkarwasz merged PR #3071: URL: https://github.com/apache/logging-log4j2/pull/3071 -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [I] Error using log4j2 api/core libraries with Android (logging-log4j2)
ppkarwasz closed issue #3056: Error using log4j2 api/core libraries with Android URL: https://github.com/apache/logging-log4j2/issues/3056 -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Fix key removal issues in Thread Context (logging-log4j2)
vy merged PR #3050: URL: https://github.com/apache/logging-log4j2/pull/3050 -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [I] Reload of key/trustsore when re-establishing a connection (logging-log4j2)
MichaelMorrisEst commented on issue #3074: URL: https://github.com/apache/logging-log4j2/issues/3074#issuecomment-2404863957 Hi @vy, thanks for the feedback > @MichaelMorrisEst, this is something crossed my mind while working on #2767, but I am not sure about the implications of trying to reload key/trust store on every new socket creation attempt. [Thinking out loud here...] If the server has indeed gained a new identity, reloading key/trust stores will solve the problem swiftly. But what if the failure is due to something else? If we decide to implement this, shall this be the default, or opt-in via a new attribute? If reloading at every re-connection is a concern then a slightly different approach could be to do the re-connection as today (i.e. don't reload the stores) but catch SSLHandshakeException and, when encountered then do the reload and try again. This would limit the reloading to only the relevant scenario of a handshake problem. I have no strong opinion on whether it should be default behaviour or opt in, and am happy to go with whichever the community prefers (if there is agreement on proceeding) > Another concern I have regarding this approach is we will be introducing an exception to the reconfiguration logic. That is, when a Log4j configuration is loaded, it is treated more or less immutable – obviously, except `LoggerConfig`s. Now we will introduce a _"please reload only this little configuration element"_ exception. I am not saying this is something bad per se. But exceptions generally bite us in the long run. > The key/truststore are already not handled the same as other configuration elements though (as changes to them do not trigger a reconfig). As they are excluded from the normal reconfiguration logic, then the only way to support changes to them is through something other than the normal reconfiguration logic. -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [I] RollingFileAppender rotates files incorrectly on ext4 due to filesystem timestamp caching (logging-log4j2)
ppkarwasz commented on issue #3068: URL: https://github.com/apache/logging-log4j2/issues/3068#issuecomment-2405009206 That commit is a fix to [LOG4J2-1906](https://issues.apache.org/jira/browse/LOG4J2-1906) and is probably related to #2297, where a regression occurred. Anyway I believe that those issues are independent of this one: - your problem affects only the **first** rollover after the JVM starts. At this time Log4j Core uses the timestamp on the current log file to deduce when the last rollover must have occurred. - those issues deal with the timestamp that is used in **all** rollovers. After the first rollover, Log4j Core does not need to check the filesystem to find out when the last rollover happened. :wink: -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[I] ScriptPatternSelector properties example throws "No type attribute provided for component patternMatch" (logging-log4j2)
martin-dorey-hv opened a new issue, #3078:
URL: https://github.com/apache/logging-log4j2/issues/3078
Problem is at
https://github.com/apache/logging-log4j2/blame/f7c26cd7710fdace463a370e85d0971107c91d8b/src/site/antora/modules/ROOT/examples/manual/pattern-layout/script-pattern-selector/log4j2.properties#L33
I suggest:
```
martind@stormy:~/tmp/D161042$ diff -u log4j2.properties{.orig,}
--- log4j2.properties.orig 2024-10-10 15:31:13.405464567 -0700
+++ log4j2.properties2024-10-10 15:31:34.670434140 -0700
@@ -30,12 +30,12 @@
} else {\
return null;\
}
-appender.0.layout.patternSelector.patternMatch.0.type = PatternMatch
-appender.0.layout.patternSelector.patternMatch.0.key = NoLocation
-appender.0.layout.patternSelector.patternMatch.0.pattern = [%-5level]
%c{1.} %msg%n
-appender.0.layout.patternSelector.patternMatch.1.type = PatternMatch
-appender.0.layout.patternSelector.patternMatch.1.key = Flow
-appender.0.layout.patternSelector.patternMatch.1.pattern = [%-5level]
%c{1.} == %C{1.}.%M:%L %msg ==%n
+appender.0.layout.patternSelector.0.type = PatternMatch
+appender.0.layout.patternSelector.0.key = NoLocation
+appender.0.layout.patternSelector.0.pattern = [%-5level] %c{1.} %msg%n
+appender.0.layout.patternSelector.1.type = PatternMatch
+appender.0.layout.patternSelector.1.key = Flow
+appender.0.layout.patternSelector.1.pattern = [%-5level] %c{1.} ==
%C{1.}.%M:%L %msg ==%n
rootLogger.level = WARN
rootLogger.appenderRef.0.ref = CONSOLE
martind@stormy:~/tmp/D161042$
```
I didn't check whether it was the only instance of such a problem, sorry. I
didn't even check whether there were any other problems in this file, let alone
anything constructive such as why automated testing didn't catch this. I
didn't find any other examples out on the internets. If I'm trying to provide
search engine fodder, for the next poor sap, I should show the full
presentation, which was this, once I'd got all my other problems out of the way:
```
Exception in thread "main"
org.apache.logging.log4j.core.config.ConfigurationException: No type attribute
provided for component patternMatch
at
org.apache.logging.log4j.core.config.properties.PropertiesConfigurationBuilder.createComponent(PropertiesConfigurationBuilder.java:338)
at
org.apache.logging.log4j.core.config.properties.PropertiesConfigurationBuilder.processRemainingProperties(PropertiesConfigurationBuilder.java:353)
at
org.apache.logging.log4j.core.config.properties.PropertiesConfigurationBuilder.createComponent(PropertiesConfigurationBuilder.java:341)
at
org.apache.logging.log4j.core.config.properties.PropertiesConfigurationBuilder.processRemainingProperties(PropertiesConfigurationBuilder.java:353)
at
org.apache.logging.log4j.core.config.properties.PropertiesConfigurationBuilder.createLayout(PropertiesConfigurationBuilder.java:330)
at
org.apache.logging.log4j.core.config.properties.PropertiesConfigurationBuilder.createAppender(PropertiesConfigurationBuilder.java:223)
at
org.apache.logging.log4j.core.config.properties.PropertiesConfigurationBuilder.build(PropertiesConfigurationBuilder.java:155)
at
org.apache.logging.log4j.core.config.properties.PropertiesConfigurationFactory.getConfiguration(PropertiesConfigurationFactory.java:56)
at
org.apache.logging.log4j.core.config.properties.PropertiesConfigurationFactory.getConfiguration(PropertiesConfigurationFactory.java:34)
at
org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:544)
at
org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:463)
at
org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:321)
at
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:719)
at
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:749)
at
org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:261)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:46)
at org.apache.logging.log4j.LogManager.getContext(LogManager.java:138)
at
org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:136)
at
org.apache.commons.logging.impl.Log4jApiLogFactory$LogAdapter.getContext(Log4jApiLogFactory.java:161)
at
org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:46)
at
org.apache.commons.logging.impl.Log4jApiLogFactory.getInstance(Log4jApiLogFactory.java:210)
at org.apache.commons.logging.LogFactory.
Re: [PR] Upgrades JUnit to version `5.11.2` (logging-log4j2)
vy commented on code in PR #3069:
URL: https://github.com/apache/logging-log4j2/pull/3069#discussion_r1794839740
##
log4j-core-test/src/main/java/org/apache/logging/log4j/core/test/junit/package-info.java:
##
@@ -20,7 +20,7 @@
* @see org.junit.rules.TestRule
*/
@Export
-@Version("2.23.0")
+@Version("2.23.1")
Review Comment:
Weren't you the one advising that we should use the version number of the
release a change will be published with? (If I'm mistaken, you can just ignore
my correction, but I'd appreciate an explanation.)
--
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: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] Use a random `${test:logging.path}` (logging-log4j2)
vy commented on code in PR #2954:
URL: https://github.com/apache/logging-log4j2/pull/2954#discussion_r1794842040
##
log4j-api-test/src/main/java/org/apache/logging/log4j/test/junit/TempLoggingDirectory.java:
##
@@ -135,6 +132,29 @@ private PathHolder createLoggingPath(final
ExtensionContext context, final Clean
return holder;
}
+private Path determinePerClassPath(ExtensionContext context) {
+// Check if the parent context already created a folder
+PathHolder holder =
ExtensionContextAnchor.getAttribute(PathHolder.class, PathHolder.class,
context);
+if (holder == null) {
+try {
+// Create temporary per-class directory
+final String baseDir = System.getProperty("basedir");
+final Path basePath = (baseDir != null ? Paths.get(baseDir,
"target") : Paths.get(".")).resolve("logs");
+final Class clazz = context.getRequiredTestClass();
+final Package pkg = clazz.getPackage();
+final String dir =
+pkg.getName().replaceAll("[.$]", File.separatorChar ==
'\\' ? "" : File.separator);
+// Create a temporary directory that uses the simple class
name as prefix
+Path packagePath = basePath.resolve(dir);
+Files.createDirectories(packagePath);
+return Files.createTempDirectory(packagePath,
clazz.getSimpleName());
Review Comment:
> Aren't those reruns happening inside the same JVM?
No, I am triggering it myself manually: `./mvnw test ...`.
--
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: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [I] Reload of key/trustsore when re-establishing a connection (logging-log4j2)
vy commented on issue #3074: URL: https://github.com/apache/logging-log4j2/issues/3074#issuecomment-2404633198 > If, during the retry, the key/truststore are reloaded, then the latest certs would always be used in re-establishing the connection and would effectively remove the need to trigger the reconfiguration. @MichaelMorrisEst, this is something crossed my mind while working on #2767, but I am not sure about the implications of trying to reload key/trust store on every new socket creation attempt. [Thinking out loud here...] If the server has indeed gained a new identity, reloading key/trust stores will solve the problem swiftly. But what if the failure is due to something else? If we decide to implement this, shall this be the default, or opt-in via a new attribute? Another concern I have regarding this approach is we will be introducing an exception to the reconfiguration logic. That is, when a Log4j configuration is loaded, it is treated more or less immutable – obviously, except `LoggerConfig`s. Now we will introduce a _"please reload only this little configuration element"_ exception. I am not saying this is something bad per se. But exceptions generally bite us in the long run. @ppkarwasz, any thoughts? -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[I] Reload of key/trustsore when re-establishing a connection (logging-log4j2)
MichaelMorrisEst opened a new issue, #3074: URL: https://github.com/apache/logging-log4j2/issues/3074 https://github.com/apache/logging-log4j2/pull/2767 introduces functionality to enable reloading key/trustore when the certs are renewed. However a manual step of triggering a reconfiguration (e.g. by touching the config file) is needed for the key/trust store to be reloaded. While this is a big improvement on having no reload, it is still not ideal to have to trigger a reconfiguration. The cert renewal has no impact on existing established connections (as the handshake is done when the connection is established) so there is no need for the key/trust store to be reloaded for existing connections to continue working. However, when an error occurs in writing to the socket a retry is attempted which includes the creation of a new socket and connection. Using a no longer valid cert here will prohibit the connection being re-established. If, during the retry, the key/truststore are reloaded, then the latest certs would always be used in re-establishing the connection and would effectively remove the need to trigger the reconfiguration. Is this something the community would be open accepting a PR on? If so I can work on it and submit -- 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: notifications-unsubscr...@logging.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Prefix stack traces with a newline in Pattern Layout (logging-log4j2)
vy merged PR #3073: URL: https://github.com/apache/logging-log4j2/pull/3073 -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [I] [MS22] Native Compilation Support #2 (logging-log4j2)
grobmeier closed issue #2831: [MS22] Native Compilation Support #2 URL: https://github.com/apache/logging-log4j2/issues/2831 -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [I] [MS22] Native Compilation Support #2 (logging-log4j2)
grobmeier commented on issue #2831: URL: https://github.com/apache/logging-log4j2/issues/2831#issuecomment-2404572665 Thanks you looks good! -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump ch.qos.logback:logback-core from 1.5.8 to 1.5.9 (logging-log4j2)
github-actions[bot] merged PR #3075: URL: https://github.com/apache/logging-log4j2/pull/3075 -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Fix key removal issues in Thread Context (logging-log4j2)
vy commented on code in PR #3050:
URL: https://github.com/apache/logging-log4j2/pull/3050#discussion_r1795242183
##
log4j-api/src/main/java/org/apache/logging/log4j/internal/map/UnmodifiableArrayBackedMap.java:
##
@@ -350,82 +351,59 @@ public UnmodifiableArrayBackedMap copyAndRemove(String
key) {
}
/**
- * Creates a new instance that contains the same entries as this map,
minus all
- * of the keys passed in the arguments.
- *
- * @param key
- * @param value
- * @return
+ * Creates a new instance where the entries of provided keys are removed.
*/
public UnmodifiableArrayBackedMap copyAndRemoveAll(Iterable
keysToRemoveIterable) {
+
+// Short-circuit if the map is empty
if (isEmpty()) {
-// shortcut: if this map is empty, the result will continue to be
empty
return EMPTY_MAP;
}
-// now we build a Set of keys to remove
-Set keysToRemoveSet;
-if (keysToRemoveIterable instanceof Set) {
-// we already have a set, let's cast it and reuse it
-keysToRemoveSet = (Set) keysToRemoveIterable;
-} else {
-// iterate through the keys and build a set
-keysToRemoveSet = new HashSet<>();
-for (String key : keysToRemoveIterable) {
-keysToRemoveSet.add(key);
-}
-}
+// Collect distinct keys to remove
+final Set keysToRemove = keysToRemoveIterable instanceof Set
+? (Set) keysToRemoveIterable
+: StreamSupport.stream(keysToRemoveIterable.spliterator(),
false)
+.collect(Collectors.toSet());
-int firstIndexToKeep = -1;
-int lastIndexToKeep = -1;
-int destinationIndex = 0;
-int numEntriesKept = 0;
-// build the new map
-UnmodifiableArrayBackedMap newMap = new
UnmodifiableArrayBackedMap(numEntries);
-for (int indexInCurrentMap = 0; indexInCurrentMap < numEntries;
indexInCurrentMap++) {
-// for each key in this map, check whether it's in the set we
built above
-Object key = backingArray[getArrayIndexForKey(indexInCurrentMap)];
-if (!keysToRemoveSet.contains(key)) {
-// this key should be kept
-if (firstIndexToKeep == -1) {
-firstIndexToKeep = indexInCurrentMap;
-}
-lastIndexToKeep = indexInCurrentMap;
-} else if (lastIndexToKeep > 0) {
-// we hit a remove, copy any keys that are known ready
-int numEntriesToCopy = lastIndexToKeep - firstIndexToKeep + 1;
-System.arraycopy(
-backingArray,
-getArrayIndexForKey(firstIndexToKeep),
-newMap.backingArray,
-getArrayIndexForKey(destinationIndex),
-numEntriesToCopy * 2);
-firstIndexToKeep = -1;
-lastIndexToKeep = -1;
-destinationIndex += numEntriesToCopy;
-numEntriesKept += numEntriesToCopy;
-}
-}
+// Create the new map
+final UnmodifiableArrayBackedMap oldMap = this;
+final int oldMapEntryCount = oldMap.numEntries;
+final UnmodifiableArrayBackedMap newMap = new
UnmodifiableArrayBackedMap(oldMapEntryCount);
-if (lastIndexToKeep > -1) {
-// at least one key still requires copying
-int numEntriesToCopy = lastIndexToKeep - firstIndexToKeep + 1;
-System.arraycopy(
-backingArray,
-getArrayIndexForKey(firstIndexToKeep),
-newMap.backingArray,
-getArrayIndexForKey(destinationIndex),
-numEntriesToCopy * 2);
-numEntriesKept += numEntriesToCopy;
+// Short-circuit if there is nothing to remove
+if (keysToRemove.isEmpty()) {
+System.arraycopy(oldMap.backingArray, 0, newMap.backingArray, 0,
oldMapEntryCount * 2);
+newMap.numEntries = oldMapEntryCount;
+return this;
}
-if (numEntriesKept == 0) {
-return EMPTY_MAP;
+// Iterate over old map entries
+int newMapEntryIndex = 0;
+for (int oldMapEntryIndex = 0; oldMapEntryIndex < oldMapEntryCount;
oldMapEntryIndex++) {
+final int oldMapKeyIndex = getArrayIndexForKey(oldMapEntryIndex);
Review Comment:
Added a dedicated test for the `copyAndRemoveAll()` in
df5ec8115974970b5625836d9c06a7d72a65b813. The bug was on this line:
https://github.com/apache/logging-log4j2/blob/2d61fe0e6a3b9c8f5d53dda1f5834752a2799138/log4j-api/src/main/java/org/apache/logging/log4j/internal/map/UnmodifiableArrayBackedMap.java#L394
It skips the removal if the slice-to-be-copied is `[0,0]`.
--
This is an autom
Re: [PR] Fix key removal issues in Thread Context (logging-log4j2)
ppkarwasz commented on code in PR #3050:
URL: https://github.com/apache/logging-log4j2/pull/3050#discussion_r1795248638
##
log4j-api/src/main/java/org/apache/logging/log4j/internal/map/UnmodifiableArrayBackedMap.java:
##
@@ -350,82 +351,59 @@ public UnmodifiableArrayBackedMap copyAndRemove(String
key) {
}
/**
- * Creates a new instance that contains the same entries as this map,
minus all
- * of the keys passed in the arguments.
- *
- * @param key
- * @param value
- * @return
+ * Creates a new instance where the entries of provided keys are removed.
*/
public UnmodifiableArrayBackedMap copyAndRemoveAll(Iterable
keysToRemoveIterable) {
+
+// Short-circuit if the map is empty
if (isEmpty()) {
-// shortcut: if this map is empty, the result will continue to be
empty
return EMPTY_MAP;
}
-// now we build a Set of keys to remove
-Set keysToRemoveSet;
-if (keysToRemoveIterable instanceof Set) {
-// we already have a set, let's cast it and reuse it
-keysToRemoveSet = (Set) keysToRemoveIterable;
-} else {
-// iterate through the keys and build a set
-keysToRemoveSet = new HashSet<>();
-for (String key : keysToRemoveIterable) {
-keysToRemoveSet.add(key);
-}
-}
+// Collect distinct keys to remove
+final Set keysToRemove = keysToRemoveIterable instanceof Set
+? (Set) keysToRemoveIterable
+: StreamSupport.stream(keysToRemoveIterable.spliterator(),
false)
+.collect(Collectors.toSet());
-int firstIndexToKeep = -1;
-int lastIndexToKeep = -1;
-int destinationIndex = 0;
-int numEntriesKept = 0;
-// build the new map
-UnmodifiableArrayBackedMap newMap = new
UnmodifiableArrayBackedMap(numEntries);
-for (int indexInCurrentMap = 0; indexInCurrentMap < numEntries;
indexInCurrentMap++) {
-// for each key in this map, check whether it's in the set we
built above
-Object key = backingArray[getArrayIndexForKey(indexInCurrentMap)];
-if (!keysToRemoveSet.contains(key)) {
-// this key should be kept
-if (firstIndexToKeep == -1) {
-firstIndexToKeep = indexInCurrentMap;
-}
-lastIndexToKeep = indexInCurrentMap;
-} else if (lastIndexToKeep > 0) {
-// we hit a remove, copy any keys that are known ready
-int numEntriesToCopy = lastIndexToKeep - firstIndexToKeep + 1;
-System.arraycopy(
-backingArray,
-getArrayIndexForKey(firstIndexToKeep),
-newMap.backingArray,
-getArrayIndexForKey(destinationIndex),
-numEntriesToCopy * 2);
-firstIndexToKeep = -1;
-lastIndexToKeep = -1;
-destinationIndex += numEntriesToCopy;
-numEntriesKept += numEntriesToCopy;
-}
-}
+// Create the new map
+final UnmodifiableArrayBackedMap oldMap = this;
+final int oldMapEntryCount = oldMap.numEntries;
+final UnmodifiableArrayBackedMap newMap = new
UnmodifiableArrayBackedMap(oldMapEntryCount);
-if (lastIndexToKeep > -1) {
-// at least one key still requires copying
-int numEntriesToCopy = lastIndexToKeep - firstIndexToKeep + 1;
-System.arraycopy(
-backingArray,
-getArrayIndexForKey(firstIndexToKeep),
-newMap.backingArray,
-getArrayIndexForKey(destinationIndex),
-numEntriesToCopy * 2);
-numEntriesKept += numEntriesToCopy;
+// Short-circuit if there is nothing to remove
+if (keysToRemove.isEmpty()) {
+System.arraycopy(oldMap.backingArray, 0, newMap.backingArray, 0,
oldMapEntryCount * 2);
+newMap.numEntries = oldMapEntryCount;
+return this;
}
-if (numEntriesKept == 0) {
-return EMPTY_MAP;
+// Iterate over old map entries
+int newMapEntryIndex = 0;
+for (int oldMapEntryIndex = 0; oldMapEntryIndex < oldMapEntryCount;
oldMapEntryIndex++) {
+final int oldMapKeyIndex = getArrayIndexForKey(oldMapEntryIndex);
Review Comment:
Great job, thanks!
--
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: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] Fix key removal issues in Thread Context (logging-log4j2)
ppkarwasz commented on code in PR #3050:
URL: https://github.com/apache/logging-log4j2/pull/3050#discussion_r1795248098
##
log4j-api-test/src/test/java/org/apache/logging/log4j/CloseableThreadContextTest.java:
##
@@ -244,4 +246,71 @@ public void pushAllWillPushAllValues() {
}
assertEquals("", ThreadContext.peek());
}
+
+/**
+ * User provided test stressing nesting using {@link
CloseableThreadContext#put(String, String)}.
+ *
+ * @see https://github.com/apache/logging-log4j2/issues/2946#issuecomment-2382935426";>#2946
+ */
+@Test
+public void testAutoCloseableThreadContextPut() {
+try (final CloseableThreadContext.Instance ctc1 =
CloseableThreadContext.put("outer", "one")) {
+try (final CloseableThreadContext.Instance ctc2 =
CloseableThreadContext.put("outer", "two")) {
+assertEquals("two", ThreadContext.get("outer"));
+
+try (final CloseableThreadContext.Instance ctc3 =
CloseableThreadContext.put("inner", "one")) {
+assertEquals("one", ThreadContext.get("inner"));
+
+ThreadContext.put(
+"not-in-closeable", "true"); // Remove this line,
and closing context behaves as expected
+assertEquals("two", ThreadContext.get("outer"));
+}
+
+assertEquals("two", ThreadContext.get("outer"));
+assertNull(ThreadContext.get("inner")); // Test fails here
+}
+
+assertEquals("one", ThreadContext.get("outer"));
+assertNull(ThreadContext.get("inner"));
+}
+assertEquals("true", ThreadContext.get("not-in-closeable"));
+
+assertNull(ThreadContext.get("inner"));
+assertNull(ThreadContext.get("outer"));
+}
+
+/**
+ * User provided test stressing nesting using {@link
CloseableThreadContext#putAll(Map)}.
+ *
+ * @see https://github.com/apache/logging-log4j2/issues/2946#issuecomment-2382935426";>#2946
+ */
+@Test
+public void testAutoCloseableThreadContextPutAll() {
+try (final CloseableThreadContext.Instance ctc1 =
CloseableThreadContext.put("outer", "one")) {
+try (final CloseableThreadContext.Instance ctc2 =
CloseableThreadContext.put("outer", "two")) {
+assertEquals("two", ThreadContext.get("outer"));
+
+try (final CloseableThreadContext.Instance ctc3 =
CloseableThreadContext.put("inner", "one")) {
+assertEquals("one", ThreadContext.get("inner"));
+
+ThreadContext.put(
+"not-in-closeable", "true"); // Remove this line,
and closing context behaves as expected
+ThreadContext.putAll(Collections.singletonMap("inner",
"two")); // But this is not a problem
+System.err.println(ThreadContext.getContext());
Review Comment:
This discussion is a little bit transversal to this PR, which only fixes a
bug in `removeAll()`.
Let us continue it in #2946.
--
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: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[I] Configuration type doesn't have MarkerFilter element (logging-log4j2)
IMurzich opened a new issue, #3077:
URL: https://github.com/apache/logging-log4j2/issues/3077
## Description
log4j.xml from
https://github.com/apache/logging-log4j2/blob/2.x/src/site/antora/modules/ROOT/examples/manual/markers/log4j2.xml
doesn't validate:
Multiple annotations found at this line:
- Element name 'MarkerFilter' is invalid.
One of the following is expected:
- CustomLevels
- Loggers
Error indicated by:
{https://logging.apache.org/xml/ns}
with code:
- cvc-complex-type.2.4.a: Invalid content was found starting
with element
'{"https://logging.apache.org/xml/ns":MarkerFilter}'. One
of '{"https://
logging.apache.org/xml/ns":CustomLevels,
"https://logging.apache.org/xml/
ns":Loggers}' is expected.
## Configuration
**Version:** Used xsd - https://logging.apache.org/xml/ns/log4j-config-2.xsd
## Reproduction
validate
https://github.com/apache/logging-log4j2/blob/2.x/src/site/antora/modules/ROOT/examples/manual/markers/log4j2.xml
--
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: notifications-unsubscr...@logging.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] Bump actions/upload-artifact from 4.4.1 to 4.4.2 [logging-parent]
vy commented on code in PR #264: URL: https://github.com/apache/logging-parent/pull/264#discussion_r1795248026 ## .github/workflows/scorecards-analysis-reusable.yaml: ## @@ -47,7 +47,7 @@ jobs: publish_results: true - name: "Upload artifact" -uses: actions/upload-artifact@604373da6381bf24206979c74d06a550515601b9 # 3.1.0 +uses: actions/upload-artifact@84480863f228bb9747b473957fcc9e309aa96097 # 3.1.0 Review Comment: ```suggestion uses: actions/upload-artifact@84480863f228bb9747b473957fcc9e309aa96097# 4.4.2 ``` -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump actions/upload-artifact from 4.4.1 to 4.4.2 [logging-parent]
vy merged PR #264: URL: https://github.com/apache/logging-parent/pull/264 -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [I] Configuration type doesn't have MarkerFilter element [logging-log4j-tools]
ppkarwasz commented on issue #152: URL: https://github.com/apache/logging-log4j-tools/issues/152#issuecomment-2405713770 @IMurzich, Thank You for the report. I moved it to `logging-log4j-tools`, since the problem is caused by our `log4j-docgen` generator. The meta-definition of the `` element does not contain filters: https://github.com/apache/logging-log4j-tools/blob/d795a97683ce3042005a8d512ae7494bdb669f26/log4j-docgen/src/main/resources/org/apache/logging/log4j/docgen/generator/base-log4j-types.xml#L118-L136 -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Change BOM activation and stop managing dependencies [logging-parent]
vy commented on code in PR #265: URL: https://github.com/apache/logging-parent/pull/265#discussion_r1795881367 ## pom.xml: ## @@ -1018,6 +944,83 @@ + + + + bom + + + + + .logging-parent-bom-activator + + + + + + + +org.codehaus.mojo +flatten-maven-plugin + + + + +flatten-revision + + + + +flatten-bom + + flatten + +process-resources + + bom + + +remove +interpolate +remove +remove +remove +remove + +keep Review Comment: @ppkarwasz, ah, now I see! You're right! Removed `keep` in 0885ebe23096ea09e7423b3e1fc95c9a3870a505. -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Change BOM activation and stop managing dependencies [logging-parent]
vy commented on PR #265: URL: https://github.com/apache/logging-parent/pull/265#issuecomment-2405734305 > That makes me wonder if we can omit `` and use the defaults. @ppkarwasz, I prefer not to – it keeps `properties`, `profiles`, etc. all redundant (and potentially dangerous) stuff there. -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Change BOM activation and stop managing dependencies [logging-parent]
vy merged PR #265: URL: https://github.com/apache/logging-parent/pull/265 -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [I] `log4j-bom` leaks non-Log4j dependencies (logging-log4j2)
vy closed issue #3066: `log4j-bom` leaks non-Log4j dependencies URL: https://github.com/apache/logging-log4j2/issues/3066 -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Change BOM activation and stop managing dependencies [logging-parent]
ppkarwasz commented on code in PR #265: URL: https://github.com/apache/logging-parent/pull/265#discussion_r1795863187 ## pom.xml: ## @@ -1018,6 +944,83 @@ + + + + bom + + + + + .logging-parent-bom-activator + + + + + + + +org.codehaus.mojo +flatten-maven-plugin + + + + +flatten-revision + + + + +flatten-bom + + flatten + +process-resources + + bom + + +remove +interpolate +remove +remove +remove +remove + +keep Review Comment: Maven plugins in this case are just simple JARs. The problem with `log4j-changelog-maven-plugin` (see [POM file](https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-changelog-maven-plugin/0.5.0/log4j-changelog-maven-plugin-0.5.0.pom)) was that: * it depended on `log4j-changelog` ([POM file](https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-changelog/0.5.0/log4j-changelog-0.5.0.pom)). * `log4j-changelog` depended on `org.osgi:osgi.annotation` (unknown version). * the version of `org.osgi:osgi.annotation` was defined in `logging-parent`, but the path to the parent was broken. -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [I] RollingFileAppender rotates files incorrectly on ext4 due to filesystem timestamp caching (logging-log4j2)
kelunik commented on issue #3068: URL: https://github.com/apache/logging-log4j2/issues/3068#issuecomment-2404403858 @rgoers Do you remember why you changed from modified time to creation time in https://github.com/apache/logging-log4j2/commit/e392c79274ab5cd545d59d7e8fa3b744c7367d16? Calling `file.lastModified()` in `initialFileTime` if the file doesn't exist doesn't seem to make sense. My fix proposal would be to revert this back to `lastModified()` and keep the `> 0` check and maybe (?) add a check that it's `<= System.currentTimeMillis()`. -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [I] Upgrade JUnit to 5.11.0 (logging-log4j2)
ppkarwasz closed issue #2843: Upgrade JUnit to 5.11.0 URL: https://github.com/apache/logging-log4j2/issues/2843 -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [I] Upgrade JUnit to 5.11.0 (logging-log4j2)
ppkarwasz closed issue #2843: Upgrade JUnit to 5.11.0 URL: https://github.com/apache/logging-log4j2/issues/2843 -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Upgrades JUnit to version `5.11.2` (logging-log4j2)
ppkarwasz merged PR #3069: URL: https://github.com/apache/logging-log4j2/pull/3069 -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Refactor parts of `log4j-core-test` to migrate to JUnit5 (logging-log4j2)
ninetteadhikari commented on PR #3061: URL: https://github.com/apache/logging-log4j2/pull/3061#issuecomment-2404427110 > > Please note the log4j-core-test module contains over 150 files and this PR updates the tests for 40 of them. Further PRs will be made to update the rest of the tests. > > @ninetteadhikari, @hulkoba, thanks so much! 😍 Would it be possible to keep all JUnit 4-to-5 migration changes in this PR for `log4j-core-test` instead of creating more follow-up PRs? sure thing:) let me then convert this PR to draft and open it for review later once we have migrated all the files. -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Change BOM activation and stop managing dependencies [logging-parent]
vy opened a new pull request, #265: URL: https://github.com/apache/logging-parent/pull/265 This PR implements following changes * Activate `flatten-bom` execution of `flatten-maven-plugin` using a `.logging-parent-bom-activator` file * Remove following managed dependencies to avoid polluting BOMs: * `biz.aQute.bnd:biz.aQute.bnd.annotation` * `com.github.spotbugs:spotbugs-annotations` * `org.jspecify:jspecify` * `org.osgi:osgi.annotation` * `org.osgi:org.osgi.annotation.bundle` * `org.osgi:org.osgi.annotation.versioning` Removed managed dependencies fixes apache/logging-log4j2#3066. -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Fix Android-related issues in Log4j Core (logging-log4j2)
ppkarwasz commented on PR #3071: URL: https://github.com/apache/logging-log4j2/pull/3071#issuecomment-2405372546 The [CI build 11273365001](https://github.com/apache/logging-log4j2/actions/runs/11273365001) confirms that a simple application on Android functions correctly with Log4j Core. -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Enable automatic Android tests [logging-log4j-samples]
ppkarwasz merged PR #198: URL: https://github.com/apache/logging-log4j-samples/pull/198 -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Change BOM activation and stop managing dependencies [logging-parent]
ppkarwasz commented on code in PR #265: URL: https://github.com/apache/logging-parent/pull/265#discussion_r1795804436 ## pom.xml: ## @@ -1018,6 +944,83 @@ + + + + bom + + + + + .logging-parent-bom-activator + + + + + + + +org.codehaus.mojo +flatten-maven-plugin + + + + +flatten-revision + + + + +flatten-bom + + flatten + +process-resources + + bom + + +remove +interpolate +remove +remove +remove +remove + +keep Review Comment: Do we need this? Our troubles were caused exactly by https://github.com/apache/logging-log4j2/issues/3066, which is fixed by this PR. -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[I] Configuration type doesn't have MarkerFilter element [logging-log4j-tools]
IMurzich opened a new issue, #152:
URL: https://github.com/apache/logging-log4j-tools/issues/152
## Description
log4j.xml from
https://github.com/apache/logging-log4j2/blob/2.x/src/site/antora/modules/ROOT/examples/manual/markers/log4j2.xml
doesn't validate:
Multiple annotations found at this line:
- Element name 'MarkerFilter' is invalid.
One of the following is expected:
- CustomLevels
- Loggers
Error indicated by:
{https://logging.apache.org/xml/ns}
with code:
- cvc-complex-type.2.4.a: Invalid content was found starting
with element
'{"https://logging.apache.org/xml/ns":MarkerFilter}'. One
of '{"https://
logging.apache.org/xml/ns":CustomLevels,
"https://logging.apache.org/xml/
ns":Loggers}' is expected.
## Configuration
**Version:** Used xsd - https://logging.apache.org/xml/ns/log4j-config-2.xsd
## Reproduction
validate
https://github.com/apache/logging-log4j2/blob/2.x/src/site/antora/modules/ROOT/examples/manual/markers/log4j2.xml
--
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: notifications-unsubscr...@logging.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] Change BOM activation and stop managing dependencies [logging-parent]
vy commented on code in PR #265: URL: https://github.com/apache/logging-parent/pull/265#discussion_r1795820838 ## pom.xml: ## @@ -1018,6 +944,83 @@ + + + + bom + + + + + .logging-parent-bom-activator + + + + + + + +org.codehaus.mojo +flatten-maven-plugin + + + + +flatten-revision + + + + +flatten-bom + + flatten + +process-resources + + bom + + +remove +interpolate +remove +remove +remove +remove + +keep Review Comment: @ppkarwasz, yes, `keep` is needed for Maven plugins. See the use case cited above this line. Do you have another idea? -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Add manual integration test workflow [logging-log4j-samples]
ppkarwasz opened a new pull request, #199: URL: https://github.com/apache/logging-log4j-samples/pull/199 Add an `integration-test.yaml` workflow that starts all the available tests for a given Log4j version. This workflow can be started manually, after we close a Staging Maven Repository during the release process. -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Enable automatic Android tests [logging-log4j-samples]
vy commented on code in PR #198:
URL:
https://github.com/apache/logging-log4j-samples/pull/198#discussion_r1794882604
##
log4j-samples-android/gradlew:
##
@@ -17,67 +17,101 @@
#
##
-##
-## Gradle start up script for UN*X
-##
+#
+# Gradle start up script for POSIX generated by Gradle.
+#
+# Important for running:
+#
+# (1) You need a POSIX-compliant shell to run this script. If your /bin/sh is
+# noncompliant, but you have some other compliant shell such as ksh or
+# bash, then to run this script, type that shell name before the whole
+# command line, like:
+#
+# ksh Gradle
+#
+# Busybox and similar reduced shells will NOT work, because this script
+# requires all of these POSIX shell features:
+# * functions;
+# * expansions «$var», «${var}», «${var:-default}», «${var+SET}»,
+# «${var#prefix}», «${var%suffix}», and «$( cmd )»;
+# * compound commands having a testable exit status, especially «case»;
+# * various built-in commands including «command», «set», and «ulimit».
+#
+# Important for patching:
+#
+# (2) This script targets any POSIX shell, so it avoids extensions provided
+# by Bash, Ksh, etc; in particular arrays are avoided.
+#
+# The "traditional" practice of packing multiple parameters into a
+# space-separated string is a well documented source of bugs and security
+# problems, so this is (mostly) avoided, by progressively accumulating
+# options in "$@", and eventually passing that to Java.
+#
+# Where the inherited environment variables (DEFAULT_JVM_OPTS, JAVA_OPTS,
+# and GRADLE_OPTS) rely on word-splitting, this is performed explicitly;
+# see the in-line comments for details.
+#
+# There are tweaks for specific operating systems such as AIX, CygWin,
+# Darwin, MinGW, and NonStop.
+#
+# (3) This script is generated from the Groovy template
+#
https://github.com/gradle/gradle/blob/master/subprojects/plugins/src/main/resources/org/gradle/api/internal/plugins/unixStartScript.txt
+# within the Gradle project.
+#
+# You can find Gradle at https://github.com/gradle/gradle/.
+#
##
# Attempt to set APP_HOME
+
# Resolve links: $0 may be a link
-PRG="$0"
-# Need this for relative symlinks.
-while [ -h "$PRG" ] ; do
-ls=`ls -ld "$PRG"`
-link=`expr "$ls" : '.*-> \(.*\)$'`
-if expr "$link" : '/.*' > /dev/null; then
-PRG="$link"
-else
-PRG=`dirname "$PRG"`"/$link"
-fi
+app_path=$0
+
+# Need this for daisy-chained symlinks.
+while
+APP_HOME=${app_path%"${app_path##*/}"} # leaves a trailing /; empty if no
leading path
+[ -h "$app_path" ]
+do
+ls=$( ls -ld "$app_path" )
+link=${ls#*' -> '}
+case $link in #(
+ /*) app_path=$link ;; #(
+ *)app_path=$APP_HOME$link ;;
+esac
done
-SAVED="`pwd`"
-cd "`dirname \"$PRG\"`/" >/dev/null
-APP_HOME="`pwd -P`"
-cd "$SAVED" >/dev/null
+
+APP_HOME=$( cd "${APP_HOME:-./}" && pwd -P ) || exit
APP_NAME="Gradle"
-APP_BASE_NAME=`basename "$0"`
+APP_BASE_NAME=${0##*/}
# Add default JVM options here. You can also use JAVA_OPTS and GRADLE_OPTS to
pass JVM options to this script.
DEFAULT_JVM_OPTS='"-Xmx64m" "-Xms64m"'
# Use the maximum available, or set MAX_FD != -1 to use that value.
-MAX_FD="maximum"
+MAX_FD=maximum
warn () {
echo "$*"
-}
+} >&2
die () {
echo
echo "$*"
echo
exit 1
-}
+} >&2
# OS specific support (must be 'true' or 'false').
cygwin=false
msys=false
darwin=false
nonstop=false
-case "`uname`" in
- CYGWIN* )
-cygwin=true
-;;
- Darwin* )
-darwin=true
-;;
- MINGW* )
-msys=true
-;;
- NONSTOP* )
-nonstop=true
-;;
+case "$( uname )" in#(
Review Comment:
Oh, I thought you added them.
I see that [the `gradlew` has it actually](
https://github.com/gradle/gradle/blob/2b5e5f3275ee87c293a9c8490b58167b7e34c208/gradlew#L111).
--
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: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] Upgrades JUnit to version `5.11.2` (logging-log4j2)
ppkarwasz commented on code in PR #3069:
URL: https://github.com/apache/logging-log4j2/pull/3069#discussion_r1794892058
##
log4j-core-test/src/main/java/org/apache/logging/log4j/core/test/junit/package-info.java:
##
@@ -20,7 +20,7 @@
* @see org.junit.rules.TestRule
*/
@Export
-@Version("2.23.0")
+@Version("2.23.1")
Review Comment:
For `MINOR` changes yes.
What I would like to convey with the `@Version` annotation is:
- the stability of the API in each package,
- in which minor version was the API last modified (a sort of `max(@since)`).
In this case this package was last modified in `2.23.0`, since then users
didn't get any additional functionality, only bug fixes. If they compile their
code against `2.23.0`, they will get the same result as using the latest
release.
--
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: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[PR] Adds `maven-args` option to workflows [logging-parent]
ppkarwasz opened a new pull request, #266: URL: https://github.com/apache/logging-parent/pull/266 We add `maven-args` option to the: * `build-reusable.yaml` workflow. * `merge-dependabot-reusable.yaml` workflow. This parameter sets the [`MAVEN_ARGS`](https://maven.apache.org/configure.html#maven_args-environment-variable) environment variable that can be used to pass additional options (e.g. `-Prelease`, `-Dslf4j.version=...`) to the Maven runs. Note that we don't add an equivalent option for [`MAVEN_OPTS`](https://maven.apache.org/configure.html#maven_opts-environment-variable), since the JVM parameters for Maven can be stored in a `.mvn/jvm.config` file. -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Adds `maven-args` option to workflows [logging-parent]
ppkarwasz commented on PR #266: URL: https://github.com/apache/logging-parent/pull/266#issuecomment-2406063935 These changes were successfully used in [CI run 11281357268](https://github.com/apache/logging-log4j-samples/actions/runs/11281357268) to run the integration tests against `2.24.0` (JLink and other failures expected). -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
