Re: Little update and additional infos on the ooRexx implementation ... (Re: 'log4r' - a new 'log4j' like framework about to be released ...
Curt Arnold <carnold <at> apache.org>
2007-05-15 00:37:54 GMT
On May 14, 2007, at 5:49 PM, Rony G. Flatscher (Apache) wrote:
> 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.
>
>> Seems like ooRexx has a established legal and development
>> framework in
>> which you are a significant participant. Is there a reason that
>> Apache would be a better home for log4r?
> Well, seeing that commons is going TLP and possibly removing its
> ties to
> Java, I thought it might be a good idea to have comparable
> implementations to the log4j architecture put untder the commons
> umbrella. OTOH, it would be possible and feasible to submit the
> current
> implentation to the opensource ooRexx project's incubator.
>
> If you think that it would be better for the project to submit it
> to the
> ooRexx projec (and maybe have a link or infos about an ooRexx
> implementation of the log4j architecture), I would do so. (If done so,
> would you think that the term "log4r" would be still confusing with
> the
> Ruby implementation?)
I think that you should avoid the name log4r regardless of the
ultimate home for the framework.
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)
>
>> On a technical side, it appears that you were involved in the
>> development of an ooRexx/Java bridge as part of Apache BSF. Does the
>> use of log4r resemble the use of log4j over the bridge?
> No, log4r as it stands now is a stand-alone, pure ooRexx
> implementation.
> It would be feasible in general, however, to take advantage of log4j
> itself using the ooRexx bridge for Apache BSF (but that is a totally
> different use-case making ooRexx dependent on Java, which nowadays -
> practically every computer has a JRE installed - may not be a
> hindering
> stone anymore).
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. Switching between languages is usually much more
expensive.
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.
RSS Feed