Re: Flume-Appender
Hi, i solved the problem. The Error: Exception in thread main java.lang.NullPointerException at org.apache.logging.log4j.core. config.plugins.PluginManager.collectPlugins(PluginManager.java:154) at org.apache.logging.log4j.core.config.plugins.PluginManager.collectPlugins(PluginManager.java:125) at org.apache.logging.log4j.core.pattern.PatternParser.init(PatternParser.java:107) at org.apache.logging.log4j.core.layout.PatternLayout.createPatternParser(PatternLayout.java:156) at org.apache.logging.log4j.core.layout.PatternLayout.init(PatternLayout.java:109) at org.apache.logging.log4j.core.layout.PatternLayout.createLayout(PatternLayout.java:193) at org.apache.logging.log4j.core.config.DefaultConfiguration.init(DefaultConfiguration.java:48) at org.apache.logging.log4j.core.LoggerContext.init(LoggerContext.java:49) at org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.locateContext(ClassLoaderContextSelector.java:161) at org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:104) at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:73) at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:30) at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:138) at de.simo.Log4j2FlumeEmbedded.main(Log4j2FlumeEmbedded.java:22) The problem: I import the dependencies log4j-core and log4j-flume-ng. Both have their own /org/apache/logging/log4j/core/config/plugins/Log4j2Plugins.dat. And i exported my project to run it on another system (eclipse, file-export-runnable jar). Then i chose the wrong library handling. You have to choose Package required libraries into generated JAR. Otherwise (Extract required...) eclipse found two Log4j2Plugins.dat and ignore the other one, but you need both of them. One required for core-appender and the other for flume-ng-appender. Sooo, it was my fault ;) Regards, Simon 2012/11/14 Ralph Goers ralph.go...@dslextreme.com This doesn't look like it has anything to do with the Flume Appender. Can you attach the jar, configuration and instructions and the source to a new Jira issue? Thanks. Ralph On Nov 14, 2012, at 2:54 AM, Simon Monecke wrote: Hi Ralph, thank you for your response, but now i have another problem. i have these dependencies: dependency groupIdorg.apache.logging.log4j/groupId artifactIdlog4j-api/artifactId version2.0-beta2/version /dependency dependency groupIdorg.apache.logging.log4j/groupId artifactIdlog4j-core/artifactId version2.0-beta2/version /dependency dependency groupIdorg.apache.logging.log4j/groupId artifactIdlog4j-flume-ng/artifactId version2.0-alpha2/version exclusions exclusion artifactIdslf4j-impl/artifactId groupIdorg.apache.logging.log4j/groupId /exclusion /exclusions /dependency dependency groupIdorg.apache.logging.log4j.adapters/groupId artifactIdslf4j-impl/artifactId version2.0-beta2/version /dependency dependency groupIdorg.apache.logging.log4j.adapters/groupId artifactIdlog4j12-api/artifactId version2.0-beta2/version /dependency dependency groupIdorg.apache.flume/groupId artifactIdflume-ng-core/artifactId version${flumeVersion}/version exclusions exclusion groupIdorg.slf4j/groupId artifactIdslf4j-log4j12/artifactId /exclusion exclusion groupIdlog4j/groupId artifactIdlog4j/artifactId /exclusion /exclusions /dependency dependency groupIdorg.apache.flume/groupId artifactIdflume-ng-node/artifactId version${flumeVersion}/version exclusions exclusion groupIdorg.slf4j/groupId artifactIdslf4j-log4j12/artifactId /exclusion exclusion groupIdlog4j/groupId artifactIdlog4j/artifactId /exclusion /exclusions /dependency dependency groupIdorg.apache.flume.flume-ng-channels/groupId artifactIdflume-file-channel/artifactId version${flumeVersion}/version /dependency dependency groupIdorg.apache.hadoop/groupId artifactIdhadoop-core/artifactId version1.0.1/version /dependency dependency
Re: Flume-Appender
okay, now my logger can connect to the flume agent. But it cant send a message: ERROR Could not search jar file '' for classes matching criteria: annotated with @Plugin file not found Has anybody an idea? Regards, Simon 2012/11/16 Simon Monecke simonmone...@gmail.com Hi, i solved the problem. The Error: Exception in thread main java.lang.NullPointerException at org.apache.logging.log4j.core. config.plugins.PluginManager.collectPlugins(PluginManager.java:154) at org.apache.logging.log4j.core.config.plugins.PluginManager.collectPlugins(PluginManager.java:125) at org.apache.logging.log4j.core.pattern.PatternParser.init(PatternParser.java:107) at org.apache.logging.log4j.core.layout.PatternLayout.createPatternParser(PatternLayout.java:156) at org.apache.logging.log4j.core.layout.PatternLayout.init(PatternLayout.java:109) at org.apache.logging.log4j.core.layout.PatternLayout.createLayout(PatternLayout.java:193) at org.apache.logging.log4j.core.config.DefaultConfiguration.init(DefaultConfiguration.java:48) at org.apache.logging.log4j.core.LoggerContext.init(LoggerContext.java:49) at org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.locateContext(ClassLoaderContextSelector.java:161) at org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:104) at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:73) at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:30) at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:138) at de.simo.Log4j2FlumeEmbedded.main(Log4j2FlumeEmbedded.java:22) The problem: I import the dependencies log4j-core and log4j-flume-ng. Both have their own /org/apache/logging/log4j/core/config/plugins/Log4j2Plugins.dat. And i exported my project to run it on another system (eclipse, file-export-runnable jar). Then i chose the wrong library handling. You have to choose Package required libraries into generated JAR. Otherwise (Extract required...) eclipse found two Log4j2Plugins.dat and ignore the other one, but you need both of them. One required for core-appender and the other for flume-ng-appender. Sooo, it was my fault ;) Regards, Simon 2012/11/14 Ralph Goers ralph.go...@dslextreme.com This doesn't look like it has anything to do with the Flume Appender. Can you attach the jar, configuration and instructions and the source to a new Jira issue? Thanks. Ralph On Nov 14, 2012, at 2:54 AM, Simon Monecke wrote: Hi Ralph, thank you for your response, but now i have another problem. i have these dependencies: dependency groupIdorg.apache.logging.log4j/groupId artifactIdlog4j-api/artifactId version2.0-beta2/version /dependency dependency groupIdorg.apache.logging.log4j/groupId artifactIdlog4j-core/artifactId version2.0-beta2/version /dependency dependency groupIdorg.apache.logging.log4j/groupId artifactIdlog4j-flume-ng/artifactId version2.0-alpha2/version exclusions exclusion artifactIdslf4j-impl/artifactId groupIdorg.apache.logging.log4j/groupId /exclusion /exclusions /dependency dependency groupIdorg.apache.logging.log4j.adapters/groupId artifactIdslf4j-impl/artifactId version2.0-beta2/version /dependency dependency groupIdorg.apache.logging.log4j.adapters/groupId artifactIdlog4j12-api/artifactId version2.0-beta2/version /dependency dependency groupIdorg.apache.flume/groupId artifactIdflume-ng-core/artifactId version${flumeVersion}/version exclusions exclusion groupIdorg.slf4j/groupId artifactIdslf4j-log4j12/artifactId /exclusion exclusion groupIdlog4j/groupId artifactIdlog4j/artifactId /exclusion /exclusions /dependency dependency groupIdorg.apache.flume/groupId artifactIdflume-ng-node/artifactId version${flumeVersion}/version exclusions exclusion groupIdorg.slf4j/groupId artifactIdslf4j-log4j12/artifactId /exclusion exclusion groupIdlog4j/groupId artifactIdlog4j/artifactId /exclusion /exclusions /dependency dependency
AW: Funny Bbehaviour Wth A Customzed Appender
Hi Gary, finally I found the trouble. It got nothing to do with log4j itself. It is the stuff around my application, since I comuniate the input file names within Systemproperties, that are filled by one but not by the other application. The logger produces empty files for each, even though the other application not even running. I guess the cause of this is that I am using just one logging config for all my applcations. I probably could fix this behaviour by using for each application an own logger config. Inkow, using system properties is not the best choice, because they are global. That makes thread safety impossible. For a long term I should overthink the comunication of properties to my NamedFileAppender. Is there another way to build up a file name for the logging using things like input file names may be with appenders that are shiiped with log4j? Malte Von: Gary Gregory [mailto:garydgreg...@gmail.com] Gesendet: Donnerstag, 15. November 2012 18:03 An: Log4J Users List Betreff: Re: Funny Bbehaviour Wth A Customzed Appender Hi Malte, You should probably file a Bugzilla issue but I am not sure how much help you'll get here because you are using custom code. There you can attach all the files you want. Can this be reproduced in any way with a stock appender of any type like a rolling file appender? The best way to get anyone to help is to create a standalone program that illustrates the problem. Ideally, it should be a unit test that fails. Another question that will come up is, does using the current version, 1.2.17, work better? Differently? Gary On Thu, Nov 15, 2012 at 11:14 AM, malte.kem...@de.equens.com wrote: Hi to all, I have programmed an appender dirived from FileAppender, that is able to produce log-files with file names that you can controll in a more flexible way. You can use an other String, for example the input file, or parts of it to produce your desired log file name, seq-numbers and time stamps etc. My applcation, that got the log-config (actually the xml configuration type) is a mroe infratstuctional Programm, that calls other applications like converters. I have put all in one single log-configuration-file using the cusomized appender on several file processing applcations. The confguration is like this, that each processed file is suppose to produce one log file per application that is processing it. For one application it works pretty good. Ror another it produces each expected log file but produces the logs for all turns only in one file. The others stay empty. I am not sure what I am doing wrong and what is going on here. I cannot understand why in one case it works (s.FEDCONV...log) , in the other it does not at all (s. XSDCHECK...log). here the contend of the only filled XSDCHECK...log (XSDCHECK.x.C0100.MCP.SAG.SWIFT-MAX.AC.20121106.120001.000.TXT.log) 2012-11-15 09:33:52,594 INFO * 2012-11-15 09:33:52,594 INFO * XSD-Checker V 1.0 * 2012-11-15 09:33:52,594 INFO * 2012-11-15 09:33:52,610 INFO using 'C:\tmp\Neuer Ordner\FED-Local\filedemon-fed-test\xsds\pacs.008.001.01.xsd' as XSD-File 2012-11-15 09:33:52,610 INFO using 'xsdError\x.C0100.MCP.SAG.SWIFT-MAX.AC.20121106.120002.000.TXT.pacs08.xm l' as Input-File 2012-11-15 09:33:52,672 INFO xsdError\x.C0100.MCP.SAG.SWIFT-MAX.AC.20121106.120002.000.TXT.pacs08.xm l is valid. 2012-11-15 09:33:52,688 INFO * 2012-11-15 09:33:52,688 INFO * XSD-Checker V 1.0 * 2012-11-15 09:33:52,688 INFO * 2012-11-15 09:33:52,688 INFO using 'C:\tmp\Neuer Ordner\FED-Local\filedemon-fed-test\xsds\pacs.008.001.01.xsd' as XSD-File 2012-11-15 09:33:52,688 INFO using 'xsdError\x.C0100.MCP.SAG.SWIFT-MAX.AC.20121106.090004.000.TXT.pacs08.xm l' as Input-File 2012-11-15 09:33:52,719 INFO xsdError\x.C0100.MCP.SAG.SWIFT-MAX.AC.20121106.090004.000.TXT.pacs08.xm l is valid. 2012-11-15 09:33:52,719 INFO * 2012-11-15 09:33:52,719 INFO * XSD-Checker V 1.0 * 2012-11-15 09:33:52,735 INFO * 2012-11-15 09:33:52,735 INFO using 'C:\tmp\Neuer Ordner\FED-Local\filedemon-fed-test\xsds\pacs.008.001.01.xsd' as XSD-File 2012-11-15 09:33:52,735 INFO using 'xsdError\x.C0100.MCP.SAG.SWIFT-MAX.AC.20121106.090005.000.TXT.pacs08.xm l' as Input-File 2012-11-15 09:33:52,750 INFO xsdError\x.C0100.MCP.SAG.SWIFT-MAX.AC.20121106.090005.000.TXT.pacs08.xm l is valid. 2012-11-15 09:33:52,750 INFO * 2012-11-15 09:33:52,766 INFO * XSD-Checker V 1.0
Communcating An Own Properties-Object To log4j As Substtution For System-Properties
Hi to all (again), I just thought on theoretical level. My problem, using log4j in a mulithraded environment using Apender that create file names using property input could only work, if it is possible to give the appender (log4) An own properties-object, rahter than using the Systm-Properties. Is there a method, with that you are able to tell an apender to get an very own Properties-Object with out the need to change the configuration possibility using ${propertiesname} to address the partcular property? right now my appender configuration looks liek that: appender name=xsd-check class=de.cmk.log4j.NameComposingFileAppender param name=string4Construction value=${input.file.path}/param param name=inputRegex value=(.*)/param param name=file value=logs/[user.name]/XSDCHECK.(0).log /param param name=Append value=false / layout class=org.apache.log4j.PatternLayout param name=ConversionPattern value=%d{ISO8601} %-5p %m%n / /layout /appender I would like to tell the an appender, by using a log4j-method within a certian application init-time. Is there something like that or is something like that planned in a later version of log4j? (Is there any chance something like that would work at all?) thanks in advancs for any hints Malte -Ursprüngliche Nachricht- Von: malte.kem...@de.equens.com [mailto:malte.kem...@de.equens.com mailto:malte.kem...@de.equens.com ] Gesendet: Freitag, 16. November 2012 13:37 An: log4j-user@logging.apache.org Betreff: AW: Funny Bbehaviour Wth A Customzed Appender Hi Gary, finally I found the trouble. It got nothing to do with log4j itself. It is the stuff around my application, since I comuniate the input file names within Systemproperties, that are filled by one but not by the other application. The logger produces empty files for each, even though the other application not even running. I guess the cause of this is that I am using just one logging config for all my applcations. I probably could fix this behaviour by using for each application an own logger config. Inkow, using system properties is not the best choice, because they are global. That makes thread safety impossible. For a long term I should overthink the comunication of properties to my NamedFileAppender. Is there another way to build up a file name for the logging using things like input file names may be with appenders that are shiiped with log4j? Malte Von: Gary Gregory [mailto:garydgreg...@gmail.com mailto:garydgreg...@gmail.com ] Gesendet: Donnerstag, 15. November 2012 18:03 An: Log4J Users List Betreff: Re: Funny Bbehaviour Wth A Customzed Appender Hi Malte, You should probably file a Bugzilla issue but I am not sure how much help you'll get here because you are using custom code. There you can attach all the files you want. Can this be reproduced in any way with a stock appender of any type like a rolling file appender? The best way to get anyone to help is to create a standalone program that illustrates the problem. Ideally, it should be a unit test that fails. Another question that will come up is, does using the current version, 1.2.17, work better? Differently? Gary On Thu, Nov 15, 2012 at 11:14 AM, malte.kem...@de.equens.com wrote: Hi to all, I have programmed an appender dirived from FileAppender, that is able to produce log-files with file names that you can controll in a more flexible way. You can use an other String, for example the input file, or parts of it to produce your desired log file name, seq-numbers and time stamps etc. My applcation, that got the log-config (actually the xml configuration type) is a mroe infratstuctional Programm, that calls other applications like converters. I have put all in one single log-configuration-file using the cusomized appender on several file processing applcations. The confguration is like this, that each processed file is suppose to produce one log file per application that is processing it. For one application it works pretty good. Ror another it produces each expected log file but produces the logs for all turns only in one file. The others stay empty. I am not sure what I am doing wrong and what is going on here. I cannot understand why in one case it works (s.FEDCONV...log) , in the other it does not at all (s. XSDCHECK...log). here the contend of the only filled XSDCHECK...log (XSDCHECK.x.C0100.MCP.SAG.SWIFT-MAX.AC.20121106.120001.000.TXT.log) 2012-11-15 09:33:52,594 INFO * 2012-11-15 09:33:52,594 INFO * XSD-Checker V 1.0 * 2012-11-15 09:33:52,594 INFO * 2012-11-15 09:33:52,610 INFO using 'C:\tmp\Neuer
Re: Communcating An Own Properties-Object To log4j As Substtution For System-Properties
Well, you can manually bind properties at configuration time by loading the config as a properties object, adding more properties, and then calling configure(Properties) [1]. It's not clear to me how this might be done with XML configuration, thought I vaguely recall it being talked about in the past? [1] http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PropertyConfigurator.html#configure%28java.util.Properties%29 Jake On Fri, 16 Nov 2012 15:12:18 +0100 malte.kem...@de.equens.com wrote: Hi to all (again), I just thought on theoretical level. My problem, using log4j in a mulithraded environment using Apender that create file names using property input could only work, if it is possible to give the appender (log4) An own properties-object, rahter than using the Systm-Properties. Is there a method, with that you are able to tell an apender to get an very own Properties-Object with out the need to change the configuration possibility using ${propertiesname} to address the partcular property? right now my appender configuration looks liek that: appender name=xsd-check class=de.cmk.log4j.NameComposingFileAppender param name=string4Construction value=${input.file.path}/param param name=inputRegex value=(.*)/param param name=file value=logs/[user.name]/XSDCHECK.(0).log /param param name=Append value=false / layout class=org.apache.log4j.PatternLayout param name=ConversionPattern value=%d{ISO8601} %-5p %m%n / /layout /appender I would like to tell the an appender, by using a log4j-method within a certian application init-time. Is there something like that or is something like that planned in a later version of log4j? (Is there any chance something like that would work at all?) thanks in advancs for any hints Malte -Ursprüngliche Nachricht- Von: malte.kem...@de.equens.com [mailto:malte.kem...@de.equens.com mailto:malte.kem...@de.equens.com ] Gesendet: Freitag, 16. November 2012 13:37 An: log4j-user@logging.apache.org Betreff: AW: Funny Bbehaviour Wth A Customzed Appender Hi Gary, finally I found the trouble. It got nothing to do with log4j itself. It is the stuff around my application, since I comuniate the input file names within Systemproperties, that are filled by one but not by the other application. The logger produces empty files for each, even though the other application not even running. I guess the cause of this is that I am using just one logging config for all my applcations. I probably could fix this behaviour by using for each application an own logger config. Inkow, using system properties is not the best choice, because they are global. That makes thread safety impossible. For a long term I should overthink the comunication of properties to my NamedFileAppender. Is there another way to build up a file name for the logging using things like input file names may be with appenders that are shiiped with log4j? Malte Von: Gary Gregory [mailto:garydgreg...@gmail.com mailto:garydgreg...@gmail.com ] Gesendet: Donnerstag, 15. November 2012 18:03 An: Log4J Users List Betreff: Re: Funny Bbehaviour Wth A Customzed Appender Hi Malte, You should probably file a Bugzilla issue but I am not sure how much help you'll get here because you are using custom code. There you can attach all the files you want. Can this be reproduced in any way with a stock appender of any type like a rolling file appender? The best way to get anyone to help is to create a standalone program that illustrates the problem. Ideally, it should be a unit test that fails. Another question that will come up is, does using the current version, 1.2.17, work better? Differently? Gary On Thu, Nov 15, 2012 at 11:14 AM, malte.kem...@de.equens.com wrote: Hi to all, I have programmed an appender dirived from FileAppender, that is able to produce log-files with file names that you can controll in a more flexible way. You can use an other String, for example the input file, or parts of it to produce your desired log file name, seq-numbers and time stamps etc. My applcation, that got the log-config (actually the xml configuration type) is a mroe infratstuctional Programm, that calls other applications like converters. I have put all in one single log-configuration-file using the cusomized appender on several file processing applcations. The confguration is like this, that each processed file is suppose to produce one log file per application that is processing it. For one application it works pretty good. Ror another it produces each expected log file but produces the logs for all turns only in one file. The others stay empty. I am not sure what I am doing wrong and what is going on here. I cannot understand
AW: Communcating An Own Properties-Object To log4j As Substtution For System-Properties
Hi Jake, Thanks for the hint. But I am afraid that is not quite that what I ment. Looking at the example below there is the following line: param name=string4Construction value=${input.file.path}/param Here the parameter string4Construction gets a value from the SystemProperty input.file.path. So actually if the SystemProperty's value is MyInputFile.txt then the parameter string4Construction got exactly its value MyInputFile.txt. The syntax ${propertyname} is already built in somewhere of log4j, I think, which means that it will be looked at runtime on the System-Properties for getting the value of the property named here. If I knew where in the code of log4j that resolving takes place, I could may be understand how to manage it, to give dynamigly own Properties-ojects while run-time. Since there was no special code needed for inventing own parameters, but producing setter-methods in the customized appender, I believe log4j binds the parameters by reflection. Malte -Ursprüngliche Nachricht- Von: Jacob Kjome [mailto:h...@visi.com] Gesendet: Freitag, 16. November 2012 18:04 An: Log4J Users List Betreff: Re: Communcating An Own Properties-Object To log4j As Substtution For System-Properties Well, you can manually bind properties at configuration time by loading the config as a properties object, adding more properties, and then calling configure(Properties) [1]. It's not clear to me how this might be done with XML configuration, thought I vaguely recall it being talked about in the past? [1] http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PropertyConfigurator.html#configure%28java.util.Properties%29 Jake On Fri, 16 Nov 2012 15:12:18 +0100 malte.kem...@de.equens.com wrote: Hi to all (again), I just thought on theoretical level. My problem, using log4j in a mulithraded environment using Apender that create file names using property input could only work, if it is possible to give the appender (log4) An own properties-object, rahter than using the Systm-Properties. Is there a method, with that you are able to tell an apender to get an very own Properties-Object with out the need to change the configuration possibility using ${propertiesname} to address the partcular property? right now my appender configuration looks liek that: appender name=xsd-check class=de.cmk.log4j.NameComposingFileAppender param name=string4Construction value=${input.file.path}/param param name=inputRegex value=(.*)/param param name=file value=logs/[user.name]/XSDCHECK.(0).log /param param name=Append value=false / layout class=org.apache.log4j.PatternLayout param name=ConversionPattern value=%d{ISO8601} %-5p %m%n / /layout /appender I would like to tell the an appender, by using a log4j-method within a certian application init-time. Is there something like that or is something like that planned in a later version of log4j? (Is there any chance something like that would work at all?) thanks in advancs for any hints Malte -Ursprüngliche Nachricht- Von: malte.kem...@de.equens.com [mailto:malte.kem...@de.equens.com mailto:malte.kem...@de.equens.com ] Gesendet: Freitag, 16. November 2012 13:37 An: log4j-user@logging.apache.org Betreff: AW: Funny Bbehaviour Wth A Customzed Appender Hi Gary, finally I found the trouble. It got nothing to do with log4j itself. It is the stuff around my application, since I comuniate the input file names within Systemproperties, that are filled by one but not by the other application. The logger produces empty files for each, even though the other application not even running. I guess the cause of this is that I am using just one logging config for all my applcations. I probably could fix this behaviour by using for each application an own logger config. Inkow, using system properties is not the best choice, because they are global. That makes thread safety impossible. For a long term I should overthink the comunication of properties to my NamedFileAppender. Is there another way to build up a file name for the logging using things like input file names may be with appenders that are shiiped with log4j? Malte Von: Gary Gregory [mailto:garydgreg...@gmail.com mailto:garydgreg...@gmail.com ] Gesendet: Donnerstag, 15. November 2012 18:03 An: Log4J Users List Betreff: Re: Funny Bbehaviour Wth A Customzed Appender Hi Malte, You should probably file a Bugzilla issue but I am not sure how much help you'll get here because you are using custom code. There you can attach all the files you want. Can this be reproduced in any way with a stock appender of any type like a rolling file appender? The best way to get anyone to help is to create a standalone program that illustrates the problem. Ideally, it should be a unit test that fails.
Re: Communcating An Own Properties-Object To log4j As Substtution For System-Properties
Yes, but that file-based configuration is only read once, and the appender only sees the fully resolved value and does not maintain the ${propertyname} for dynamic runtime substitution. Even the solution I proposed only applies the one time. It just allows you to define local properties rather than depending on System properties set JVM-wide. You have to obtain an reference to the appender object and re-set its properties. This is most certainly doable. Just look up a logger that the appender is assigned to and use getAppender(appenderName). Then you can modify the appender to your heart's content. Jake On Fri, 16 Nov 2012 18:26:10 +0100 malte.kem...@de.equens.com wrote: Hi Jake, Thanks for the hint. But I am afraid that is not quite that what I ment. Looking at the example below there is the following line: param name=string4Construction value=${input.file.path}/param Here the parameter string4Construction gets a value from the SystemProperty input.file.path. So actually if the SystemProperty's value is MyInputFile.txt then the parameter string4Construction got exactly its value MyInputFile.txt. The syntax ${propertyname} is already built in somewhere of log4j, I think, which means that it will be looked at runtime on the System-Properties for getting the value of the property named here. If I knew where in the code of log4j that resolving takes place, I could may be understand how to manage it, to give dynamigly own Properties-ojects while run-time. Since there was no special code needed for inventing own parameters, but producing setter-methods in the customized appender, I believe log4j binds the parameters by reflection. Malte -Ursprüngliche Nachricht- Von: Jacob Kjome [mailto:h...@visi.com] Gesendet: Freitag, 16. November 2012 18:04 An: Log4J Users List Betreff: Re: Communcating An Own Properties-Object To log4j As Substtution For System-Properties Well, you can manually bind properties at configuration time by loading the config as a properties object, adding more properties, and then calling configure(Properties) [1]. It's not clear to me how this might be done with XML configuration, thought I vaguely recall it being talked about in the past? [1] http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PropertyConfigurator.html#configure%28java.util.Properties%29 Jake On Fri, 16 Nov 2012 15:12:18 +0100 malte.kem...@de.equens.com wrote: Hi to all (again), I just thought on theoretical level. My problem, using log4j in a mulithraded environment using Apender that create file names using property input could only work, if it is possible to give the appender (log4) An own properties-object, rahter than using the Systm-Properties. Is there a method, with that you are able to tell an apender to get an very own Properties-Object with out the need to change the configuration possibility using ${propertiesname} to address the partcular property? right now my appender configuration looks liek that: appender name=xsd-check class=de.cmk.log4j.NameComposingFileAppender param name=string4Construction value=${input.file.path}/param param name=inputRegex value=(.*)/param param name=file value=logs/[user.name]/XSDCHECK.(0).log /param param name=Append value=false / layout class=org.apache.log4j.PatternLayout param name=ConversionPattern value=%d{ISO8601} %-5p %m%n / /layout /appender I would like to tell the an appender, by using a log4j-method within a certian application init-time. Is there something like that or is something like that planned in a later version of log4j? (Is there any chance something like that would work at all?) thanks in advancs for any hints Malte -Ursprüngliche Nachricht- Von: malte.kem...@de.equens.com [mailto:malte.kem...@de.equens.com mailto:malte.kem...@de.equens.com ] Gesendet: Freitag, 16. November 2012 13:37 An: log4j-user@logging.apache.org Betreff: AW: Funny Bbehaviour Wth A Customzed Appender Hi Gary, finally I found the trouble. It got nothing to do with log4j itself. It is the stuff around my application, since I comuniate the input file names within Systemproperties, that are filled by one but not by the other application. The logger produces empty files for each, even though the other application not even running. I guess the cause of this is that I am using just one logging config for all my applcations. I probably could fix this behaviour by using for each application an own logger config. Inkow, using system properties is not the best choice, because they are global. That makes thread safety impossible. For a long term I should overthink the comunication of properties to my NamedFileAppender. Is there another way to build up a file name for the logging using things like input file names may be with appenders that are shiiped with log4j? Malte
AW: Communcating An Own Properties-Object To log4j As Substtution For System-Properties
Hi Jake, I see. But if the log4j-config is reloaded each time that application is called, the appender gets loaded with the current values of the Properties (actually System.properties). I ried that already. If I get the way of your sugesstion right, the application itselve would be supposed to code the configuration for a certan appender type. That is probably doable, but seems to me a bit contradictional to the ability to configure appenders of what kind ever. I mean why should an application know about what appender type and name is used in log4 configuration? I am afraid the logger then is loosing a lot of configuration flexibility, does'nt it? Malte -Ursprüngliche Nachricht- Von: Jacob Kjome [mailto:h...@visi.com] Gesendet: Freitag, 16. November 2012 18:54 An: Log4J Users List Betreff: Re: Communcating An Own Properties-Object To log4j As Substtution For System-Properties Yes, but that file-based configuration is only read once, and the appender only sees the fully resolved value and does not maintain the ${propertyname} for dynamic runtime substitution. Even the solution I proposed only applies the one time. It just allows you to define local properties rather than depending on System properties set JVM-wide. You have to obtain an reference to the appender object and re-set its properties. This is most certainly doable. Just look up a logger that the appender is assigned to and use getAppender(appenderName). Then you can modify the appender to your heart's content. Jake On Fri, 16 Nov 2012 18:26:10 +0100 malte.kem...@de.equens.com wrote: Hi Jake, Thanks for the hint. But I am afraid that is not quite that what I ment. Looking at the example below there is the following line: param name=string4Construction value=${input.file.path}/param Here the parameter string4Construction gets a value from the SystemProperty input.file.path. So actually if the SystemProperty's value is MyInputFile.txt then the parameter string4Construction got exactly its value MyInputFile.txt. The syntax ${propertyname} is already built in somewhere of log4j, I think, which means that it will be looked at runtime on the System-Properties for getting the value of the property named here. If I knew where in the code of log4j that resolving takes place, I could may be understand how to manage it, to give dynamigly own Properties-ojects while run-time. Since there was no special code needed for inventing own parameters, but producing setter-methods in the customized appender, I believe log4j binds the parameters by reflection. Malte -Ursprüngliche Nachricht- Von: Jacob Kjome [mailto:h...@visi.com] Gesendet: Freitag, 16. November 2012 18:04 An: Log4J Users List Betreff: Re: Communcating An Own Properties-Object To log4j As Substtution For System-Properties Well, you can manually bind properties at configuration time by loading the config as a properties object, adding more properties, and then calling configure(Properties) [1]. It's not clear to me how this might be done with XML configuration, thought I vaguely recall it being talked about in the past? [1] http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PropertyC onfigurator.html#configure%28java.util.Properties%29 Jake On Fri, 16 Nov 2012 15:12:18 +0100 malte.kem...@de.equens.com wrote: Hi to all (again), I just thought on theoretical level. My problem, using log4j in a mulithraded environment using Apender that create file names using property input could only work, if it is possible to give the appender (log4) An own properties-object, rahter than using the Systm-Properties. Is there a method, with that you are able to tell an apender to get an very own Properties-Object with out the need to change the configuration possibility using ${propertiesname} to address the partcular property? right now my appender configuration looks liek that: appender name=xsd-check class=de.cmk.log4j.NameComposingFileAppender param name=string4Construction value=${input.file.path}/param param name=inputRegex value=(.*)/param param name=file value=logs/[user.name]/XSDCHECK.(0).log /param param name=Append value=false / layout class=org.apache.log4j.PatternLayout param name=ConversionPattern value=%d{ISO8601} %-5p %m%n / /layout /appender I would like to tell the an appender, by using a log4j-method within a certian application init-time. Is there something like that or is something like that planned in a later version of log4j? (Is there any chance something like that would work at all?) thanks in advancs for any hints Malte -Ursprüngliche Nachricht- Von: malte.kem...@de.equens.com [mailto:malte.kem...@de.equens.com mailto:malte.kem...@de.equens.com ] Gesendet: Freitag, 16. November 2012 13:37 An: log4j-user@logging.apache.org