AW: Communcating An Own Properties-Object To log4j As Substtution For System-Properties
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
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
