Return-Path: Delivered-To: apmail-logging-general-archive@www.apache.org Received: (qmail 96746 invoked from network); 15 May 2007 08:27:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 15 May 2007 08:27:29 -0000 Received: (qmail 88077 invoked by uid 500); 15 May 2007 08:27:35 -0000 Delivered-To: apmail-logging-general-archive@logging.apache.org Received: (qmail 88039 invoked by uid 500); 15 May 2007 08:27:35 -0000 Mailing-List: contact general-help@logging.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: "Logging General" List-Id: Delivered-To: mailing list general@logging.apache.org Received: (qmail 88026 invoked by uid 99); 15 May 2007 08:27:35 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 May 2007 01:27:35 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [137.208.8.46] (HELO sslmail2.wu-wien.ac.at) (137.208.8.46) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 May 2007 01:27:28 -0700 Received: from [137.208.224.177] (abt-wi-018.wu-wien.ac.at [137.208.224.177]) (authenticated bits=0) by sslmail2.wu-wien.ac.at (8.13.3/8.13.1) with ESMTP id l4F8R3xR018498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 15 May 2007 10:27:04 +0200 (CEST) (envelope-from rony@apache.org) Message-ID: <46496ED6.9020701@apache.org> Date: Tue, 15 May 2007 10:27:02 +0200 From: "Rony G. Flatscher (Apache)" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Logging General Subject: and two examples... (Re: Little update and additional infos on the ooRexx implementation ... (Re: 'log4r' - a new 'log4j' like framework about to be released ... References: <462FB5CF.1080407@apache.org> <1729CFA3-9140-4B18-B98B-0579BFAC22C0@apache.org> <4630DC12.3000607@apache.org> <46480B44.4020803@apache.org> <4648E77E.7040103@apache.org> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: multipart/alternative; boundary="------------090505080200010302020800" X-Virus-Scanned: ClamAV 0.90.2/3244/Tue May 15 02:50:47 2007 on pocken.wu-wien.ac.at X-Virus-Status: Clean X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. --------------090505080200010302020800 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Curt, >>> Seems like it may have already out-grown the labs phase. You >>> apparently have a functioning code base and maybe the start of a >>> community and applying to the incubator might be the appropriate >>> action. Completing a Podling Proposal would be helpful to identify >>> any issues. >> Sorry, not being a native English speaker and not finding a translation, >> may I just ask you what a "Podling Proposal" would be? > > A proposal for an incubator project (also known as a podling). A > guide to proposal creation is available at > http://incubator.apache.org/guides/proposal.html and an example is > available at http://maven.apache.org/proposals/incubator/nmaven.html. > You should also be familiar with the exit criteria for the incubator > as described in > http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Exit+Requirements. > Thank you very much for your kind explanations and links! > I think that you should avoid the name log4r regardless of the > ultimate home for the framework. Yes, I will rename the package to "log4rexx". > Logging Services would be most appropriate ultimate home for log4r > within Apache. I don't know ooRexx community at all, so I can't judge > your other options. Here are the pros and cons with hosting the > project at Apache: > > Pros: > > 1. Established community and customs > 2. Potential cross-pollination with log4j, log4cxx and log4net > 3. Apache license > > Cons: > > 1. Unable to formally release until graduation from incubator > 2. Incubator exit criteria of 3 independent committers may be hard to > achieve and maintain > 3. No established ooRexx community (as far as I know) The ooRexx community is rather small at this time (it draws mostly from the established, albeit largely unknown Rexx community). There are a few ooRexx developers who are contemplating of employing the framework with the intent to enhance it to meet their own needs here and there. However, it may be a good idea to "wait and see" how it picks up (i.e., "planting" it in the ooRexx community) and come back later. I will try to make sure that from a licensing point of view each addition from others carries the Apache license as well to keep the option. > I was not suggesting implementing log4r in Java. The design goal in > all the log4X frameworks has been to minimize the cost of logging when > disabled to the absolute minimum, ideally as little as an integer > compare. Yes, tried to keep that principle with the ooRexx implementation. > Switching between languages is usually much more expensive. Definitely! Especially, if matching Jaa with a dynamic(ally typed) language that gets interpreted like ooRexx. [The hardware has become so powerful it seems, that for all practical purposes, this switching has become feasible. And the hardware has been still growing more and more powerful.] > What I was suggesting is that you know what the syntax would be for > calling log4j over the ooRexx-Java bridge and consider that your users > might want to be able to migrate from log4r to log4j over the bridge > if they need a feature not in log4r or if they are running within the > context that is already using log4j. Hmm, interesting question! (I cannot believe that I have never tried that out while developing log4r, so the following two little examples are a premiere for me as well!) The following two ooRexx programs were run with Java 1.5 and "logging-log4j-1.2.13.jar" (ooRexx version 3.1.2 with the BSF4Rexx package). This execution was under Windows, but could also have been run e.g. on Linux (or MacOSX). You may want to know: * the tilde (~) is an explicit message operator, the name right of it is always the name of the message; conceptually ooRexx will go and look for a method by the same name of the message, using its inheritance/classifcation tree for lookup, * ooRexx is *not* case-sensitive (actually everything outside of quotes is uppercased before the Rexx statement gets interpreted), * ooRexx class objects can be accessed by using the class name prepended with a dot; it is possible with BSF4Rexx to import a Java class object and thereafter interact with it as if it was an ooRexx (proxy) class object, * attribute assignments in ooRexx are usually carried out by sending the name of the attribute to the object followed by an equal sign, followed by an expression which value gets assigned to the attribute; querying an attribute value is as easy as sending the name of the attribute to the object. This behaviour would also be available for accessing/setting Java fields via BSF4Rexx. Example 1: demonstrate how to access the log4j rootLogger and use it to log messages to it: Logger=bsf.loadClass("org.apache.log4j.Logger") /* get the Java class object */ r=Logger~getRootLogger /* get the rootLogger */ say "rootLogger's level:" r~level~toString /* get the string value of the Level object */ /* use the rootLogger */ r~trace("Using the 'log4j' rootLogger, method 'trace'") r~debug("Using the 'log4j' rootLogger, method 'debug'") r~info("Using the 'log4j' rootLogger, method 'info'") r~warn("Using the 'log4j' rootLogger, method 'warn'") r~error("Using the 'log4j' rootLogger, method 'error'") r~fatal("Using the 'log4j' rootLogger, method 'fatal'") ::requires bsf.cls /* get the BSF support */ The output of the program ("testlog4j.rex") above yields: F:\tmp\logging-log4j-1.2.13\dist\lib>testlog4j.rex rootLogger's level: FATAL FATAL - Using the 'log4j' rootLogger, method 'fatal' Example 2: transcription of the example from the log4j documentation file "manual.html" which got copied and pasted, and finally edited to turn it into an ooRexx program: -- import the Java class objects we need in ooRexx, this time -- we want to access the Java class objects via ooRexx (proxy) -- class objects (which get a dot prepended to the class name) call bsf.import "org.apache.log4j.Logger", "Logger" call bsf.import "org.apache.log4j.Level", "Level" -- get a logger instance named "com.foo" logger = .Logger~getLogger("com.foo") -- Now set its level. Normally you do not need to set the -- level of a logger programmatically. This is usually done -- in configuration files. logger~setLevel(.Level~INFO) -- can also be stated as an ooRexx attribute assignment: logger~level=.level~info barlogger = .Logger~getLogger("com.foo.Bar") -- This request is enabled, because WARN >= INFO. logger~warn("Low fuel level."); -- This request is disabled, because DEBUG < INFO. logger~debug("Starting search for nearest gas station."); -- The logger instance barlogger, named "com.foo.Bar", -- will inherit its level from the logger named -- "com.foo" Thus, the following request is enabled -- because INFO >= INFO. barlogger~info("Located nearest gas station."); -- This request is disabled, because DEBUG < INFO. barlogger~debug("Exiting gas station search"); ::requires bsf.cls /* get the BSF support */ The output of the program ("testlog4j.rex") above yields: F:\tmp\logging-log4j-1.2.13\dist\lib>testlog4j-2.rex WARN - Low fuel level. INFO - Located nearest gas station. Loading the above two ooRexx programs into the vim editor would syntax highlight them, making it easier to immediately spot the comments, the code with the keywords and operators highlighted. If you have any questions, please ask! Regards, ---rony --------------090505080200010302020800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Curt,
Seems like it may have already out-grown the labs phase.  You
apparently have a functioning code base and maybe the start of a
community and applying to the incubator might be the appropriate
action.  Completing a Podling Proposal would be helpful to identify
any issues.
Sorry, not being a native English speaker and not finding a translation,
may I just ask you what a "Podling Proposal" would be?

A proposal for an incubator project (also known as a podling).  A guide to proposal creation is available at http://incubator.apache.org/guides/proposal.html and an example is available at http://maven.apache.org/proposals/incubator/nmaven.html.  You should also be familiar with the exit criteria for the incubator as described in http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Exit+Requirements.
Thank you very much for your kind explanations and links!

I think that you should avoid the name log4r regardless of the ultimate home for the framework.
Yes, I will rename the package to "log4rexx".

Logging Services would be most appropriate ultimate home for log4r within Apache.  I don't know ooRexx community at all, so I can't judge your other options.  Here are the pros and cons with hosting the project at Apache:

Pros:

1. Established community and customs
2. Potential cross-pollination with log4j, log4cxx and log4net
3. Apache license

Cons:

1. Unable to formally release until graduation from incubator
2. Incubator exit criteria of 3 independent committers may be hard to achieve and maintain
3. No established ooRexx community (as far as I know)
The ooRexx community is rather small at this time (it draws mostly from the established, albeit largely unknown Rexx community). There are a few ooRexx developers who are contemplating of employing the framework with the intent to enhance it to meet their own needs here and there. However, it may be a good idea to "wait and see" how it picks up (i.e., "planting" it in the ooRexx community) and come back later. I will try to make sure that from a licensing point of view each addition from others carries the Apache license as well to keep the option.

I was not suggesting implementing log4r in Java.  The design goal in all the log4X frameworks has been to minimize the cost of logging when disabled to the absolute minimum, ideally as little as an integer compare. 
Yes, tried to keep that principle with the ooRexx implementation.

Switching between languages is usually much more expensive.
Definitely! Especially, if matching Jaa with a dynamic(ally typed) language that gets interpreted like ooRexx. [The hardware has become so powerful it seems, that for all practical purposes, this switching has become feasible. And the hardware has been still growing more and more powerful.]

What I was suggesting is that you know what the syntax would be for calling log4j over the ooRexx-Java bridge and consider that your users might want to be able to migrate from log4r to log4j over the bridge if they need a feature not in log4r or if they are running within the context that is already using log4j.
Hmm, interesting question! (I cannot believe that I have never tried that out while developing log4r, so the following two little examples are a premiere for me as well!)

The following two ooRexx programs were run with Java 1.5 and "logging-log4j-1.2.13.jar" (ooRexx version 3.1.2 with the BSF4Rexx package). This execution was under Windows, but could also have been run e.g. on Linux (or MacOSX).

You may want to know:
  • the tilde (~) is an explicit message operator, the name right of it is always the name of the message; conceptually ooRexx will go and look for a method by the same name of the message, using its inheritance/classifcation tree for lookup,
  • ooRexx is *not* case-sensitive (actually everything outside of quotes is uppercased before the Rexx statement gets interpreted),
  • ooRexx class objects can be accessed by using the class name prepended with a dot; it is possible with BSF4Rexx to import a Java class object and thereafter interact with it as if it was an ooRexx (proxy) class object,
  • attribute assignments in ooRexx are usually carried out by sending the name of the attribute to the object followed by an equal sign, followed by an expression which value gets assigned to the attribute; querying an attribute value is as easy as sending the name of the attribute to the object. This behaviour would also be available for accessing/setting Java fields via BSF4Rexx.

Example 1: demonstrate how to access the log4j rootLogger and use it to log messages to it:
Logger=bsf.loadClass("org.apache.log4j.Logger") /* get the Java class object  */
r=Logger~getRootLogger                          /* get the rootLogger        */

say "rootLogger's level:" r~level~toString      /* get the string value of the Level object  */

   /* use the rootLogger   */
r~trace("Using the 'log4j' rootLogger, method 'trace'")
r~debug("Using the 'log4j' rootLogger, method 'debug'")
r~info("Using the 'log4j' rootLogger, method 'info'")
r~warn("Using the 'log4j' rootLogger, method 'warn'")
r~error("Using the 'log4j' rootLogger, method 'error'")
r~fatal("Using the 'log4j' rootLogger, method 'fatal'")

::requires bsf.cls      /* get the BSF support     */
The output of the program ("testlog4j.rex") above yields:
F:\tmp\logging-log4j-1.2.13\dist\lib>testlog4j.rex
rootLogger's level: FATAL
FATAL - Using the 'log4j' rootLogger, method 'fatal'

Example 2: transcription of the example from the log4j documentation file "manual.html" which got copied and pasted, and finally edited to turn it into an ooRexx program:
-- import the Java class objects we need in ooRexx, this time
-- we want to access the Java class objects via ooRexx (proxy)
-- class objects (which get a dot prepended to the class name)
call bsf.import "org.apache.log4j.Logger", "Logger"
call bsf.import "org.apache.log4j.Level",  "Level"

   -- get a logger instance named "com.foo"
   logger = .Logger~getLogger("com.foo")

   -- Now set its level. Normally you do not need to set the
   -- level of a logger programmatically. This is usually done
   -- in configuration files.
   logger~setLevel(.Level~INFO)
   -- can also be stated as an ooRexx attribute assignment:
   logger~level=.level~info

   barlogger = .Logger~getLogger("com.foo.Bar")

   -- This request is enabled, because WARN >= INFO.
   logger~warn("Low fuel level.");

   -- This request is disabled, because DEBUG < INFO.
   logger~debug("Starting search for nearest gas station.");

   -- The logger instance barlogger, named "com.foo.Bar",
   -- will inherit its level from the logger named
   -- "com.foo" Thus, the following request is enabled
   -- because INFO >= INFO.
   barlogger~info("Located nearest gas station.");

   -- This request is disabled, because DEBUG < INFO.
   barlogger~debug("Exiting gas station search");


::requires bsf.cls      /* get the BSF support     */
The output of the program ("testlog4j.rex") above yields:
F:\tmp\logging-log4j-1.2.13\dist\lib>testlog4j-2.rex
WARN - Low fuel level.
INFO - Located nearest gas station.
Loading the above two ooRexx programs into the vim editor would syntax highlight them, making it easier to immediately spot the comments, the code with the keywords and operators highlighted.

If you have any questions, please ask!

Regards,

---rony

--------------090505080200010302020800--