To propose some concrete idea then.
A plugin or extension that would allow programmatic control/config would
have to do at least two things:
- provide a Factory that plugs into core and that enables the easier
control/config.
- provide a Configuration that embodies this.
- provide an interface to both that makes it "public API"
Picture:
http://www.xen.dds.nl/f/i/diagrams/log4j-coreplug1.png
Lol that took me about an hour and a half to construct that picture with
my leet Inkscape skills and no mouse.
Maybe even two hours.
Just so that your precious time won't be wasted in having to read
something unattractive.
I hope you get the idea. There should be a plugin to the core that
enables an interface for the public in which public configuration is
possible. Meaning, the plugin should extend the "API" (I call it
"interface" in the image because API has a different meaning with you).
Since your public API is rather strictly defined, this is hard.
An official Configuration/Builder thing (there could be multiple) would
provide a programming interface that might differ from one version
(offering) to another but would all the same provide elements such that:
- there are methods to construct the configuration
- there is a method to retrieve the configuration builder interface itself
- the same interface/class that yielded the configuration builder to
you, has a method to take what you created with it and put it in place
- this is akin to switching a configuration.
I think those are the essentials.
CustomConfigurationBuilder ccb = CustomConfigurationBuilder.newInstance();
ccb.doStuff();
CCB.setConfiguration( ccb.build() );
or
CustomConfigurationBuilder ccb = CustomConfigurationBuilder.newInstance();
ccb.doStuff();
CCB.install( ccb );
but you have factories
CustomConfigurationFactory ccf = CustomConfigurationFactory.newInstance();
ccf.doStuff();
LogManager.setFactory (ccf); // ugly.
or
CustomConfigurationFactory ccf = CustomConfigurationFactory.newInstance();
CustomConfigurationBuilder ccb = ccf.newBuilder();
ccb.doStuff();
ccf.install( ccb );
LogManager.setFactory( ccf ); // better.
or
CustomConfigurationFactory ccf = CustomConfigurationFactory.newInstance();
CustomConfigurationBuilder ccb = ccf.getBuilder();
ccb.doStuff();
ccf.useBuilder();
LogManager.setFactory( ccf ); // dunno
Ideally you can retrieve the configuration yourself because you might
want to keep multiple copies around:
CustomConfigurationBuilder ccb = CCB.newInstance();
Configuration conf = ccb.doStuff().doStuff().doStuff().build();
CustomConfigurationFactory ccf = new CCF();
ccf.setConfiguration( conf );
LogManager.setFactory( ccf );
later on:
CustomConfigurationBuilder ccb = CCB.newInstance();
Configuration conf2 = ccb.doStuff().doStuff().doStuff().build();
loggerContext.setConfiguration( conf2 ); /// does not exist.
It's all weird.
Question: (I'll put a Jira for this) :
https://issues.apache.org/jira/browse/LOG4J2-1095
Check the attached image. Image:
https://issues.apache.org/jira/secure/attachment/12750883/12750883_log4j-xen-configurationbuilder-uml.jpg
I think our ConfigurationBuilder should build a Specification, the
Specification is fed to the Factory, and the Factory is fed to the
system but it can also reward a direct Configuration.
The specification should be in manual hands.
Other than that the system is perfect I think. Comments on the Jira.
Regards, B.
ccf.doStuff();
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
