Here is the same message with two paragraphs taken out that are numbered
and that you would have seen had you scrolled down:
You need to determine what level of involvement is required for anyone
doing programmatic customization:
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).
You have two choices to make:
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?.
The second choice refers to the first three points.
So the summary of the cut-out summary is:
a. Do you even want real programmatic configuration
b. If you do, do you want it to be as an interface-only thing, as a
core-thing that requires Factory subclassing, or as a core-thing that
requires Factory and Configuration subclassing.
And the summary of that is:
/You must make a principle decisions about these areas if you wish to
continue in any clear way and know what you have to do beyond this point.
/At least that is my belief. Bye, and see ya.
Op 17-8-2015 om 12:09 schreef Ralph Goers:
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 <mailto: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.
