Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Developers List" <log4j-dev@logging.apache.org>
From: Ralph Goers <ralph.goers@dslextreme.com>
Content-Type: multipart/alternative;
	boundary=Apple-Mail-1BB6A609-EC47-45CA-978D-FFA763B4B057
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Subject: Re: Version 2 outreach?
Message-Id: <9ED608D4-8FF1-47FE-B5C0-3959A49E8581@dslextreme.com>
Date: Mon, 17 Aug 2015 03:09:39 -0700
References: 
 <CACZkXPzjR6b1GQOBbArbVBGXaoSQNnmsP5tGT85zJrKOjaqT6g@mail.gmail.com>
 <55CE656F.80005@dds.nl> <E5B3DF74-A7A7-4F00-8598-CDB340A4A687@dslextreme.com>
 <55CF24C1.3080201@dds.nl>
 <CACZkXPxQmRQz7zD54mwyFBQ0KTzr0h94h7M9nvcHh2OvPEE+Rg@mail.gmail.com>
 <55D049F5.2050305@dds.nl>
In-Reply-To: <55D049F5.2050305@dds.nl>
To: Log4J Developers List <log4j-dev@logging.apache.org>

--Apple-Mail-1BB6A609-EC47-45CA-978D-FFA763B4B057
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Just letting you know I did NOT read your email beyond the first 2 paragraph=
s. 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 <xen@dds.nl> wrote:
>=20
> Op 15-8-2015 om 17:36 schreef Gary Gregory:
>=20
>> 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 bu=
ilder 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 p=
lace.=20
>>=20
>> 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 o=
f the public API? Should the config API aim to configure the Core or any sup=
ported logging back-end? Surely we would only start with the Core and worry a=
bout the rest later. Or should we? I'm asking a lot of questions I know.
>>=20
>> How do we even discuss this via emails? That's a lot of writing! Is there=
 are better way to discuss this instead?
>>=20
>> Gary
>=20
> Actually first thing I think additional builder classes can't hurt really b=
ecause they don't really change the API in any way except by creating a conv=
enience that Core-modifiers can use and there is very little chance at this p=
oint of them needing to be removed again.
>=20
> Also removing them can't be hard unless they have been in there for a whil=
e and code has been built against it. What of course the "public API" sees t=
o avoid.
>=20
> But which it of course doesn't do, maybe for the majority of corporate use=
rs, but certainly not for people like me. (I read a wildly megalomanous adve=
rt for a software developer today that basically required perfect programmin=
g skills from knowing every important language to being "fluid in cross-brow=
ser issues" to being wonderfully communicative to taking pride in writing /s=
tandards-compliant code/.). Well if standards-complicance is not using the C=
ore API directly, then maybe everything you've said and done is true ;-).
>=20
> Seriously.
>=20
> Anyway. The questions.
>=20
> =46rom what I /see/ happening is that there is going to be some effort in h=
aving 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 d=
erive fields/inputs/values from a config file, then maybe calling individual=
 builder methods is not useful and a create method is better suited. I gener=
ally think at     this point that you should leave that like that.
>=20
> So programmatic control, me being a layman, depends on two things:
>=20
> - 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 con=
fig files stop being fully completely totally solely centric, then the initi=
alization code (this is just ConfigurationFactory.java) should not give an e=
rror, however it could still be a warning an info or even a debug, as they d=
on't make it through to the StatusLogger in the default config. So the obvio=
us first thing to do is to supply a patch to change that ERROR level to WARN=
.
>=20
> - at that point you are really 'bug' free to do either XML/JSON/whatever c=
onfig, or programmatic config. The second thing that is important then is wh=
ether you want to keep focussing solely on ConfigurationFactories or whether=
 you want an application to be able to for instance create some personal Log=
ging.init() method or whatever to initialize the system programmatically. Th=
e difference is at that point: do we SubClass a ConfigurationFactory (and cr=
aft a configuration in it using programmatic control) or do we SubClass a Co=
nfigurationFactory as well as an AbstractConfiguration that will then use pr=
ogrammatic control (or even other means) inside its constructor/initializer,=
 or do we agree or find outselves in agreement with just using a DefaultConf=
iguration as it is returned and adjusting that?.
>=20
> Those are three different levels of involvement.
>=20
> 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 t=
he core yourself now)
> 3. Need to subclass a factory and even create a new /type/ of configuratio=
n (as if you are really deeply mired into the core now).
>=20
> Currently my program that I haven't worked on for days now ;-)...
>=20
> 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 a=
m at the choice of whether to stay outside as much as I can, or to let mysel=
f be absorbed into Core by subclassing a factory. Currently my .log package d=
oes have a factory but it is to avoid the ERROR level message for not having=
 a configuration file.
>=20
> Customizing something really requires staying outside as you deal with the=
 system, because otherwise you ar really writing a form of plugin and you ar=
e extending the system just as a way of configuring it.
>=20
> I don't know about the Configurator I must say, it didn't or doesn't seem t=
o do (mostly didn't) the things I wanted from it / from the system.
>=20
> Now of course the endeavour by that can't remember his name to create a Co=
nfigurationBuilder would fit probably the mark of extending the system in or=
der that another won't have to do it anymore.
>=20
> But you have to make these two choices, I can't do it for you:
>=20
> 1. Do you want programmatic configuration to be an equivalent or near-equi=
valent to config-file based control?
> 2. Do you want it to be an interface-only element (outside access to confi=
guration methods) a core element that requires factory substantiation or a c=
ore element that requires factory substantiation and configuration descenden=
t substantiation?.
>=20
> I think the rest of your choices will follow automatically once you've mad=
e 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 inte=
rface 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 answe=
r these two questions with a "yes" and a "the first".
>=20
> But the rest is up to you, you have to decide, I can't work with you if yo=
u don't because it will be up in the air and you will do something random.
>=20
> Regards...
>=20
> B.=20

--Apple-Mail-1BB6A609-EC47-45CA-978D-FFA763B4B057
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>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.<br><br>Ralph</div><div><br>On Aug 16, 2015, at 1:29 AM, Xen &lt;<a href="mailto:xen@dds.nl">xen@dds.nl</a>&gt; wrote:<br><br></div><blockquote type="cite"><div>
  
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  
  
    Op 15-8-2015 om 17:36 schreef Gary Gregory:<br>
    <br>
    <blockquote cite="mid:CACZkXPxQmRQz7zD54mwyFBQ0KTzr0h94h7M9nvcHh2OvPEE+Rg@mail.gmail.com" type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">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.&nbsp;
            <div><br>
            </div>
            <div>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.</div>
            <div><br>
            </div>
            <div>How do we even discuss this via emails? That's a lot of
              writing! Is there are better way to discuss this instead?</div>
            <div><br>
            </div>
            <div>Gary</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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 ;-).<br>
    <br>
    Seriously.<br>
    <br>
    Anyway. The questions.<br>
    <br>
    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.<br>
    <br>
    So programmatic control, me being a layman, depends on two things:<br>
    <br>
    - 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.<br>
    <br>
    - 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?.<br>
    <br>
    Those are three different levels of involvement.<br>
    <br>
    1. Free to use the API from the outside.<br>
    2. Need to subclass a factory to do it from within (as if you are
    part of the core yourself now)<br>
    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).<br>
    <br>
    Currently my program that I haven't worked on for days now ;-)...<br>
    <br>
    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.<br>
    <br>
    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 <i>extending</i> the system just as a way of
    configuring it.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    But you have to make these two choices, I can't do it for you:<br>
    <br>
    1. Do you want programmatic configuration to be an equivalent or
    near-equivalent to config-file based control?<br>
    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?.<br>
    <br>
    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 <i>doing</i>
    the first of these three things, and so I answer these two questions
    with a "yes" and a "the first".<br>
    <br>
    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.<br>
    <br>
    Regards...<br>
    <br>
    B. <br>
  

</div></blockquote></body></html>
--Apple-Mail-1BB6A609-EC47-45CA-978D-FFA763B4B057--