logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Xen <...@dds.nl>
Subject Suggestion for factory extension for programmatic contol (idea)
Date Mon, 17 Aug 2015 19:51:48 GMT
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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message