[ https://issues.apache.org/jira/browse/LOG4J2-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700789#comment-14700789 ]
Bart S. commented on LOG4J2-1095: --------------------------------- I feel embarassed having used that wonderful software (UML Designer) -- It seems I am not worth something like that, and it's free even :p. > 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 (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