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:

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