Viet Pham wrote:
I am from Market Development Engineering department at Sun Microsystems.
I have some questions about log4j Solaris 10 supports. Could you please
point me to the right person? Thanks.
I'm going to go out on a limb here and suggest that the right place to
get answers about log4j is
Tommi Maekitalo wrote:
I personally feel, that the whole logstream-concept is broken by design. I use
streams heavily, but don't use logstream. I have a macro, which encapsulates
this whole formatting-stuff. I instantiate a ostringstream, when loging is
enabled. Here is my macro-definition:
#de
Curt Arnold wrote:
On Dec 22, 2004, at 4:33 PM, Christopher Sm ith wrote:
With the normal idiom for logstreams you would want different streams
for each log level which would avoid this issue entirely.
What "normal" idiom? I'm not aware of any established patterns for
using a STL stream-like in
Curt Arnold wrote:
On Dec 21, 2004, at 7:12 PM, Christopher Smith wrote:
If it isn't derived from std::ios_base, then manipulators like
std::width etc can't be applied.
Actually, I believe my delegation based approach to doing logger
streams did work just fine with IO maniplulato
Curt Arnold wrote:
On Dec 21, 2004, at 5:34 PM, Tommi Mäkitalo wrote:
I think it would be better to derive logstream from ostream or do not
derive at all. I removed the base-class and the example-program works now.
Here is my patch.
I had originally implemented this based on std::basic_ostream
b
Tommi Mäkitalo wrote:
I just would like to know, if logstream works at all? The example-program
segfaults, when it tries to print something. It is a platform-specific
problem (SuSE 9.2/x86-84)?
Hmm.. they work fine for me. It'd be intersting to know where it's
segfaulting. Have you tried the alt
So, I think in a perfect world, we'd want our logging package to depend
on as few other libraries as possible. I'll have to look at the timezone
code, but I have to think that there is some way to avoid the TZ problem
using standard libraries.
I love ICU, but it seems like a huge library just t
Curt Arnold wrote:
No it is still helpful. I threw together the CVS stuff in a few hours
to keep the conversation going and getting it to work and getting the
API right were the priorities. Deriving log4cxx::basic_logstreambuf
from std::basic_stringbuf was expedient to get things functional, b
Curt Arnold wrote:
The benchmark, like all benchmarks, is synthetic. This one assumes
that a log stream is allocated for each logging request which I would
assume is very atypical. I'd expect that most of the cost is in the
construction of std::basic_stringbuf, but would love to see a profile
Christopher Smith wrote:
P.S.: I just noticed some performance optimizations to LocationInfo
committed into CVS. I'll rerun and see if they have any impact on
these results.
Looks like it shaved off about 100ns per iteration across the board.
--Chris
Christopher Smith wrote:
Curt Arnold wrote:
On Oct 7, 2004, at 2:51 PM, Christopher Smith wrote:
1) You pay the price of constructing std::basic_stream regardless of
whether logging is turned on.
Do you have any metrics on the cost of that?
No, but I may have some in a week or so. I'll
Curt Arnold wrote:
I mentioned this back in our earlier emails
(http://nagoya.apache.org/eyebrowse/ReadMsg?listName=log4cxx-
[EMAIL PROTECTED]&msgNo=272, see point 1), I was surprised when
your submission didn't derive from basic_ostream.
You were thinking inheritence and I was thinking deleg
Curt Arnold wrote:
On Oct 7, 2004, at 2:51 PM, Christopher Smith wrote:
1) You pay the price of constructing std::basic_stream regardless of
whether logging is turned on.
Do you have any metrics on the cost of that?
No, but I may have some in a week or so. I'll post them as soon as I do.
I
Curt Arnold wrote:
Some additional comments on the patch are available at the bug report,
LOGCXX-18. The major difference is that this logstream is derived from
std::basic_stream and can be passed to methods expecting that stream.
The insertion operator will typically be short-circuited when
Curt Arnold wrote:
Thanks, Please submit it as a bug request since that has a explicit
statement that you are donating the code to ASF and I'll get it in
shortly.
Done. ID is LOGCXX-18.
I fixed forcedLog before submitting it.
--Chris
Christopher Smith wrote:
7) The code is specifically designed so an optimizer can produce code
that only checks logging levels once per log event.
Ugh. I knew I'd make a mistake. ;-)
This is not quite true. The current code actually requires 2 checks per
log event. This is because o
I think the discussion of idea will work better with an implementation
to look at. Please find attached my implementation. I wanted to try to
clean it up a bit more, but realized my time was short and it was better
to just post and let others provide feedback. A few quick notes:
1) I am not hap
Tommi Maekitalo wrote:
Am Dienstag, 5. Oktober 2004 01:44 schrieb Christopher Smith:
...
LoggingStream foo(logger, WARN);
foo << "We got: " << anInt << " for a total of: " << anotherInt;
foo << " and an average of: " << aFloat &
Curt Arnold wrote:
Per the previous discussion on iostream-free log4cxx, this alternative
API should be completely optional. Ideally included in its own header
(log4cxx/loggingstream.h?) and delegating to the primary API.
Yup, I set it up entirely in a header.
A couple of issues:
1. It would be
Curt Arnold wrote:
Could you not go with standard iostreams for log4cxx then? I mean,
given that iostreams tend to be entirely in headers, it seems like
you could compile log4cxx with an iostreams library independant of
what your customers have.
At least for the Microsoft platform, you are no
Once again, as a former log4cpp user, I've identified something that
log4cxx appears to be missing but which I'd like to have: LoggingStreams
(or CategoryStreams as they are called in log4cpp).
These are streams that are tied to a particular Logger and priority
level. This allows you to do some
Ken Knox wrote:
I'm investigating the posibility of using log4cxx in a middleware
product - the Java port of which already uses log4j. As we ship on
numerous platforms and because of the fact that we provide libraries
which our customers link with, we have to make as few assumptions
about customer
On Sun, 2004-09-26 at 05:10, Christophe de Vienne wrote:
> The NDC constructor/desctructor already implement RAII. One can write :
Now I feel silly. :-(
Hmmm... It looks like the NDC constructor (and destructor for that
matter) aren't documented. Looks like that psyched me out.
--Chris
So, I just started playing with log4cxx today. I've used log4cpp in the
past, but it appears to have stagnated, so I thought I'd make a change.
Anyway, one of the first things I noticed was that NDC's don't have a
natural way to follow the RAII paradigm to ensure they get cleaned up. I
made a s
24 matches
Mail list logo
