Just letting you know I did NOT read your email beyond the first 2 paragraphs. It is just way too long. Please summarize if you have something important to say.
Ralph > On Aug 16, 2015, at 1:29 AM, Xen <x...@dds.nl> wrote: > > Op 15-8-2015 om 17:36 schreef Gary Gregory: > >> I think we are also in limbo so to speak as to what to do WRT providing a >> programmatic interface for configuration. We have factory methods, a few >> builder classes, but probably not a clear road map. We all need to think >> about the big picture before we continue sprinkling builder classes all over >> the place. >> >> Should such an API be part of the Core or a new log4j-config module where >> all configuration code would sit? We probably still do not want it as part >> of the public API? Should the config API aim to configure the Core or any >> supported logging back-end? Surely we would only start with the Core and >> worry about the rest later. Or should we? I'm asking a lot of questions I >> know. >> >> How do we even discuss this via emails? That's a lot of writing! Is there >> are better way to discuss this instead? >> >> Gary > > Actually first thing I think additional builder classes can't hurt really > because they don't really change the API in any way except by creating a > convenience that Core-modifiers can use and there is very little chance at > this point of them needing to be removed again. > > Also removing them can't be hard unless they have been in there for a while > and code has been built against it. What of course the "public API" sees to > avoid. > > But which it of course doesn't do, maybe for the majority of corporate users, > but certainly not for people like me. (I read a wildly megalomanous advert > for a software developer today that basically required perfect programming > skills from knowing every important language to being "fluid in cross-browser > issues" to being wonderfully communicative to taking pride in writing > /standards-compliant code/.). Well if standards-complicance is not using the > Core API directly, then maybe everything you've said and done is true ;-). > > Seriously. > > Anyway. The questions. > > From what I /see/ happening is that there is going to be some effort in > having a nicer interface that does not really need to use individual > builders. On the other hand I don't know why other code shouldn't use it but > if you derive fields/inputs/values from a config file, then maybe calling > individual builder methods is not useful and a create method is better > suited. I generally think at this point that you should leave that like > that. > > So programmatic control, me being a layman, depends on two things: > > - would it really be something that the core developers want? In that case > the error message from not having a config file should leave/depart. If > config files stop being fully completely totally solely centric, then the > initialization code (this is just ConfigurationFactory.java) should not give > an error, however it could still be a warning an info or even a debug, as > they don't make it through to the StatusLogger in the default config. So the > obvious first thing to do is to supply a patch to change that ERROR level to > WARN. > > - at that point you are really 'bug' free to do either XML/JSON/whatever > config, or programmatic config. The second thing that is important then is > whether you want to keep focussing solely on ConfigurationFactories or > whether you want an application to be able to for instance create some > personal Logging.init() method or whatever to initialize the system > programmatically. The difference is at that point: do we SubClass a > ConfigurationFactory (and craft a configuration in it using programmatic > control) or do we SubClass a ConfigurationFactory as well as an > AbstractConfiguration that will then use programmatic control (or even other > means) inside its constructor/initializer, or do we agree or find outselves > in agreement with just using a DefaultConfiguration as it is returned and > adjusting that?. > > Those are three different levels of involvement. > > 1. Free to use the API from the outside. > 2. Need to subclass a factory to do it from within (as if you are part of the > core yourself now) > 3. Need to subclass a factory and even create a new /type/ of configuration > (as if you are really deeply mired into the core now). > > Currently my program that I haven't worked on for days now ;-)... > > Has just created its own package ( .log ) with a class (Logging) that does > everything I need to do configuration wise. At that point, for instance, I am > at the choice of whether to stay outside as much as I can, or to let myself > be absorbed into Core by subclassing a factory. Currently my .log package > does have a factory but it is to avoid the ERROR level message for not having > a configuration file. > > Customizing something really requires staying outside as you deal with the > system, because otherwise you ar really writing a form of plugin and you are > extending the system just as a way of configuring it. > > I don't know about the Configurator I must say, it didn't or doesn't seem to > do (mostly didn't) the things I wanted from it / from the system. > > Now of course the endeavour by that can't remember his name to create a > ConfigurationBuilder would fit probably the mark of extending the system in > order that another won't have to do it anymore. > > But you have to make these two choices, I can't do it for you: > > 1. Do you want programmatic configuration to be an equivalent or > near-equivalent to config-file based control? > 2. Do you want it to be an interface-only element (outside access to > configuration methods) a core element that requires factory substantiation or > a core element that requires factory substantiation and configuration > descendent substantiation?. > > I think the rest of your choices will follow automatically once you've made > these choices and become clear on them. I cannot really say anything about it > because my preferences are already known and I like to deal with an interface > only, and this was the original goal of the public / separatist API. I am > currently actually doing the first of these three things, and so I answer > these two questions with a "yes" and a "the first". > > But the rest is up to you, you have to decide, I can't work with you if you > don't because it will be up in the air and you will do something random. > > Regards... > > B.
