gmane.comp.apache.logging

[ANNOUNCEMENT] Apache Log4j 2.0-beta6 released

Ralph Goers — 2013-05-12T06:09:52

The Apache Log4j 2 team is pleased to announce the Log4j 2.0-beta6 release!

Apache log4j is a well known framework for logging application behavior. Log4j 2 is an upgrade to
Log4j that provides significant improvements over its predecessor, Log4j 1.x, and provides
many of the improvements available in Logback while fixing some inherent problems in Logback's
architecture.

This is the eighth release of Log4j 2 and is being made available to encourage use and feedback from the community.

Bug fixes and enhancements

Changes in this version include:


Fixed Bugs:
o LOG4J2-231:  Logger.getParent() was not returning the correct Logger. 
o LOG4J2-201:  Renamed Plugin annotation attribute from "type" to "category". 
o LOG4J2-219:  Fix: install default root logger if not configured (this is unchanged),
        but make sure to include configured named loggers. Clarified documentation. Thanks to Peter DePasquale. 
o LOG4J2-159:  Use OSGi version format in Fragment-Host 
o LOG4J2-234:  RegexFilter threw a NullPointer

Re: log4cx: attic or incubation?

Christian Grobmeier — 2013-05-04T19:43:34

log4j 1.x build is also so complicated, and recently I considered
creating a Vagrant file for it.
http://vagrantup.com/

This might be cool for log4cxx too. But of course, this requires a bit
more time. I have managed to get into Puppet/Vagrant into a couple of
hours and its worth every minute, but if you will not need it, its of
course a lot of time.



On Sat, May 4, 2013 at 9:39 PM, Ralph Goers <ralph.goers< at >dslextreme.com> wrote:

Re: log4cx: attic or incubation?

Ralph Goers — 2013-05-04T19:39:07

Well, I just downloaded the source. It seems my first challenge is going to be getting it to compile on my Mac.  I suppose I could fire up my Linux box or install an Ubuntu VM but I should be able to find the dependencies.

Ralph


On May 4, 2013, at 12:27 PM, Christian Grobmeier wrote:

Re: log4cx: attic or incubation?

Christian Grobmeier — 2013-05-04T19:27:03

If you could look at the patches a bit (i can take care on the typos
and non-c++ related things) I might find out how to do a release.
So far only a few patches came in.

In this case we really might try to create a asf git mirror as Gary
suggested and I can start with creating a rc (somehow)

If we get that far, it might give others a push





--
http://www.grobmeier.de
https://www.timeandbill.de

Re: log4cx: attic or incubation?

Ralph Goers — 2013-05-04T19:23:04

I actually have enough of a C++ background that I could oversee incoming patches. My problem is that I have been consumed with Log4j.  However, if it is only a few patches I could probably find the time.  At the same time, I would not be wanting to be the one to do the releases.

Ralph

On May 4, 2013, at 10:45 AM, Christian Grobmeier wrote:

Re: log4cx: attic or incubation?

Rhys Ulerich — 2013-05-04T18:52:24

The repo isn't silent because no one wants to contribute bug fixes. It is
silent because it has been effectively locked due to a lack of active
committers.

- Rhys

Re: log4cx: attic or incubation?

Christian Grobmeier — 2013-05-04T17:48:39

All true. I find it hard to believe that in all these years nobody
needed a new feature.
Maybe it's a language thing and all cxx devs are really happy with
what they have.
But on the other hand you are right, contributing is difficult.


Please also see the mail from Gary. He proposed to set up an official
ASF mirror, from
which we could directly accept patches (I heard).


The sad truth is that I never built log4cxx and I am not sure if I can
do it - i simply have never done anything with cxx. Maybe I will get
it with the help of the community. This at least would prove the
interest of the people who raised their hand over at log4cxx land

Thanks for speaking up!

Cheers
Christian




--
http://www.grobmeier.de
https://www.timeandbill.de

Re: log4cx: attic or incubation?

Christian Grobmeier — 2013-05-04T17:45:01

Hi,

On Sat, May 4, 2013 at 7:34 PM, Gary Gregory <garydgregory< at >gmail.com> wrote:

Definitely an interesting idea. Just want to mention, it was the Board
which has asked me.
So far I can't judge on the incoming patches; I have no clue on c++
nor do I plan to build up the skills.
I thought this would maybe not be enough to make changes in an ASF
repository. I have applied a few
patches recently but it made me a bit uncomfortable.

In addition, we wouldn't have an PMC member which actually would
oversee the incoming patches. And who is actually supposed to vote on
it?

That said it is unlikely that we can make up a community again.

As I understood it, this is when the attic comes into play. Unused
repositories which do not get any maintenance. They are still readable
though and can be used.

Anyway, creating a GIt mirror for log4cxx sounds reasonable despite
all concerns. It is a small, first step. We can then see what happens.
Maybe when I find some time I will have a chat with the attic people.
Actually I a

Re: log4cx: attic or incubation?

Gary Gregory — 2013-05-04T17:34:07

Hi All:

[Note that I am not and do not plan on working on log4cxx]

The attic step seems like potentially unnecessary work.

If the project is being used but not developed actively, that's fine. It is
still an asset.

I thought Apache already had a process by which a project can be mirrored
with Git?

You can then process pull requests as you would with any Git repo.

It might be that the project as is is doing it's job in a manner that
satisfies its users, without further tweaking ;)

Gary


On Fri, May 3, 2013 at 10:04 AM, Rhys Ulerich <rhys.ulerich< at >gmail.com>wrote:

Re: log4cx: attic or incubation?

Rhys Ulerich — 2013-05-03T14:04:11

The library is, more or less, stable and feature complete.  There's
not much shepherding to be done in terms of driving the functionality
in some particular direction.  That is, unless there's some burning
feature set that folks need that hasn't been discussed on the log4cxx
mailing list in the years that I have been lurking.  The problem seems
to be that the overhead of contributing small fixes is off-puttingly
high.  It's hard to elicit a YAY from anyone under these
circumstances.


I like this approach.

I would ask that, before you do this, you please make one last 10.2
release off the Apache-blessed sources.  Trunk differs in slight but
important ways from 10.1 (e.g., it builds).  This way the distro
package managers can at least get one last blessed version into their
pipelines before the log4cxx community goes off and experiments with a
reboot.

- Rhys

log4cx: attic or incubation?

Christian Grobmeier — 2013-05-03T09:19:34

Hello folks,

please look at these few e-mails:
http://mail-archives.apache.org/mod_mbox/logging-log4cxx-dev/201304.mbox/browser

For me there are two ways for log4cxx: incubation or attic.

I was outreaching for devs on log4cxx and got a few responses. It seems a couple
of people are interested in continuing this component. Most of them
said they might apply a couple of patches here and there, but nobody
burst out in emotions saying, YAY, this is it.

Without such a person I guess we have little chance in the incubator.
Maybe I am having a wrong view on it, so I ask you to voice your
opinion.

For now I would like to propose that I am cloning log4cxx to my GitHub
account and move the svn repos to the attic. That way I can overlook
if there is a team growing around log4cxx or not. Also I can ask for
ICLAs before accepting pull requests, which should help when we go
back to incubation. If there is, we can go back to incubation at any
time. If there is not, then well, no harm done.

Comments?

Christian

--
ht

[ANNOUNCEMENT] Apache Log4j 2.0-beta5 released

Ralph Goers — 2013-04-25T06:17:31

The Apache Log4j 2 team is pleased to announce the Log4j 2.0-beta5 release!

Apache log4j is a well known framework for logging application behavior. Log4j 2 is an upgrade to
Log4j that provides significant improvements over its predecessor, Log4j 1.x, and provides
many of the improvements available in Logback while fixing some inherent problems in Logback's
architecture.

This is the seventh release of Log4j 2 and is being made available to encourage use and feedback from the community.

Bug fixes and enhancements

Changes in this version include:

New features:
o LOG4J2-207:  Add JMX support. Thanks to Remko Popma. 
o LOG4J2-187:  Add tag library. Thanks to Nick Williams. 
o LOG4J2-164:  Add methods is/setEndOfBatch to LogEvent. Thanks to Remko Popma. 
o LOG4J2-163:  Add support for asynchronous loggers. Thanks to Remko Popma. 
o LOG4J2-179:  Add Logger interface APIs to log at given levels. 
o Added FlumePersistentManager which writes to BerkeleyDB and then writes to Flume asynchronously. 
o LOG4J2-155:

Re: Mirroring Log4J 2 on GitHub

Christian Grobmeier — 2013-03-18T19:34:17

I agree with Ivan this is possible. I thought similar like you before
two years. But actually I have meanwhile learned to value the workflow
described here:
http://nvie.com/posts/a-successful-git-branching-model/

Its great to work with branches, because you can commit even when it
is a half finished feature. You would commit to a feature branch. When
the feature branch is done you would bring it into the develop branch.
Meanwhile I love feature branches. The separation from develop to
master makes sense, esp when you want to create a hotfix. You could
create a hotfix branch directly from the master, make the fix and
finally release from hotfix and merge back to master.

One should also mention that it is pretty common to delete branches
when they are not longer of use.

That said, I have had a couple of merge conflicts in the past, but
they were all better to resolve than with svn. Git is not the solution
for everything, but it is definitely giving some more cool mojo-power
than svn.

cheers
Christian

Re: Mirroring Log4J 2 on GitHub

Ivan Habunek — 2013-03-18T18:12:21

Sure, whatever floats your boat. :) Nothing is preventing you from
forming own your workflow.

Regards,
Ivan

Re: Mirroring Log4J 2 on GitHub

Gary Gregory — 2013-03-18T18:08:08

But you do not have to do it that way right? We could keep master to be the
same as trunk.

G


On Mon, Mar 18, 2013 at 1:44 PM, Ivan Habunek <ivan.habunek< at >gmail.com>wrote:

Re: Mirroring Log4J 2 on GitHub

Ivan Habunek — 2013-03-18T17:44:56

Here's an example for accepting other people's work.

We have an issue on the tracker:
https://issues.apache.org/jira/browse/LOG4PHP-207

I got a patch from a person I trust and he asked me to merge it:
0001-LOG4PHP-207-Using-class-MongoClient-instead-of-Mongo.patch

To apply the patch you download it to your project and run:
git am --signoff 0001-LOG4PHP-207-Using-class-MongoClient-instead-of-Mongo.patch

By adding --signoff, you will get a line similar to this in your commit message:
Signed-off-by: Ivan Habunek <ivan.habunek< at >gmail.com>

Vladimir also used --signoff when creating the patch (see the
contributor guidelines I sent in the previous mail), so you get two
lines at the bottom of the commit message:
Signed-off-by: Vladimir Gorej <gorej< at >codescale.net>
Signed-off-by: Ivan Habunek <ivan.habunek< at >gmail.com>

That way, it's clearly visible who did participated in creating and
merging the commit.

Here's the commit in our repo:
https://git-wip-us.apache.org/repos/asf?p=logging-log4php.git;a=commit;h=f6d60

Re: Mirroring Log4J 2 on GitHub

Ivan Habunek — 2013-03-18T17:34:57

We don't have a very extensive documentation yet. We follow the so
called "git flow" model [1] which means we develop in the "develop"
branch and merge "master" branch with "develop" only when doing a
release. This means that "master" branch always contains the last
released version, and "develop" is similar to "trunk" in svn. This
might not be very visible in our repo yet because we have not made a
release since switching to git. :)

We also have a modest contributor's guide on our wiki [2].

Also, there's a git extension for automating some of the git flow
process [3] written by the same guy(s) who wrote the article under
[1].

I'm very happy with this workflow, it seems very natural.

[1] http://nvie.com/posts/a-successful-git-branching-model/
[2] http://wiki.apache.org/logging-log4php/Contributing
[3] https://github.com/nvie/gitflow

Regards,
Ivan

Re: Mirroring Log4J 2 on GitHub

Ralph Goers — 2013-03-18T17:27:28

Where are the processes that you use with Git documented?  While I'm very comfortable with SVN I am only passable on Git - I can happily work with other people's stuff but I'm not sure what it takes to integrate changes people make from their forks.

Ralph


On Mar 18, 2013, at 9:59 AM, Ivan Habunek wrote:

Re: Mirroring Log4J 2 on GitHub

Ivan Habunek — 2013-03-18T16:59:21

It's actually pretty easy. You have guidelines here:
https://git-wip-us.apache.org/docs/switching-to-git.html

Just open the infra issue with the info they specify there. Log4php
moved to git with no problems.

Regards,
Ivan

Re: Mirroring Log4J 2 on GitHub

Gary Gregory — 2013-03-18T16:44:50


I think we just have to ask infra?

G

Re: Mirroring Log4J 2 on GitHub

Ralph Goers — 2013-03-18T16:30:01

Also, would you mind creating a Jira issue for the getSource problem.  We have a contributor who is working heavily on async stuff who has also pointed this out and it would make sense to make that pluggable.

Ralph

On Mar 18, 2013, at 9:27 AM, Ralph Goers wrote: