[GitHub] [logging-log4j2] ppkarwasz commented on pull request #804: [LOG4J2-3427] Replace ServiceLoader calls with ServiceLoaderUtil
ppkarwasz commented on PR #804: URL: https://github.com/apache/logging-log4j2/pull/804#issuecomment-1091092434 @jvz, I added an `OsgiServiceLocator` to retrieve the services that are registered as OSGI services. This also works for services declared through _Declarative Services_ in other bundles, although adding DS in Log4j should not be necessary: we register the services 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (LOG4J2-3469) Create new builder from existing Appender
[
https://issues.apache.org/jira/browse/LOG4J2-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518487#comment-17518487
]
Jody Garnett edited comment on LOG4J2-3469 at 4/7/22 12:28 AM:
---
Updated example based on very helpful comments on LOG4J2-2590.
For now supplementing my XMLConfiguration subclass with:
{code:java}
public static > B
newBuilder(RollingFileAppender rollingFileAppender){
return RollingFileAppender.newBuilder()
.setName(rollingFileAppender.getName())
.withFileName(rollingFileAppender.getFileName())
.withFilePattern(rollingFileAppender.getFilePattern())
.setLayout(rollingFileAppender.getLayout())
.withPolicy(rollingFileAppender.getTriggeringPolicy());
} {code}
was (Author: jodygarnett):
Updated example based on very helpful comments on LOG4J2-2590.
> Create new builder from existing Appender
> -
>
> Key: LOG4J2-3469
> URL: https://issues.apache.org/jira/browse/LOG4J2-3469
> Project: Log4j 2
> Issue Type: New Feature
> Components: Configuration, Configurators, Core
>Affects Versions: 2.17.2
>Reporter: Jody Garnett
>Priority: Minor
> Attachments: DEFAULT_LOGGING.xml
>
>
>
> The documentation covers both [Initialize Log4j by Combining Configuration
> File with Programmatic
> Configuration|https://logging.apache.org/log4j/2.x/manual/customconfig.html#Hybrid]
> and [Programmatically Modifying the Current Configuration after
> Initialization|https://logging.apache.org/log4j/2.x/manual/customconfig.html#Programmatically_Modifying_the_Current_Configuration_after_Initialization].
>
> However both these techniques are limited as to what they can accomplish:
> * MyXMLConfiguration.doConfigure() is shown adding an appender, via
> addLogger method
> * A custom configuration super.setup() method is shown using
> config.addLogger() and then ctx.updateLoggers().
> My challenge is to programatically update the configuration to:
> * Override logfile output location, either directly modifying appender, or
> modifying config property used by appender.
> * Optionally Filter out any RollingFileAppender or FileAppender appenders
> * Optionally suppress (filter out) any Console loggers if asked
> I am seeking an api used to pre-process configuration objects if one is
> available.
> In the past when using a fluent / builder API there is an option to
> jump-start a builder with the configuration of an existing object. This
> approach would allow a builder to be loaded with an existing appender;
> revised, and a new appender generated as a replacement.
> {code:java}
> @Override protected void doConfigure() {
> super.doConfigure();
> getProperties().put("GEOSERVER_LOG_LOCATION","geoserver.log");
> Appender appender = getAppenders("geoserverlogfile");
> if( appender instanceof RollingFileAppender){
> RollingFileAppender fileAppender =(RollingFileAppender) appender;
> RollingFileAppender replacement =
> RollingFileAppender.newBuilder(fileAppender)
> .withFileName("${GEOSERVER_LOG_LOCATION}.log")
> .withFilePattern("${GEOSERVER_LOG_LOCATION}-%i.log")
> .build();
>
> getAppenders().remove("geoserverlogfile");
> addAppender(replacement);
> }
> }{code}
> The alternative is verbose and may miss copying new parameters added over
> time.
> Alternatives considered:
> *MyXMLConfiguration.setup()* prior to super.setup(): Unclear how easy/safe it
> is to to modify _rootNode_ structure directly? Is this what is intended by
> the documentation.
> {code:java}
> public void setup() {
> for( Node child : rootNode.getChildren()){
> if ("Properties".equals(child.getName())){
> for( Node property : child.getChildren() ){
> if( property.getAttributes().containsKey("name") &&
>
> property.getAttributes().get("name").equals("GEOSERVER_LOG_LOCATION")) {
> // override value with current GEOSERVER_LOG_LOCATION
> property.setValue("foo.log");
> }
> }
> }
> }
> super.setup();
> }{code}
> *MyXMLConfiguration.doConfigure()* before super.doConfigure(): should be able
> to modify _rootNode_ and make any changes required. Unclear how easy/safe it
> is to to modify node structure directly?
> *MyXMLConfiguration.doConfigure()* after super.doConfigure(): is too late as
> shown above.
> - Can add loggers and appenders
> - Modifications to config.getProperties() are not reflected in appender
> configuration
> - Modifications to existing appenders cannot be accomplished
> {*}MyXMLConfiguration.{*}{*}preConfigure(Node){*} allows xml to be rewritten
> just-in-time:
>
[jira] [Updated] (LOG4J2-3469) Create new builder from existing Appender
[
https://issues.apache.org/jira/browse/LOG4J2-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jody Garnett updated LOG4J2-3469:
-
Summary: Create new builder from existing Appender (was: Create new
AppenderComponentBuilder from existing Appender)
> Create new builder from existing Appender
> -
>
> Key: LOG4J2-3469
> URL: https://issues.apache.org/jira/browse/LOG4J2-3469
> Project: Log4j 2
> Issue Type: New Feature
> Components: Configuration, Configurators, Core
>Affects Versions: 2.17.2
>Reporter: Jody Garnett
>Priority: Minor
> Attachments: DEFAULT_LOGGING.xml
>
>
>
> The documentation covers both [Initialize Log4j by Combining Configuration
> File with Programmatic
> Configuration|https://logging.apache.org/log4j/2.x/manual/customconfig.html#Hybrid]
> and [Programmatically Modifying the Current Configuration after
> Initialization|https://logging.apache.org/log4j/2.x/manual/customconfig.html#Programmatically_Modifying_the_Current_Configuration_after_Initialization].
>
> However both these techniques are limited as to what they can accomplish:
> * MyXMLConfiguration.doConfigure() is shown adding an appender, via
> addLogger method
> * A custom configuration super.setup() method is shown using
> config.addLogger() and then ctx.updateLoggers().
> My challenge is to programatically update the configuration to:
> * Override logfile output location, either directly modifying appender, or
> modifying config property used by appender.
> * Optionally Filter out any RollingFileAppender or FileAppender appenders
> * Optionally suppress (filter out) any Console loggers if asked
> I am seeking an api used to pre-process configuration objects if one is
> available.
> In the past when using a fluent / builder API there is an option to
> jump-start a builder with the configuration of an existing object. This
> approach would allow a builder to be loaded with an existing appender;
> revised, and a new appender generated as a replacement.
> {code:java}
> @Override protected void doConfigure() {
> super.doConfigure();
> getProperties().put("GEOSERVER_LOG_LOCATION","geoserver.log");
> Appender appender = getAppenders("geoserverlogfile");
> if( appender instanceof RollingFileAppender){
> RollingFileAppender fileAppender =(RollingFileAppender) appender;
> RollingFileAppender replacement =
> RollingFileAppender.newBuilder(fileAppender)
> .withFileName("${GEOSERVER_LOG_LOCATION}.log")
> .withFilePattern("${GEOSERVER_LOG_LOCATION}-%i.log")
> .build();
>
> getAppenders().remove("geoserverlogfile");
> addAppender(replacement);
> }
> }{code}
> The alternative is verbose and may miss copying new parameters added over
> time.
> Alternatives considered:
> *MyXMLConfiguration.setup()* prior to super.setup(): Unclear how easy/safe it
> is to to modify _rootNode_ structure directly? Is this what is intended by
> the documentation.
> {code:java}
> public void setup() {
> for( Node child : rootNode.getChildren()){
> if ("Properties".equals(child.getName())){
> for( Node property : child.getChildren() ){
> if( property.getAttributes().containsKey("name") &&
>
> property.getAttributes().get("name").equals("GEOSERVER_LOG_LOCATION")) {
> // override value with current GEOSERVER_LOG_LOCATION
> property.setValue("foo.log");
> }
> }
> }
> }
> super.setup();
> }{code}
> *MyXMLConfiguration.doConfigure()* before super.doConfigure(): should be able
> to modify _rootNode_ and make any changes required. Unclear how easy/safe it
> is to to modify node structure directly?
> *MyXMLConfiguration.doConfigure()* after super.doConfigure(): is too late as
> shown above.
> - Can add loggers and appenders
> - Modifications to config.getProperties() are not reflected in appender
> configuration
> - Modifications to existing appenders cannot be accomplished
> {*}MyXMLConfiguration.{*}{*}preConfigure(Node){*} allows xml to be rewritten
> just-in-time:
> {code:java}
> @Overrideprotected void preConfigure(Node node) {
> if( !node.isRoot() && node.getName().equals("Property")){
> if( node.getAttributes().containsKey("name") &&
>
> node.getAttributes().get("name").equals("GEOSERVER_LOG_LOCATION")) {
> // override value with current GEOSERVER_LOG_LOCATION
> node.setValue("foo.log");
> }
> }
> super.preConfigure(node);
> } {code}
> For reference see attached {*}DEFAULT_LOGGING.xml{*}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3469) Create new AppenderComponentBuilder from existing Appender
[
https://issues.apache.org/jira/browse/LOG4J2-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jody Garnett updated LOG4J2-3469:
-
Description:
The documentation covers both [Initialize Log4j by Combining Configuration File
with Programmatic
Configuration|https://logging.apache.org/log4j/2.x/manual/customconfig.html#Hybrid]
and [Programmatically Modifying the Current Configuration after
Initialization|https://logging.apache.org/log4j/2.x/manual/customconfig.html#Programmatically_Modifying_the_Current_Configuration_after_Initialization].
However both these techniques are limited as to what they can accomplish:
* MyXMLConfiguration.doConfigure() is shown adding an appender, via addLogger
method
* A custom configuration super.setup() method is shown using
config.addLogger() and then ctx.updateLoggers().
My challenge is to programatically update the configuration to:
* Override logfile output location, either directly modifying appender, or
modifying config property used by appender.
* Optionally Filter out any RollingFileAppender or FileAppender appenders
* Optionally suppress (filter out) any Console loggers if asked
I am seeking an api used to pre-process configuration objects if one is
available.
In the past when using a fluent / builder API there is an option to jump-start
a builder with the configuration of an existing object. This approach would
allow a builder to be loaded with an existing appender; revised, and a new
appender generated as a replacement.
{code:java}
@Override protected void doConfigure() {
super.doConfigure();
getProperties().put("GEOSERVER_LOG_LOCATION","geoserver.log");
Appender appender = getAppenders("geoserverlogfile");
if( appender instanceof RollingFileAppender){
RollingFileAppender fileAppender =(RollingFileAppender) appender;
RollingFileAppender replacement =
RollingFileAppender.newBuilder(fileAppender)
.withFileName("${GEOSERVER_LOG_LOCATION}.log")
.withFilePattern("${GEOSERVER_LOG_LOCATION}-%i.log")
.build();
getAppenders().remove("geoserverlogfile");
addAppender(replacement);
}
}{code}
The alternative is verbose and may miss copying new parameters added over time.
Alternatives considered:
*MyXMLConfiguration.setup()* prior to super.setup(): Unclear how easy/safe it
is to to modify _rootNode_ structure directly? Is this what is intended by the
documentation.
{code:java}
public void setup() {
for( Node child : rootNode.getChildren()){
if ("Properties".equals(child.getName())){
for( Node property : child.getChildren() ){
if( property.getAttributes().containsKey("name") &&
property.getAttributes().get("name").equals("GEOSERVER_LOG_LOCATION")) {
// override value with current GEOSERVER_LOG_LOCATION
property.setValue("foo.log");
}
}
}
}
super.setup();
}{code}
*MyXMLConfiguration.doConfigure()* before super.doConfigure(): should be able
to modify _rootNode_ and make any changes required. Unclear how easy/safe it is
to to modify node structure directly?
*MyXMLConfiguration.doConfigure()* after super.doConfigure(): is too late as
shown above.
- Can add loggers and appenders
- Modifications to config.getProperties() are not reflected in appender
configuration
- Modifications to existing appenders cannot be accomplished
{*}MyXMLConfiguration.{*}{*}preConfigure(Node){*} allows xml to be rewritten
just-in-time:
{code:java}
@Overrideprotected void preConfigure(Node node) {
if( !node.isRoot() && node.getName().equals("Property")){
if( node.getAttributes().containsKey("name") &&
node.getAttributes().get("name").equals("GEOSERVER_LOG_LOCATION")) {
// override value with current GEOSERVER_LOG_LOCATION
node.setValue("foo.log");
}
}
super.preConfigure(node);
} {code}
For reference see attached {*}DEFAULT_LOGGING.xml{*}.
was:
The documentation covers both [Initialize Log4j by Combining Configuration File
with Programmatic
Configuration|https://logging.apache.org/log4j/2.x/manual/customconfig.html#Hybrid]
and [Programmatically Modifying the Current Configuration after
Initialization|https://logging.apache.org/log4j/2.x/manual/customconfig.html#Programmatically_Modifying_the_Current_Configuration_after_Initialization].
However both these techniques are limited as to what they can accomplish:
* MyXMLConfiguration.doConfigure() is shown adding an appender, via addLogger
method
* A custom configuration super.setup() method is shown using
config.addLogger() and then ctx.updateLoggers().
My challenge is to programatically update the configuration to:
* Override logfile output location, either directly modifying appender, or
modifying config property
[jira] [Commented] (LOG4J2-3469) Create new AppenderComponentBuilder from existing Appender
[
https://issues.apache.org/jira/browse/LOG4J2-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518487#comment-17518487
]
Jody Garnett commented on LOG4J2-3469:
--
Updated example based on very helpful comments on LOG4J2-2590.
> Create new AppenderComponentBuilder from existing Appender
> --
>
> Key: LOG4J2-3469
> URL: https://issues.apache.org/jira/browse/LOG4J2-3469
> Project: Log4j 2
> Issue Type: New Feature
> Components: Configuration, Configurators, Core
>Affects Versions: 2.17.2
>Reporter: Jody Garnett
>Priority: Minor
> Attachments: DEFAULT_LOGGING.xml
>
>
>
> The documentation covers both [Initialize Log4j by Combining Configuration
> File with Programmatic
> Configuration|https://logging.apache.org/log4j/2.x/manual/customconfig.html#Hybrid]
> and [Programmatically Modifying the Current Configuration after
> Initialization|https://logging.apache.org/log4j/2.x/manual/customconfig.html#Programmatically_Modifying_the_Current_Configuration_after_Initialization].
>
> However both these techniques are limited as to what they can accomplish:
> * MyXMLConfiguration.doConfigure() is shown adding an appender, via
> addLogger method
> * A custom configuration super.setup() method is shown using
> config.addLogger() and then ctx.updateLoggers().
> My challenge is to programatically update the configuration to:
> * Override logfile output location, either directly modifying appender, or
> modifying config property used by appender.
> * Optionally Filter out any RollingFileAppender or FileAppender appenders
> * Optionally suppress (filter out) any Console loggers if asked
> I am seeking an api used to pre-process configuration objects if one is
> available.
> In the past when using a fluent / builder API there is an option to
> jump-start a builder with the configuration of an existing object. This
> approach would allow a builder to be loaded with an existing appender;
> revised, and a new appender generated as a replacement.
> {code:java}
> @Override protected void doConfigure() {
> super.doConfigure();
> final LoggerContext context = (LoggerContext)
> LogManager.getContext(false);
> final Configuration config = context.getConfiguration();
> config.getProperties().put("GEOSERVER_LOG_LOCATION","geoserver.log");
> ConfigurationBuilder builder =
>ConfigurationBuilderFactory.newConfigurationBuilder();
> Appender appender = config.getAppenders("geoserverlogfile");
> if( appender instanceof RollingFileAppender){
> RollingFileAppender fileAppender =(RollingFileAppender) appender;
>
> AppenderComponentBuilder appenderBuilder = builder.
> newAppender("geoserverlogfile", fileAppender)
> .addAttribute("fileName", "${GEOSERVER_LOG_LOCATION}.log");
>
> config.getAppenders().remove("geoserverlogfile");
> addAppender((Appender) appenderBuilder.build());
> }
> }{code}
> The alternative is verbose and may miss copying new parameters added over
> time.
> Alternatives considered
> *MyXMLConfiguration.setup()* prior to super.setup(): Unclear how easy/safe it
> is to to modify _rootNode_ structure directly? Is this what is intended by
> the documentation.
> {code:java}
> public void setup() {
> for( Node child : rootNode.getChildren()){
> if ("Properties".equals(child.getName())){
> for( Node property : child.getChildren() ){
> if( property.getAttributes().containsKey("name") &&
>
> property.getAttributes().get("name").equals("GEOSERVER_LOG_LOCATION")) {
> // override value with current GEOSERVER_LOG_LOCATION
> property.setValue("foo.log");
> }
> }
> }
> }
> super.setup();
> }{code}
> *MyXMLConfiguration.doConfigure()* before super.doConfigure(): should be able
> to modify _rootNode_ and make any changes required. Unclear how easy/safe it
> is to to modify node structure directly?
> *MyXMLConfiguration.doConfigure()* after super.doConfigure(): is too late as
> shown above.
> - Can add loggers and appenders
> - Modifications to config.getProperties() are not reflected in appender
> configuration
> - Modifications to existing appenders cannot be accomplished
> {*}MyXMLConfiguration.{*}{*}preConfigure(Node){*} allows xml to be rewritten
> just-in-time:
> {code:java}
> @Overrideprotected void preConfigure(Node node) {
> if( !node.isRoot() && node.getName().equals("Property")){
> if( node.getAttributes().containsKey("name") &&
>
> node.getAttributes().get("name").equals("GEOSERVER_LOG_LOCATION")) {
> // override value with current GEOSERVER_LOG_LOCATION
>
[jira] [Commented] (LOGCXX-552) Log4cxx 0.12.1 it is not working on windows platform
[
https://issues.apache.org/jira/browse/LOGCXX-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518485#comment-17518485
]
Robert Middleton commented on LOGCXX-552:
-
Did you run the cmake without copying the log4cxx.hw and log4cxx_private.hw?
Those files are no longer needed as the CMake configuration will automatically
generate them for you. The files that it generates will be in the build
directory. You should just need to run the 'install' target at that point to
copy all of the files to a directory of your choosing.
>From visual studio you can go to "Build->Install log4cxx." If you're doing
>the command line CMake, try "{{{}cmake --build . --target install{}}}"
> Log4cxx 0.12.1 it is not working on windows platform
>
>
> Key: LOGCXX-552
> URL: https://issues.apache.org/jira/browse/LOGCXX-552
> Project: Log4cxx
> Issue Type: Bug
> Components: Build, Documentation
>Affects Versions: 0.12.1
>Reporter: Stefan Jipa
>Priority: Major
> Fix For: 0.12.1
>
>
> Hi,
> We want to upgrade log4cxx from 0.11.0 to 0.12.1.
> We have some problems when trying to use log4cxx 0.12.1 on windows platform.
> We succeded to compile it (here steps (we are using c++17)):
> -copy src/main/include/log4cxx/log4cxx.hw to
> src/main/include/log4cxx/log4cxx.h
> -copy src/main/include/log4cxx/private/log4cxx_private.hw
> src/main/include/log4cxx/private/log4cxx_private.h
> -we disable odbc by commenting:
> apache-log4cxx-0.12.1\src\main\include\CMakeLists.txt
> #if(WIN32)
> # CHECK_INCLUDE_FILES(sqlext.h HAS_ODBC)
> #else()
> # include(FindPkgConfig)
> #
> # pkg_check_modules( odbc QUIET odbc )
> # if(${odbc_FOUND})
> # set(HAS_ODBC 1)
> # endif(${odbc_FOUND})
> #endif(WIN32)
> -we use x64 Native Tools Command Prompt for VS 2019 (c++17)
> cmake -S . -B build -G"Visual Studio 16 2019" -A x64
> -DAPR_INCLUDE_DIR=path_to_apr\include\apr-1\
> -DAPR_LIBRARIES=path_to_apr\lib\libapr-1.lib
> -DAPR_UTIL_INCLUDE_DIR=path_to_apr-util\include\apr-1\
> -DAPR_UTIL_LIBRARIES=path_to_apr-util\lib\libaprutil-1.lib
> -DBUILD_TESTING=OFF -DEXPAT_LIBRARY=path_to_expat\lib\expat.lib
> -DEXPAT_INCLUDE_DIR=path_to_expat\include
> -open build/log4cxx.sln with VS 2019 and compile it in release mode x64 (with
> Windows SDK Version 10.0.19041.0)
> -copy from src/main/include all .h files to a different location
> -copy from build/src/main/cpp/Release/ log4cxx dll and lib files to a
> different location
> -delete build folder
> -in another x64 Native Tools Command Prompt for VS 2019
> cmake -S . -B build -G"Visual Studio 16 2019" -A x64
> -DBUILD_SHARED_LIBS=OFF -DAPR_INCLUDE_DIR=path_to_apr\include\apr-1\
> -DAPR_LIBRARIES=path_to_apr\lib\libapr-1.lib
> -DAPR_UTIL_INCLUDE_DIR=path_to_apr-util\include\apr-1\
> -DAPR_UTIL_LIBRARIES=path_to_apr-util\lib\libaprutil-1.lib
> -DBUILD_TESTING=OFF -DEXPAT_LIBRARY=path_to_expat\lib\expat.lib
> -DEXPAT_INCLUDE_DIR=path_to_expat\include
> -open build/log4cxx.sln with VS 2019 and compile it in release mode x64 (with
> Windows SDK Version 10.0.19041.0 and Code Generation -> Runtime Library ->
> Multi-threaded(/MT))
> -copy build/src/main/cpp/Release/log4cxx.lib to a different location
> When we try to compile a module which is using log4cxx code we get a stack
> full of errors
> generated from PATH_to_log4cxx_0.12.1\include\log4cxx/logger.h caused by
> log4cxx::helpers::ObjectPtrT.
> We saw that log4cxx.hw was not updated and we replaced all apparitions of
> log4cxx::helpers::ObjectPtrT
> with std::shared_ptr. With this we managed to get rid of all that errors,
> but we have this stack of errors
> generated directly from log4cxx code:
> PATH_to_log4cxx_0.12.1\include\log4cxx/logger.h(105): error C2039:
> 'LoggerRepositoryWeakPtr': is not a member of 'log4cxx::spi'
> PATH_to_log4cxx_0.12.1\include\log4cxx/logger.h(45): note: see declaration of
> 'log4cxx::spi'
> PATH_to_log4cxx_0.12.1\include\log4cxx/logger.h(105): error C3646:
> 'repository': unknown override specifier
> PATH_to_log4cxx_0.12.1\include\log4cxx/logger.h(105): error C4430: missing
> type specifier - int assumed. Note: C++ does not support default-int
> PATH_to_log4cxx_0.12.1\include\log4cxx/logger.h(626): error C2039:
> 'LoggerRepositoryWeakPtr': is not a member of 'log4cxx::spi'
> PATH_to_log4cxx_0.12.1\include\log4cxx/logger.h(45): note: see declaration of
> 'log4cxx::spi'
> PATH_to_log4cxx_0.12.1\include\log4cxx/logger.h(626): error C3646:
> 'getLoggerRepository': unknown override specifier
> PATH_to_log4cxx_0.12.1\include\log4cxx/logger.h(626):
[jira] [Commented] (LOG4J2-2872) Unable to parse Custom Log Levels
[
https://issues.apache.org/jira/browse/LOG4J2-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518472#comment-17518472
]
Alla Gofman commented on LOG4J2-2872:
-
Hi,
Did you try to create logger that use this custom level in log4j2.xml
configuration file?
The error will occur on createLogger.
Please see the stack trace before.
> Unable to parse Custom Log Levels
> -
>
> Key: LOG4J2-2872
> URL: https://issues.apache.org/jira/browse/LOG4J2-2872
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.13.3
>Reporter: Alla Gofman
>Priority: Major
>
> When I set the logger level to custom value I get exception although my
> custom levels was created on init.
> WARN Error while converting string [alert] to type [class
> org.apache.logging.log4j.Level]. Using default value [null].
> java.lang.IllegalArgumentException: Unknown level constant [ALERT].
>
> The CustomLevel not added to Level.LEVELS ( ConcurrentMap
> LEVELS).
> My configuration:
> {code:xml}
>
>
> ${cm.home}/../../proclog %d\{-MM-dd HH:mm:ss,SSS} %-2p [%t]
> (%logger\{1}:%L) - %m%n
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> filePattern="${log-path}/alerts%i.log">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> h2. {{Please see log in debug:}}
> {code}
> 2020-06-17 19:23:31,770 main DEBUG PluginManager 'Lookup' found 16 plugins
> 2020-06-17 19:23:31,772 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,773 main DEBUG createLevel(name="emerg", intLevel="0")
> 2020-06-17 19:23:31,773 main DEBUG Creating CustomLevel(name='emerg',
> intValue=0)
> 2020-06-17 19:23:31,774 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,774 main DEBUG createLevel(name="alert", intLevel="1")
> 2020-06-17 19:23:31,774 main DEBUG Creating CustomLevel(name='alert',
> intValue=1)
> 2020-06-17 19:23:31,774 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,775 main DEBUG createLevel(name="crit", intLevel="2")
> 2020-06-17 19:23:31,775 main DEBUG Creating CustomLevel(name='crit',
> intValue=2)
> 2020-06-17 19:23:31,775 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,776 main DEBUG createLevel(name="err", intLevel="3")
> 2020-06-17 19:23:31,776 main DEBUG Creating CustomLevel(name='err',
> intValue=3)
> 2020-06-17 19:23:31,776 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,776 main DEBUG createLevel(name="warning", intLevel="4")
> 2020-06-17 19:23:31,777 main DEBUG Creating CustomLevel(name='warning',
> intValue=4)
> 2020-06-17 19:23:31,777 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,777 main DEBUG createLevel(name="notice", intLevel="5")
> 2020-06-17 19:23:31,777 main DEBUG Creating CustomLevel(name='notice',
> intValue=5)
> 2020-06-17 19:23:31,778 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,778 main DEBUG createLevel(name="info", intLevel="6")
> 2020-06-17 19:23:31,779 main DEBUG Creating CustomLevel(name='info',
> intValue=6)
> 2020-06-17 19:23:31,779 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,780 main DEBUG createLevel(name="debug", intLevel="7")
> 2020-06-17 19:23:31,780 main DEBUG Creating CustomLevel(name='debug',
> intValue=7)
> 2020-06-17 19:23:31,780 main DEBUG Building Plugin[name=CustomLevels,
> class=org.apache.logging.log4j.core.config.CustomLevels].
> 2020-06-17 19:23:31,780 main DEBUG
> createCustomLevels(=\{CustomLevel[name=emerg, intLevel=0],
> CustomLevel[name=alert, intLevel=1], CustomLevel[name=crit, intLevel=2],
> CustomLevel[name=err, intLevel=3], CustomLevel[name=warning, intLevel=4],
> CustomLevel[name=notice, intLevel=5], CustomLevel[name=info, intLevel=6],
> CustomLevel[name=debug, intLevel=7]})
> ...
> 2020-06-17 19:23:31,864 main WARN Error while converting string [alert] to
> type [class org.apache.logging.log4j.Level]. Using default value [null].
> java.lang.IllegalArgumentException: Unknown level constant [ALERT].2020-06-17
[jira] [Updated] (LOG4J2-3469) Create new AppenderComponentBuilder from existing Appender
[
https://issues.apache.org/jira/browse/LOG4J2-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jody Garnett updated LOG4J2-3469:
-
Description:
The documentation covers both [Initialize Log4j by Combining Configuration File
with Programmatic
Configuration|https://logging.apache.org/log4j/2.x/manual/customconfig.html#Hybrid]
and [Programmatically Modifying the Current Configuration after
Initialization|https://logging.apache.org/log4j/2.x/manual/customconfig.html#Programmatically_Modifying_the_Current_Configuration_after_Initialization].
However both these techniques are limited as to what they can accomplish:
* MyXMLConfiguration.doConfigure() is shown adding an appender, via addLogger
method
* A custom configuration super.setup() method is shown using
config.addLogger() and then ctx.updateLoggers().
My challenge is to programatically update the configuration to:
* Override logfile output location, either directly modifying appender, or
modifying config property used by appender.
* Optionally Filter out any RollingFileAppender or FileAppender appenders
* Optionally suppress (filter out) any Console loggers if asked
I am seeking an api used to pre-process configuration objects if one is
available.
In the past when using a fluent / builder API there is an option to jump-start
a builder with the configuration of an existing object. This approach would
allow a builder to be loaded with an existing appender; revised, and a new
appender generated as a replacement.
{code:java}
@Override protected void doConfigure() {
super.doConfigure();
final LoggerContext context = (LoggerContext) LogManager.getContext(false);
final Configuration config = context.getConfiguration();
config.getProperties().put("GEOSERVER_LOG_LOCATION","geoserver.log");
ConfigurationBuilder builder =
ConfigurationBuilderFactory.newConfigurationBuilder();
Appender appender = config.getAppenders("geoserverlogfile");
if( appender instanceof RollingFileAppender){
RollingFileAppender fileAppender =(RollingFileAppender) appender;
AppenderComponentBuilder appenderBuilder = builder.
newAppender("geoserverlogfile", fileAppender)
.addAttribute("fileName", "${GEOSERVER_LOG_LOCATION}.log");
config.getAppenders().remove("geoserverlogfile");
addAppender((Appender) appenderBuilder.build());
}
}{code}
The alternative is verbose and may miss copying new parameters added over time.
Alternatives considered
*MyXMLConfiguration.setup()* prior to super.setup(): Unclear how easy/safe it
is to to modify _rootNode_ structure directly? Is this what is intended by the
documentation.
{code:java}
public void setup() {
for( Node child : rootNode.getChildren()){
if ("Properties".equals(child.getName())){
for( Node property : child.getChildren() ){
if( property.getAttributes().containsKey("name") &&
property.getAttributes().get("name").equals("GEOSERVER_LOG_LOCATION")) {
// override value with current GEOSERVER_LOG_LOCATION
property.setValue("foo.log");
}
}
}
}
super.setup();
}{code}
*MyXMLConfiguration.doConfigure()* before super.doConfigure(): should be able
to modify _rootNode_ and make any changes required. Unclear how easy/safe it is
to to modify node structure directly?
*MyXMLConfiguration.doConfigure()* after super.doConfigure(): is too late as
shown above.
- Can add loggers and appenders
- Modifications to config.getProperties() are not reflected in appender
configuration
- Modifications to existing appenders cannot be accomplished
{*}MyXMLConfiguration.{*}{*}preConfigure(Node){*} allows xml to be rewritten
just-in-time:
{code:java}
@Overrideprotected void preConfigure(Node node) {
if( !node.isRoot() && node.getName().equals("Property")){
if( node.getAttributes().containsKey("name") &&
node.getAttributes().get("name").equals("GEOSERVER_LOG_LOCATION")) {
// override value with current GEOSERVER_LOG_LOCATION
node.setValue("foo.log");
}
}
super.preConfigure(node);
} {code}
For reference see attached {*}DEFAULT_LOGGING.xml{*}.
was:
The documentation covers both [Initialize Log4j by Combining Configuration File
with Programmatic
Configuration|https://logging.apache.org/log4j/2.x/manual/customconfig.html#Hybrid]
and [Programmatically Modifying the Current Configuration after
Initialization|https://logging.apache.org/log4j/2.x/manual/customconfig.html#Programmatically_Modifying_the_Current_Configuration_after_Initialization].
However both these techniques are limited as to what they can accomplish:
* MyXMLConfiguration.doConfigure() is shown adding an appender, via addLogger
method
* A custom configuration super.setup()
[jira] [Updated] (LOG4J2-3469) Create new AppenderComponentBuilder from existing Appender
[
https://issues.apache.org/jira/browse/LOG4J2-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jody Garnett updated LOG4J2-3469:
-
Summary: Create new AppenderComponentBuilder from existing Appender (was:
Override configuration file properties and appenders with programmatic
configuration)
> Create new AppenderComponentBuilder from existing Appender
> --
>
> Key: LOG4J2-3469
> URL: https://issues.apache.org/jira/browse/LOG4J2-3469
> Project: Log4j 2
> Issue Type: New Feature
> Components: Configuration, Configurators, Core
>Affects Versions: 2.17.2
>Reporter: Jody Garnett
>Priority: Minor
> Attachments: DEFAULT_LOGGING.xml
>
>
>
> The documentation covers both [Initialize Log4j by Combining Configuration
> File with Programmatic
> Configuration|https://logging.apache.org/log4j/2.x/manual/customconfig.html#Hybrid]
> and [Programmatically Modifying the Current Configuration after
> Initialization|https://logging.apache.org/log4j/2.x/manual/customconfig.html#Programmatically_Modifying_the_Current_Configuration_after_Initialization].
>
> However both these techniques are limited as to what they can accomplish:
> * MyXMLConfiguration.doConfigure() is shown adding an appender, via
> addLogger method
> * A custom configuration super.setup() method is shown using
> config.addLogger() and then ctx.updateLoggers().
> My challenge is to programatically update the configuration to:
> * Override logfile output location, either directly modifying appender, or
> modifying config property used by appender.
> * Optionally Filter out any RollingFileAppender or FileAppender appenders
> * Optionally suppress (filter out) any Console loggers if asked
> I am seeking an api used to pre-process configuration objects if one is
> available.
> In the past when using a fluent / builder API there is an option to
> jump-start a builder with the configuration of an existing object. This
> approach would allow a builder to be loaded with an existing appender;
> revised, and a new appender generated as a replacement.
> {code:java}
> ConfigurationBuilder builder =
> ConfigurationBuilderFactory.newConfigurationBuilder();
> Appender appender = config.getAppenders("geoserverlogfile");
> if( appender instanceof RollingFileAppender){
> RollingFileAppender fileAppender =(RollingFileAppender) appender;
>
> AppenderComponentBuilder appenderBuilder = builder.
> newAppender("geoserverlogfile", fileAppender)
> .addAttribute("fileName", "${GEOSERVER_LOG_LOCATION}.log");
>
> config.getAppenders().remove("geoserverlogfile");
> addAppender((Appender) appenderBuilder.build());
> }{code}
> The alternative is quite verbose and prone may miss copying new parameters
> added over time.
>
> Candidates:
> *MyXMLConfiguration.setup()* prior to super.setup(): Unclear how easy/safe it
> is to to modify _rootNode_ structure directly? Is this what is intended?
> {code:java}
> public void setup() {
> for( Node child : rootNode.getChildren()){
> if ("Properties".equals(child.getName())){
> for( Node property : child.getChildren() ){
> if( property.getAttributes().containsKey("name") &&
>
> property.getAttributes().get("name").equals("GEOSERVER_LOG_LOCATION")) {
> // override value with current GEOSERVER_LOG_LOCATION
> property.setValue("foo.log");
> }
> }
> }
> }
> super.setup();
> }{code}
> *MyXMLConfiguration.doConfigure()* before super.doConfigure(): should be able
> to modify _rootNode_ and make any changes required. Unclear how easy/safe it
> is to to modify node structure directly?
> *MyXMLConfiguration.doConfigure()* after super.doConfigure(): is too late:
> - Can add loggers and appenders
> - Modifications to config.getProperties() are not reflected in appender
> configuration.
> - Modifications to existing appenders cannot be accomplished
> {*}MyXMLConfiguration.{*}{*}preConfigure(Node){*} allows xml to be rewritten
> just-in-time:
> {code:java}
> @Overrideprotected void preConfigure(Node node) {
> if( !node.isRoot() && node.getName().equals("Property")){
> if( node.getAttributes().containsKey("name") &&
>
> node.getAttributes().get("name").equals("GEOSERVER_LOG_LOCATION")) {
> // override value with current GEOSERVER_LOG_LOCATION
> node.setValue("foo.log");
> }
> }
> super.preConfigure(node);
> } {code}
> For reference see attached {*}DEFAULT_LOGGING.xml{*}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3469) Override configuration file properties and appenders with programmatic configuration
[
https://issues.apache.org/jira/browse/LOG4J2-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jody Garnett updated LOG4J2-3469:
-
Description:
The documentation covers both [Initialize Log4j by Combining Configuration File
with Programmatic
Configuration|https://logging.apache.org/log4j/2.x/manual/customconfig.html#Hybrid]
and [Programmatically Modifying the Current Configuration after
Initialization|https://logging.apache.org/log4j/2.x/manual/customconfig.html#Programmatically_Modifying_the_Current_Configuration_after_Initialization].
However both these techniques are limited as to what they can accomplish:
* MyXMLConfiguration.doConfigure() is shown adding an appender, via addLogger
method
* A custom configuration super.setup() method is shown using
config.addLogger() and then ctx.updateLoggers().
My challenge is to programatically update the configuration to:
* Override logfile output location, either directly modifying appender, or
modifying config property used by appender.
* Optionally Filter out any RollingFileAppender or FileAppender appenders
* Optionally suppress (filter out) any Console loggers if asked
I am seeking an api used to pre-process configuration objects if one is
available.
In the past when using a fluent / builder API there is an option to jump-start
a builder with the configuration of an existing object. This approach would
allow a builder to be loaded with an existing appender; revised, and a new
appender generated as a replacement.
{code:java}
ConfigurationBuilder builder =
ConfigurationBuilderFactory.newConfigurationBuilder();
Appender appender = config.getAppenders("geoserverlogfile");
if( appender instanceof RollingFileAppender){
RollingFileAppender fileAppender =(RollingFileAppender) appender;
AppenderComponentBuilder appenderBuilder = builder.
newAppender("geoserverlogfile", fileAppender)
.addAttribute("fileName", "${GEOSERVER_LOG_LOCATION}.log");
config.getAppenders().remove("geoserverlogfile");
addAppender((Appender) appenderBuilder.build());
}{code}
The alternative is quite verbose and prone may miss copying new parameters
added over time.
Candidates:
*MyXMLConfiguration.setup()* prior to super.setup(): Unclear how easy/safe it
is to to modify _rootNode_ structure directly? Is this what is intended?
{code:java}
public void setup() {
for( Node child : rootNode.getChildren()){
if ("Properties".equals(child.getName())){
for( Node property : child.getChildren() ){
if( property.getAttributes().containsKey("name") &&
property.getAttributes().get("name").equals("GEOSERVER_LOG_LOCATION")) {
// override value with current GEOSERVER_LOG_LOCATION
property.setValue("foo.log");
}
}
}
}
super.setup();
}{code}
*MyXMLConfiguration.doConfigure()* before super.doConfigure(): should be able
to modify _rootNode_ and make any changes required. Unclear how easy/safe it is
to to modify node structure directly?
*MyXMLConfiguration.doConfigure()* after super.doConfigure(): is too late:
- Can add loggers and appenders
- Modifications to config.getProperties() are not reflected in appender
configuration.
- Modifications to existing appenders cannot be accomplished
{*}MyXMLConfiguration.{*}{*}preConfigure(Node){*} allows xml to be rewritten
just-in-time:
{code:java}
@Overrideprotected void preConfigure(Node node) {
if( !node.isRoot() && node.getName().equals("Property")){
if( node.getAttributes().containsKey("name") &&
node.getAttributes().get("name").equals("GEOSERVER_LOG_LOCATION")) {
// override value with current GEOSERVER_LOG_LOCATION
node.setValue("foo.log");
}
}
super.preConfigure(node);
} {code}
For reference see attached {*}DEFAULT_LOGGING.xml{*}.
was:
The documentation covers both [Initialize Log4j by Combining Configuration File
with Programmatic
Configuration|https://logging.apache.org/log4j/2.x/manual/customconfig.html#Hybrid]
and [Programmatically Modifying the Current Configuration after
Initialization|https://logging.apache.org/log4j/2.x/manual/customconfig.html#Programmatically_Modifying_the_Current_Configuration_after_Initialization].
However both these techniques are limited as to what they can accomplish:
* MyXMLConfiguration.doConfigure() is shown adding an appender, via addLogger
method
* A custom configuration super.setup() method is shown using
config.addLogger() and then ctx.updateLoggers().
My challenge is to programatically update the configuration to:
* Override logfile output location, either directly modifying appender, or
modifying config property used by appender.
* Optionally Filter out any RollingFileAppender or FileAppender appenders
* Optionally suppress (filter
[jira] [Updated] (LOG4J2-3469) Override configuration file properties and appenders with programmatic configuration
[
https://issues.apache.org/jira/browse/LOG4J2-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jody Garnett updated LOG4J2-3469:
-
Description:
The documentation covers both [Initialize Log4j by Combining Configuration File
with Programmatic
Configuration|https://logging.apache.org/log4j/2.x/manual/customconfig.html#Hybrid]
and [Programmatically Modifying the Current Configuration after
Initialization|https://logging.apache.org/log4j/2.x/manual/customconfig.html#Programmatically_Modifying_the_Current_Configuration_after_Initialization].
However both these techniques are limited as to what they can accomplish:
* MyXMLConfiguration.doConfigure() is shown adding an appender, via addLogger
method
* A custom configuration super.setup() method is shown using
config.addLogger() and then ctx.updateLoggers().
My challenge is to programatically update the configuration to:
* Override logfile output location, either directly modifying appender, or
modifying config property used by appender.
* Optionally Filter out any RollingFileAppender or FileAppender appenders
* Optionally suppress (filter out) any Console loggers if asked
I am seeking an api used to pre-process configuration if one is available.
Candidates:
*MyXMLConfiguration.setup()* prior to super.setup(): Unclear how easy/safe it
is to to modify node structure directly? Is this what is intended?
{code:java}
public void setup() {
for( Node child : rootNode.getChildren()){
if ("Properties".equals(child.getName())){
for( Node property : child.getChildren() ){
if( property.getAttributes().containsKey("name") &&
property.getAttributes().get("name").equals("GEOSERVER_LOG_LOCATION")) {
// override value with current GEOSERVER_LOG_LOCATION
property.setValue("foo.log");
}
}
}
}
super.setup();
}{code}
*MyXMLConfiguration.doConfigure()* before super.doConfigure(): should be able
to modify ``rootNode`` and make any changes required. Unclear how easy/safe it
is to to modify node structure directly?
*MyXMLConfiguration.doConfigure()* after super.doConfigure(): is too late:
- Can only append add loggers and appenders
- Modifications to config.getProperties() are not reflected in appender
configuration.
- Modifications to existing appenders cannot be accomplished
- In the past when using a fluent / builder API there is an option to
jump-start a builder with the configuration of an existing object. This
approach would allow a builder to be loaded with an existing appender; revised,
and a new appender generated as a replacement.
{*}MyXMLConfiguration.{*}{*}preConfigure(Node){*} allows xml to be rewritten
just-in-time:
{code:java}
@Overrideprotected void preConfigure(Node node) {
if( !node.isRoot() && node.getName().equals("Property")){
if( node.getAttributes().containsKey("name") &&
node.getAttributes().get("name").equals("GEOSERVER_LOG_LOCATION")) {
// override value with current GEOSERVER_LOG_LOCATION
node.setValue("foo.log");
}
}
super.preConfigure(node);
} {code}
For reference see attached {*}DEFAULT_LOGGING.xml{*}.
was:
The documentation covers both [Initialize Log4j by Combining Configuration File
with Programmatic
Configuration|https://logging.apache.org/log4j/2.x/manual/customconfig.html#Hybrid]
and [Programmatically Modifying the Current Configuration after
Initialization|https://logging.apache.org/log4j/2.x/manual/customconfig.html#Programmatically_Modifying_the_Current_Configuration_after_Initialization].
However both these techniques are limited as to what they can accomplish:
* MyXMLConfiguration.doConfigure() is shown adding an appender, via addLogger
method
* A custom configuration super.setup() method is shown using
config.addLogger() and then ctx.updateLoggers().
My challenge is to programatically update the configuration to:
* Override logfile output location, either directly modifying appender, or
modifying config property used by appender.
* Optionally Filter out any RollingFileAppender or FileAppender appenders
* Optionally suppress (filter out) any Console loggers if asked
I am seeking an api used to pre-process configuration if one is available.
Candidates:
*MyXMLConfiguration.setup()* prior to super.setup(): Unclear how easy/safe it
is to to modify node structure directly? Is this what is intended?
{code:java}
public void setup() {
for( Node child : rootNode.getChildren()){
if ("Properties".equals(child.getName())){
for( Node property : child.getChildren() ){
if( property.getAttributes().containsKey("name") &&
property.getAttributes().get("name").equals("GEOSERVER_LOG_LOCATION")) {
// override value with current
[jira] [Created] (LOG4J2-3469) Override configuration file properties and appenders with programmatic configuration
Jody Garnett created LOG4J2-3469:
Summary: Override configuration file properties and appenders with
programmatic configuration
Key: LOG4J2-3469
URL: https://issues.apache.org/jira/browse/LOG4J2-3469
Project: Log4j 2
Issue Type: New Feature
Components: Configuration, Configurators, Core
Affects Versions: 2.17.2
Reporter: Jody Garnett
Attachments: DEFAULT_LOGGING.xml
The documentation covers both [Initialize Log4j by Combining Configuration File
with Programmatic
Configuration|https://logging.apache.org/log4j/2.x/manual/customconfig.html#Hybrid]
and [Programmatically Modifying the Current Configuration after
Initialization|https://logging.apache.org/log4j/2.x/manual/customconfig.html#Programmatically_Modifying_the_Current_Configuration_after_Initialization].
However both these techniques are limited as to what they can accomplish:
* MyXMLConfiguration.doConfigure() is shown adding an appender, via addLogger
method
* A custom configuration super.setup() method is shown using
config.addLogger() and then ctx.updateLoggers().
My challenge is to programatically update the configuration to:
* Override logfile output location, either directly modifying appender, or
modifying config property used by appender.
* Optionally Filter out any RollingFileAppender or FileAppender appenders
* Optionally suppress (filter out) any Console loggers if asked
I am seeking an api used to pre-process configuration if one is available.
Candidates:
*MyXMLConfiguration.setup()* prior to super.setup(): Unclear how easy/safe it
is to to modify node structure directly? Is this what is intended?
{code:java}
public void setup() {
for( Node child : rootNode.getChildren()){
if ("Properties".equals(child.getName())){
for( Node property : child.getChildren() ){
if( property.getAttributes().containsKey("name") &&
property.getAttributes().get("name").equals("GEOSERVER_LOG_LOCATION")) {
// override value with current GEOSERVER_LOG_LOCATION
property.setValue("foo.log");
}
}
}
}
super.setup();
}{code}
*MyXMLConfiguration.doConfigure()* before super.doConfigure(): should be able
to modify ``rootNode`` and make any changes required. Unclear how easy/safe it
is to to modify node structure directly?
*MyXMLConfiguration.doConfigure()* after super.doConfigure(): is too late:
- Can only append add loggers and appenders
- Modifications to config.getProperties() are not reflected in appender
configuration.
- Modifications to existing appenders cannot be accomplished
- In the past when using a fluent / builder API there is an option to
jump-start a builder with the configuration of an existing object. This
approach would allow a builder to be loaded with an existing appender; revised,
and a new appender generated as a replacement.
*MyXMLConfiguration.*{*}preConfigure(Node){*} allows xml to be rewritten
just-in-time:
{code:java}
@Overrideprotected void preConfigure(Node node) {
if( !node.isRoot() && node.getName().equals("Property")){
if( node.getAttributes().containsKey("name") &&
node.getAttributes().get("name").equals("GEOSERVER_LOG_LOCATION")) {
// override value with current GEOSERVER_LOG_LOCATION
node.setValue("foo.log");
}
}
super.preConfigure(node);
} {code}
For reference see attached {*}DEFAULT_LOGGING.xml{*}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3467) Update from Log4J 2.17.1 to 2.17.2 breaks application
[
https://issues.apache.org/jira/browse/LOG4J2-3467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518345#comment-17518345
]
Piotr Karwasz commented on LOG4J2-3467:
---
[~veita],
{{PropertyConfigurator}} was a no-op in 2.17.1 and is a functional class in
2.17.2.
Probably your third-party library uses it to reconfigure logging and you can
not find your logs in the usual places. You can run the application with
{{-Dlog4j.debug=true}} to debug it.
> Update from Log4J 2.17.1 to 2.17.2 breaks application
> -
>
> Key: LOG4J2-3467
> URL: https://issues.apache.org/jira/browse/LOG4J2-3467
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.17.2
>Reporter: Alexander Veit
>Priority: Major
>
> We have an application that uses a third-party library which seems to
> reconfigure Log4J according to its needs. This worked for quite some years
> with various Log4J versions.
> After upgrading from Log4J 2.17.1 to 2.17.2 a call to the library immediately
> stops logging completely in the sense that no further logging is performed
> until restarting the JVM.
> We've tried to identify the change that leads to the problem. Our best guess
> is PropertyConfigurator, line 164 in
> https://github.com/apache/logging-log4j2/commit/73a2cd1cd0e94c7f4f36e4ac9dc72380d30750ef#diff-607596a6cadd10faf2dbeefc4e03092264b8e0dbe23fb89ffa6505d644602c9dR164
> Note that according to semantic versioning such breaking changes should not
> occur when only the patch version is incremented. ;-)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3468) can we set log4j property 'Log4jContextSelector' per webapps war deployment
[
https://issues.apache.org/jira/browse/LOG4J2-3468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518332#comment-17518332
]
Ralph Goers commented on LOG4J2-3468:
-
You have asked this same question on the user's list. Ignoring this issue for
now.
> can we set log4j property 'Log4jContextSelector' per webapps war deployment
> ---
>
> Key: LOG4J2-3468
> URL: https://issues.apache.org/jira/browse/LOG4J2-3468
> Project: Log4j 2
> Issue Type: Question
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
>
> In my application where I am using custom logger and custom ContextSelector
> log4j2 2.17.2 version, I have 2 processes running and there are 3 webapps war
> files which get deployed in tomcat version 9.0.60. Out of these 3 war files,
> one war file is internal to my application while other 2 are coming as final
> artifacts from artifiactory.
> My war uses a custom logger and custom ContextSelector, however other 2 wars
> from artifactory uses standard logger and standard ContextSelector.
>
> I have defined below system property as a static block in custom logger.
> _*static {*_
> _*System.setProperty("Log4jContextSelector",
> "logger.log4j2.CustomLog4j2ContextSelector");*_
> _*}*_
> However for some unknown reason when my war gets deployed this log4j jars
> don't find this property and leads to ClassCastException
> "java.lang.ClassCastException:
> org.apache.logging.log4j.core.selector.ContextSelector cannot be cast to
> logger.log4j2.CustomLog4j2ContextSelector". To fix this I have placed
> 'log4j2.component.properties' file on log4j jars class path.
>
> Content of file 'log4j2.component.properties' ->
> _*Log4jContextSelector=logger.log4j2.CustomLog4j2ContextSelector*_
> But with this fix, for other 2 wars I get following below harmless error(wars
> functionality works fine) when I keep 'log4j2.component.properties' file on
> log4j jars class path, to fix class cast exception which I was getting
> earlier during deployment of my war file.
>
> _*ERROR StatusLogger Unable to create custom ContextSelector. Falling back to
> default.*_
> _*"java.lang.ClassCastException: Cannot cast
> logger.log4j2.CustomLog4j2ContextSelector to
> org.apache.logging.log4j.core.selector.ContextSelector".*_
>
> I am looking for help to come up with a solution where, when my war gets
> deployed then custom logger context
> "logger.log4j2.CustomLog4j2ContextSelector" should be used while when other 2
> wars get deployed then
> "org.apache.logging.log4j.core.selector.ContextSelector" should be used.
> Please let me know if you have any idea on this.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3467) Update from Log4J 2.17.1 to 2.17.2 breaks application
[ https://issues.apache.org/jira/browse/LOG4J2-3467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518316#comment-17518316 ] Alexander Veit commented on LOG4J2-3467: Here's a small project to reproduce the issue: https://github.com/veita/LOG4J2-3467 > Update from Log4J 2.17.1 to 2.17.2 breaks application > - > > Key: LOG4J2-3467 > URL: https://issues.apache.org/jira/browse/LOG4J2-3467 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.17.2 >Reporter: Alexander Veit >Priority: Major > > We have an application that uses a third-party library which seems to > reconfigure Log4J according to its needs. This worked for quite some years > with various Log4J versions. > After upgrading from Log4J 2.17.1 to 2.17.2 a call to the library immediately > stops logging completely in the sense that no further logging is performed > until restarting the JVM. > We've tried to identify the change that leads to the problem. Our best guess > is PropertyConfigurator, line 164 in > https://github.com/apache/logging-log4j2/commit/73a2cd1cd0e94c7f4f36e4ac9dc72380d30750ef#diff-607596a6cadd10faf2dbeefc4e03092264b8e0dbe23fb89ffa6505d644602c9dR164 > Note that according to semantic versioning such breaking changes should not > occur when only the patch version is incremented. ;-) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-2872) Unable to parse Custom Log Levels
[
https://issues.apache.org/jira/browse/LOG4J2-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518311#comment-17518311
]
Jody Garnett commented on LOG4J2-2872:
--
I was able to work with custom log levels:
{code:java}
logs/geoserver
...{code}
I also defined the levels programatically for use when coding:
{code:java}
public static final Level CONFIG =
Level.forName("CONFIG", StandardLevel.INFO.intLevel() + 50);
public static final Level FINEST =
Level.forName("FINEST", StandardLevel.TRACE.intLevel() + 100);
{code}
> Unable to parse Custom Log Levels
> -
>
> Key: LOG4J2-2872
> URL: https://issues.apache.org/jira/browse/LOG4J2-2872
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.13.3
>Reporter: Alla Gofman
>Priority: Major
>
> When I set the logger level to custom value I get exception although my
> custom levels was created on init.
> WARN Error while converting string [alert] to type [class
> org.apache.logging.log4j.Level]. Using default value [null].
> java.lang.IllegalArgumentException: Unknown level constant [ALERT].
>
> The CustomLevel not added to Level.LEVELS ( ConcurrentMap
> LEVELS).
> My configuration:
> {code:xml}
>
>
> ${cm.home}/../../proclog %d\{-MM-dd HH:mm:ss,SSS} %-2p [%t]
> (%logger\{1}:%L) - %m%n
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> filePattern="${log-path}/alerts%i.log">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> h2. {{Please see log in debug:}}
> {code}
> 2020-06-17 19:23:31,770 main DEBUG PluginManager 'Lookup' found 16 plugins
> 2020-06-17 19:23:31,772 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,773 main DEBUG createLevel(name="emerg", intLevel="0")
> 2020-06-17 19:23:31,773 main DEBUG Creating CustomLevel(name='emerg',
> intValue=0)
> 2020-06-17 19:23:31,774 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,774 main DEBUG createLevel(name="alert", intLevel="1")
> 2020-06-17 19:23:31,774 main DEBUG Creating CustomLevel(name='alert',
> intValue=1)
> 2020-06-17 19:23:31,774 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,775 main DEBUG createLevel(name="crit", intLevel="2")
> 2020-06-17 19:23:31,775 main DEBUG Creating CustomLevel(name='crit',
> intValue=2)
> 2020-06-17 19:23:31,775 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,776 main DEBUG createLevel(name="err", intLevel="3")
> 2020-06-17 19:23:31,776 main DEBUG Creating CustomLevel(name='err',
> intValue=3)
> 2020-06-17 19:23:31,776 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,776 main DEBUG createLevel(name="warning", intLevel="4")
> 2020-06-17 19:23:31,777 main DEBUG Creating CustomLevel(name='warning',
> intValue=4)
> 2020-06-17 19:23:31,777 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,777 main DEBUG createLevel(name="notice", intLevel="5")
> 2020-06-17 19:23:31,777 main DEBUG Creating CustomLevel(name='notice',
> intValue=5)
> 2020-06-17 19:23:31,778 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,778 main DEBUG createLevel(name="info", intLevel="6")
> 2020-06-17 19:23:31,779 main DEBUG Creating CustomLevel(name='info',
> intValue=6)
> 2020-06-17 19:23:31,779 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,780 main DEBUG createLevel(name="debug", intLevel="7")
> 2020-06-17 19:23:31,780 main DEBUG Creating CustomLevel(name='debug',
> intValue=7)
> 2020-06-17 19:23:31,780 main DEBUG Building Plugin[name=CustomLevels,
> class=org.apache.logging.log4j.core.config.CustomLevels].
> 2020-06-17 19:23:31,780 main DEBUG
> createCustomLevels(=\{CustomLevel[name=emerg, intLevel=0],
> CustomLevel[name=alert, intLevel=1], CustomLevel[name=crit, intLevel=2],
> CustomLevel[name=err, intLevel=3], CustomLevel[name=warning, intLevel=4],
> CustomLevel[name=notice, intLevel=5], CustomLevel[name=info, intLevel=6],
> CustomLevel[name=debug, intLevel=7]})
> ...
> 2020-06-17
[jira] [Commented] (LOG4J2-3467) Update from Log4J 2.17.1 to 2.17.2 breaks application
[ https://issues.apache.org/jira/browse/LOG4J2-3467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518282#comment-17518282 ] Gary D. Gregory commented on LOG4J2-3467: - I just need something I can drop in and test, for me, I do not have issues with this kind of setup where I mix slf4j and log4j api's, all backed by log4j core. I am assuming you have log4j-slf4j-impl on your class path. > Update from Log4J 2.17.1 to 2.17.2 breaks application > - > > Key: LOG4J2-3467 > URL: https://issues.apache.org/jira/browse/LOG4J2-3467 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.17.2 >Reporter: Alexander Veit >Priority: Major > > We have an application that uses a third-party library which seems to > reconfigure Log4J according to its needs. This worked for quite some years > with various Log4J versions. > After upgrading from Log4J 2.17.1 to 2.17.2 a call to the library immediately > stops logging completely in the sense that no further logging is performed > until restarting the JVM. > We've tried to identify the change that leads to the problem. Our best guess > is PropertyConfigurator, line 164 in > https://github.com/apache/logging-log4j2/commit/73a2cd1cd0e94c7f4f36e4ac9dc72380d30750ef#diff-607596a6cadd10faf2dbeefc4e03092264b8e0dbe23fb89ffa6505d644602c9dR164 > Note that according to semantic versioning such breaking changes should not > occur when only the patch version is incremented. ;-) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3467) Update from Log4J 2.17.1 to 2.17.2 breaks application
[ https://issues.apache.org/jira/browse/LOG4J2-3467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518262#comment-17518262 ] Gary D. Gregory commented on LOG4J2-3467: - What is the class path you use to run this program? > Update from Log4J 2.17.1 to 2.17.2 breaks application > - > > Key: LOG4J2-3467 > URL: https://issues.apache.org/jira/browse/LOG4J2-3467 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.17.2 >Reporter: Alexander Veit >Priority: Major > > We have an application that uses a third-party library which seems to > reconfigure Log4J according to its needs. This worked for quite some years > with various Log4J versions. > After upgrading from Log4J 2.17.1 to 2.17.2 a call to the library immediately > stops logging completely in the sense that no further logging is performed > until restarting the JVM. > We've tried to identify the change that leads to the problem. Our best guess > is PropertyConfigurator, line 164 in > https://github.com/apache/logging-log4j2/commit/73a2cd1cd0e94c7f4f36e4ac9dc72380d30750ef#diff-607596a6cadd10faf2dbeefc4e03092264b8e0dbe23fb89ffa6505d644602c9dR164 > Note that according to semantic versioning such breaking changes should not > occur when only the patch version is incremented. ;-) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3467) Update from Log4J 2.17.1 to 2.17.2 breaks application
[
https://issues.apache.org/jira/browse/LOG4J2-3467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518256#comment-17518256
]
Alexander Veit edited comment on LOG4J2-3467 at 4/6/22 3:57 PM:
Unfortunately I cannot provide a test application to reproduce the problem with
the actual dependencies (third-party library, closed-source). However, the
smallest program to reproduce the issue is probably the following (derived from
bytecode):
{code:java}
import java.util.Properties;
import org.apache.log4j.PropertyConfigurator;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
private static final Logger logger = LoggerFactory.getLogger(Test.class);
logger.error("ERROR1");
PropertyConfigurator.configure(new Properties());
logger.error("ERROR2");
{code}
Hereby {{logger}} is a SLF4J logger with a Log4J backend and configuration.
Only ERROR1 is being logged.
was (Author: veita):
Unfortunately I cannot provide a test application to reproduce the problem with
the actual dependencies (third-party library, closed-source). However, the
smallest program to reproduce the issue is probably the following:
{code:java}
import java.util.Properties;
import org.apache.log4j.PropertyConfigurator;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
private static final Logger logger = LoggerFactory.getLogger(Test.class);
logger.error("ERROR1");
PropertyConfigurator.configure(new Properties());
logger.error("ERROR2");
{code}
Hereby {{logger}} is a SLF4J logger with a Log4J backend and configuration.
Only ERROR1 is being logged.
> Update from Log4J 2.17.1 to 2.17.2 breaks application
> -
>
> Key: LOG4J2-3467
> URL: https://issues.apache.org/jira/browse/LOG4J2-3467
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.17.2
>Reporter: Alexander Veit
>Priority: Major
>
> We have an application that uses a third-party library which seems to
> reconfigure Log4J according to its needs. This worked for quite some years
> with various Log4J versions.
> After upgrading from Log4J 2.17.1 to 2.17.2 a call to the library immediately
> stops logging completely in the sense that no further logging is performed
> until restarting the JVM.
> We've tried to identify the change that leads to the problem. Our best guess
> is PropertyConfigurator, line 164 in
> https://github.com/apache/logging-log4j2/commit/73a2cd1cd0e94c7f4f36e4ac9dc72380d30750ef#diff-607596a6cadd10faf2dbeefc4e03092264b8e0dbe23fb89ffa6505d644602c9dR164
> Note that according to semantic versioning such breaking changes should not
> occur when only the patch version is incremented. ;-)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3467) Update from Log4J 2.17.1 to 2.17.2 breaks application
[
https://issues.apache.org/jira/browse/LOG4J2-3467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518256#comment-17518256
]
Alexander Veit commented on LOG4J2-3467:
Unfortunately I cannot provide a test application to reproduce the problem with
the actual dependencies (third-party library, closed-source). However, the
smallest program to reproduce the issue is probably the following:
{code:java}
import java.util.Properties;
import org.apache.log4j.PropertyConfigurator;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
private static final Logger logger = LoggerFactory.getLogger(Test.class);
logger.error("ERROR1");
PropertyConfigurator.configure(new Properties());
logger.error("ERROR2");
{code}
Hereby {{logger}} is a SLF4J logger with a Log4J backend and configuration.
Only ERROR1 is being logged.
> Update from Log4J 2.17.1 to 2.17.2 breaks application
> -
>
> Key: LOG4J2-3467
> URL: https://issues.apache.org/jira/browse/LOG4J2-3467
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.17.2
>Reporter: Alexander Veit
>Priority: Major
>
> We have an application that uses a third-party library which seems to
> reconfigure Log4J according to its needs. This worked for quite some years
> with various Log4J versions.
> After upgrading from Log4J 2.17.1 to 2.17.2 a call to the library immediately
> stops logging completely in the sense that no further logging is performed
> until restarting the JVM.
> We've tried to identify the change that leads to the problem. Our best guess
> is PropertyConfigurator, line 164 in
> https://github.com/apache/logging-log4j2/commit/73a2cd1cd0e94c7f4f36e4ac9dc72380d30750ef#diff-607596a6cadd10faf2dbeefc4e03092264b8e0dbe23fb89ffa6505d644602c9dR164
> Note that according to semantic versioning such breaking changes should not
> occur when only the patch version is incremented. ;-)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j-audit-sample] dependabot[bot] opened a new pull request, #1: Bump spring-core from 4.3.3.RELEASE to 5.3.18
dependabot[bot] opened a new pull request, #1: URL: https://github.com/apache/logging-log4j-audit-sample/pull/1 Bumps [spring-core](https://github.com/spring-projects/spring-framework) from 4.3.3.RELEASE to 5.3.18. Release notes Sourced from https://github.com/spring-projects/spring-framework/releases;>spring-core's releases. v5.3.18 :star: New Features Restrict access to property paths on Class references https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28261;>#28261 Introduce cancel(boolean mayInterruptIfRunning) in ScheduledTask https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28233;>#28233 :lady_beetle: Bug Fixes Move off deprecated API in SessionTransactionData https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28234;>#28234 :notebook_with_decorative_cover: Documentation Introduce warnings in documentation of SerializationUtils https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28246;>#28246 Update copyright date in reference manual https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28237;>#28237 @Transactional test does not execute all JPA lifecycle callback methods https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28228;>#28228 :heart: Contributors We'd like to thank all the contributors who worked on this release! https://github.com/izeye;>@izeye https://github.com/quaff;>@quaff v5.3.17 :star: New Features Using DataClassRowMapper causes No property found for column debug messages in logs https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28179;>#28179 Improve diagnostics in SpEL for large array creation https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28145;>#28145 Support custom HTTP status in client-side REST testing support https://github-redirect.dependabot.com/spring-projects/spring-framework/pull/28105;>#28105 AsyncRestTemplate logging too verbose https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28049;>#28049 :lady_beetle: Bug Fixes java.lang.NoClassDefFoundError: org/springframework/cglib/beans/BeanMapEmitter https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28110;>#28110 CronExpression fails to calculate properly next execution when running on the day of winter daylight saving time https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28095;>#28095 Private init/destroy method may be invoked twice https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28083;>#28083 MappingJacksonValue and Jackson2CodecSupport#registerObjectMappersForType do not work together https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28045;>#28045 SpEL fails to recover from error during MIXED mode compilation https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28043;>#28043 When returning a ResponseEntity with a Flux while the function is suspended, it fails to encode the body https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/27809;>#27809 :notebook_with_decorative_cover: Documentation Improve documentation for @EnabledIf and @DisabledIf test support https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28157;>#28157 Links to Spring Security are broken in the reference guide https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28135;>#28135 Document that transaction rollback rules may result in unintentional matches https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28125;>#28125 Improve documentation for TestContext events https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/27757;>#27757 Clarify behavior for generics support in BeanUtils.copyProperties https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/27259;>#27259 :hammer: Dependency Upgrades ... (truncated) Commits https://github.com/spring-projects/spring-framework/commit/707a24c48b21fc35e8be715afc80f020a24a9714;>707a24c Release v5.3.18 https://github.com/spring-projects/spring-framework/commit/002546b3e4b8d791ea6acccb81eb3168f51abb15;>002546b Refine PropertyDescriptor filtering https://github.com/spring-projects/spring-framework/commit/1627f57f1f77abe17dd607c75476b9e4cb22ffbb;>1627f57 Disable flaky integration tests for now https://github.com/spring-projects/spring-framework/commit/3811cd4c0a0be3aac6e842cf1890610ce986449d;>3811cd4 Introduce warnings in documentation of SerializationUtils
[jira] [Created] (LOG4J2-3468) can we set log4j property 'Log4jContextSelector' per webapps war deployment
Pooja Pandey created LOG4J2-3468:
Summary: can we set log4j property 'Log4jContextSelector' per
webapps war deployment
Key: LOG4J2-3468
URL: https://issues.apache.org/jira/browse/LOG4J2-3468
Project: Log4j 2
Issue Type: Question
Components: Log4j 1.2 bridge
Affects Versions: 2.17.2
Reporter: Pooja Pandey
In my application where I am using custom logger and custom ContextSelector
log4j2 2.17.2 version, I have 2 processes running and there are 3 webapps war
files which get deployed in tomcat version 9.0.60. Out of these 3 war files,
one war file is internal to my application while other 2 are coming as final
artifacts from artifiactory.
My war uses a custom logger and custom ContextSelector, however other 2 wars
from artifactory uses standard logger and standard ContextSelector.
I have defined below system property as a static block in custom logger.
_*static {*_
_*System.setProperty("Log4jContextSelector",
"logger.log4j2.CustomLog4j2ContextSelector");*_
_*}*_
However for some unknown reason when my war gets deployed this log4j jars don't
find this property and leads to ClassCastException
"java.lang.ClassCastException:
org.apache.logging.log4j.core.selector.ContextSelector cannot be cast to
logger.log4j2.CustomLog4j2ContextSelector". To fix this I have placed
'log4j2.component.properties' file on log4j jars class path.
Content of file 'log4j2.component.properties' ->
_*Log4jContextSelector=logger.log4j2.CustomLog4j2ContextSelector*_
But with this fix, for other 2 wars I get following below harmless error(wars
functionality works fine) when I keep 'log4j2.component.properties' file on
log4j jars class path, to fix class cast exception which I was getting earlier
during deployment of my war file.
_*ERROR StatusLogger Unable to create custom ContextSelector. Falling back to
default.*_
_*"java.lang.ClassCastException: Cannot cast
logger.log4j2.CustomLog4j2ContextSelector to
org.apache.logging.log4j.core.selector.ContextSelector".*_
I am looking for help to come up with a solution where, when my war gets
deployed then custom logger context "logger.log4j2.CustomLog4j2ContextSelector"
should be used while when other 2 wars get deployed then
"org.apache.logging.log4j.core.selector.ContextSelector" should be used. Please
let me know if you have any idea on this.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3467) Update from Log4J 2.17.1 to 2.17.2 breaks application
[ https://issues.apache.org/jira/browse/LOG4J2-3467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518130#comment-17518130 ] Gary D. Gregory commented on LOG4J2-3467: - Thank you for your report. We need something to reproduce this issue, a small app, a failing unit test, a better and detailed description. > Update from Log4J 2.17.1 to 2.17.2 breaks application > - > > Key: LOG4J2-3467 > URL: https://issues.apache.org/jira/browse/LOG4J2-3467 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.17.2 >Reporter: Alexander Veit >Priority: Major > > We have an application that uses a third-party library which seems to > reconfigure Log4J according to its needs. This worked for quite some years > with various Log4J versions. > After upgrading from Log4J 2.17.1 to 2.17.2 a call to the library immediately > stops logging completely in the sense that no further logging is performed > until restarting the JVM. > We've tried to identify the change that leads to the problem. Our best guess > is PropertyConfigurator, line 164 in > https://github.com/apache/logging-log4j2/commit/73a2cd1cd0e94c7f4f36e4ac9dc72380d30750ef#diff-607596a6cadd10faf2dbeefc4e03092264b8e0dbe23fb89ffa6505d644602c9dR164 > Note that according to semantic versioning such breaking changes should not > occur when only the patch version is incremented. ;-) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (LOG4J2-3467) Update from Log4J 2.17.1 to 2.17.2 breaks application
Alexander Veit created LOG4J2-3467: -- Summary: Update from Log4J 2.17.1 to 2.17.2 breaks application Key: LOG4J2-3467 URL: https://issues.apache.org/jira/browse/LOG4J2-3467 Project: Log4j 2 Issue Type: Bug Components: Core Affects Versions: 2.17.2 Reporter: Alexander Veit We have an application that uses a third-party library which seems to reconfigure Log4J according to its needs. This worked for quite some years with various Log4J versions. After upgrading from Log4J 2.17.1 to 2.17.2 a call to the library immediately stops logging completely in the sense that no further logging is performed until restarting the JVM. We've tried to identify the change that leads to the problem. Our best guess is PropertyConfigurator, line 164 in https://github.com/apache/logging-log4j2/commit/73a2cd1cd0e94c7f4f36e4ac9dc72380d30750ef#diff-607596a6cadd10faf2dbeefc4e03092264b8e0dbe23fb89ffa6505d644602c9dR164 Note that according to semantic versioning such breaking changes should not occur when only the patch version is incremented. ;-) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (LOGCXX-552) Log4cxx 0.12.1 it is not working on windows platform
Stefan Jipa created LOGCXX-552:
--
Summary: Log4cxx 0.12.1 it is not working on windows platform
Key: LOGCXX-552
URL: https://issues.apache.org/jira/browse/LOGCXX-552
Project: Log4cxx
Issue Type: Bug
Components: Build, Documentation
Affects Versions: 0.12.1
Reporter: Stefan Jipa
Fix For: 0.12.1
Hi,
We want to upgrade log4cxx from 0.11.0 to 0.12.1.
We have some problems when trying to use log4cxx 0.12.1 on windows platform.
We succeded to compile it (here steps (we are using c++17)):
-copy src/main/include/log4cxx/log4cxx.hw to src/main/include/log4cxx/log4cxx.h
-copy src/main/include/log4cxx/private/log4cxx_private.hw
src/main/include/log4cxx/private/log4cxx_private.h
-we disable odbc by commenting:
apache-log4cxx-0.12.1\src\main\include\CMakeLists.txt
#if(WIN32)
# CHECK_INCLUDE_FILES(sqlext.h HAS_ODBC)
#else()
# include(FindPkgConfig)
#
# pkg_check_modules( odbc QUIET odbc )
# if(${odbc_FOUND})
# set(HAS_ODBC 1)
# endif(${odbc_FOUND})
#endif(WIN32)
-we use x64 Native Tools Command Prompt for VS 2019 (c++17)
cmake -S . -B build -G"Visual Studio 16 2019" -A x64
-DAPR_INCLUDE_DIR=path_to_apr\include\apr-1\
-DAPR_LIBRARIES=path_to_apr\lib\libapr-1.lib
-DAPR_UTIL_INCLUDE_DIR=path_to_apr-util\include\apr-1\
-DAPR_UTIL_LIBRARIES=path_to_apr-util\lib\libaprutil-1.lib
-DBUILD_TESTING=OFF -DEXPAT_LIBRARY=path_to_expat\lib\expat.lib
-DEXPAT_INCLUDE_DIR=path_to_expat\include
-open build/log4cxx.sln with VS 2019 and compile it in release mode x64 (with
Windows SDK Version 10.0.19041.0)
-copy from src/main/include all .h files to a different location
-copy from build/src/main/cpp/Release/ log4cxx dll and lib files to a different
location
-delete build folder
-in another x64 Native Tools Command Prompt for VS 2019
cmake -S . -B build -G"Visual Studio 16 2019" -A x64
-DBUILD_SHARED_LIBS=OFF -DAPR_INCLUDE_DIR=path_to_apr\include\apr-1\
-DAPR_LIBRARIES=path_to_apr\lib\libapr-1.lib
-DAPR_UTIL_INCLUDE_DIR=path_to_apr-util\include\apr-1\
-DAPR_UTIL_LIBRARIES=path_to_apr-util\lib\libaprutil-1.lib
-DBUILD_TESTING=OFF -DEXPAT_LIBRARY=path_to_expat\lib\expat.lib
-DEXPAT_INCLUDE_DIR=path_to_expat\include
-open build/log4cxx.sln with VS 2019 and compile it in release mode x64 (with
Windows SDK Version 10.0.19041.0 and Code Generation -> Runtime Library ->
Multi-threaded(/MT))
-copy build/src/main/cpp/Release/log4cxx.lib to a different location
When we try to compile a module which is using log4cxx code we get a stack full
of errors
generated from PATH_to_log4cxx_0.12.1\include\log4cxx/logger.h caused by
log4cxx::helpers::ObjectPtrT.
We saw that log4cxx.hw was not updated and we replaced all apparitions of
log4cxx::helpers::ObjectPtrT
with std::shared_ptr. With this we managed to get rid of all that errors,
but we have this stack of errors
generated directly from log4cxx code:
PATH_to_log4cxx_0.12.1\include\log4cxx/logger.h(105): error C2039:
'LoggerRepositoryWeakPtr': is not a member of 'log4cxx::spi'
PATH_to_log4cxx_0.12.1\include\log4cxx/logger.h(45): note: see declaration of
'log4cxx::spi'
PATH_to_log4cxx_0.12.1\include\log4cxx/logger.h(105): error C3646:
'repository': unknown override specifier
PATH_to_log4cxx_0.12.1\include\log4cxx/logger.h(105): error C4430: missing type
specifier - int assumed. Note: C++ does not support default-int
PATH_to_log4cxx_0.12.1\include\log4cxx/logger.h(626): error C2039:
'LoggerRepositoryWeakPtr': is not a member of 'log4cxx::spi'
PATH_to_log4cxx_0.12.1\include\log4cxx/logger.h(45): note: see declaration of
'log4cxx::spi'
PATH_to_log4cxx_0.12.1\include\log4cxx/logger.h(626): error C3646:
'getLoggerRepository': unknown override specifier
PATH_to_log4cxx_0.12.1\include\log4cxx/logger.h(626): error C2059: syntax
error: '('
PATH_to_log4cxx_0.12.1\include\log4cxx/logger.h(626): error C2238: unexpected
token(s) preceding ';'
PATH_to_log4cxx_0.12.1\include\log4cxx/logger.h(1467): error C2039:
'LoggerRepositoryWeakPtr': is not a member of 'log4cxx::spi'
PATH_to_log4cxx_0.12.1\include\log4cxx/logger.h(45): note: see declaration of
'log4cxx::spi'
PATH_to_log4cxx_0.12.1\include\log4cxx/logger.h(1467): error C2061: syntax
error: identifier 'LoggerRepositoryWeakPtr'
PATH_to_log4cxx_0.12.1\include\log4cxx/logger.h(1729): error C3646: 'mutex':
unknown override specifier
PATH_to_log4cxx_0.12.1\include\log4cxx/logger.h(1729): error C4430: missing
type specifier - int assumed. Note: C++ does not support default-int
PATH_to_log4cxx_0.12.1\include\log4cxx/appenderskeleton.h(77): error C2039:
'shared_mutex': is not a member of 'log4cxx'
PATH_to_log4cxx_0.12.1\include\log4cxx/appenderskeleton.h(35):
