You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Paul Benedict <pb...@apache.org> on 2014/04/14 18:32:39 UTC
How good is log4j2 at variable management?
Asking the developers here...
One thing I would like to accomplish is to use the same log4j config file
for different appservers. Unfortunately, each appserver has a different
logging root variable (${catalina.home} = Tomcat, ${jboss.server.log.dir} =
JBoss, etc.).
One way to solve this is to make sure all variable names are extracted from
a map. For example, JEE provides an ELResolver that provides an interface
to get the variable values.
If log4j had such an interface (does it?), then it would be possible to
allow a pre-processor to run before parsing the configuration file and
insert new variables as appropriate. In my example, I would probably inject
a "logRoot" variable and set to it the appropriate location based on what
kind of appeserver is running.
What do you guys think?
[1] http://docs.oracle.com/javaee/5/api/javax/el/ELResolver.html
--
Cheers,
Paul
Re: How good is log4j2 at variable management?
Posted by Matt Sicker <bo...@gmail.com>.
Take a look at the other StrLookup implementations. One that uses
ELResolver sounds pretty neat to be honest.
On 14 April 2014 16:08, Paul Benedict <pb...@apache.org> wrote:
> If I am understanding you correctly, all I have to do is write a new class
> that implements StrLookup and annotate it with @Plugin?
>
>
> On Mon, Apr 14, 2014 at 2:01 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>
>> The Interpolator class manages variables. During configuration you can
>> currently use the system properties, environment variables, thread context,
>> date and jndi lookups. In addition, if you are running in a web container
>> the web lookup is also used. You can programmatically add variables to any
>> one of these and they will be picked up by Log4j 2. In addition, any
>> custom lookups you may add will be added to the list of available lookups
>> and can be used in the configuration once the configuration element has
>> completed processing its attributes and so can be used in all the “normal”
>> configuration elements.
>>
>> Ralph
>>
>> On Apr 14, 2014, at 10:35 AM, Paul Benedict <pb...@apache.org> wrote:
>>
>> No, but I am not sure this what I am looking for either. I am looking for
>> the programmatic injection of properties; I can't accomplish this using a
>> declarative approach. I want a class to be called by log4j at startup.
>>
>>
>> On Mon, Apr 14, 2014 at 12:15 PM, Ralph Goers <ralph.goers@dslextreme.com
>> > wrote:
>>
>>> Have you looked at
>>> http://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution
>>> ?
>>>
>>> Ralph
>>>
>>>
>>> On Apr 14, 2014, at 9:32 AM, Paul Benedict <pb...@apache.org> wrote:
>>>
>>> Asking the developers here...
>>>
>>> One thing I would like to accomplish is to use the same log4j config
>>> file for different appservers. Unfortunately, each appserver has a
>>> different logging root variable (${catalina.home} = Tomcat,
>>> ${jboss.server.log.dir} = JBoss, etc.).
>>>
>>> One way to solve this is to make sure all variable names are extracted
>>> from a map. For example, JEE provides an ELResolver that provides an
>>> interface to get the variable values.
>>>
>>> If log4j had such an interface (does it?), then it would be possible to
>>> allow a pre-processor to run before parsing the configuration file and
>>> insert new variables as appropriate. In my example, I would probably inject
>>> a "logRoot" variable and set to it the appropriate location based on what
>>> kind of appeserver is running.
>>>
>>> What do you guys think?
>>>
>>>
>>> [1] http://docs.oracle.com/javaee/5/api/javax/el/ELResolver.html
>>>
>>> --
>>> Cheers,
>>> Paul
>>>
>>>
>>>
>>
>>
>> --
>> Cheers,
>> Paul
>>
>>
>>
>
>
> --
> Cheers,
> Paul
>
--
Matt Sicker <bo...@gmail.com>
Re: How good is log4j2 at variable management?
Posted by Paul Benedict <pb...@apache.org>.
If I am understanding you correctly, all I have to do is write a new class
that implements StrLookup and annotate it with @Plugin?
On Mon, Apr 14, 2014 at 2:01 PM, Ralph Goers <ra...@dslextreme.com>wrote:
> The Interpolator class manages variables. During configuration you can
> currently use the system properties, environment variables, thread context,
> date and jndi lookups. In addition, if you are running in a web container
> the web lookup is also used. You can programmatically add variables to any
> one of these and they will be picked up by Log4j 2. In addition, any
> custom lookups you may add will be added to the list of available lookups
> and can be used in the configuration once the configuration element has
> completed processing its attributes and so can be used in all the “normal”
> configuration elements.
>
> Ralph
>
> On Apr 14, 2014, at 10:35 AM, Paul Benedict <pb...@apache.org> wrote:
>
> No, but I am not sure this what I am looking for either. I am looking for
> the programmatic injection of properties; I can't accomplish this using a
> declarative approach. I want a class to be called by log4j at startup.
>
>
> On Mon, Apr 14, 2014 at 12:15 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>
>> Have you looked at
>> http://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution
>> ?
>>
>> Ralph
>>
>>
>> On Apr 14, 2014, at 9:32 AM, Paul Benedict <pb...@apache.org> wrote:
>>
>> Asking the developers here...
>>
>> One thing I would like to accomplish is to use the same log4j config file
>> for different appservers. Unfortunately, each appserver has a different
>> logging root variable (${catalina.home} = Tomcat, ${jboss.server.log.dir} =
>> JBoss, etc.).
>>
>> One way to solve this is to make sure all variable names are extracted
>> from a map. For example, JEE provides an ELResolver that provides an
>> interface to get the variable values.
>>
>> If log4j had such an interface (does it?), then it would be possible to
>> allow a pre-processor to run before parsing the configuration file and
>> insert new variables as appropriate. In my example, I would probably inject
>> a "logRoot" variable and set to it the appropriate location based on what
>> kind of appeserver is running.
>>
>> What do you guys think?
>>
>>
>> [1] http://docs.oracle.com/javaee/5/api/javax/el/ELResolver.html
>>
>> --
>> Cheers,
>> Paul
>>
>>
>>
>
>
> --
> Cheers,
> Paul
>
>
>
--
Cheers,
Paul
Re: How good is log4j2 at variable management?
Posted by Ralph Goers <ra...@dslextreme.com>.
The Interpolator class manages variables. During configuration you can currently use the system properties, environment variables, thread context, date and jndi lookups. In addition, if you are running in a web container the web lookup is also used. You can programmatically add variables to any one of these and they will be picked up by Log4j 2. In addition, any custom lookups you may add will be added to the list of available lookups and can be used in the configuration once the configuration element has completed processing its attributes and so can be used in all the “normal” configuration elements.
Ralph
On Apr 14, 2014, at 10:35 AM, Paul Benedict <pb...@apache.org> wrote:
> No, but I am not sure this what I am looking for either. I am looking for the programmatic injection of properties; I can't accomplish this using a declarative approach. I want a class to be called by log4j at startup.
>
>
> On Mon, Apr 14, 2014 at 12:15 PM, Ralph Goers <ra...@dslextreme.com> wrote:
> Have you looked at http://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution?
>
> Ralph
>
>
> On Apr 14, 2014, at 9:32 AM, Paul Benedict <pb...@apache.org> wrote:
>
>> Asking the developers here...
>>
>> One thing I would like to accomplish is to use the same log4j config file for different appservers. Unfortunately, each appserver has a different logging root variable (${catalina.home} = Tomcat, ${jboss.server.log.dir} = JBoss, etc.).
>>
>> One way to solve this is to make sure all variable names are extracted from a map. For example, JEE provides an ELResolver that provides an interface to get the variable values.
>>
>> If log4j had such an interface (does it?), then it would be possible to allow a pre-processor to run before parsing the configuration file and insert new variables as appropriate. In my example, I would probably inject a "logRoot" variable and set to it the appropriate location based on what kind of appeserver is running.
>>
>> What do you guys think?
>>
>>
>> [1] http://docs.oracle.com/javaee/5/api/javax/el/ELResolver.html
>>
>> --
>> Cheers,
>> Paul
>
>
>
>
> --
> Cheers,
> Paul
Re: How good is log4j2 at variable management?
Posted by Paul Benedict <pb...@apache.org>.
No, but I am not sure this what I am looking for either. I am looking for
the programmatic injection of properties; I can't accomplish this using a
declarative approach. I want a class to be called by log4j at startup.
On Mon, Apr 14, 2014 at 12:15 PM, Ralph Goers <ra...@dslextreme.com>wrote:
> Have you looked at
> http://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution
> ?
>
> Ralph
>
>
> On Apr 14, 2014, at 9:32 AM, Paul Benedict <pb...@apache.org> wrote:
>
> Asking the developers here...
>
> One thing I would like to accomplish is to use the same log4j config file
> for different appservers. Unfortunately, each appserver has a different
> logging root variable (${catalina.home} = Tomcat, ${jboss.server.log.dir} =
> JBoss, etc.).
>
> One way to solve this is to make sure all variable names are extracted
> from a map. For example, JEE provides an ELResolver that provides an
> interface to get the variable values.
>
> If log4j had such an interface (does it?), then it would be possible to
> allow a pre-processor to run before parsing the configuration file and
> insert new variables as appropriate. In my example, I would probably inject
> a "logRoot" variable and set to it the appropriate location based on what
> kind of appeserver is running.
>
> What do you guys think?
>
>
> [1] http://docs.oracle.com/javaee/5/api/javax/el/ELResolver.html
>
> --
> Cheers,
> Paul
>
>
>
--
Cheers,
Paul
Re: How good is log4j2 at variable management?
Posted by Ralph Goers <ra...@dslextreme.com>.
Have you looked at http://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution?
Ralph
On Apr 14, 2014, at 9:32 AM, Paul Benedict <pb...@apache.org> wrote:
> Asking the developers here...
>
> One thing I would like to accomplish is to use the same log4j config file for different appservers. Unfortunately, each appserver has a different logging root variable (${catalina.home} = Tomcat, ${jboss.server.log.dir} = JBoss, etc.).
>
> One way to solve this is to make sure all variable names are extracted from a map. For example, JEE provides an ELResolver that provides an interface to get the variable values.
>
> If log4j had such an interface (does it?), then it would be possible to allow a pre-processor to run before parsing the configuration file and insert new variables as appropriate. In my example, I would probably inject a "logRoot" variable and set to it the appropriate location based on what kind of appeserver is running.
>
> What do you guys think?
>
>
> [1] http://docs.oracle.com/javaee/5/api/javax/el/ELResolver.html
>
> --
> Cheers,
> Paul