[
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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
