Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id C6C18200B83 for ; Sat, 17 Sep 2016 18:49:12 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id C544E160ACD; Sat, 17 Sep 2016 16:49:12 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 88CB3160AB5 for ; Sat, 17 Sep 2016 18:49:11 +0200 (CEST) Received: (qmail 50421 invoked by uid 500); 17 Sep 2016 16:49:10 -0000 Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Log4J Developers List" Reply-To: "Log4J Developers List" Delivered-To: mailing list log4j-dev@logging.apache.org Received: (qmail 50411 invoked by uid 99); 17 Sep 2016 16:49:10 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 17 Sep 2016 16:49:10 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 463971A0337 for ; Sat, 17 Sep 2016 16:49:10 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.98 X-Spam-Level: * X-Spam-Status: No, score=1.98 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id GtEEpgUD2zmH for ; Sat, 17 Sep 2016 16:49:08 +0000 (UTC) Received: from smtp687.redcondor.net (smtp687.redcondor.net [208.80.206.87]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 2EE1F5F59E for ; Sat, 17 Sep 2016 16:49:08 +0000 (UTC) Received: from mailproxy13.neonova.net ([137.118.22.78]) by smtp687.redcondor.net ({f50aeeea-7a14-4dd3-bdda-1246754c15b3}) via TCP (outbound) with ESMTP id 20160917164900658_0687 for ; Sat, 17 Sep 2016 16:49:00 +0000 X-RC-FROM: X-RC-RCPT: Received: from [172.20.0.67] (rrcs-45-59-194-183.west.biz.rr.com [45.59.194.183]) (Authenticated sender: ralph.goers@dslextreme.com) by mailproxy13.neonova.net (Postfix) with ESMTPA id 884B336005E for ; Sat, 17 Sep 2016 12:48:56 -0400 (EDT) From: Ralph Goers Content-Type: multipart/alternative; boundary="Apple-Mail=_DBE9EA19-5BDE-4B43-89C5-8F66EBD787C8" Message-Id: <5BCAAF16-02F7-45B1-B597-2A22A602AF44@dslextreme.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: OS-based dynamic configuration file Date: Sat, 17 Sep 2016 09:48:55 -0700 References: <1E11A584-4C6F-43EC-9ADA-64611AC68641@dslextreme.com> <9C614807-A40E-4DE7-B38D-9D3D839E17AB@dslextreme.com> <9FEC89CA-E148-4FA5-907F-49CD8A696516@dslextreme.com> To: Log4J Developers List In-Reply-To: X-Mailer: Apple Mail (2.3124) X-DLP-OUTBOUND: 137.118.22.64/27 X-MAG-OUTBOUND: greymail.redcondor.net@137.118.22.64/27 archived-at: Sat, 17 Sep 2016 16:49:13 -0000 --Apple-Mail=_DBE9EA19-5BDE-4B43-89C5-8F66EBD787C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 See inline > On Sep 16, 2016, at 10:31 PM, Gary Gregory = wrote: >=20 > On Fri, Sep 16, 2016 at 8:38 PM, Ralph Goers = > wrote: > Gary, >=20 > I have no problem with components that can be dumbed down to do simple = things. I do have a problem with components that only do simple things = because people will constantly asked to have them be enhanced. >=20 > As for what you are proposing here, can I just say =E2=80=9CNo=E2=80=9D?= =20 >=20 > Sure! :-) You can say whatever you want! :-)=20 > =20 > Having the Appenders element deferred just smells to me and having an = arbitrary script there just seems weird to me. Does it even have a = contract or is it a free-for-all? How does it cause multiple appenders = to be initialized?=20 >=20 > I think the RoutingAppender is a more appropriate solution. However, = if you want to dumb it down a bit and turn it into an AppenderSelector = I=E2=80=99d be ok with that. However, it would still be fairly similar = to the RoutingAppender. >=20 > OK, so going back to one of your eariler messages: >=20 > =3D=3Dcopy start=3D=3D >=20 > This sort of sounds like you want an Appender Selector, which would be = an Appender that uses a Selector to figure out which Appender to = delegate to. This is a bit like the PatternSelector. I would imagine it = would make sense to implement AppenderSelectors and LayoutSelectors. = You probably would want to dynamically initialize the Appenders much = like the RoutingAppender does.=20 >=20 > Maybe it would look like: >=20 > > > > > > > =20 > > >=20 > The thing is that this script would run every time the Selector was = accessed while it sounds like you would only want the script to run when = the Selector is initialized. We could do that too but the script would = need to be declared in a property that would only be used when the = selector is initialized. I would want to support being able to do both. >=20 > =3D=3Dcopy end=3D=3D >=20 > This is indeed like the RoutingAppender _except_ that the whole point = is to do the script selection on start up. When you say that you'd want = it both ways, on start up and on each log event; what would the = configuration difference look like? >=20 > But.. "Appender that uses a Selector to figure out which Appender to = delegate to" ... that is _so_ much like a RoutingAppender as to be = redundant, no? The difference is that a AppenderSelector can just implement the Builder = or Factory and invoke the script at that time to figure out which = Appender to create. It then returns that Appender. So while the = AppenderSelector is technically an Appender, it really is just an = AppenderBuilder. The RoutingAppender is a real Appender. >=20 > What I want is for the script to determine which appender to use = (once), and instantiate that appender (once). There is no need for one = appender to delegate to another appender. And that is what I just described. >=20 > The more general case is for the script to determine which appenders = (plural) to use (once), and instantiate those appenders (plural) (once). = There is no need for one appender to delegate to another appender list. = I do not have a use case for this today, but I do for the one appender = case. An AppenderSelector could only instantiate a single Appender, not a = group. If you wanted multiple appenders dynamically created this way you = would using multiple selectors. I=E2=80=99m not sure I see that as a = drawback. >=20 > My goal would be explained to a user like this: "This feature helps = you build your configuration dynamically, all from the configuration = file, to determine which appender(s) to configure. This is different = from using a RoutingAppender which creates a level of indirection and = decides what to do for each log event _at runtime_" Yes, this is a = simpler explanation than also explaining the new role of scripts in the = RoutingAppender but you get the idea. >=20 > I am open different solutions that meet the goal of building the = configuration dynamically, as if you'd done it in XML explicitly (or = JSON) but does not end up with one appender delegating to another. >=20 > Thoughts? >=20 > Gary >=20 --Apple-Mail=_DBE9EA19-5BDE-4B43-89C5-8F66EBD787C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
See inline

On Sep 16, 2016, at 10:31 PM, = Gary Gregory <garydgregory@gmail.com> wrote:

On Fri, Sep 16, 2016 at = 8:38 PM, Ralph Goers <ralph.goers@dslextreme.com> wrote:
Gary,

I have no problem with components that can be dumbed down to = do simple things. I do have a problem with components that only do = simple things because people will constantly asked to have them be = enhanced.

As = for what you are proposing here, can I just say =E2=80=9CNo=E2=80=9D? =  

Sure! :-) You can say whatever you want! :-) 
 
Having the = Appenders element deferred just smells to me and having an arbitrary = script there just seems weird to me. Does it even have a contract or is = it a free-for-all? How does it cause multiple appenders to be = initialized? 

I think the RoutingAppender is a more appropriate solution. = However, if you want to dumb it down a bit and turn it into an = AppenderSelector I=E2=80=99d be ok with that. However, it would still be = fairly similar to the RoutingAppender.

OK, so going back to one = of your eariler messages:

=3D=3Dcopy start=3D=3D

This sort of sounds like you want an Appender = Selector, which would be an Appender that uses a Selector to figure out = which Appender to delegate to. This is a bit like the PatternSelector. I = would imagine it would make sense to implement AppenderSelectors and = LayoutSelectors.  You probably would want to dynamically initialize = the Appenders much like the RoutingAppender does. 

Maybe it would look = like:

<Appenders>
  <ScriptSelector name=3D=E2=80=9C" = default=3D=E2=80=9C=E2=80=9D>
     <Script = language=3D=E2=80=9Cgroovy=E2=80=9D><![CDATA[
        =  if (System.getProperty=E2=80=9Dos.name=E2=80=9D).contains(=E2=80=9COS/390=E2=80=9D)) then {
        =      return =E2=80=9CSocket=E2=80=9D;
        =  } else {
  =            return =E2=80=9CFile=E2=80=9D;
      =    }           
    =  </Script>
     <Appenders>
        =  <SocketAppender name=3D=E2=80=9CSocket=E2=80=9D = =E2=80=A6/>
  =        <FileAppender name=3D=E2=80=9CFile=E2=80=9D = =E2=80=A6/>
  =    </Appenders>     
  = </ScriptSelector>
</Appenders>

The thing is that this script would run every time the = Selector was accessed while it sounds like you would only want the = script to run when the Selector is initialized. We could do that too but = the script would need to be declared in a property that would only be = used when the selector is initialized. I would want to support being = able to do both.

=3D=3Dcopy = end=3D=3D

This is = indeed like the RoutingAppender _except_ that the whole point is to do = the script selection on start up. When you say that you'd want it both = ways, on start up and on each log event; what would the configuration = difference look like?

But.. "Appender = that uses a Selector to figure out which Appender to delegate to" ... = that is _so_ much like a RoutingAppender as to be redundant, = no?

The difference is that a AppenderSelector can just = implement the Builder or Factory and invoke the script at that time to = figure out which Appender to create. It then returns that Appender. So = while the AppenderSelector is technically an Appender, it really is just = an AppenderBuilder.  The RoutingAppender is a real = Appender.


What I = want is for the script to determine which appender to use (once), and = instantiate that appender (once). There is no need for one appender to = delegate to another = appender.

And that is what I just described.


The = more general case is for the script to determine which appenders (plural) to use = (once), and instantiate those appenders (plural) (once). There is no = need for one appender to delegate to another appender list. I do not = have a use case for this today, but I do for the one appender = case.

An AppenderSelector could only instantiate a = single Appender, not a group. If you wanted multiple appenders = dynamically created this way you would using multiple selectors. I=E2=80=99= m not sure I see that as a drawback.



My = goal would be explained to a user like this: "This feature helps you = build your configuration dynamically, all from the configuration file, = to determine which appender(s) to configure. This is different from = using a RoutingAppender which creates a level of indirection and decides = what to do for each log event _at runtime_" Yes, this is a simpler = explanation than also explaining the new role of scripts in the = RoutingAppender but you get the idea.

I am open different solutions that meet the goal of = building the configuration dynamically, as if you'd done it in = XML explicitly (or JSON) but does not end up with one appender = delegating to another.

Thoughts?

Gary

= --Apple-Mail=_DBE9EA19-5BDE-4B43-89C5-8F66EBD787C8--