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.
