On Aug 12, 2004, at 12:34 AM, troy d.straszheim wrote:
Hi log4cxx --
I have a feature written, I wonder if log4cxx wants it.
there are the handy LOG4CXX_DEBUG(log, message) macros. The thing
that gets me is that it won't do formatstring/args like printf.
...
If there is any interest I'll send on
I'm uncomfortable with that solution, but I'm on deadline on something
else and can't research it now. It is a problem that needs to be
fixed, but I'd like to fix it by eliminating implementation details
(like the config_auto.h) from the expansions of the API include files
like logger.h.
On A
On Aug 12, 2004, at 3:53 PM, c wrote:
I agree with you, Curt. But I think it's a good short term solution to
help developers who are blocked with the current implementation.
The solution you refer to is surely the best one, but much work will
be needed to achieve it. Consequently, we could delive
I just rebuilt log4cxx on Linux to sanity check yesterday's changes.
That went okay, but when I ran performance/logging.sh, I got messages
like:
Results: performance/logging.sh: line 1: ./logging: No such file or
directory
performance/logging.sh: line 43: [: -lt: unary operator expected
I don
Every part in the chain believes that it can treat the messages as
text. A file appender, for example, would possibly apply a character
set encoding conversion before outputting a file. It would be unlikely
that your binary extraction code would work reliably if the user
reconfigured the outp
On Aug 27, 2004, at 1:21 PM, Jack Strohm wrote:
I was thinking about making a customized LoggingEvent (a BlobEvent?)
that supported what I need (blobs and properties with primitive data
types) and then my own Appender to transport it. I guess it wouldn't
be something anyone else would want to
For the blob events I would build my own appender but if it was
derived from LoggingEvent and didn't overide or change any of the
functionality I would think it would work fine.
Why derive a class If it doesn't override or change functionality?
Even if it was transported, everything in the log
Hi,
Can someone explain why does RollingCalendar::computeTriggeringPeriod
permanently overrides the user's TZ environment variable?
Shouldn't it fetch the users value with getenv, save it temporarily,
then set TZ
to GMT and when it's finished restore it?
If this is not a bug, can someone explain
Can you handle this ? Is there a better way to proceed to this
kind of
submission ?
In fact, I eventually have more changes (linked to the BCB
support) to
submit to you if you find it useful.
By the way, I almost forgot to say that we really appreciate the
work
done by the log4cxx te
On Oct 4, 2004, at 10:41 AM, Ken Knox wrote:
My question is - is there any plans to remove iostream dependencies
from log4cxx - or if not should we undertake to do so, would this
effort be likely to be accepted into the codebase, and an effort made
subsequently to keep log4cxx iostream free?
Thanks
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 not allowed to mix o
On Oct 4, 2004, at 6:44 PM, Christopher Smith wrote:
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 L
On Oct 4, 2004, at 7:50 PM, Christopher Smith wrote:
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
On Oct 5, 2004, at 2:49 AM, Tommi Maekitalo wrote:
Am Dienstag, 5. Oktober 2004 01:44 schrieb Christopher Smith:
This has a major performance-drawback. When processing operator<< your
compiler/system/whoever can't know, you will throw away the results.
It has
to format all your output even if logg
Defering is good, but I would derive Exception from runtime_error,
which needs
a std::string in constructor, so the conversion need to be done in the
constructor.
Another possible solution is to use runtime_error, give the
constructor a
empty string and override what().
I'd suggest doing in the
It is a known issue, see:
http://nagoya.apache.org/jira/browse/LOGCXX-2. There has been previous
discussion on it and I thought that the some work had been committed to
the CVS to at least avoid clashing with the calling applications
config.h.
On Oct 6, 2004, at 11:29 AM, Tommi Maekitalo wrot
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.
Thanks for the submission. It wasn't quite what I had in mind. I'm
trying to flesh my thoughts out right now (well after getting some
sleep) and will reply tomorrow.
On Oct 6, 2004, at 1:31 PM, Christopher Smith wrote:
Curt Arnold wrote:
Thanks, Please submit it as a bug request
I've committed my stab at logging streams to the CVS. The stream based
interface is defined in include/log4cxx/stream.h and there is a usage
example in examples/stream.cpp. I've updated the Makefile.am's so the
make based build will work (after an autogen), but I haven't updated
the MSVC proj
On Oct 7, 2004, at 2:51 PM, Christopher Smith wrote:
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
On Oct 7, 2004, at 4:47 PM, 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
On my home system (2.4GHz P4 running Gentoo & gcc-3.3) these are the
numbers I got (this is the average time per iteration):
CVS logstream
Logging when disabled: 1600-1800ns
Logging when enabled: 13000-15000ns
My LoggingStream
Logging when disabled: 40-50ns
Logging when enabled: 15000-18000ns
Th
I'm sorry, I appear to have wasted my time and yours. When you asked
for construction metrics I had assumed you meant for your
implementation. With your current scheme there would be no way to
avoid the cost of instantiating std::basic_stringbuf, as it's not a
templated parameter.
No it is sti
Jira is still down, so I went ahead and committed a patch that
eliminates dependency on all non-local static variables (didn't mess
with ThreadLocalStorage). I would appreciate any feedback especially
from those who reported segmentation faults at startup.
On Oct 20, 2004, at 7:24 PM,
I've hinted for a long time that I thought that use of the Apache
Portable Runtime (http://apr.apache.org) was likely in our future. I
think the time is quickly approaching to start using it. I've cleared
off most of the bug list that would not be affected by a vote or
against APR. ICU4C
On Oct 27, 2004, at 10:48 AM, Christopher Smith wrote:
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 librarie
On Oct 27, 2004, at 1:52 PM, Curt Arnold wrote:
I'm currently writing test cases for log4j's date formatting to
determine what it actually supports. I'm finding some strange
behavior and will probably raise that on the log4j dev mailing list
tomorrow. After I figure out what l
I agree it is a critical bug (actually set of bugs). I've been working
on adding test cases to log4j to establish its current behavior and
fixing the bugs that I've found there before revamping the log4cxx
code. When finished, I believe that it will not be necessary to ever
change the value o
On Nov 3, 2004, at 12:10 PM, Christophe de VIENNE wrote:
I think we should try to make a release quite soon. I know that some
issue remains, but if we want the lastest modifications to be
correctly tested, a release is necessary.
Curt, could we try to plan this after APR integration ?
I also wan
The APR migration has been in progress for a couple of weeks and I'm
more and more convinced that it was the right approach. For
deployment, I'm expecting that we will build log4cxx using APR in a
static library, so there won't be a runtime dependency on apr.dll et
al. Won't know how it will
I've committed the first (and second) iterations on the APR thread
migration. There are a couple of things still broken, but I've run out
of steam for today.
On Windows, AsyncAppenderTestCase.test3 is deadlocking and is #ifdef'd
out. I wasn't able to figure out what was going on and I thought
log4j 1.3 contains an upward compatible replacement of the
DOMConfigurator called the Joran Configurator (named after a wind that
blows over Lac Laman) https://www.qos.ch/logging/joran.pdf.
There are a couple of forthcoming changes that will require working on
the existing log4cxx DOMConfigura
On Nov 27, 2004, at 4:48 PM, Ceki Gülcü wrote:
Regarding non-ASCII characters for file names, logger names etc, Joran
just takes in the data supplied by the parser. It does not attempt to
perform any character conversions. Anyway, isn't correctly decoding
the character data the responsibility of
I've just committed a fairly hefty modification to CVS that represents
the current state of the long pending "Unicode" rework (bug LOGCXX-10).
At present, though it compiles on Linux using the Ant script, I
believe that it is effectively non-functional. Usually, I wait until
all the unit test
Tommi Mäkitalo wrote:
Hi,
I tried to compile the CVS-version, but run into a minor problem and a big
problem.
The minor problem was, that there is a missign '\' in
tests/src/helpers/Makefile.am. Here is the diff:
The larger problem is log4cxx/string.h.
Thanks for the feedback. I had added
Tommi Mäkitalo wrote:
Hi,
I'm not a ant-user. I use autoconf/automake for my own programs. So I try to
compile log4cxx with autoconf/automake.
I'm not an autoconf/automake guy. Definitely the plan is to get the
other build systems up to speed, but I start with an Ant build since it
readily s
I wonder why you declare apr_int64_t in log4cxx-headers. apr_int64_t
is defined in apr_atomic.h, so if you need it, include this header.
I've avoided including APR headers in the log4cxx headers to eliminate
the need for applications that are using log4cxx to have to add APR to
their include
There is a trivial example (examples/stream) that works for me. If you
are getting segfaults it is likely due to a problem in the core since I
haven't had a chance to work through the unit tests yet (which fail due
to a segfault).
On Dec 16, 2004, at 2:56 PM, Tommi Mäkitalo wrote:
Hi,
I just w
On Dec 16, 2004, at 5:12 PM, Tommi Mäkitalo wrote:
Hi again,
why there is a empty line between each log-message? Here is how the
output of
example/trivia looks like:
Looks like I probably added a \n that didn't need to be there. This
should cause a test failure when I'm able to run more than a f
On Dec 18, 2004, at 2:43 PM, Tommi Mäkitalo wrote:
Hi,
I have a patch for the autoconf.build-system. The include-directory
log4cxx/spi/location was missing. The patch also disables inernal
debugging
as it should be (as it was before curts last checkin).
I was going to revert the internal debuggin
On Dec 18, 2004, at 3:02 PM, Tommi Mäkitalo wrote:
Hi,
there is a problem printing thread-id on 64-bit:
log4cxx uses "StringHelper::toString(int, apr_pool_t*)" to convert the
current
thread-id to a string. On my machine thead-id is 64 bit unsigned
(unsigned
long), but int is only 32 bit and signe
Just to fight at least a little for STL (I don't want to start a
flame-war
about STL): I created StringHelper::UlongToString-methods and
benchmarked it
against std::wostringstream. The result was, that for large numbers
(>INT_MAX, where your optimization don't catch), it took 2.3 seconds to
forma
On Dec 18, 2004, at 6:19 PM, Curt Arnold wrote:
Just to fight at least a little for STL (I don't want to start a
flame-war
about STL): I created StringHelper::UlongToString-methods and
benchmarked it
against std::wostringstream. The result was, that for large numbers
(>INT_MAX, wh
I did see your earlier message and thought that I had replied to it,
but can't seem to find a message in the archives.
I'd like to get Ceki's opinion on this. I can see where it would be
useful to you, but I'm sure that there are probably issues that need to
be considered.
The appropriate loc
On Dec 21, 2004, at 5:34 PM, Tommi Mäkitalo wrote:
Hi,
logstream has indeed a problem: ios_base needs to be initialized.
Normally
should happen by calling basic_ios<...>::init(), which is protected.
Before
calling init the values are undefined. Width() returns on my machine
2507262709. This is no
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 maniplulators. It did ignore them
if the strea
On Dec 21, 2004, at 10:47 PM, Barak Simon wrote:
Hi Curt,
Would it be possible to add the following minor changes?
Add:
#include
To:
socketoutputstream.cpp, stringtokenizer.cpp, xmlsocketappender.cpp
Add:
#include
#include
To:
tchar.h
This will enable log4cxx to compile on sunpro 5.6 with -libra
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 interface for loggin
On Dec 23, 2004, at 3:02 PM, Christopher Smith wrote:
If I was doing:
filestream << "We have: " << std::scientific << 3.1415926 <<
std::endl;
At the end of the statement, I would expect that either an exception
had been thrown (disk full, etc) or the filestream would have be left
with the file
On Dec 28, 2004, at 2:13 PM, Kadarkarai, Prabhakar (Prabhakar) wrote:
Hi,
I would like send messages to MSMQ using Log C++.
Is there any appender available for MSMQ (Microsoft Messaging Queue)?
If so, could you please tell me where I can find it?
Thanks,
PK
I'm not aware of any, but maybe someone
On Dec 28, 2004, at 4:07 PM, Tommi Mäkitalo wrote:
Hi Curt,
I just checked out a fresh version and realized, that you checked in a
nonworking src/transcoder.cpp. You added a "#iinclude
".
Did you change config_auto.h to config.h?
Sorry, comment out the include statement for now.
In the Ant build
On Dec 30, 2004, at 5:13 PM, Tommi Mäkitalo wrote:
Hi,
I just thought about config_msvc.h. I think it would be better to
remove it
and replace with autoconf-tests. The idea of autoconf is not to
distinquish
compilers, but features. There should be no "#if _MSC_VER <= 1200" or
something, but "#if
On Dec 31, 2004, at 5:46 AM, Tommi Mäkitalo wrote:
You have also previously suggested moving config_auto.h into the src
directory since it is not needed by client applications. A lot of
other files in the include tree are also not needed by client
applications, we might suppress those
in the "mak
Are you building against log4cxx 0.9.7 or a CVS build? What version of
Visual C++ are you using?
The CVS is just recovering from some major surgery, but I was still
able to compile and link examples/trivial.cpp with a fairly simple VC 6
project. Basically, create trivial.dsw in \logging-log4c
On Jan 6, 2005, at 12:32 PM, Kevin Tew wrote:
I've wrote a example app below that illustrates the problem.
Any suggestions?
Kevin ( listman)
The threading code in the current CVS is now based on Apache Portable
Runtime, so any threading related bug in 0.9.7 has at least moved. I
converted your c
On Jan 6, 2005, at 4:45 AM, Ceki Gülcü wrote:
Curt,
While you are importing unit tests over from log4j, you probably
became aware that the log4j tests based on the witness approach,
although very valuable, are fragile and somewhat hard to maintain. I
suspect that better and cheaper testing methodol
Thanks for the interest.
Could you look at the Contributor License Agreement at
http://www.apache.org/licenses/ and see if you would be able to sign
one for this work? If you have previously signed one, you aren't
showing up in the CLA list. If you do fax or mail one in, note that
[EMAIL PRO
This is a more appropriate questions for log4cxx-user, not log4cxx-dev.
You might want to read
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=log4cxx-
[EMAIL PROTECTED]&msgNo=649 where I was reply to someone who was
having problems getting an custom appender recognized.
It is hard to d
Cocoon has started to fail to compile due to a failure to find
DOMConfiguration,
http://brutus.apache.org/gump/public/cocoon/cocoon/gump_work/
build_cocoon_cocoon.html. Was this expected and intentional?
Oops, should have been log4j-dev.
On Jan 20, 2005, at 12:13 PM, Curt Arnold wrote:
Cocoon has started to fail to compile due to a failure to find
DOMConfiguration,
http://brutus.apache.org/gump/public/cocoon/cocoon/gump_work/
build_cocoon_cocoon.html. Was this expected and intentional?
I've have reworked the Ant build script so it will download and build
Apache Portable Runtime (apr, apr-util and apr-iconv modules) and
Cppunit if a location for the installed versions are not specified.
Also, the need for boost-regex in the unit tests has been eliminated by
using "sed" to nor
I think that you are experiencing a different problem that you suppose,
but first to the problem that you think that you are having.
My original intent was that log4cxx could be built against either APR-0
or APR-1, however there were enough differences that it was going to
add a large amount of
On Feb 17, 2005, at 5:04 PM, Kevin Tew wrote:
Platform Debian sid up to date
Note I'm building using autoconf/automake and I'm supplying
/usr/local/apr the configure script as the apr location
ldd liblog4cxx.so.9.0.0
libapr-1.so.0 => /usr/local/apr/lib/libapr-1.so.0 (0x40101000)
lib
The code was designed to support logchar as being wchar_t or UTF-8
char's. However, the support routines for UTF-8 chars was not coded
since at the time I didn't have apr-iconv integrated.
Right now, use of wchar_t is hardcoded by the
#define LOG4CXX_LOGCHAR_IS_WCHAR 1
in logstring.h
If you cha
I've filled in the missing stuff to allow log4cxx to be built using
UTF-8 for logchar, which I had planned, and to allow log4cxx to be
build with no use of wchar_t which I hadn't considered (and which
implies using UTF-8 for logchar).
To build without wchar_t:
ant -Dhas.wchar_t=0
To build with
On Mar 16, 2005, at 7:44 AM, Peter Steiner wrote:
Hello!
I'm trying to integrate log4cxx into a new Visual Studio 2003 project
and tried to use the static library.
Using the current CVS head (from 2005-03-15 16:00GMT), I have found
several problems:
- INSTALL: typo in Build options description:
"
On Mar 16, 2005, at 7:44 AM, Peter Steiner wrote:
Hello!
I'm trying to integrate log4cxx into a new Visual Studio 2003 project
and tried to use the static library.
Using the current CVS head (from 2005-03-15 16:00GMT), I have found
several problems:
I've attempted to address these issues without re
I've committed changes that add support an "encoding" attribute on
appenders that inherit from WriterAppender. The internal structure of
WriterAppender has been changed to bring it a lot closer to log4j.
With these changes encoding has been moved into CharsetEncoder and
CharsetDecoder which ar
Some patches fix problems that prevent compilation with compilers that
we want to support (such as Borland C++) that have not been of concern
to APR. I'm hoping that I can get them integrated into the APR
Subversion HEAD, but they haven't been. APR 1.1.1 wasn't a time to
force the issue since
Sorry it took so long. I've now eliminated the use of APR's apr_xlate
function on Windows since apr_iconv had issues. The choices of
encodings is substantially more limited on Windows, only the encodings
guaranteed to be present on Java are there (US-ASCII, ISO-8859-1,
UTF-8, UTF-16LE, UTF-16
The message parameter on the logging calls is a string, that is a
sequence of characters, not an arbitrary vector of bytes and log4cxx
(and log4j and log4net for that matter) make no guarantees that
arbitrary bytes will pass through the processing pipeline intact.
Since the message is stated t
I done yet another iteration of character encoding. The structure is
still based on the JDK 1.4 CharsetDecoder and CharsetEncoder, but now
most of the heavy lifting is done with a small set of implementations
within log4cxx. apr_xlate is used as a fallback in case the nature of
wchar_t is not
On Apr 29, 2005, at 10:59 AM, Ceki Gülcü wrote:
Curt,
It is nice to see that you are making progress on log4cxx. One of the
promises that we made to the ASF when log4cxx graduated from the
incubator was to increase the committer base of log4cxx. Have you
taken steps to enlarge the comm
On Apr 29, 2005, at 12:30 PM, Ceki Gülcü wrote:
The 3+ active committer should not come as a surprise. Having 3+
active committers has always been a requirement for graduation. There
are numerous discussions of this rule in the [EMAIL PROTECTED] mailing
list. The Incubator PMC made several remarks
About this, I have a problem with some ac variables you use in
log4cxx.h.in
but which are not set by configure.in :
LOGCHAR_IS_UTF8 and HAS_WCHAR_T
How do you expect them to be defined ? Do I add some option to
configure of do
I compute it from --enable-unicode ?
Sorry, I forgot about that. LOG
rovide whatever examples for similar configurations you can find.
On May 7, 2005, at 12:06 AM, Curt Arnold wrote:
About this, I have a problem with some ac variables you use in
log4cxx.h.in
but which are not set by configure.in :
LOGCHAR_IS_UTF8 and HAS_WCHAR_T
How do you expect them to be defined
Our Gump builds had not been attempted for several days due to a
problem that kept Ant itself from building.
I hadn't remembered that having two header files that have the same
name would trip up the "header-check" target which checks header files
against the Effective C++ guidelines. I rename
On May 10, 2005, at 1:06 PM, Kevin Tew wrote:
I'm getting tons of these warnings for every log4cxx class
Any Ideas?
c:\Branches\main\cb\ExternalLibs\include\log4cxx\helpers
\appenderattachableimpl.h(106) : warning C4250:
'log4cxx::helpers::AppenderAttachableImpl' : inherits
'log4cxx::helpers::
FYI
Begin forwarded message:
From: Justin Erenkrantz <[EMAIL PROTECTED]>
Date: May 14, 2005 10:51:03 PM CDT
To: dev@apr.apache.org
Subject: RogueWave Standard C++ Library proposal in Incubator
Hi everyone!
While this is not directly concerned with APR, I believe that some APR
developers here may fi
On May 16, 2005, at 3:47 AM, Tommi Mäkitalo wrote:
Am Montag, 16. Mai 2005 10:19 schrieb Christophe de VIENNE:
Le Samedi 14 Mai 2005 21:52, Tommi Mäkitalo a écrit :
Sorry - updated - I forgot LOG4CXX_HAS_WCHAR_T. And now I read
once again
the mail from Curt about LOG4CXX_HAS_WCHAR_T and
LOG4CXX
You will likely have noticed a fairly large commit related to porting
over the new RollingFileAppender framework from the log4j CVS HEAD.
I tried to keep the Makefile.am's in synch, but it looks like I
bungled something related to the include/log4cxx/pattern
subdirectory. I would apprecia
On Jun 2, 2005, at 2:30 AM, Slava Tutushkin wrote:
Hi all.
I was trying to create unicode logs and messed with it for whole
night.
As it turned out, there is no setOption method in WriterAppender, so
it was impossible to get Unicode output just with using
PropertyConfigurator. An
If it is failing on sys/stat.h, what is really occurring is a failure
to compile Apache Portable Runtime. I haven't tried compiling with
eVC. Will add it to my list of platforms to check.
On Jun 2, 2005, at 6:16 AM, Matthias Krause wrote:
Hi,
is it possible to build log4cxx for eVC?
I try
ittle bit and save some time.
Greetings
Matthias Krause
Curt Arnold wrote:
If it is failing on sys/stat.h, what is really occurring is a
failure to compile Apache Portable Runtime. I haven't tried
compiling with eVC. Will add it to my list of platforms to check.
On Jun 2, 2005,
On Jun 9, 2005, at 12:17 PM, Andreas Fester wrote:
Hi Tommi, Curt and Christophe,
Tommi, you once sent a patch for autoconf regarding the UTF8 and WCHAR
definitions. It has been partly applied some days ago, but the
definition of the macros is still missing from configure.in:
+AC_MSG_CHECKING
FYI: I intend to add another option for logchar which would use the
Apple Core Foundation CFString class for LogString. Since CFString
isn't an STL basic_string, it may be desirable to not specify logchar
but to have preprocessor macros that determine if LogString is
typedef'd as std::wstr
On Jul 1, 2005, at 1:03 AM, Andreas Fester wrote:
Hi,
I would like to take this to discuss one thing I thought about
when working on log4cxx and creating the Debian packages:
Is 0.9.8 really the correct version number?
Background: The SO_NAME of the 0.9.7 library was "9", so we have to
ch
On Jul 26, 2005, at 2:02 PM, Andreas Fester wrote:
Or, you can get a daily build from
http://brutus.apache.org/gump/public-jars/cpptasks/ as
Curt noted in an earlier posting.
BUT: brutus.apache.org is currently down:
An error occurred while loading http://brutus.apache.org/gump/
public-jars
On Aug 12, 2005, at 9:48 PM, Mark Womack wrote:
What's the deal with this GUMP failure?
-Mark
Sloth. My recollection is that I wasn't able to reproduce this on
Linux, but I now have a FreeBSD box and will try again. The
no_wchar_t is a variant build for platforms that do not have a
On Sep 12, 2005, at 3:16 AM, Ruggero Maffei wrote:
Hi to all,
i'm just wondering if it is possible to compile the log4cxx dll
under windows using ONLY open source tools.
I haven't Visual C or Borland C compiler, so i have no hope to
accomplish this task?
If so, is ti planned for the nex
On Sep 12, 2005, at 7:58 PM, Curt Arnold wrote:
I haven't confirmed it lately, but I did have log4cxx building with
MinGW a few months ago. The major issue was patching Apache
Portable Runtime to compile on MinGW.
To clarify: the Ant build will patch the APR source as part o
It is also needed for Borland C++. I've submitted the patch to the
APR group at least 6 months ago and have been pestering them to get
in into there SVN version. I think there were some functionality
patches, but I'll have to review. It would be great if the APR team
would get the patche
On Sep 14, 2005, at 10:22 AM, Josh Clark wrote:
Maybe I'm just dense, but when I try to submit a bug report, the
only project available is Cocoon 2. Am I missing something?
Try navigating in from http://issues.apache.org/jira.
Also, are you saying I should submit all three changes? As s
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
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
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
All Logging Services projects have been migrated to Subversion. See
http://logging.apache.org/site/repositories.html for instructions,
but use log4cxx, not logging-log4cxx, as the project name. See
http://www.apache.org/dev/version-control.html for general
information about Subversion use
Andreas has been a consistent contributor to the log4cxx project in
terms of code contributions and community for many months now and it
is my pleasure to announce is now a committer to the log4cxx
project. Please welcome [EMAIL PROTECTED]
On Nov 14, 2005, at 1:38 PM, Andreas Fester wrote:
Hi,
I intend to commit the following patches; they are all a first step
towards creating a proper dist-tarball with the GNU autotools based
build.
Any objections?
Thanks,
Andreas
+1
+1
1 - 100 of 200 matches
Mail list logo
