[prev in list] [next in list] [prev in thread] [next in thread] 

List:       log4j-dev
Subject:    [jira] [Commented] (LOG4J2-1095) How can we have multiple Configurations?
From:       "Ralph Goers (JIRA)" <jira () apache ! org>
Date:       2016-04-27 5:25:13
Message-ID: JIRA.12856707.1439838436000.43247.1461734713001 () Atlassian ! JIRA
[Download RAW message or body]


    [ 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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]