logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bart S. (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-1095) How can we have multiple Configurations?
Date Tue, 18 Aug 2015 20:33:45 GMT

    [ https://issues.apache.org/jira/browse/LOG4J2-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14701939#comment-14701939

Bart S. commented on LOG4J2-1095:

It feels as though granting support to all of the possible classes (appenders, filters, layouts)
is a rather daunting task.

Any filter appears to have at least this config tuple (name, type, match, mismatch)

But appenders have wildly varying required attributes. It is hard to find consistency beyond
(name, type) -- there are no mandatory parameters that are the same for every appender. Layouts
also do not have common consistent attributes.

This means either you need to add all of them as a (name, attribute, value) tuple or even
separated by type (if you don't want unique names across the board).

After that you require a 'construction' method that will read every value for every known
attribute and feed them to the create..... methods.

For things that have a lot of attributes this becomes rather daunting, even to configure it
as a user.

If you do without local variable keeping and also without composition, it means a lot of calls
that reference the name of the item giving an attribute to.

I don't really know what to make of that. I still prefer flat-level string-based relationship
mapping at this point.

> How can we have multiple Configurations?
> ----------------------------------------
>                 Key: LOG4J2-1095
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1095
>             Project: Log4j 2
>          Issue Type: Brainstorming
>          Components: Configurators
>    Affects Versions: 2.4
>            Reporter: Bart S.
>              Labels: features
>             Fix For: 2.4
>         Attachments: log4j-xen-configurationbuilder-uml.jpg
> So the question is how can a user maintain multiple configurations that he can then establish
or activate at will.
> The idea is to break away from using files as the only case, to both using files and
using custom programmatic control, as both special cases of configuration.
> While thinking of it I created an UML diagram:
> !log4j-xen-configurationbuilder-uml.jpg!
> I believe this should be the setup. Our new Factory can be fed a Specification instead
of a ConfigurationSource/file location.
> That would make these two sources equivalent.
> Programmatically what you might get is:
> {code}
> Specification a1 = SpecificationBuilder.newInstance()
>     .addAppender(....)
>     .addConfig(...)
>     .addTo(..., ....)
>     .build();
> Specification a2 = SpecificationBuilder.newInstance()
>     .addAppender(....)
>     .addConfig(...)
>     .addTo(..., ....)
>     .build();
> Configuration c1 =
>     CustomConfigurationFactory.getInstance().getConfiguration( a1 );
> Configuration c2 =
>     CustomConfigurationFactory.getInstance().getConfiguration( a2 );
> {code}
> Or alternatively
> {code}
> CustomConfigurationFactory ccf = CustomConfigurationFactory.getInstance();
> ccf.setSpecification( a1 );
> LogManager.setFactory( ccf );
> {code}
> The Factory only needs to be given to the system because the system wants to do static
initialisation at some point in the beginning. After that setting a new configuration should
not require the factory, but indeed be something directly:
> {{Configurator.setConfiguration(Configuration)}}
> or
> {{LoggerContext.set/start/update(Configuration)}}
> It is unclear to me how a new configuration can be fed to the context. There are two
methods that might work: updateLoggers and start.
> I believe there can be mutlple contexts; if there are or could be indeed multiple contexts
in a logging system, then it becomes adamant to give the Configuration to the right one; in
other cases I don't really know what {{initialize()}} does, in fact it _returns_ a LoggerContext.
It would seem required to use this LoggerContext to change the current configuration?

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message