The version of Apache log4j used by SoundHelix.
Clone
HTTPS:
git clone https://vervis.peers.community/repos/aEp6o
SSH:
git clone USERNAME@vervis.peers.community:aEp6o
Branches
Tags
- 1.3alpha-7
- CHAINSAW_2_SANDBOX_MERGE
- CORE_VERSION
- LEVEL_REPLACES_PRIORITY
- PREALPHA_1_3_AS_OF_2004_05_12
- PRE_CHAINSAW_MODEL_CONVERSION
- PRE_UGLI_MOVE
- TAG_CHAINSAW2_MOVE
- log4j-1.2.17
- log4j-1.2.17-rc1
- v1.3alpha8
- v1.3alpha8-temp
- v1_2_1
- v1_2_10-recalled
- v1_2_11
- v1_2_11_rc1
- v1_2_11rc3
- v1_2_12
- v1_2_12_rc1
- v1_2_12_rc2
- v1_2_12_rc3
- v1_2_12_rc4
- v1_2_12_rc5
- v1_2_12_rc6
- v1_2_13
- v1_2_13_rc1
- v1_2_13_rc2
- v1_2_13_site_update
- v1_2_14
- v1_2_14_maven
- v1_2_14_rc1
- v1_2_14_site_update
- v1_2_15
- v1_2_15_rc1
- v1_2_15_rc2
- v1_2_15_rc3
- v1_2_15_rc4
- v1_2_15_rc5
- v1_2_15_rc6
- v1_2_16
- v1_2_16_rc1
- v1_2_16_rc2
- v1_2_17
- v1_2_17-rc1
- v1_2_17_rc1
- v1_2_17_rc2
- v1_2_17_rc3
- v1_2_2
- v1_2_3
- v1_2_4
- v1_2_6
- v1_2_7
- v1_2_9
- v1_2_alpha0
- v1_2_alpha7
- v1_2beta1
- v1_2final
- v1_3alpha_1
- v1_3alpha_6
- v_1_0
- v_1_0_1
- v_1_0_4
- v_1_1
- v_1_1_1
- v_1_1_2
- v_1_1_3
- v_1_1_b1
- v_1_1b2
- v_1_1b3
- v_1_1b5
- v_1_1b6
- v_1_1b7
- v_1_2beta3
SUMMARY
This file contains the summary of what has been discussed on the
log4j-dev@ mailing lists. Its monthly contents are sent to the editor
of the Jakarta Newsletter. For the first issue of the Jakarta
Newsletter see:
http://marc.theaimsgroup.com/?l=jakarta-general&m=102328546509220&w=2
+==========+
|June 20002|
+==========+
The month started with a question by John Armstrong [1] on whether
log4j offered any guarantees on binary compatibility between various
versions. To which Ceki replied by stating [2] the current policy of
not removing deprecated methods until at least two release cycles are
complete. This reply did not seem to satisfy John Armstrong and a long
discussion ensued. A historical perspective [3] seemed to satisfy most
people, at least the discussion petered off.
[1] http://marc.theaimsgroup.com/?l=log4j-dev&m=102335790906496&w=2
[2] http://marc.theaimsgroup.com/?l=log4j-dev&m=102336327109965&w=2
[3] http://marc.theaimsgroup.com/?l=log4j-dev&m=102387540521717&w=2
Mike Agnus started [4] a discussion about timezone and locale related
issues in log4j date formats. James Cakalic and Mike discussed the
importance of the decimal character separator. Possible performance
improvements were also suggested. Mark Womack submitted code for
timezone support for date elements of pattern layout. Unfortunately,
the code was anonymous and we could not take into consideration. The
idea seemed to catch on though.
[4] http://marc.theaimsgroup.com/?l=log4j-dev&m=102209832808942&w=2
[5] http://marc.theaimsgroup.com/?l=log4j-dev&m=102420694310844&w=2
Ceki asked for clarifications [6] on java buffered IO because his
experience did not match the myth. Georg Lundesgaard mentioned [7] the
character conversion buffering aspect as explained in the
OutputStreamWriter javadocs.
[6] http://marc.theaimsgroup.com/?l=log4j-dev&m=102326443025158&w=2
[7] http://marc.theaimsgroup.com/?l=log4j-dev&m=102327620700816&w=2
Costin Manolache related his experience [8] with configuring log4j
with JMX. He mentioned the web-application logging insulation
problem. In response, Ceki wrote a specification [9] for solving the
logging separation problem. This was followed by a promising
discussion [10] on Tomcat-dev.
[8] http://marc.theaimsgroup.com/?l=log4j-dev&m=102412323003656&w=2
[9] http://qos.ch/containers/sc.html
[10] http://marc.theaimsgroup.com/?t=102510381000001&r=1&w=2
Mark made a proposal [1]] for a new log4j component called "Receiver."
[11] http://marc.theaimsgroup.com/?l=log4j-dev&m=102523926310678&w=2