logging-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rony G. Flatscher (Apache)" <r...@apache.org>
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 ...
Date Tue, 15 May 2007 08:27:02 GMT
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

> 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:

        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.
           -- can also be stated as an ooRexx attribute assignment:

           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:

        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!



View raw message