I started some sandbox proposed as described in http://
marc.theaimsgroup.com/?l=apache-logging-general&m=112649550919155&w=2
and have to take a break before I pick up later this evening. What
I've done so far is add another directory in the sandbox to separate
the classic "log4j_sandbox" p
On Nov 28, 2005, at 10:50 PM, Mark Womack wrote:
This is a vote to release the 1.2.13rc2 as the official release for
1.2.13.
If accepted by the committers and the PMC, then I will build the
official version from the current 1.2 branch head.
+1
+1
Was able to reproduce rc2 on my JDK 1
I've seen log4jMini or log4jME but haven't investigated them and have
been curious about their status, deviations from log4j proper, etc.
Can anyone give a quick overview or a reference. Should we add them
to the Gump builds?
---
Thanks. Could you review the Apache Contributors License Agreement
(CLA) at http://www.apache.org/licenses/ and see if you'd be in a
position to sign one?
I haven't had a chance to review the code yet, but there are a couple
of areas that concern me: duplication of existing functionality
On Dec 1, 2005, at 9:22 AM, Jess Holle wrote:
Has anyone tried replacing the synchronization in log4j with Java 5
locks to and done any benchmarks?
I'm curious as I think it would be interesting to have a lock
factory which produces something like the existing locks for pre-
Java-5 JVMs a
There were two fairly long threads this summer on the topics raised
in this thread (http://marc.theaimsgroup.com/?l=log4j-
dev&m=111901190409097&w=2 and http://marc.theaimsgroup.com/?
t=11209413893&r=1&w=2). I haven't seen any new issues here, just
a reiteration that we are not in a happ
On Nov 28, 2005, at 1:15 PM, Scott Deboy wrote:
I'll have her submit an email to log4j-dev.
I think a bug report is the preferred mechanism. The Apache JIRA has
a check box saying that you contribute the code to the ASF. Don't
see a similar thing in the Bugzilla attachment dialog, but y
On Nov 28, 2005, at 10:15 AM, Scott Deboy wrote:
Lara D'Abreo is the author of stat4j, an RSSAppender (jdom and rome
dependencies).
I asked her if she'd be willing to contribute the appender to the
log4j project, and she was happy to.
I don't think that is an adequate audit trail for a
On Nov 14, 2005, at 4:05 PM, Paul Smith wrote:
Anyone have any objection to putting some ASL licensed jars in the
Chainsaw repo? Rather than force our customers who build this thing
from source to download external jars, could we embed the jars
needed in a lib directory?
The ones I wish
I'll +1 it, but I would have still preferred "honorReassignment" to
be changed to "follow".
On Nov 6, 2005, at 10:20 PM, Mark Womack wrote:
This is a vote to release the 1.2.13rc1 as the official release for
1.2.13.
If accepted by the committers and the PMC, then I will build the
offici
On Oct 20, 2005, at 12:52 AM, Mark Womack wrote:
- expanded test case to include more TRACE coverage
- updated HISTORY.txt
- updated build.xml to 1.2.13rc1
- Created a v1_2_13_rc1 tag in svn
Build can be accessed from: http://cvs.apache.org/builds/logging/
log4j/log4j-1.2.13rc1/
I used the
After some thought, maybe "follow" is better than
"honorReassignment". It definitely is shorter. I'll pulling plugs
on my computers in a few minutes, so I'll leave it to you to consider
it or think of a better name for the property.
On Oct 19, 2005, at 12:02 PM, Mark Womack wrote:
Cur
On Oct 2, 2005, at 4:17 PM, Andreas Fester wrote:
Hi,
I played with the RollingFileAppender in log4j 1.3 today, mainly
because I started some work on the RollingFileAppender in log4cxx.
Just to be sure:
- The old RollingFileAppender (outside the rolling package)
is not supported anymore, n
I arrived safe in Ft. Worth, Texas yesterday at 6 PM after 14 hours
on back roads avoiding anything like an obvious evacuation path from
Houston. I'll stay in Ft. Worth until the consequences of Rita are
clear at which time I'll return to Houston or temporarily relocate to
Tulsa, OK. Hope
Arrived in Ft. Worth, TX last night around 6 pm yesterday after a 14
hour drive on Texas backroads. I knew there was a reason I wanted to
get a nav system on my car, but made due with my laptop's map
software, phone support from my sister and a US Atlas map of Texas.
Was in danger of runn
For those of you who are not familiar with my location within
Houston, I would not expect my house to be subject to any tidal
flooding short of asteroid impact, though in Houston any place is
subject to flash flooding particularly if storm drains get blocked.
My neighbors have had minor fl
On Sep 19, 2005, at 7:15 AM, Yoav Shapira wrote:
Back to the main point of this thread: do we really need
JoranConfigurator at
all? I agree it can be modified to work with log4j 1.3, but I
wonder if it's
necessary at all. It has some advantages over the DOMConfigurator,
sure, but
perhap
On Sep 1, 2005, at 2:05 PM, Scott Deboy wrote:
I know it sounds crazy, but it is pretty handy, and it's another
example
of how to write your own receiver:
http://wiki.apache.org/logging-log4j/ChainsawHelp
Could you elaborate on scenarios where it is handy? I'm not sure I
get it.
There
On Sep 1, 2005, at 12:52 PM, [EMAIL PROTECTED] wrote:
Hi Folks,
I'd like to pass a cloned NDC Stack across an EJB call, but can't
since its
NDC.DiagnosticContext entries are not serializable. Does anybody
see any
potential issues with adding an "implements java.io.Serializable"
to the
D
On Sep 1, 2005, at 10:10 AM, Jacob Kjome wrote:
Quoting Mark Womack <[EMAIL PROTECTED]>:
Looks like the next version of SLF4J will have Marker's removed
from the
interface (1). Hopefully this will happen in the near future so
that it can be
integrated with Log4j-1.3 before the snapshot re
On Aug 29, 2005, at 2:52 PM, Dan Bush wrote:
Excellent.
On 8/29/05, Ceki Gülcü <[EMAIL PROTECTED]> wrote:
Dan.
Are you aware of SLF4J API which already incorporates a similar
approach?
The same pattern is also in the CVS HEAD. However, I think there is
a better approach. This top
On Aug 30, 2005, at 12:45 AM, Mark Womack wrote:
I hope.
http://cvs.apache.org/builds/logging/log4j/log4j-1.2.12
For some reason all of the .class files are different than the
1.2.12rc6 build. I don't know why. I verified that jdk 1.3.1_16
was used to do the build.
This build and rc6
On Aug 31, 2005, at 7:35 AM, K Sunil wrote:
Hi All,
I am using Log4j 1.3 alpha build for the development.
In this build, I tried to use TimeBasedRollingPolicy,
set below properties
TimeBasedRollingPolicy f = new TimeBasedRollingPolicy();
f.setActiveF
+1
My last set of modifications to the unit tests did not appear to take
the first time even though commit messages hit the list. I retried
and it appears to have taken this time and used the same revision
numbers. The modifications have no effect on the distribution.
Checked the tarbal
I took a shot at using a replaceregexp task in build.xml to strip out
the "Generate by javadoc on..." comments in the generate Javadoc.
That much worked, but the jar file still has embedded timestamps so
my goal of having a completely reproducible distribution appears to
be unachievable.
On Aug 23, 2005, at 12:47 AM, Mark Womack wrote:
Located from: http://cvs.apache.org/builds/logging/log4j/
log4j-1.2.12rc5/
This version built with the benefit of Curt's slogging through the
various jdk combos.
Built with JDK 1.3.1_16 and the proper set of jmx, jms, jndi, jaf,
javamail,
Did a quick little head to head comparison of the most recent
releases and the current state of v1_2-branch. All Javadoc were
removed and the log4j.jar file expanded before comparison.
log4j 1.2.8 vs log4j 1.2.9: All files appear in both releases. All
class files are different.
log4j 1
log4j1.1.12rc4 was missing the org.apache.log4j.jmx package due to a
misconfigured location for jmxtools.jar in build.properties.sample.
I fixed build.properties.sample and added a checks to the release
target for missing classes due to missing prerequisites.
With the exception of the time
I've posted an log4j 1.2.12 release candidate log4j-1.2.12rc4 to
http://people.apache.org/~carnold/logging-log4j-1.2.12rc4.zip and
http://people.apache.org/~carnold/logging-log4j-1.2.12rc4.tar.gz.
This is not explicitly not an official release and should not be used
for anything other than
On Aug 19, 2005, at 6:34 AM, Endre Stølsvik wrote:
Have you tested by using the normal javac (thus 1.5), but with
bootclasspath set (and -obviously- target=1.1|2)? I find this
better, as
one may assume that later javac's will make more efficient code than
earlier (using the bytecode better, t
As you can tell, been busy today. In the current state, log4j should
build and pass all unit tests on JDK 1.2-5 (that is building and
running on same JDK, haven't tested crosses yet). JDK 1.2 will
require you to rebuild Ant 1.6.5 first since it suffers from the same
issue that we have bee
On Aug 18, 2005, at 1:31 PM, Curt Arnold wrote:
1. o.a.l.chainsaw.LoggingReceiver.java does not compile with javac
from JDK 1.1 and 1.2.
Logged as bug 36262
2. log4j does not compile with jikes due to the @deprecated on
org.apache.log4j.spi.LoggerRepository.
Slippery. I don't th
On Aug 18, 2005, at 11:55 AM, Mark Womack wrote:
includeAntRuntime was explicitly set to "no" because I DO NOT WANT to
include it anymore. I want to explicitly isolate our compilation
classpath
from whatever might be in your/mine Ant environment. We have
defined the
exact set of jars (at
On Aug 18, 2005, at 1:31 AM, Mark Womack wrote:
I got a chance to play with the 1.2 build tonight. Here is what I
did:
1) Isolated the build jdk from the Ant runtime jdk.
Basically, I added the following attributes to all of the javac tasks:
fork="yes"
includeAntRuntim
On Aug 17, 2005, at 3:45 AM, Endre Stølsvik wrote:
So, set source=1.2, target=1.2 and bootclasspath=/usr/java/jdk1.2/
rt.jar,
and the code will compile according to 1.2 rules, compile to 1.2
classfiles, and be compiled against 1.2 runtime libraries. It will
thus
run on 1.2 JREs!
That is a
On Aug 16, 2005, at 6:55 PM, Mark Womack wrote:
I will see if I can play with this tonight. It would be nice if these
settings could be controlled from our build.properties file instead of
setting property values in the command line.
Placing it in build.properties should the same effect as s
On Aug 16, 2005, at 4:33 PM, Mark Womack wrote:
The javac tag supports an "executable" attribute that lets you
specify a
path to the javac to use. Between that and the other attributes, I
think we
will have enough control to do what we want?
I agree that switching to the jdk 1.2 compile
On Aug 16, 2005, at 1:58 PM, Mark Womack wrote:
We can make it so that log4j is compatible with 1.2 and happy when
it runs.
Just compile using jdk 1.2 instead of jdk 1.3 or 1.4.
That should be possible, but I suggested using Jikes while producing
the distribution since it seemed to be an
The best option that I've found is to Jikes which doesn't appear to
trigger the annoying warning when running on earlier JVM's. Jikes
did have a problem with a class implementing an interface method that
had been marked deprecated, so in the following patch, the
@deprecation on LoggerRepos
On Aug 15, 2005, at 8:23 PM, Paul Smith wrote:
This does beg the question that one of the original design goals of
log4j 1.3 was that it's minimum requirement would be JDK 1.2. Are
we still all in favour of that? I would like to think that JDK 1.3
would be an acceptable minimum in this d
Things are not ideal when trying to run log4j 1.2.12 on JDK 1.2 or
1.1 and not at all happy when trying to build it there. Later javac
compilers should produce bytecode compatible with earlier JVM's, but
when attempting to run log4j on JDK 1.1 or JDK 1.2, you will likely
get a warning like
On Aug 5, 2005, at 12:08 PM, Mark Womack wrote:
I am going to build rc3 this weekend. We should treat that version
as the
final release candidate and move forward with final release,
hopefully by
the middle of next week.
If there are any concerns or issues, now is the time.
Thanks,
-Mark
I'll try to commit an update tonight (barring objection) that will
update the CVS HEAD to use slf4j-1.0-beta4 (currently uses beta3)
when compiled using the -Dslf4j=true switch. The major change is
that messages and format specifiers have been changed from Object to
String in org.slf4j.Lo
On Aug 2, 2005, at 12:08 AM, Mark Womack wrote:
Well, the most interesting slf4j development that I saw recently
was the new "marker" concept. Kind of nice way to allow the
developer to define "aspects" or "concerns" within their code.
Sure does multiply the number of methods though. It
On Jul 29, 2005, at 11:43 AM, Curt Arnold wrote:
On Jul 29, 2005, at 9:16 AM, Jacob Kjome wrote:
Of course, we could release a modified version of the DTD in
Log4j-1.2.12 with
the "name" attribute not declared as of type "id". Thoughts?
Using a type ID for name w
On Jul 29, 2005, at 9:16 AM, Jacob Kjome wrote:
Of course, we could release a modified version of the DTD in
Log4j-1.2.12 with
the "name" attribute not declared as of type "id". Thoughts?
Using a type ID for name was not a good choice, but I don't think we
can change it. If anybody was u
On Jul 27, 2005, at 10:08 PM, Mark Womack wrote:
For the bugs that have been marked as "1.2.12 candidate" that are
still open, here is the current review:
14551, 17227, 18122, 30804, 30819 are Javadoc related.
24159 - declined, will not be fixed for 1.2.12.
26345 - may be too dangerous, ne
On Jul 22, 2005, at 6:36 PM, Yoav Shapira wrote:
Hi,
I think we're being a little conservative: call the next one a
beta, and
hopefully we'll get more user testing and feedback ;) But either
way a new
build is welcome.
As long as beta does not imply that the API is frozen, I'd be willin
log4j-1.3-alpha-6 is getting a little stale, but we have not made any
progress on cleaning up the API to release anything that I'd feel
comfortable calling a beta. Any thoughts about releasing another
alpha in conjunction with upcoming log4j 1.2.12?
I've taken a pass through the 1.2.12 bug list (searching for log4j
bugs with the word "candidate" in a comment) and killed off the ones
that I wanted to and left the icky ones for everybody else. I'm
going to have to work on something else for a while.
The following bugs still seem to be p
On Jul 22, 2005, at 4:23 PM, Mark Womack wrote:
OK, so do we see that making this change does not affect
performance? This
change uses any String object, not the shared intern() version AND
it uses
String.equals() since it no longer depends on a the single intern()
reference.
And we shoul
On Jul 14, 2005, at 5:01 PM, Paul Smith wrote:
That is a biggie isn't it...
I feel quite a bit uncomfortable about attempting this for 1.2.x.
My rationale is that 1.2.x has been around a LONG time now. I know
"better the devil you know" is not a great way to develop software,
but in th
On Jul 11, 2005, at 8:16 AM, Rob Oxspring wrote:
Hi,
We've stumbled across a scenario where the location information
comes out with the method set to java and the classname ending
with . The problem occurs only after the first few calls to
the constructors in question and we've only se
On Jul 1, 2005, at 6:18 PM, Simon Kitching wrote:
On Fri, 2005-07-01 at 16:13 -0700, Mark Womack wrote:
This all seems sane to me. JCL will provide a way (eventually) to
choose
between the Log4j12Logger and the future Log4j13Logger? There is
a request
to add a method of determining the
On Jul 1, 2005, at 4:59 PM, Mark Womack wrote:
If we are going to restore classes that have been previously
removed, then
we should mark them as deprecated in favor of the classes/features
that are
replacing them in v1.3. In this case I believe it is the new
filtering
expression language
On Jul 1, 2005, at 12:43 PM, Mark Womack wrote:
I think we should target 7/13 as the date to finalize the set of
bugs to
include in the 1.2.12 release. Fixes/patches would be applied soon
after
that (they can be applied sooner if no objections) with a release
by the end
of July.
I see
On Jul 1, 2005, at 11:46 AM, Mark Womack wrote:
[getting ready to duck rotten eggs and tomatoes...]
What about just doing what the deprecation warning has been saying
for all
of the 1.2 release and getting rid of Category and Priority
altogether in
the 1.3 release? I think everyone has b
Since I alluded to my efforts in the "Shut off internal logger
output" thread in log4j-user, I thought I'd give a quick heads up.
After I addressed the problems that were causing the log4j 1.2 unit
tests to fail with later JVM's due to changes in stack trace in
logged exceptions (http://is
On Jun 28, 2005, at 11:32 AM, Yoav Shapira wrote:
Hi,
While they might help us as a one-time thing, this should become a
standard
part of our release process. Automation would be nice ;)
The older files under ASL 1.1 license do not need to be touched. Only
releases made since last ye
On Jun 28, 2005, at 12:30 AM, Carlos Sanchez wrote:
Hi,
I'm a maven PMC member and responsible of mantaining the maven repo at
ibiblio. We're getting requests to upload the latest log4j 1.2.9. The
point is that apache projects should use the apache java repo at
www.apache.org/dist/java-reposit
On Jun 26, 2005, at 9:08 AM, Syed Ghaznavi wrote:
Hi all,
My question is regarding the feature list for the future Log4J
releases, specifically 1.3.
I couldn’t find any information on the log4J website, indicating
the use (implementation) of SLF4J interfaces in Log4J.
Is SLF4J ever goin
Only affected the zip files, the tar.gz had the slash. I had thought
that I tested the zip downloads, but must have missed it. The slash
was missing in the CVS for the page prior to the 1.2.11 release,
though it might have been one the pages changed in place as part of
the 1.2.10 recall.
The Logging Services PMC is pleased to announce the release of log4j
1.2.11. Log4j version 1.2.11, is identical to version 1.2.9, except
that the class org.apache.log4j.or.jms.MessageRenderer is now
explicitly contained in the 1.2.11.jar. In previous releases of the
1.2 branch it was somet
Do either of these apply to your situation?
http://mail-archives.apache.org/mod_mbox/logging-log4j-user/
200402.mbox/%
[EMAIL PROTECTED]
bank.com%3E
http://www-1.ibm.com/support/docview.wss?
rs=180&context=SSEQTP&uid=swg1PQ80288
---
+1
With the following comments (all of which are carried over from 1.2.9
and should have been mentioned earlier):
The ls-logo.jpg is always fetched from http://logging.apache.org/
images, not from ./images like the other images. ls-logo.jpg would
need to be added to the docs/images direct
On Jun 19, 2005, at 5:26 PM, Yoav Shapira wrote:
Hi,
Hmm, I could swear the Releases section in http://www.apache.org/
dev/ had a
thing about PGP usage. Basically, by signing a release you vouch
that it's
legit.
Yoav Shapira
Maybe you were thinking of one of these:
http://www.apache
On Jun 18, 2005, at 12:02 AM, Simon Kitching wrote:
The current migration strategy actually is:
in 1.3)
* formally deprecate Category and Priority
* change Priority/Level class hierarchies so that all existing code
compiled against log4j1.2 which uses method
Logger.log(String, Leve
On Jun 2, 2005, at 12:33 AM, Mark Womack wrote:
I am running the test cases against the 1.2.11 code, and the
minimum case fails right off the bat:
Minimum:
[junit] Running org.apache.log4j.MinimumTestCase
[junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed:
0.501 sec
[juni
--- Additional Comments From [EMAIL PROTECTED] 2005-05-27
07:10 ---
re: 4) Give docs dir a thorough once over to make sure all is valid.
Mark, if you can generate the docs and put them up somewhere, I
could give them
a review?
The easiest approach would be to commit them to the
On May 26, 2005, at 11:19 PM, Mark Womack wrote:
It just seems wierd to me that the 1.2 stuff has it's own version
of all the web pages. These are not uploaded to the logging site,
right? The ones from logging-site cvs are uploaded to the site?
Would appreciate some help figuring this
FYI: Jakarta Commons VFS is in the process of leaving the sandbox.
If I remember correctly, Chainsaw uses it. Saw the item and thought
I'd give everybody a heads up.
See http://marc.theaimsgroup.com/?l=jakarta-commons-
dev&m=111696649015606&w=2
--
Sorry about that. I've added the AvoidStarImports rule to src/
sun_checks.xml file which is used to configure checkstyle. It
appears that Jalopy should be able to optimize imports (http://
jalopy.sourceforge.net/imports.html) but it unclear how that text
should be translated to the Jalopy X
On May 25, 2005, at 6:30 PM, Andy McBride wrote:
I don't see how you could make Level final in a 1.x release.
Version labels have been real fluid but it would likely fit in a
release where intentional breaking changes which would indicate a x.0
release.
As you can not
deprecate the c
On May 25, 2005, at 6:01 PM, Mark Womack wrote:
- What happens in a tool like chainsaw that is receiving logging
events from
several sources, each of which could have their own custom Levels
defined?
I imagine this happens today when a developer extends log4j to
support their
levels?
I
On May 25, 2005, at 4:59 PM, Scott Deboy wrote:
This shouldn't be a factory. I don't want to have to manage the
instance, but I do want to reference the instance from anywhere
(this is assuming support for levels outside of TRACE, regardless
of if we still support the trace helper methods
I was surprised that it was hard to find a lot of previous discussion
or previous bugs on the issue. If anybody else has links to relevant
discussions, please add them. Here are some that I found:
Recent log4j-user discussion (assume existence of problem): http://
marc.theaimsgroup.com/
Like most java appilicatios today, log4j relies on ANT as its build
-tool. ANT is availale from "http://jakarta.apache.org/ant/";. ANT
+tool. ANT is availale from "http://ant.apache.org/";. ANT
While you are at it:
s/applicatios/applications/
s/availale/available/
-
On May 23, 2005, at 11:54 PM, Paul Smith wrote:
August! Probably why I don't remember it. I don't remember last
week as it is... :) I love the idea of Asnyc roll/compress, as the
mail thread pointed out, a system can be blocking quite a while if
the log file is being compressed in a sync
On May 23, 2005, at 6:58 PM, Paul Smith wrote:
Hi Curt, I'm just looking at bug 34979, and it says "...suggested
during the port of those classes to log4jcxx'.
Sorry, that was a little cryptic. Porting the log4j 1.3
RollingFileAppender framework to log4cxx (http://issues.apache.org/
j
I subscribe to the Gump list and there has been chatter that I'm not
sure I'm interpreting correctly, but it appears that the main Gump
server "Brutus" is being redeployed so Gump will be off-line for a
few days and will be reborn running on a VM somewhere.
Gump wouldn't be appropriate for r
On May 19, 2005, at 9:22 AM, Mark Womack wrote:
I was hoping that Ceki would decide to drive this, but since he
appears to be unwilling, choosing to instead create a fork of log4j
1.2.9 within the slf4j group (NLOG4J), I am going to pick this up.
Being the optimist, I believe there is a solu
On May 18, 2005, at 2:54 PM, Ceki Gülcü wrote:
I'd lean against adding the TRACE level to the 1.2 branch. Scott
and Jake may feel the same way. In my opinion, the TRACE level
promotes bad habits, especially in light of the confusion between
TRACE and DEBUG. There is also the question of back
On May 17, 2005, at 8:43 PM, Paul Smith wrote:
Is there a specific reason that Paul is assigned to do the jDiff
report (i.e. previous involvement with jDiff, etc)? I've got a
high priority task at the moment, but expect I could get it done
today or tomorrow.
Other than I wouldn't mind doin
I'm still trying to work out some of the kinks with the Clover
coverage report. I'm going to have to do some tweaks to tests/
build.xml to get the process repeatable, but I did manage to nurse a
run to completion and have placed the results at http://
home.houston.rr.com/curta/coverage-20050
On May 17, 2005, at 10:59 AM, Mark Womack wrote:
So, Paul, you are +1 on the overall proposal? Hashing out the
specific bug
fixes for 1.2.12 is a TBD. I was not suggesting that these
specific fixes
had to go in as part of the proposal. Appreciate the quick review.
And, of course, when you
On May 16, 2005, at 11:53 AM, Mark Womack wrote:
I figured that a "[VOTE]" message would get folks more interested in
discussing. :-) Here is proposal #2.
Assume that we will adequately inform the user base what is going
on with
the versions, starting with a detailed email to the user list.
1
On May 12, 2005, at 6:44 PM, Andy McBride wrote:
Hi,
The current cvs head contains breaking changes including the
removal of
org.apache.log4j.jmx.HierarchyDynamicMBean,
org.apache.log4j.spi.ErrorHandler and
org.apache.log4j.spi.ErrorCode without
any apparent replacement or deprecation cycle.
N
On May 12, 2005, at 12:05 PM, Yoav Shapira wrote:
3) Release a 1.4 version with the TRACE change and other fixes
that will
make life happier for the user base (action item: determine the
other
changes). No major structural changes. Just most "important"
bugfixes.
The base of the 1.4 code wo
I was just thinking the same thing. Relabeling the 1.3 as 1.5 gives
us the option to do an interim minor release and have something to
call it even if the decision to actually prepare a release to occupy
that number was deferred. And it also preserves the big 2.0 for
bigger changes (so lo
The 1.2.x development branch has been locked down for quite a while
in anticipation of a forthcoming 1.3 release. It has been suggested
that a minor release from the 1.2.x branch that addresses more than
just critical bugs could be beneficial. If the log4j 1.3 development
is relabeled as
There have been suggestions that it may be beneficial to relabel the
current log4j 1.3 branch as log4j 2.0 and have an interim minor
release from the 1.2.x branch designated 1.2.11 or 1.4.0 (will be
raised in a separate thread).
The current 1.3 branch is a substantial enough change from the
I've just committed changes to the logging-site and log4j CVS that
would change the web site, but I have not updated the site to allow
some time for comments before going live. The web site currently
does not correspond to a specific state of the CVS since the download
page was forced back
Gump failure of tests was due to the new serialization checking
tests. Checks for identical binary streams with some explicit bytes
to skip that have been observed to change values over time or between
platforms. The exception test is the most sensitive and I have not
previously seen a di
On May 7, 2005, at 6:15 PM, Claudio Corsi wrote:
Curt,
I noticed that you removed the protected closeWriter method. This need
to be included because these streams should not be closed.
They aren't. SystemOutStream.close does not call down to
System.out.close.
I also wanted to point out that
One use case for this would be to force roll-over of files at
particular times. However, if that is the only use case there might be
simpler approach within the RFA framework.
Could you elaborate on other use cases that you are wanting to support?
On May 6, 2005, at 2:32 PM, Glen wrote:
Hi All,
On a similar note, HouseKeepingFileAppender might be better done as a
RollingPolicy for the log4j 1.3 RollingFileAppender framework.
I wouldn't discourage your from filing bugs with the use-cases that you
were trying to support. At least that would allow us to know what
concerns prompted the d
I think it would be highly unlikely that I would change my opinion
about the implementation technique for the legacy branch. A facade
pattern is really the only satisfactory approach that could support the
already deployed log4j 1.2 releases. Acceptance of slf4j among people
who don't trust t
On May 4, 2005, at 11:06 AM, Mark Womack wrote:
Great, I am +1 with the modified proposal.
We will clean up the web site appropriately, but I need to get up to
speed
on that stuff.
How about this, once you have tagged the CVS modules and given the all
clear, I'll commit my changes to the XML so
On May 4, 2005, at 9:03 AM, Mark Womack wrote:
Actually, you beat me to this, but I have a slight alteration to your
proposal:
Current 1.2 branch is tagged/moved to a new branch called 1_2_slf4j
and will be available for modification and "experimental" slf4j
builds. The "head" of the 1.2 branc
On May 4, 2005, at 1:04 AM, Scott Deboy wrote:
I agree that LoggingEvent should be serial-compatible with previous
versions (1.2.7/8 at a minimum).
If Chainsaw were to have its own release cycle, we would release a lot
more often than log4j and also plan releases to coincide with log4j's
releas
501 - 600 of 772 matches
Mail list logo
