Thank you very much for your kind explanations and links!Seems like it may have already out-grown the labs phase. YouSorry, not being a native English speaker and not finding a translation,
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
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.
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: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.
1. Established community and customs
2. Potential cross-pollination with log4j, log4cxx and log4net
3. Apache license
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)
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!)
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'
-- 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: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.
F:\tmp\logging-log4j-1.2.13\dist\lib>testlog4j-2.rex WARN - Low fuel level. INFO - Located nearest gas station.