after these others.
--
Jess Holle
So use a separate SimpleDateFormat for each thread ala ThreadLocal.
I've been doing that in a patch to log4j 1.2 for a long time now --
along with moving the formatting out of the sync appender block on a
per-layout-class opt-in basis.
Yes, I should move to log4j 2.x, but I've had these concu
Is anyone going to vote on 1.2.17.1?
I'll use this release in any case, but it would be nice if this was the
latest public release in general.
On 10/21/2013 9:26 AM, Christian Grobmeier wrote:
On 21 Oct 2013, at 15:28, Jess Holle wrote:
Packaging now looks good at a glance as I now s
Packaging now looks good at a glance as I now see no duplication.
I don't own the code in our application that actually uses this, nor
even know where the test cases are, however -- plus my vote doesn't
actually count anyway -- so I'll leave that to others.
On 10/21/2013 3:20 AM, Christian Gr
ng went a bit sideways with the -bin jar.
The source jar is correct (no Appender class), but the -bin jar does
have the additional classes in it.
Well, let's not kick ourselves too long. Who wants to cut a 1.2.17.1?
Gary
Scott
On 10/20/13, Jess Holle mailto:je...@ptc.com>
y
(thanks to Daniel Stankiewicz) Fixes 53536.
- DBAppender has a compile error (thanks to Antonio Petrelli) Fixes
53645.
- Prefixed FormattingInfo and PatternParser with Extras to avoid
classloading conflict
- Fixed product naming
- Removed duplicated classes (thanks to Jess Holle for s
I'm guilty of that weird (and useless) style -- for me it's an old habit
from C days where I frequently defined a return(X) macro when doing
certain types of troubleshooting.
While this case is useless, it's also harmless.
On 5/13/2013 10:14 AM, Gary Gregory wrote:
The parentheses are useless
Useless parentheses are not useless if they make it easier to comprehend
code.
Not everyone remembers && vs. || precedence rules as well as */ vs +-
precedence.
On 5/13/2013 10:09 AM, Nick Williams wrote:
The PMD inspector says the following if statement contains "Useless
parentheses."
That'd work too.
On 5/4/2013 8:53 AM, Gary Gregory wrote:
Why not number the extras module the same as the version of log4j it requires?
Gary
On May 4, 2013, at 8:33, Jess Holle wrote:
On 5/4/2013 7:02 AM, Christian Grobmeier wrote:
Thank you for reminding me. I did a quick check, t
.16 if
not 1.2.17. Jess, would this work for you?
I'm absolutely fine with requiring 1.2.17.
--
Jess Holle
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
cific
minimum log4j 1.2.x version that provides all the classes (and methods)
it needs, as I /suspect /that log4j-extras includes log4j classes to try
to work with older log4j versions. Including redundant classes is not
really a solution, though, as it causes issues like that noted above.
--
Jes
t;install" goal by default.
When running in this simple, default, I-know-nothing-about-the-POM mode,
~20 tests failed.
As for filing an issue, at this point I guess I'll just be very, very
careful about moving to 1.2 -- and will be sure to manually gut the jar
file as needed at that point.
--
Jess Holle
if anyone
else is trying to use or support log4j-extras they should know.
--
Jess Holle
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
I don't have a vote, but in spirit I'm definitely +1.
At this point I'd be quite happy requiring Java 6. In fact the log4j I
use is patched with several locking improvements one of which requires
Java 6.
--
Jess Holle
On 4/10/2012 6:19 AM, Jacob Kjome wrote:
+1
Of course
On 2/22/2010 2:14 AM, Ralph Goers wrote:
On Feb 21, 2010, at 5:22 PM, Jess Holle wrote:
On 2/20/2010 11:16 AM, Ralph Goers wrote:
One thing I'd like to make sure is not lost is an easy way to pass an Object
rather than a String.
I'd prefer a Message instead of an Object. T
On 2/20/2010 11:16 AM, Ralph Goers wrote:
One thing I'd like to make sure is not lost is an easy way to pass an Object
rather than a String.
I'd prefer a Message instead of an Object. The primary difference is that the
Message is an interface that looks like:
That initially seems rea
es.
If only a String is passed or using clumsy syntax is required to pass an
Object, then such richly structured output is defeated.
--
Jess Holle
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additio
Curt Arnold wrote:
On Oct 9, 2009, at 8:18 AM, Jess Holle wrote:
Curt Arnold wrote:
2. org.apache.log4j.RollingFileAppender and
org.apache.log4j.DailyRollingFileAppender have a disproportionate
number of bugs. The extras companion has the log4j 1.3 rework which
still is subject to the
best solution to these
requires Java 5. In others, it may not be possible to maintain absolute
compatibility (though I think I'm awfully close).
--
Jess Holle
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apac
Or I can keep using log4j :-)
And patch it myself as needed -- as it is indeed hard to get necessary
improvements into log4j 1.2.x at this point. I have my own Java 5
specific changes to reduce locking, etc, at this point.
Ceki Gulcu wrote:
Jess Holle wrote:
To be fair and clear, my usage
dig one's heels so as to
prevent change based on the backward compatibility argument.
The changes I am proposing will affect an extremely small minority,
say less than 1 user in 100'000,
Jess Holle immediately responded when the idea was floated that it
would break his use of log
Ralph
On Oct 4, 2009, at 11:53 AM, Jess Holle wrote:
Code using using org.apache.log4j.Logger would continue to work as
is, ensuring backward compatibility, at least as far as the log4j
signatures are concerned. Users who rely on the fact that the
message argument was an Object instead of Strin
place various fields into separate relational database
columns.
Losing first class access to such abilities is a non-starter.
--
Jess Holle
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional
I think you need to debug this in your case.
Logging from RMI threads/frameworks works just fine in general.
ShivaVarma wrote:
Hi.
Logging around the RMI framework works, but logs in the code invoked by the
RMI framework do not get printed either to standard output or to a file. Any
workaround
Sounds bizarre. This clearly isn't a simple matter of just an RMI
problem -- as your description applies to plenty of code that works just
fine with log4j.
ShivaVarma wrote:
Hi
My RMI framework, spawns multiple classes, containing log4J log
statements, however, none of these log statements
igures the system. I can see use cases for multiple-processes
writing to one file, but I'd personally rather avoid the extra
contention inherent in this.
--
Jess Holle
Curt Arnold wrote:
On Aug 7, 2009, at 2:16 AM, Scott Deboy wrote:
Is it possible to use the new implementation and p
Curt Arnold wrote:
On May 13, 2009, at 6:19 AM, Jess Holle wrote:
Curt Arnold wrote:
Sorry hadn't followed that one. It seems like a good replacement
for some not ready for primetime code that has been in log4j for a
while. However, since it is all new code and not any modification
resent,
it would be good to remove those...]
--
Jess Holle
Isn't this class still available via the OpenDMK project
(https://opendmk.dev.java.net/)? I didn't see any plans for this to be
removed.
I recently built log4j just fine with this -- albeit with Java 5 and its
built in JMX classes rather than an external JMX library.
Curt Arnold wrote:
On
re were cases [whose details I forget,
unfortunately], where a logical list of data was converted into a
dynamic attribute set -- to ill effect. I used child MBeans for such
cases -- which also allowed for broader/deeper configuration coverage.
--
Jess Holle
Curt Arnold (JIRA) wrote:
log4j
e or more popular AOP tools, though.
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
this thread is how much
compatibility should be maintained for existing Appenders, Layouts, etc.
I can see that we'd want new improved Appenders and Layouts and base
classes thereof, but could also see it making migration more palatable
if ol
Curt Arnold wrote:
On Jun 5, 2008, at 7:19 PM, Jess Holle wrote:
For my own usage I went ahead and completed the a set of changes to
reduce log4j 1.2.x's locking and deadlock potential. The results are
attached and make unabashed use of Java 5 -- as from discussion to
this point it
Jess Holle wrote:
o I created an AppenderSkeleton alternative for our own
usage similar to ConcurrentAppender but different in
several respects.
+ ConcurrentAppender relies on all sorts of stuff from
outside the core log4j jar
?
I'd argue not. log4j 1.2.x works well enough for pre-Java-5 and
Java 5 provides compelling advantages.
* Etc...
--
Jess Holle
# This patch file was generated by NetBeans IDE
# Following Index: paths are relative to: D:\User
Profiles\jessh.PTCNET\Desktop\log4jsvn
# This
Curt Arnold wrote:
On May 19, 2008, at 11:22 AM, Jess Holle wrote:
If it is sufficiently compelling it appears it would be possible to
rework AppenderSkeleton without breaking most extensions thereof but
allowing Layout.format() to be hoisted out of the synchronization
block in cases where
Jess Holle wrote:
Curt Arnold wrote:
Exactly. Almost nothing inside of log4j 1.2.x is inherently
thread-safe and depends on a big, coarse-grained synchronization lock
to insure safety. Almost any incremental improvement has the
potential for breaking compatibility.
Significantly
uot; (next generation) modules.
In the nearer term my proposed changes would at least reduce the
duration of synchronization in any cases where multiple appenders are
being used on one logger and allow one to produce a high-performance,
reduce/no loc
Jess Holle wrote:
Thanks.
I'm also starting to ponder whether there's a mostly compatible way to
reduce locking in AppenderSkeleton and WriterAppender.
For instance, we could add a special Layout interface that would allow
the String to be pre-computed prior to holding the lock
Thanks.
I'm also starting to ponder whether there's a mostly compatible way to
reduce locking in AppenderSkeleton and WriterAppender.
For instance, we could add a special Layout interface that would allow
the String to be pre-computed prior to holding the lock (but after
filters and threshol
cating the desired synchronization policy.
At least this issue can be worked around by creating your own appender.
Jess Holle wrote:
By the way, I am aware that these changes don't (yet) address the
opportunity for deadlock. That'll come later (hopefully).
This just *reduces* both the bot
By the way, I am aware that these changes don't (yet) address the
opportunity for deadlock. That'll come later (hopefully).
This just *reduces* both the bottleneck and deadlock potential.
Jess Holle wrote:
I made a slight adjustment to the pre-Java-5 solution and replaced it
(uncon
I made a slight adjustment to the pre-Java-5 solution and replaced it
(unconditionally here, though this could easily be made conditional)
with a Java 5 implementation.
Jess Holle wrote:
We as many others have been bitten by the synchronization nuances of
log4j.
Attached is a proposed patch
some
discussion as to what's wrong with such a change, etc.
I was considering using Java 5 features here and could, but the key
issue here does not appear to require such fanciness to address.
--
Jess Holle
# This patch file was generated by NetBeans IDE
# Following Index: paths are relative t
?
--
Jess Holle
entify across JVMs -- where part of the id is a sequence
within a given JVM but the other portions are a best attempt at being
unique across JVMs via various mechanisms (e.g. in Java 5 you have
unofficial access to the process id and then you have hostna
-site (vs. extension) usage is still critical from my standpoint in
any case -- else you might as well switch logging frameworks entirely.
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
to have. Obviously anyone can make one, it would be nice to have
one in the distribution.
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
MBeans for log4j. I looked at how the
built-in log4j MBeans did things, but went my own way in a good number
of cases and added support for multiple LoggerRepository's. I'd share
my MBeans, but my employer wouldn't like that -- and they use other
pieces of our JMX framework anyway.
--
Jess Holle
e log4j configuration file and reconfigure when it
changes -- not instantaneous, but still no restart required.
--
Jess Holle
Will Sargent wrote:
Hi all,
I've heard several people ask if you can change log4j levels
dynamically, once the application is already running. I see that
there&#
Paul Smith wrote:
On 05/04/2007, at 6:51 AM, Jess Holle wrote:
I didn't know about the MDC treatment -- I'll have to look into that.
Otherwise, I knew that #2 and #3 were covered by the existing
Chainsaw. I just didn't want to give up any of that to get #1
covered -- and d
able log4j
1.3.x and use that -- but at this point it does not matter whether this
is technically possible, the 1.3.x stream has enough of a troubled
history that a new version # is really needed to clear the air if
nothing else.]
--
Jess Holle
Scott Deboy wrote:
# 1 is relatively easy to achie
ry selectors, JMX MBeans
that account for and handle multiple repositories, etc.
o I'd give these up if the library fulfilled these roles
completely adequately. The MBeans would actually be
most difficult to give up as I really like mine :-)
--
Jess Holle
one by having Object messages -- apart
from the simple (but useful) lazy invocation of toString().
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Curt Arnold wrote:
On Apr 3, 2007, at 9:33 AM, Jess Holle wrote:
Largely I won't disagree.
That said, I think there is a point to having a new log4j version
that is almost entirely API (source and binary) compatible with log4j
1.2.14, but:
Has finer-grained synchronization and elimi
hus avoids fracturing log4j's
mindshare. Instead deployers could simply decide on the version of
log4j that best met their needs, e.g. old JVM compatible or not, etc.
--
Jess Holle
P.S. Okay, the ability to add a listener to a repository for log level
changes (as per log4j 1.3'
t is simply not possible if you use some XSLT functionality).]
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Jess Holle wrote:
Curt Arnold wrote:
One things that seemed potentially interesting is to have
a JMX appender that would allow log4j calls to generate JMX events.
That would seem to be trivial.
My approach has been to do any/all JMX notification in prior to and/or
in parallel to
such notifications that you
cannot see initially. For such cases, such an appender seems like a
very good thing.
Dumb question along these lines: how does one reliably get the entire
MDC for a logging event, e.g. as a Map/Hashtable, from within an
appender? I can see how to do everything else easily enough, but
that's one little nit.
--
Jess Holle
t back into old JVM's maintenance releases.]
--
Jess Holle
Endre Stølsvik wrote:
On Thu, 23 Feb 2006, Boris Unckel wrote:
| Mark Womack wrote:
| > What base JDK version do we want to support for log4j 1.3? > JDK 1.2?
| > > JDK 1.3?
| +1 for version >= JDK 1.3
| with jav
rsion
prior to latest yet want the latest log4j?"
Boris Unckel wrote:
Jess Holle wrote:
I'm sure I'm in the minority here, but 1.2.13 seems fine for "legacy"
versions of Java, i.e. everything prior to Java 5.
I'd be fine with requiring Java 5 for log4j 1.3 and using
I'm sure I'm in the minority here, but 1.2.13 seems fine for "legacy"
versions of Java, i.e. everything prior to Java 5.
I'd be fine with requiring Java 5 for log4j 1.3 and using the best
concurrency, etc, utilities it has to offer.
--
Jess Holle
Mark Womack wro
I've written up the bugs, though I must admit the detail is rather
minimal as I was pressed for time.
--
Jess Holle
Mark Womack wrote:
Jess, can you write these 2 up as bugs?
Thanks for the review!
-Mark
On 2/4/06, Jess Holle <[EMAIL PROTECTED]> wrote:
Another is
Another issue:
log4j 1.3 alpha 8 triggers throws SecurityExceptions when you attempt to
use it from within an applet in a Java 5 JVM.
[It attempts to read a system property during LogManager static
initialization without wrapping this in a try/catch.]
Jess Holle wrote:
Oh. I mispoke
Oh. I mispoke slightly -- I had to leave one change in place.
DailyRollingFileAppender no longer extends FileAppender in log4j 1.3
alpha 8, which is noticeable to my code. I already had workarounds in
place, however, so I just need to keep those in place.
--
Jess Holle
Jess Holle wrote
fire JMX notifications on this basis).
Overall 1.3 alpha 8 worked just fine from my short testing. Good work
everyone!
--
Jess Holle
Jess Holle wrote:
Mark Womack wrote:
Jesse, we'll be very interested in what you find compatibility-wise
with the new alpha-8 version.
:-)
Sorry, I'
Mark Womack wrote:
Jesse, we'll be very interested in what you find compatibility-wise
with the new alpha-8 version.
:-)
Sorry, I've been preoccupied with a number of other efforts and have not
had time to check yet.
Doing so would clearly be a good thing, though....
--
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
nd the plan
for their delivery is a clear next step.
--
Jess Holle
og4j2?)
I believe that's a must -- else you pose serious issues to both those
attempting to use log4j 1.x and those attempting to use log4j 2.x --
they'll be stepping on each other in practice otherwise.
--
Jess Holle
-
rd place
you can always apply changes to your own copy yourself.
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
h-end" usage, so all-in-all I can see leaving
this as it is in 1.3 if everyone else can.]
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
ss on the server side at that point.
Moreover one has to wonder how many pre-Java-5 environments are going to
bother deploying new versions of log4j...
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
out that folk are busy with ApacheCon, however, as I
really was worried that the log4j development community was this sleepy
that loud, obnoxious raising of serious issues didn't stir too much
response or immediate action. Putting this in context wi
Curt Arnold wrote:
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
e and require Java 5 and higher for all new development at
this point, which may make us unusual, but that's where we're at. I
understand the need to support earlier JVMs, but am interested in
squeezing the best possible performance and scalability out under Java 5.
tely, uses Avalon).
Let's stop the code-purity madness, preserve binary compatibility of
existing common libraries and end-user code usages, and
move on to produce better, faster, and more flexible logging!
--
Jess Holle
Jess Holle wrote:
Finally, I hope to get a chance to chase the lack of appender removal
and log level change event firings and propose patches for these issues
as well.
Attached is a patch that adds event firing upon appender removal and
log level change.
Please take this patch. The
P.S. I filed bug #37735
on this and attached the patch to it.
Jess Holle wrote:
Okay, first off, I must apologize for going off half-cocked and
somewhat rudely after running into issues earlier this week.
Secondly, I must admit that I was way offbase on some of my analysis of
the
event firings and propose patches for these issues
as well.
--
Jess Holle
Index: Level.java
===
--- Level.java (revision 349818)
+++ Level.java (working copy)
@@ -36,99 +36,9 @@
@author Ceki Gülcü
@author Yoav Shapira
SVN or CVS at this point? Is HEAD reasonably stable at
the moment? If so, I can tinker with this and propose diffs.
--
Jess Holle
to address the deadlock issues should be
made in 1.3. It was my understanding that such an attempt had already
been made in 1.3. Am I mistaken?
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional c
I have no vote as I'm not a commiter, but 1.2.13rc2 works fine for me.
--
Jess Holle
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 b
e deadlock in my application yet, so
it may never hit it. The specter of such an issue cannot be accepted
for long, however.
--
Jess Holle
hanges necessary for 1.3 were limited to relative
few files in a few modules which generally were making more elaborate
usage of log4j than what might be consider the 80-90% case of simple
Logger/Level usage.
--
Jess Holle
-
Specific MBean subclasses for various appender types so you can
tail log files from JMX, properly interact with asynch appenders, etc.
Numerous bugs
--
Jess Holle
Paul Smith wrote:
On 29/11/2005, at 7:47 AM, Elias Ross wrote:
On Mon, 2005-11-28 at 14:07 -0600, Jess Holle wrote:
What is breaking so much source code and many existing binaries really
buying?
In my opinion, removing "Category" would be just like Sun deciding
dlock will just have to be
accepted, of course.]
--
Jess Holle
Elias Ross wrote:
On Mon, 2005-11-28 at 14:07 -0600, Jess Holle wrote:
What is breaking so much source code and many existing binaries really
buying?
In my opinion, removing "Category" would be ju
Jess Holle wrote:
Also give that most legacy libraries won't be recompiled against a
hypothetical 1.2.13 real soon, there is still something to be said for
either:
Reintroducing Category and Priority
Sure their existence is ugly but how much did they *really*
hurt a
piled legacy sources.
--
Jess Holle
Jess Holle wrote:
Jess Holle wrote:
P.S. As log4j 1.3 now stands, I'd think it would be tempting to
repackage all of log4j 1.3 in org.apache.log4j2.* and call it
log4j 2.0. That way you could have log4j 1.2 and 1.3/2.0 in the same
classloader
Jess Holle wrote:
P.S. As log4j 1.3 now stands, I'd think it would be tempting to
repackage all of log4j 1.3 in org.apache.log4j2.* and call it
log4j 2.0. That way you could have log4j 1.2 and 1.3/2.0 in the same
classloader at the same time without having to worry about some l
ust recompile
against 1.3 at that point. I'm a bit doubtful that nothing else would
break, however!
--
Jess Holle
would seem to hurt the log4j community if the 1.3
release was to occur today. On the other hand assuming nothing else
broke that I use that in turn uses log4j, I'd personally just recompile
against 1.3 at that point. I'm a bit doubtful that nothing else would
break, however!
--
Jess Holle
93 matches
Mail list logo
