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 <[email protected]> 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 > <[email protected]>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 <[email protected]> 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 <[email protected] >> > 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 <[email protected]> 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 <[email protected]>
