You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Christian Grobmeier <gr...@gmail.com> on 2011/08/25 09:20:21 UTC
Re: Missing commit messages for rev 1158186 1159577, 1159583
On Thu, Aug 25, 2011 at 5:38 AM, Curt Arnold <ca...@apache.org> wrote:
> I didn't see any commit messages for these revisions which I likely means that Christian isn't subscribed to the log4j-dev list using grobmeire@apache.org and the commit messages from SVN got bounced by the mailing list. I checked the status on the request for commits@logging.apache.org and it is still open, I added a request that any configuration that would allow SVN commit messages to get through would be appreciated. I've made an attempt to add grobmeire@apache.org to the log4j-dev-allow list which hopefully will should let his messages get through without sending outgoing messages.
I have forwarded on of the commits in question before a while manually
and then subscribed to the list with my apache email address. Besides
these rvs you should have got all the other
> Two of the commits removed substantial sections of build.xml that are used in the Gump build which caused Gump to start failing to build extras and components as evidenced by the recent nag messages on log4j-dev.
>
> Maybe when he returns Stefan might update us on the current capabilities of Gump, but last time I visited it, it had limited abiiity with Maven, so it depended on the Ant build to provide the current nightly builds to the entire universe of code it rebuilds and tests several times a day. I've reverted the changes that removed the targets that Gump configuration depends upon. Hopefully that will eliminate the nag messages and allow Gump to build and test extras and component (and anything that depends on them again).
Actually Gump does now build again with Java 1.2. I am not sure how
that works without an error, because all of the components do use 1.4
features. Before reverting the commit, I would have tried to change
the Gump configuration.
Because it "fully supports Apache Ant, Apache Maven (1.x to 3.x)"
(gump.apache.org)
For the time being I would have preferred to leave Gump in an error
state and modify the Gump config instead or disable Gump for the mini
projects.
> It would be good to isolate whitespace changes from non-whitespace changes (or avoid whitespace only changes). One of the changes to build.xml had a decent number of indent changes (likely due to a code reformatter) in addition to some non-cosmetic changes. Reformatting the code, particularly in conjunction with actual changes, complicates code reviews in commit messages or ViewSVN. If you must reformat, reformat first, commit then make changes.
>
> http://svn.apache.org/viewvc?view=revision&revision=1159577
> http://svn.apache.org/viewvc?view=revision&revision=1159583
> http://svn.apache.org/viewvc?view=revision&revision=1158186
Will do the next time. I didn't want to change the formatting, but it
was so heavy to read, that I decided to do everything at once.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
--
http://www.grobmeier.de
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Combine Component and Receivers into extras or Chainsaw (was Re:
Missing commit messages for rev 1158186 1159577, 1159583_
Posted by Christian Grobmeier <gr...@gmail.com>.
On Mon, Aug 29, 2011 at 6:20 AM, Curt Arnold <cu...@gmail.com> wrote:
> On Aug 26, 2011, at 1:38 PM, Christian Grobmeier wrote:
>
>>> Pulling old Chainsaw and lf5 out of core would have probably made up for the
>>> difference..but hey, that ship has sailed...maybe they could all be pulled
>>> into extras (component and receivers?)
>>
>> You mean, move the code from component and receivers into the extras trunk?
>> I am +1 on this - we could even kill the parent project then and get
>> rid of three releases and make only one for all
>
>
> I was playing catch on this one once the Gump builds started failing and then not finding any commit notifications in the email. I didn't see the heads up.
>
> The motivation to have "companions" as a distinct products was not to keep the log4j.jar trim, but allow the companions to be available for people who were stuck with older versions of log4j 1.2 (due to package managers or other software bundlers liking to distribution ancient versions of log4j 1.2).
>
> I am not aware of any other users of components and receivers other than Chainsaw, so another option would be to roll them into Chainsaw.
hey thats a pretty good idea too. Then Scott is 100% independent with
Chainsaw. After all, if somebody *really* needs the classes he can put
the chainsaw jar onto his classpath or extract them himself.
Cheers
Christian
> I have no attachment to Ant builds for component, receivers or Chainsaw.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
--
http://www.grobmeier.de
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Combine Component and Receivers into extras or Chainsaw (was Re: Missing commit messages for rev 1158186 1159577, 1159583_
Posted by Curt Arnold <cu...@gmail.com>.
On Aug 26, 2011, at 1:38 PM, Christian Grobmeier wrote:
>> Pulling old Chainsaw and lf5 out of core would have probably made up for the
>> difference..but hey, that ship has sailed...maybe they could all be pulled
>> into extras (component and receivers?)
>
> You mean, move the code from component and receivers into the extras trunk?
> I am +1 on this - we could even kill the parent project then and get
> rid of three releases and make only one for all
I was playing catch on this one once the Gump builds started failing and then not finding any commit notifications in the email. I didn't see the heads up.
The motivation to have "companions" as a distinct products was not to keep the log4j.jar trim, but allow the companions to be available for people who were stuck with older versions of log4j 1.2 (due to package managers or other software bundlers liking to distribution ancient versions of log4j 1.2).
I am not aware of any other users of components and receivers other than Chainsaw, so another option would be to roll them into Chainsaw.
I have no attachment to Ant builds for component, receivers or Chainsaw.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Missing commit messages for rev 1158186 1159577, 1159583
Posted by Scott Deboy <sc...@gmail.com>.
Yes, that's what I mean..would seem to simplify everything..
On Fri, Aug 26, 2011 at 11:38 AM, Christian Grobmeier
<gr...@gmail.com>wrote:
> > Pulling old Chainsaw and lf5 out of core would have probably made up for
> the
> > difference..but hey, that ship has sailed...maybe they could all be
> pulled
> > into extras (component and receivers?)
>
> You mean, move the code from component and receivers into the extras trunk?
> I am +1 on this - we could even kill the parent project then and get
> rid of three releases and make only one for all
>
>
>
> >
> > Scott
> >
> > On Fri, Aug 26, 2011 at 6:21 AM, Christian Grobmeier <
> grobmeier@gmail.com>
> > wrote:
> >>
> >> Hello Curt,
> >>
> >> > On Aug 26, 2011, at 12:12 AM, Curt Arnold wrote:
> >> >
> >> >> We've supported both building with either Ant or Maven for many
> years,
> >> >> though releases have been exclusively Maven for a while. The Ant
> build and
> >> >> test scripts were necessary to build and test on JDK 1.3 and earlier
> (which
> >> >> also required an earlier version of Ant, though I forget the specific
> >> >> version), but that is obviously less of a concern than it was long
> time ago.
> >> >> As far as I can tell, the Ant build works and isn't hurting anyone,
> so I'd
> >> >> be inclined to keep it around at least until there is a some
> discussion to
> >> >> remove Ant as a build environment.
> >>
> >>
> >> It seems you have missed my prewarning before I did the change:
> >> http://bit.ly/oUAy1R
> >>
> >> I saw commons testing on jdk 1.3:
> >>
> >>
> http://svn.apache.org/repos/asf/commons/proper/commons-parent/trunk/pom.xml
> >> (scroll down to the profiles)
> >>
> >> Then I would like to point you to the discussion on the JDK 1.3:
> >> http://bit.ly/nDMN7f
> >>
> >> Maybe we have supported Ant for many years. But companions are just a
> >> few classes and honstely, do we really expect a second release of
> >> them? I do not. My suggestion is and was to stip off everything which
> >> is not necessary. The ant build and the usage of ant within maven
> >> makes the pom.xml hard to read. The whole build is somewhat complex
> >> compared to other maven projects. I doubt the sense behind it - at
> >> least we are speaking of only a few files in each project.
> >>
> >> In addition, I can't open the project with JDK1.3 compiler settings in
> >> eclipse. It is simply to old. I have suggested to level at least to
> >> 1.4. Since companions has not been released so far, it should not
> >> cause any trouble. JDK 1.3 users are lost these days. For good
> >> reasons. If people still survive with JDK 1.3, they probably don't
> >> need companions. They need prayers, each day. ;-)
> >>
> >>
> >>
> >> > There were also a couple of other scenarios where it was handy to have
> >> > the Ant scripts around. The ant scripts allowed you to test without
> >> > rebuilding which was handy to check that the jar that you built on the
> >> > release platform worked on other platforms. I'm not sure how easily
> that can
> >> > be accomplished with Maven as I think it is going to want to rebuild
> the jar
> >> > first. Also, I recall some JVM (JRocket, Geronimo, gcj) not running
> Maven,
> >> > but able to build and test with Ant.
> >>
> >>
> >> Maven 2 and 3 is pretty stable and widely spread. Even at Commons
> >> Maven is the standard - a project were components need to work for all
> >> environments. I have not heard that JRocket and others cannot run
> >> Maven. I could not find any references when googling. Somebody said,
> >> JRockit + Maven has a poor performance. But anyway - it is not likely
> >> that companions users will download the sources and compile themself.
> >> Honestly I do not expect a single download except when Scott builds
> >> his Chainsaw. :-)
> >>
> >> In addition, mvn test works very well for me. Testing (at least to my
> >> knowledge) does not happen with a jar file, it happens on the compiled
> >> classes. Even when we need to build a jar on each test, no problem
> >> with 3 classes in a project.
> >>
> >> Summarizing, I don't think we need the features you outlined. We
> >> should make a quick release now. If we need a feature which is not
> >> provided by maven, we can put it into the code later. And as a second
> >> release is very unlikely...
> >>
> >> Would be nice to hear other voices on this one.
> >>
> >> Cheers
> >> Christian
> >>
> >>
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> >> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> http://www.grobmeier.de
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> >> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >>
> >
> >
>
>
>
> --
> http://www.grobmeier.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
Re: Missing commit messages for rev 1158186 1159577, 1159583
Posted by Christian Grobmeier <gr...@gmail.com>.
> Pulling old Chainsaw and lf5 out of core would have probably made up for the
> difference..but hey, that ship has sailed...maybe they could all be pulled
> into extras (component and receivers?)
You mean, move the code from component and receivers into the extras trunk?
I am +1 on this - we could even kill the parent project then and get
rid of three releases and make only one for all
>
> Scott
>
> On Fri, Aug 26, 2011 at 6:21 AM, Christian Grobmeier <gr...@gmail.com>
> wrote:
>>
>> Hello Curt,
>>
>> > On Aug 26, 2011, at 12:12 AM, Curt Arnold wrote:
>> >
>> >> We've supported both building with either Ant or Maven for many years,
>> >> though releases have been exclusively Maven for a while. The Ant build and
>> >> test scripts were necessary to build and test on JDK 1.3 and earlier (which
>> >> also required an earlier version of Ant, though I forget the specific
>> >> version), but that is obviously less of a concern than it was long time ago.
>> >> As far as I can tell, the Ant build works and isn't hurting anyone, so I'd
>> >> be inclined to keep it around at least until there is a some discussion to
>> >> remove Ant as a build environment.
>>
>>
>> It seems you have missed my prewarning before I did the change:
>> http://bit.ly/oUAy1R
>>
>> I saw commons testing on jdk 1.3:
>>
>> http://svn.apache.org/repos/asf/commons/proper/commons-parent/trunk/pom.xml
>> (scroll down to the profiles)
>>
>> Then I would like to point you to the discussion on the JDK 1.3:
>> http://bit.ly/nDMN7f
>>
>> Maybe we have supported Ant for many years. But companions are just a
>> few classes and honstely, do we really expect a second release of
>> them? I do not. My suggestion is and was to stip off everything which
>> is not necessary. The ant build and the usage of ant within maven
>> makes the pom.xml hard to read. The whole build is somewhat complex
>> compared to other maven projects. I doubt the sense behind it - at
>> least we are speaking of only a few files in each project.
>>
>> In addition, I can't open the project with JDK1.3 compiler settings in
>> eclipse. It is simply to old. I have suggested to level at least to
>> 1.4. Since companions has not been released so far, it should not
>> cause any trouble. JDK 1.3 users are lost these days. For good
>> reasons. If people still survive with JDK 1.3, they probably don't
>> need companions. They need prayers, each day. ;-)
>>
>>
>>
>> > There were also a couple of other scenarios where it was handy to have
>> > the Ant scripts around. The ant scripts allowed you to test without
>> > rebuilding which was handy to check that the jar that you built on the
>> > release platform worked on other platforms. I'm not sure how easily that can
>> > be accomplished with Maven as I think it is going to want to rebuild the jar
>> > first. Also, I recall some JVM (JRocket, Geronimo, gcj) not running Maven,
>> > but able to build and test with Ant.
>>
>>
>> Maven 2 and 3 is pretty stable and widely spread. Even at Commons
>> Maven is the standard - a project were components need to work for all
>> environments. I have not heard that JRocket and others cannot run
>> Maven. I could not find any references when googling. Somebody said,
>> JRockit + Maven has a poor performance. But anyway - it is not likely
>> that companions users will download the sources and compile themself.
>> Honestly I do not expect a single download except when Scott builds
>> his Chainsaw. :-)
>>
>> In addition, mvn test works very well for me. Testing (at least to my
>> knowledge) does not happen with a jar file, it happens on the compiled
>> classes. Even when we need to build a jar on each test, no problem
>> with 3 classes in a project.
>>
>> Summarizing, I don't think we need the features you outlined. We
>> should make a quick release now. If we need a feature which is not
>> provided by maven, we can put it into the code later. And as a second
>> release is very unlikely...
>>
>> Would be nice to hear other voices on this one.
>>
>> Cheers
>> Christian
>>
>>
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >
>> >
>>
>>
>>
>> --
>> http://www.grobmeier.de
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>
>
--
http://www.grobmeier.de
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Missing commit messages for rev 1158186 1159577, 1159583
Posted by Scott Deboy <sc...@gmail.com>.
+1 I agree with Christian on this...I believe we can go forward with
exclusively maven for companions...although to be honest it seems having
companions at all seems a little overkill..it's a few extra classes..seems
size was the main driver?
Pulling old Chainsaw and lf5 out of core would have probably made up for the
difference..but hey, that ship has sailed...maybe they could all be pulled
into extras (component and receivers?)
Scott
On Fri, Aug 26, 2011 at 6:21 AM, Christian Grobmeier <gr...@gmail.com>wrote:
> Hello Curt,
>
> > On Aug 26, 2011, at 12:12 AM, Curt Arnold wrote:
> >
> >> We've supported both building with either Ant or Maven for many years,
> though releases have been exclusively Maven for a while. The Ant build and
> test scripts were necessary to build and test on JDK 1.3 and earlier (which
> also required an earlier version of Ant, though I forget the specific
> version), but that is obviously less of a concern than it was long time ago.
> As far as I can tell, the Ant build works and isn't hurting anyone, so I'd
> be inclined to keep it around at least until there is a some discussion to
> remove Ant as a build environment.
>
>
> It seems you have missed my prewarning before I did the change:
> http://bit.ly/oUAy1R
>
> I saw commons testing on jdk 1.3:
> http://svn.apache.org/repos/asf/commons/proper/commons-parent/trunk/pom.xml
> (scroll down to the profiles)
>
> Then I would like to point you to the discussion on the JDK 1.3:
> http://bit.ly/nDMN7f
>
> Maybe we have supported Ant for many years. But companions are just a
> few classes and honstely, do we really expect a second release of
> them? I do not. My suggestion is and was to stip off everything which
> is not necessary. The ant build and the usage of ant within maven
> makes the pom.xml hard to read. The whole build is somewhat complex
> compared to other maven projects. I doubt the sense behind it - at
> least we are speaking of only a few files in each project.
>
> In addition, I can't open the project with JDK1.3 compiler settings in
> eclipse. It is simply to old. I have suggested to level at least to
> 1.4. Since companions has not been released so far, it should not
> cause any trouble. JDK 1.3 users are lost these days. For good
> reasons. If people still survive with JDK 1.3, they probably don't
> need companions. They need prayers, each day. ;-)
>
>
>
> > There were also a couple of other scenarios where it was handy to have
> the Ant scripts around. The ant scripts allowed you to test without
> rebuilding which was handy to check that the jar that you built on the
> release platform worked on other platforms. I'm not sure how easily that can
> be accomplished with Maven as I think it is going to want to rebuild the jar
> first. Also, I recall some JVM (JRocket, Geronimo, gcj) not running Maven,
> but able to build and test with Ant.
>
>
> Maven 2 and 3 is pretty stable and widely spread. Even at Commons
> Maven is the standard - a project were components need to work for all
> environments. I have not heard that JRocket and others cannot run
> Maven. I could not find any references when googling. Somebody said,
> JRockit + Maven has a poor performance. But anyway - it is not likely
> that companions users will download the sources and compile themself.
> Honestly I do not expect a single download except when Scott builds
> his Chainsaw. :-)
>
> In addition, mvn test works very well for me. Testing (at least to my
> knowledge) does not happen with a jar file, it happens on the compiled
> classes. Even when we need to build a jar on each test, no problem
> with 3 classes in a project.
>
> Summarizing, I don't think we need the features you outlined. We
> should make a quick release now. If we need a feature which is not
> provided by maven, we can put it into the code later. And as a second
> release is very unlikely...
>
> Would be nice to hear other voices on this one.
>
> Cheers
> Christian
>
>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
> >
>
>
>
> --
> http://www.grobmeier.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
Re: Missing commit messages for rev 1158186 1159577, 1159583
Posted by Christian Grobmeier <gr...@gmail.com>.
Hello Curt,
> On Aug 26, 2011, at 12:12 AM, Curt Arnold wrote:
>
>> We've supported both building with either Ant or Maven for many years, though releases have been exclusively Maven for a while. The Ant build and test scripts were necessary to build and test on JDK 1.3 and earlier (which also required an earlier version of Ant, though I forget the specific version), but that is obviously less of a concern than it was long time ago. As far as I can tell, the Ant build works and isn't hurting anyone, so I'd be inclined to keep it around at least until there is a some discussion to remove Ant as a build environment.
It seems you have missed my prewarning before I did the change:
http://bit.ly/oUAy1R
I saw commons testing on jdk 1.3:
http://svn.apache.org/repos/asf/commons/proper/commons-parent/trunk/pom.xml
(scroll down to the profiles)
Then I would like to point you to the discussion on the JDK 1.3:
http://bit.ly/nDMN7f
Maybe we have supported Ant for many years. But companions are just a
few classes and honstely, do we really expect a second release of
them? I do not. My suggestion is and was to stip off everything which
is not necessary. The ant build and the usage of ant within maven
makes the pom.xml hard to read. The whole build is somewhat complex
compared to other maven projects. I doubt the sense behind it - at
least we are speaking of only a few files in each project.
In addition, I can't open the project with JDK1.3 compiler settings in
eclipse. It is simply to old. I have suggested to level at least to
1.4. Since companions has not been released so far, it should not
cause any trouble. JDK 1.3 users are lost these days. For good
reasons. If people still survive with JDK 1.3, they probably don't
need companions. They need prayers, each day. ;-)
> There were also a couple of other scenarios where it was handy to have the Ant scripts around. The ant scripts allowed you to test without rebuilding which was handy to check that the jar that you built on the release platform worked on other platforms. I'm not sure how easily that can be accomplished with Maven as I think it is going to want to rebuild the jar first. Also, I recall some JVM (JRocket, Geronimo, gcj) not running Maven, but able to build and test with Ant.
Maven 2 and 3 is pretty stable and widely spread. Even at Commons
Maven is the standard - a project were components need to work for all
environments. I have not heard that JRocket and others cannot run
Maven. I could not find any references when googling. Somebody said,
JRockit + Maven has a poor performance. But anyway - it is not likely
that companions users will download the sources and compile themself.
Honestly I do not expect a single download except when Scott builds
his Chainsaw. :-)
In addition, mvn test works very well for me. Testing (at least to my
knowledge) does not happen with a jar file, it happens on the compiled
classes. Even when we need to build a jar on each test, no problem
with 3 classes in a project.
Summarizing, I don't think we need the features you outlined. We
should make a quick release now. If we need a feature which is not
provided by maven, we can put it into the code later. And as a second
release is very unlikely...
Would be nice to hear other voices on this one.
Cheers
Christian
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
--
http://www.grobmeier.de
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Missing commit messages for rev 1158186 1159577, 1159583
Posted by Curt Arnold <ca...@apache.org>.
On Aug 26, 2011, at 12:12 AM, Curt Arnold wrote:
> We've supported both building with either Ant or Maven for many years, though releases have been exclusively Maven for a while. The Ant build and test scripts were necessary to build and test on JDK 1.3 and earlier (which also required an earlier version of Ant, though I forget the specific version), but that is obviously less of a concern than it was long time ago. As far as I can tell, the Ant build works and isn't hurting anyone, so I'd be inclined to keep it around at least until there is a some discussion to remove Ant as a build environment.
>
There were also a couple of other scenarios where it was handy to have the Ant scripts around. The ant scripts allowed you to test without rebuilding which was handy to check that the jar that you built on the release platform worked on other platforms. I'm not sure how easily that can be accomplished with Maven as I think it is going to want to rebuild the jar first. Also, I recall some JVM (JRocket, Geronimo, gcj) not running Maven, but able to build and test with Ant.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Missing commit messages for rev 1158186 1159577, 1159583
Posted by Curt Arnold <ca...@apache.org>.
We've supported both building with either Ant or Maven for many years, though releases have been exclusively Maven for a while. The Ant build and test scripts were necessary to build and test on JDK 1.3 and earlier (which also required an earlier version of Ant, though I forget the specific version), but that is obviously less of a concern than it was long time ago. As far as I can tell, the Ant build works and isn't hurting anyone, so I'd be inclined to keep it around at least until there is a some discussion to remove Ant as a build environment.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org