logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: Version 2 outreach?
Date Mon, 17 Aug 2015 10:09:39 GMT
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.


> On Aug 16, 2015, at 1:29 AM, Xen <xen@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
> 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. 

View raw message