[
https://issues.apache.org/jira/browse/LOG4J2-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15259577#comment-15259577
]
Ralph Goers commented on LOG4J2-1095:
-------------------------------------
Do we still need this issue? It would seem to me that the ConfigurationBuilder
and CompositeConfiguration capture this. If not, I am not really sure what
would be needed.
> 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
> 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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
