Hi Jake, Yes, sorry, I probably hoped to find somehow a solution by configuration. Your way seems to be the only one, so I'll go for it, even though I probably need to ask for the particular class the appender belongs to.
Thanks Malte -----Ursprüngliche Nachricht----- Von: Jacob Kjome [mailto:h...@visi.com] Gesendet: Freitag, 16. November 2012 19:51 An: Log4J Users List Betreff: Re: Communcating An Own Properties-Object To log4j As Substtution For System-Properties I have to say, I'm very confused as to exactly what you are asking. I told you how you can configure using custom properties without resorting to system properties. You said I was missing the point even though, after re-reading, I believe the answer I provided directly addressed your question. I then told you how you can directly reconfigure an appender, along with one example of how you can get a handle on an appender (there are others - read the API docs). You responded saying that this example, somehow, reflected a of lack of flexibility in Log4j. I'm at a loss. Please restate what it is that you are aiming at here, because I cannot figure it out. Jake On Fri, 16 Nov 2012 19:23:34 +0100 <malte.kem...@de.equens.com> wrote: > > 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 >>> 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 >>>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 >>> * >>> 2012-11-15 09:33:52,766 INFO >>> ***************************************** >>> 2012-11-15 09:33:52,766 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,766 INFO using >>>'xsdError\x.C0100.MCP.SAG.SWIFT-MAX.AC.20121106.090006.000.TXT.pacs08. >>>xm >>> l' as Input-File >>> 2012-11-15 09:33:52,781 INFO >>> >>>"xsdError\x.C0100.MCP.SAG.SWIFT-MAX.AC.20121106.090006.000.TXT.pacs08. >>>xm >>> l" is valid. >>> 2012-11-15 09:33:52,781 INFO >>> ***************************************** >>> 2012-11-15 09:33:52,781 INFO * XSD-Checker V 1.0 >>> * >>> 2012-11-15 09:33:52,797 INFO >>> ***************************************** >>> 2012-11-15 09:33:52,797 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,797 INFO using >>>'xsdError\x.C0100.MCP.SAG.SWIFT-MAX.AC.20121106.120001.000.TXT.pacs08. >>>xm >>> l' as Input-File >>> 2012-11-15 09:33:52,813 INFO >>> >>>"xsdError\x.C0100.MCP.SAG.SWIFT-MAX.AC.20121106.120001.000.TXT.pacs08. >>>xm >>> l" is valid. >>> >>> >>> here the content was filled obviously in the log-file of the >>>last File beeing processed, instead of puting them to each log, that >>>has already been produced. >>> >>> Please find attached the source code of the appender and >>>dependings (*.java) , the configuration(log4j.xml), and an example of >>>the logging of log4j itself (log4j-log-log). >>> I am using log4j version log4j-1.2.15.jar >>> >>> >>> Best regards and thanks for any hints in advance >>> >>> Malte >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: >>> log4j-user-unsubscr...@logging.apache.org >>> For additional commands, e-mail: >>> log4j-user-h...@logging.apache.org >>> >>> >>> >>> >>> >>> -- >>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in >>>Action, 2nd Ed: <http://goog_1249600977 <http://goog_1249600977> > >>>http://bit.ly/ECvg0 <http://bit.ly/ECvg0> Spring Batch in Action: >>><http://s.apache.org/HOq <http://s.apache.org/HOq> > >>>http://bit.ly/bqpbCK <http://bit.ly/bqpbCK> >>> Blog: http://garygregory.wordpress.com >>><http://garygregory.wordpress.com> >>> <http://garygregory.wordpress.com/ >>><http://garygregory.wordpress.com/> > >>> Home: http://garygregory.com/ <http://garygregory.com/> Tweet! >>>http://twitter.com/GaryGregory <http://twitter.com/GaryGregory> >>> >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org >>For additional commands, e-mail: log4j-user-h...@logging.apache.org >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org >>For additional commands, e-mail: log4j-user-h...@logging.apache.org >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org >For additional commands, e-mail: log4j-user-h...@logging.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org >For additional commands, e-mail: log4j-user-h...@logging.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
