[jira] [Commented] (LOGCXX-394) Levels are not thread safe
[
https://issues.apache.org/jira/browse/LOGCXX-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13903070#comment-13903070
]
Thorsten Schöning commented on LOGCXX-394:
--
Don't we have two problems here? First there is the use of singletons
ultimately causing the bug in some multithreaded environments, but second there
are those tests or other users which want to compare the equality of levels by
relying on the (former) implementation detail that all same levels are in fact
the same object. I find the latter behavior to be wrong because the users
shouldn't rely on those implementation details and would suggest changing this
anyways.
The use of singletons already seem to cause problems in some multithreaded
environments (LOGCXX-322 and others), so do we really want to stick with those
if we already know there are problems with thread safetiness? The only benefit
using a singleton I see is if one has a use case where one needs to compare
Levels a lot of times and is always using Level::get* instead of simply saving
the result once.
The only two things I see to stay with the singletons would be using a mutex
for each to protect it's construction or using static data members. But the
latter seems to already fail around LOGCXX-322 and others and all the
Level::get* methods were introduced in rev 308676 because of seg faults in
using static data members. And I don't think introducing mutexes is worth the
effort.
> Levels are not thread safe
> --
>
> Key: LOGCXX-394
> URL: https://issues.apache.org/jira/browse/LOGCXX-394
> Project: Log4cxx
> Issue Type: Bug
> Components: Appender
> Environment: Windows 7, Visual Studio 2010 SP1
>Reporter: Petro Protsyk
>Assignee: Thorsten Schöning
>Priority: Minor
> Labels: thread-safety
>
> Level.cpp. All default level variables are function static. This is not
> thread safe, especially in Visual C++ compiler.
> Here is code to reproduce the issue in VC++ 2010:
> Concurrency::parallel_for (int(0), int(10), [&](int i)
> {
> if (::log4cxx::Level::getWarn() == NULL)
> {
> throw std::exception();
> }
> });
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (LOGCXX-426) nteventlogappender.cpp could fail to compile with winsock redefinition errors.
Joseph Southwell created LOGCXX-426: --- Summary: nteventlogappender.cpp could fail to compile with winsock redefinition errors. Key: LOGCXX-426 URL: https://issues.apache.org/jira/browse/LOGCXX-426 Project: Log4cxx Issue Type: Bug Environment: Visual Studio 2008 Reporter: Joseph Southwell 1>Compiling... 1>nteventlogappender.cpp 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(91) : warning C4005: 'AF_IPX' : macro redefinition 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock.h(460) : see previous definition of 'AF_IPX' 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(127) : warning C4005: 'AF_MAX' : macro redefinition 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock.h(479) : see previous definition of 'AF_MAX' 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(163) : warning C4005: 'SO_DONTLINGER' : macro redefinition 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock.h(402) : see previous definition of 'SO_DONTLINGER' 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(206) : error C2011: 'sockaddr' : 'struct' type redefinition 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock.h(485) : see declaration of 'sockaddr' 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(384) : error C2143: syntax error : missing '}' before 'constant' 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(384) : error C2143: syntax error : missing ';' before 'constant' 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(384) : error C2059: syntax error : 'constant' 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(437) : error C2143: syntax error : missing ';' before '}' 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(437) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(437) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(518) : warning C4005: 'IN_CLASSA' : macro redefinition 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock.h(287) : see previous definition of 'IN_CLASSA' 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(524) : warning C4005: 'IN_CLASSB' : macro redefinition 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock.h(293) : see previous definition of 'IN_CLASSB' 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(530) : warning C4005: 'IN_CLASSC' : macro redefinition 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock.h(299) : see previous definition of 'IN_CLASSC' 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(541) : warning C4005: 'INADDR_ANY' : macro redefinition 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock.h(304) : see previous definition of 'INADDR_ANY' 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(543) : warning C4005: 'INADDR_BROADCAST' : macro redefinition 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock.h(306) : see previous definition of 'INADDR_BROADCAST' 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(577) : error C2011: 'sockaddr_in' : 'struct' type redefinition 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock.h(312) : see declaration of 'sockaddr_in' 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock2.h(132) : error C2011: 'fd_set' : 'struct' type redefinition 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock.h(68) : see declaration of 'fd_set' 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock2.h(167) : warning C4005: 'FD_SET' : macro redefinition 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock.h(102) : see previous definition of 'FD_SET' 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock2.h(176) : error C2011: 'timeval' : 'struct' type redefinition 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock.h(111) : see declaration of 'timeval' 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock2.h(232) : error C2011: 'hostent' : 'struct' type redefinition 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock.h(167) : see declaration of 'hostent' 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock2.h(245) : error C2011: 'netent' : 'struct' type redefinition 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock.h(180) : see declaration of 'netent' 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock2.h(252) : error C2011: 'servent'
svn commit: r1569054 - /incubator/log4cxx/trunk/src/main/cpp/nteventlogappender.cpp
Author: joseph Date: Mon Feb 17 16:47:10 2014 New Revision: 1569054 URL: http://svn.apache.org/r1569054 Log: LOGCXX-426 Modified: incubator/log4cxx/trunk/src/main/cpp/nteventlogappender.cpp Modified: incubator/log4cxx/trunk/src/main/cpp/nteventlogappender.cpp URL: http://svn.apache.org/viewvc/incubator/log4cxx/trunk/src/main/cpp/nteventlogappender.cpp?rev=1569054&r1=1569053&r2=1569054&view=diff == --- incubator/log4cxx/trunk/src/main/cpp/nteventlogappender.cpp (original) +++ incubator/log4cxx/trunk/src/main/cpp/nteventlogappender.cpp Mon Feb 17 16:47:10 2014 @@ -17,6 +17,7 @@ #if (defined(WIN32) || defined(_WIN32)) && !defined(_WIN32_WCE) +#define _WINSOCKAPI_ #include #undef ERROR #include
[jira] [Closed] (LOGCXX-426) nteventlogappender.cpp could fail to compile with winsock redefinition errors.
[ https://issues.apache.org/jira/browse/LOGCXX-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Southwell closed LOGCXX-426. --- Resolution: Fixed Assignee: Joseph Southwell fixed with +#define _WINSOCKAPI_ #include in nteventlogappender.cpp > nteventlogappender.cpp could fail to compile with winsock redefinition errors. > -- > > Key: LOGCXX-426 > URL: https://issues.apache.org/jira/browse/LOGCXX-426 > Project: Log4cxx > Issue Type: Bug > Environment: Visual Studio 2008 >Reporter: Joseph Southwell >Assignee: Joseph Southwell > > 1>Compiling... > 1>nteventlogappender.cpp > 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(91) : > warning C4005: 'AF_IPX' : macro redefinition > 1>C:\Program Files\Microsoft > SDKs\Windows\v6.0A\include\winsock.h(460) : see previous definition of > 'AF_IPX' > 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(127) : > warning C4005: 'AF_MAX' : macro redefinition > 1>C:\Program Files\Microsoft > SDKs\Windows\v6.0A\include\winsock.h(479) : see previous definition of > 'AF_MAX' > 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(163) : > warning C4005: 'SO_DONTLINGER' : macro redefinition > 1>C:\Program Files\Microsoft > SDKs\Windows\v6.0A\include\winsock.h(402) : see previous definition of > 'SO_DONTLINGER' > 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(206) : error > C2011: 'sockaddr' : 'struct' type redefinition > 1>C:\Program Files\Microsoft > SDKs\Windows\v6.0A\include\winsock.h(485) : see declaration of 'sockaddr' > 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(384) : error > C2143: syntax error : missing '}' before 'constant' > 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(384) : error > C2143: syntax error : missing ';' before 'constant' > 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(384) : error > C2059: syntax error : 'constant' > 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(437) : error > C2143: syntax error : missing ';' before '}' > 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(437) : error > C4430: missing type specifier - int assumed. Note: C++ does not support > default-int > 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(437) : error > C4430: missing type specifier - int assumed. Note: C++ does not support > default-int > 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(518) : > warning C4005: 'IN_CLASSA' : macro redefinition > 1>C:\Program Files\Microsoft > SDKs\Windows\v6.0A\include\winsock.h(287) : see previous definition of > 'IN_CLASSA' > 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(524) : > warning C4005: 'IN_CLASSB' : macro redefinition > 1>C:\Program Files\Microsoft > SDKs\Windows\v6.0A\include\winsock.h(293) : see previous definition of > 'IN_CLASSB' > 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(530) : > warning C4005: 'IN_CLASSC' : macro redefinition > 1>C:\Program Files\Microsoft > SDKs\Windows\v6.0A\include\winsock.h(299) : see previous definition of > 'IN_CLASSC' > 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(541) : > warning C4005: 'INADDR_ANY' : macro redefinition > 1>C:\Program Files\Microsoft > SDKs\Windows\v6.0A\include\winsock.h(304) : see previous definition of > 'INADDR_ANY' > 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(543) : > warning C4005: 'INADDR_BROADCAST' : macro redefinition > 1>C:\Program Files\Microsoft > SDKs\Windows\v6.0A\include\winsock.h(306) : see previous definition of > 'INADDR_BROADCAST' > 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2def.h(577) : error > C2011: 'sockaddr_in' : 'struct' type redefinition > 1>C:\Program Files\Microsoft > SDKs\Windows\v6.0A\include\winsock.h(312) : see declaration of 'sockaddr_in' > 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock2.h(132) : > error C2011: 'fd_set' : 'struct' type redefinition > 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock.h(68) > : see declaration of 'fd_set' > 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock2.h(167) : > warning C4005: 'FD_SET' : macro redefinition > 1>C:\Program Files\Microsoft > SDKs\Windows\v6.0A\include\winsock.h(102) : see previous definition of > 'FD_SET' > 1>C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock2.h(176) : > error C2011: 'timeval' : 'struct' type redefinition > 1>C:\Program Files\Microsoft > SDKs\Windows\v6.0A\include\winsock.h(111) : see declaration of 'timeval' > 1>C:\Program Files\Microsoft SDKs\Windows\v6.0
[jira] [Created] (LOGCXX-427) console appender test app doesn't build on windows
Joseph Southwell created LOGCXX-427: --- Summary: console appender test app doesn't build on windows Key: LOGCXX-427 URL: https://issues.apache.org/jira/browse/LOGCXX-427 Project: Log4cxx Issue Type: Bug Reporter: Joseph Southwell Assignee: Joseph Southwell Priority: Trivial 1>Compiling... 1>console.cpp 1>.\src\examples\cpp\console.cpp(29) : fatal error C1083: Cannot open include file: 'stdint.h': No such file or directory -- This message was sent by Atlassian JIRA (v6.1.5#6160)
svn commit: r1569059 - /incubator/log4cxx/trunk/src/examples/cpp/console.cpp
Author: joseph Date: Mon Feb 17 17:10:55 2014 New Revision: 1569059 URL: http://svn.apache.org/r1569059 Log: LOGCXX-427 Modified: incubator/log4cxx/trunk/src/examples/cpp/console.cpp Modified: incubator/log4cxx/trunk/src/examples/cpp/console.cpp URL: http://svn.apache.org/viewvc/incubator/log4cxx/trunk/src/examples/cpp/console.cpp?rev=1569059&r1=1569058&r2=1569059&view=diff == --- incubator/log4cxx/trunk/src/examples/cpp/console.cpp (original) +++ incubator/log4cxx/trunk/src/examples/cpp/console.cpp Mon Feb 17 17:10:55 2014 @@ -26,7 +26,9 @@ #include #include #include +#ifndef WIN32 #include +#endif using namespace log4cxx; using namespace log4cxx::helpers;
[jira] [Resolved] (LOGCXX-427) console appender test app doesn't build on windows
[ https://issues.apache.org/jira/browse/LOGCXX-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Southwell resolved LOGCXX-427. - Resolution: Fixed +#ifdef WIN32 #include +#endif > console appender test app doesn't build on windows > -- > > Key: LOGCXX-427 > URL: https://issues.apache.org/jira/browse/LOGCXX-427 > Project: Log4cxx > Issue Type: Bug >Reporter: Joseph Southwell >Assignee: Joseph Southwell >Priority: Trivial > > 1>Compiling... > 1>console.cpp > 1>.\src\examples\cpp\console.cpp(29) : fatal error C1083: Cannot open include > file: 'stdint.h': No such file or directory -- This message was sent by Atlassian JIRA (v6.1.5#6160)
svn commit: r1569092 - in /incubator/log4cxx/trunk/src/main: cpp/domconfigurator.cpp include/log4cxx/xml/domconfigurator.h
Author: joseph
Date: Mon Feb 17 19:28:18 2014
New Revision: 1569092
URL: http://svn.apache.org/r1569092
Log:
LOGCXX-390
Modified:
incubator/log4cxx/trunk/src/main/cpp/domconfigurator.cpp
incubator/log4cxx/trunk/src/main/include/log4cxx/xml/domconfigurator.h
Modified: incubator/log4cxx/trunk/src/main/cpp/domconfigurator.cpp
URL:
http://svn.apache.org/viewvc/incubator/log4cxx/trunk/src/main/cpp/domconfigurator.cpp?rev=1569092&r1=1569091&r2=1569092&view=diff
==
--- incubator/log4cxx/trunk/src/main/cpp/domconfigurator.cpp (original)
+++ incubator/log4cxx/trunk/src/main/cpp/domconfigurator.cpp Mon Feb 17
19:28:18 2014
@@ -57,23 +57,30 @@ using namespace log4cxx::rolling;
#if APR_HAS_THREADS
-class XMLWatchdog : public FileWatchdog
+namespace log4cxx
{
-public:
-XMLWatchdog(const File& filename) : FileWatchdog(filename)
-{
-}
-
-/**
-Call DOMConfigurator#doConfigure with the
-filename to reconfigure log4cxx.
-*/
-void doOnChange()
-{
-DOMConfigurator().doConfigure(file,
-LogManager::getLoggerRepository());
-}
-};
+namespace xml
+{
+ class XMLWatchdog : public FileWatchdog
+ {
+ public:
+ XMLWatchdog(const File& filename) :
FileWatchdog(filename)
+ {
+ }
+
+ /**
+ Call DOMConfigurator#doConfigure with the
+ filename to reconfigure log4cxx.
+ */
+ void doOnChange()
+ {
+ DOMConfigurator().doConfigure(file,
+
LogManager::getLoggerRepository());
+ }
+ };
+ }
+}
+XMLWatchdog *DOMConfigurator::xdog = NULL;
#endif
@@ -814,7 +821,8 @@ void DOMConfigurator::configureAndWatch(
{
File file(filename);
#if APR_HAS_THREADS
-XMLWatchdog * xdog = new XMLWatchdog(file);
+ if( xdog ) delete xdog;
+xdog = new XMLWatchdog(file);
APRInitializer::registerCleanup(xdog);
xdog->setDelay(delay);
xdog->start();
@@ -828,7 +836,8 @@ void DOMConfigurator::configureAndWatch(
{
File file(filename);
#if APR_HAS_THREADS
-XMLWatchdog * xdog = new XMLWatchdog(file);
+ if( xdog ) delete xdog;
+xdog = new XMLWatchdog(file);
APRInitializer::registerCleanup(xdog);
xdog->setDelay(delay);
xdog->start();
@@ -843,7 +852,9 @@ void DOMConfigurator::configureAndWatch(
{
File file(filename);
#if APR_HAS_THREADS
-XMLWatchdog * xdog = new XMLWatchdog(file);
+ if( xdog ) delete xdog;
+xdog = new XMLWatchdog(file);
+APRInitializer::registerCleanup(xdog);
xdog->setDelay(delay);
xdog->start();
#else
@@ -857,7 +868,9 @@ void DOMConfigurator::configureAndWatch(
{
File file(filename);
#if APR_HAS_THREADS
-XMLWatchdog * xdog = new XMLWatchdog(file);
+ if( xdog ) delete xdog;
+xdog = new XMLWatchdog(file);
+APRInitializer::registerCleanup(xdog);
xdog->setDelay(delay);
xdog->start();
#else
Modified: incubator/log4cxx/trunk/src/main/include/log4cxx/xml/domconfigurator.h
URL:
http://svn.apache.org/viewvc/incubator/log4cxx/trunk/src/main/include/log4cxx/xml/domconfigurator.h?rev=1569092&r1=1569091&r2=1569092&view=diff
==
--- incubator/log4cxx/trunk/src/main/include/log4cxx/xml/domconfigurator.h
(original)
+++ incubator/log4cxx/trunk/src/main/include/log4cxx/xml/domconfigurator.h Mon
Feb 17 19:28:18 2014
@@ -49,6 +49,7 @@ namespace log4cxx
namespace xml
{
+ class XMLWatchdog;
/**
Use this class to initialize the log4cxx environment using a DOM
tree.
@@ -303,7 +304,7 @@ namespace log4cxx
// prevent assignment or copy statements
DOMConfigurator(const DOMConfigurator&);
DOMConfigurator& operator=(const DOMConfigurator&);
-
+ static XMLWatchdog *xdog;
};
LOG4CXX_PTR_DEF(DOMConfigurator);
} // namespace xml
svn commit: r1569091 - in /incubator/log4cxx/trunk/src/main: cpp/propertyconfigurator.cpp include/log4cxx/propertyconfigurator.h
Author: joseph
Date: Mon Feb 17 19:27:29 2014
New Revision: 1569091
URL: http://svn.apache.org/r1569091
Log:
LOGCXX-342
Modified:
incubator/log4cxx/trunk/src/main/cpp/propertyconfigurator.cpp
incubator/log4cxx/trunk/src/main/include/log4cxx/propertyconfigurator.h
Modified: incubator/log4cxx/trunk/src/main/cpp/propertyconfigurator.cpp
URL:
http://svn.apache.org/viewvc/incubator/log4cxx/trunk/src/main/cpp/propertyconfigurator.cpp?rev=1569091&r1=1569090&r2=1569091&view=diff
==
--- incubator/log4cxx/trunk/src/main/cpp/propertyconfigurator.cpp (original)
+++ incubator/log4cxx/trunk/src/main/cpp/propertyconfigurator.cpp Mon Feb 17
19:27:29 2014
@@ -51,31 +51,34 @@ using namespace log4cxx::config;
#if APR_HAS_THREADS
#include
-
-class PropertyWatchdog : public FileWatchdog
+namespace log4cxx
{
-public:
-PropertyWatchdog(const File& filename) : FileWatchdog(filename)
-{
-}
+ class PropertyWatchdog : public FileWatchdog
+ {
+ public:
+ PropertyWatchdog(const File& filename) :
FileWatchdog(filename)
+ {
+ }
+
+ /**
+ Call PropertyConfigurator#doConfigure(const String&
configFileName,
+ const spi::LoggerRepositoryPtr& hierarchy) with the
+ filename to reconfigure log4cxx.
+ */
+ void doOnChange()
+ {
+ PropertyConfigurator().doConfigure(file,
+
LogManager::getLoggerRepository());
+ }
+ };
+}
+
+PropertyWatchdog *PropertyConfigurator::pdog = NULL;
-/**
-Call PropertyConfigurator#doConfigure(const String& configFileName,
-const spi::LoggerRepositoryPtr& hierarchy) with the
-filename to reconfigure log4cxx.
-*/
-void doOnChange()
-{
-PropertyConfigurator().doConfigure(file,
-LogManager::getLoggerRepository());
-}
-};
#endif
IMPLEMENT_LOG4CXX_OBJECT(PropertyConfigurator)
-
-
PropertyConfigurator::PropertyConfigurator()
: registry(new std::map()), loggerFactory(new
DefaultLoggerFactory())
{
@@ -137,7 +140,9 @@ void PropertyConfigurator::configureAndW
void PropertyConfigurator::configureAndWatch(
const File& configFilename, long delay)
{
-PropertyWatchdog * pdog = new PropertyWatchdog(configFilename);
+ if(pdog)
+ delete pdog;
+pdog = new PropertyWatchdog(configFilename);
APRInitializer::registerCleanup(pdog);
pdog->setDelay(delay);
pdog->start();
Modified:
incubator/log4cxx/trunk/src/main/include/log4cxx/propertyconfigurator.h
URL:
http://svn.apache.org/viewvc/incubator/log4cxx/trunk/src/main/include/log4cxx/propertyconfigurator.h?rev=1569091&r1=1569090&r2=1569091&view=diff
==
--- incubator/log4cxx/trunk/src/main/include/log4cxx/propertyconfigurator.h
(original)
+++ incubator/log4cxx/trunk/src/main/include/log4cxx/propertyconfigurator.h Mon
Feb 17 19:27:29 2014
@@ -50,6 +50,7 @@ namespace log4cxx
class LoggerFactory;
}
+ class PropertyWatchdog;
/**
Allows the configuration of log4cxx from an external file. See
{@link #doConfigure(const File&, log4cxx::spi::LoggerRepositoryPtr&)}
@@ -384,6 +385,7 @@ protected:
private:
PropertyConfigurator(const PropertyConfigurator&);
PropertyConfigurator& operator=(const PropertyConfigurator&);
+ static PropertyWatchdog *pdog;
}; // class PropertyConfigurator
} // namespace log4cxx
[jira] [Commented] (LOGCXX-396) log4cxx-0.10.0 - compile error on OSX Lion using clang-3.1 building universal due to old libtool scripts
[ https://issues.apache.org/jira/browse/LOGCXX-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13903472#comment-13903472 ] Joseph Southwell commented on LOGCXX-396: - I think making a new release might fix this automatically. The downloadable source tar balls have a configure script. We do not have one in subversion. So I am guessing autogen.sh gets run at some point in the process of creating a new release source tar ball in order to create the configure script. I think this is really just a complaint about how old our release tar ball is. > log4cxx-0.10.0 - compile error on OSX Lion using clang-3.1 building universal > due to old libtool scripts > > > Key: LOGCXX-396 > URL: https://issues.apache.org/jira/browse/LOGCXX-396 > Project: Log4cxx > Issue Type: Bug > Components: Build >Affects Versions: 0.10.0 > Environment: Mac OSX Lion 10.7.4, XCode-4.3.2, clang-3.1 (build 318) >Reporter: nibbles >Assignee: Joseph Southwell >Priority: Blocker > Labels: build, clang, libtool > Fix For: 0.10.1 > > > I'm reporting a compile error on OSX Lion when using clang and building > universal for i386 and x86_64 due to old libtool scripts crafting a > non-functional compile command for the liblog4cxx.dylib. I'm doing this for > Homebrew, a package installer for Macs. The issue is discussed at length > here: > https://github.com/mxcl/homebrew/issues/12127 > The clue that the libtool scripts are too old to be useful is that the > commands they choose during configure are not the ones I always see. > The error arises when libtool calls `clang++ -r` but fails to add the arch > flags to that command, `-arch i386 -arch x86_64` which causes the > liblog4cxx.dylib to be missing all the 32bit symbols while it does contain > the 64bit symbols. Please see the issue linked above for all the details. > The solution for us is to run `autogen.sh` before configure, which fixes the > problem by updating the build scripts. > Thanks for reading this. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
svn commit: r1569099 - in /incubator/log4cxx/trunk/src/main: cpp/aprinitializer.cpp cpp/domconfigurator.cpp cpp/propertyconfigurator.cpp include/log4cxx/helpers/aprinitializer.h
Author: joseph
Date: Mon Feb 17 19:50:37 2014
New Revision: 1569099
URL: http://svn.apache.org/r1569099
Log:
LOGCXX-390
LOGCXX-342
Modified:
incubator/log4cxx/trunk/src/main/cpp/aprinitializer.cpp
incubator/log4cxx/trunk/src/main/cpp/domconfigurator.cpp
incubator/log4cxx/trunk/src/main/cpp/propertyconfigurator.cpp
incubator/log4cxx/trunk/src/main/include/log4cxx/helpers/aprinitializer.h
Modified: incubator/log4cxx/trunk/src/main/cpp/aprinitializer.cpp
URL:
http://svn.apache.org/viewvc/incubator/log4cxx/trunk/src/main/cpp/aprinitializer.cpp?rev=1569099&r1=1569098&r2=1569099&view=diff
==
--- incubator/log4cxx/trunk/src/main/cpp/aprinitializer.cpp (original)
+++ incubator/log4cxx/trunk/src/main/cpp/aprinitializer.cpp Mon Feb 17 19:50:37
2014
@@ -59,7 +59,7 @@ APRInitializer::~APRInitializer() {
synchronized sync(mutex);
apr_threadkey_private_delete(tlsKey);
#endif
-for(std::vector::iterator iter = watchdogs.begin();
+for(std::list::iterator iter = watchdogs.begin();
iter != watchdogs.end();
iter++) {
delete *iter;
@@ -95,3 +95,19 @@ void APRInitializer::registerCleanup(Fil
instance.watchdogs.push_back(watchdog);
}
+void APRInitializer::unregisterCleanup(FileWatchdog* watchdog) {
+APRInitializer& instance(getInstance());
+#if APR_HAS_THREADS
+synchronized sync(instance.mutex);
+#endif
+for(std::list::iterator iter = instance.watchdogs.begin();
+iter != instance.watchdogs.end();
+iter++) {
+ if(*iter == watchdog)
+ {
+ instance.watchdogs.erase(iter);
+ return;
+ }
+}
+}
+
Modified: incubator/log4cxx/trunk/src/main/cpp/domconfigurator.cpp
URL:
http://svn.apache.org/viewvc/incubator/log4cxx/trunk/src/main/cpp/domconfigurator.cpp?rev=1569099&r1=1569098&r2=1569099&view=diff
==
--- incubator/log4cxx/trunk/src/main/cpp/domconfigurator.cpp (original)
+++ incubator/log4cxx/trunk/src/main/cpp/domconfigurator.cpp Mon Feb 17
19:50:37 2014
@@ -821,7 +821,11 @@ void DOMConfigurator::configureAndWatch(
{
File file(filename);
#if APR_HAS_THREADS
- if( xdog ) delete xdog;
+ if( xdog )
+ {
+ APRInitializer::unregisterCleanup(xdog);
+ delete xdog;
+ }
xdog = new XMLWatchdog(file);
APRInitializer::registerCleanup(xdog);
xdog->setDelay(delay);
@@ -836,7 +840,11 @@ void DOMConfigurator::configureAndWatch(
{
File file(filename);
#if APR_HAS_THREADS
- if( xdog ) delete xdog;
+ if( xdog )
+ {
+ APRInitializer::unregisterCleanup(xdog);
+ delete xdog;
+ }
xdog = new XMLWatchdog(file);
APRInitializer::registerCleanup(xdog);
xdog->setDelay(delay);
@@ -852,7 +860,11 @@ void DOMConfigurator::configureAndWatch(
{
File file(filename);
#if APR_HAS_THREADS
- if( xdog ) delete xdog;
+ if( xdog )
+ {
+ APRInitializer::unregisterCleanup(xdog);
+ delete xdog;
+ }
xdog = new XMLWatchdog(file);
APRInitializer::registerCleanup(xdog);
xdog->setDelay(delay);
@@ -868,7 +880,11 @@ void DOMConfigurator::configureAndWatch(
{
File file(filename);
#if APR_HAS_THREADS
- if( xdog ) delete xdog;
+ if( xdog )
+ {
+ APRInitializer::unregisterCleanup(xdog);
+ delete xdog;
+ }
xdog = new XMLWatchdog(file);
APRInitializer::registerCleanup(xdog);
xdog->setDelay(delay);
Modified: incubator/log4cxx/trunk/src/main/cpp/propertyconfigurator.cpp
URL:
http://svn.apache.org/viewvc/incubator/log4cxx/trunk/src/main/cpp/propertyconfigurator.cpp?rev=1569099&r1=1569098&r2=1569099&view=diff
==
--- incubator/log4cxx/trunk/src/main/cpp/propertyconfigurator.cpp (original)
+++ incubator/log4cxx/trunk/src/main/cpp/propertyconfigurator.cpp Mon Feb 17
19:50:37 2014
@@ -141,7 +141,10 @@ void PropertyConfigurator::configureAndW
const File& configFilename, long delay)
{
if(pdog)
+ {
+ APRInitializer::unregisterCleanup(pdog);
delete pdog;
+ }
pdog = new PropertyWatchdog(configFilename);
APRInitializer::registerCleanup(pdog);
pdog->setDelay(delay);
Modified:
incubator/log4cxx/trunk/src/main/include/log4cxx/helpers/aprinitializer.h
URL:
http://svn.apache.org/viewvc/incubator/log4cxx/trunk/src/main/include/log4cxx/helpers/aprinitia
[jira] [Commented] (LOGCXX-390) xml::DOMConfigurator::configureAndWatch leaks memory and threads like LOGCXX-342
[
https://issues.apache.org/jira/browse/LOGCXX-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13903478#comment-13903478
]
Joseph Southwell commented on LOGCXX-390:
-
My solution didn't work because there is a already a list tracking these
pointers in the aprinitialize class. Instead I just tracked that pointer
separately and removed it from that list and deleted it. That way if one is
left when apr is terminated it gets deleted as it should be to avoid issues
like LOGCXX-396.
> xml::DOMConfigurator::configureAndWatch leaks memory and threads like
> LOGCXX-342
>
>
> Key: LOGCXX-390
> URL: https://issues.apache.org/jira/browse/LOGCXX-390
> Project: Log4cxx
> Issue Type: Bug
> Components: Configurator
>Affects Versions: 0.10.1
> Environment: windows
>Reporter: Victor
>Assignee: Joseph Southwell
>
> Each call to configureAndWatch causes a new FileWatcher object to be created
> (without deleting the old one) and consequently a new thread to be created
> (even though the old one may still be running).
> It problem may be fixed by creating
> std::vector> vecWatchDog;
> change
> // XMLWatchdog * xdog = new XMLWatchdog(file);
> // xdog->setDelay(delay);
> // xdog->start();
> std::tr1::shared_ptr xdog((FileWatchdog*)new
> XMLWatchdog(file));
> xdog->setDelay(delay);
> xdog->start();
> vecWatchDog.push_back(xdog);
> and adding
> void xml::DOMConfigurator::stopAllWatch()
> {
> vecWatchDog.clear();
> }
> for correctly stoped FileWatchers on application exit befor destroing Pool
> objects. Or need create vecWatchDog on Pool.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (LOGCXX-342) PropertyConfigurator::configureAndWatch leaks memory and threads
[ https://issues.apache.org/jira/browse/LOGCXX-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13903480#comment-13903480 ] Joseph Southwell commented on LOGCXX-342: - see LOGCXX-390 > PropertyConfigurator::configureAndWatch leaks memory and threads > > > Key: LOGCXX-342 > URL: https://issues.apache.org/jira/browse/LOGCXX-342 > Project: Log4cxx > Issue Type: Bug > Components: Configurator >Affects Versions: 0.10.0 > Environment: WinXP 64 bit >Reporter: Assaf Lavie >Assignee: Joseph Southwell >Priority: Critical > Attachments: propertyconfigurator.cpp.patch > > > Each call to configureAndWatch causes a new FileWatcher object to be created > (without deleting the old one) and consequently a new thread to be created > (even though the old one may still be running). > This means that it's very unsafe to call configureAndWatch more than once > (and even when calling it just once, it leaks soem mem and a thread). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (LOGCXX-416) FileWatchdog thread crash on exit()
[
https://issues.apache.org/jira/browse/LOGCXX-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13903586#comment-13903586
]
Joseph Southwell commented on LOGCXX-416:
-
I am not able to reproduce this. There is code that is supposed to join those
threads before calling apr_terminate. It was incompletely implemented and I
fixed that. The 2 places it was not implemented are for config macros that are
not true on my system. Can you update again and see if the problem goes away
for you?
> FileWatchdog thread crash on exit()
> ---
>
> Key: LOGCXX-416
> URL: https://issues.apache.org/jira/browse/LOGCXX-416
> Project: Log4cxx
> Issue Type: Bug
> Components: Configurator
>Affects Versions: 0.10.0
>Reporter: Jin Qing
>Assignee: Joseph Southwell
>Priority: Critical
>
> On exit(), FileWatchdog::checkAndConfigure() calls apr_pool_creae() and crash.
> Test code:
> #include
> class A
> {
> public:
> A() {};
> ~A() {
> for (int i = 0; i < 100; i++)
> for (int i = 0; i < 100; i++)
> ;
> }
> } g_a;
> int main()
> {
> log4cxx::xml::DOMConfigurator::configureAndWatch("log4j.xml", 1000);
> return 0;
> }
> After main() returned, but main thread is still running, watchdog thread
> will crash when checkAdnConfigure().
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (LOGCXX-342) PropertyConfigurator::configureAndWatch leaks memory and threads
[ https://issues.apache.org/jira/browse/LOGCXX-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Southwell resolved LOGCXX-342. - Resolution: Fixed > PropertyConfigurator::configureAndWatch leaks memory and threads > > > Key: LOGCXX-342 > URL: https://issues.apache.org/jira/browse/LOGCXX-342 > Project: Log4cxx > Issue Type: Bug > Components: Configurator >Affects Versions: 0.10.0 > Environment: WinXP 64 bit >Reporter: Assaf Lavie >Assignee: Joseph Southwell >Priority: Critical > Attachments: propertyconfigurator.cpp.patch > > > Each call to configureAndWatch causes a new FileWatcher object to be created > (without deleting the old one) and consequently a new thread to be created > (even though the old one may still be running). > This means that it's very unsafe to call configureAndWatch more than once > (and even when calling it just once, it leaks soem mem and a thread). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (LOGCXX-390) xml::DOMConfigurator::configureAndWatch leaks memory and threads like LOGCXX-342
[
https://issues.apache.org/jira/browse/LOGCXX-390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Southwell resolved LOGCXX-390.
-
Resolution: Fixed
> xml::DOMConfigurator::configureAndWatch leaks memory and threads like
> LOGCXX-342
>
>
> Key: LOGCXX-390
> URL: https://issues.apache.org/jira/browse/LOGCXX-390
> Project: Log4cxx
> Issue Type: Bug
> Components: Configurator
>Affects Versions: 0.10.1
> Environment: windows
>Reporter: Victor
>Assignee: Joseph Southwell
>
> Each call to configureAndWatch causes a new FileWatcher object to be created
> (without deleting the old one) and consequently a new thread to be created
> (even though the old one may still be running).
> It problem may be fixed by creating
> std::vector> vecWatchDog;
> change
> // XMLWatchdog * xdog = new XMLWatchdog(file);
> // xdog->setDelay(delay);
> // xdog->start();
> std::tr1::shared_ptr xdog((FileWatchdog*)new
> XMLWatchdog(file));
> xdog->setDelay(delay);
> xdog->start();
> vecWatchDog.push_back(xdog);
> and adding
> void xml::DOMConfigurator::stopAllWatch()
> {
> vecWatchDog.clear();
> }
> for correctly stoped FileWatchers on application exit befor destroing Pool
> objects. Or need create vecWatchDog on Pool.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (LOGCXX-394) Levels are not thread safe
[
https://issues.apache.org/jira/browse/LOGCXX-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13903605#comment-13903605
]
Rhys Ulerich commented on LOGCXX-394:
-
You make a good point re: the equality checks. Two things:
First, I don't understand the comparison overrides for LevelPtr in r1568810.
Neither does GCC:
log4cxx/src/main/include/log4cxx/level.h:279:14: error: specializing member
‘log4cxx::helpers::ObjectPtrT::operator==’ requires
‘template<>’ syntax
inline bool LevelPtr::operator==(const LevelPtr& rhs) const
Second, I'm not sure how to just add in magic behavior for LevelPtr::operator==
since LevelPtr is an ObjectPtrT and ObjectPtrT::operator== is non-virtual. Is
there some better virtual function pattern that could be used so that LevelPtr
automatically adopts the semantics of Level? Or should it at all adopt the
semantics of Level equality and instead simply behave like an ObjectPtr?
Thanks for digging into this one,
Rhys
> Levels are not thread safe
> --
>
> Key: LOGCXX-394
> URL: https://issues.apache.org/jira/browse/LOGCXX-394
> Project: Log4cxx
> Issue Type: Bug
> Components: Appender
> Environment: Windows 7, Visual Studio 2010 SP1
>Reporter: Petro Protsyk
>Assignee: Thorsten Schöning
>Priority: Minor
> Labels: thread-safety
>
> Level.cpp. All default level variables are function static. This is not
> thread safe, especially in Visual C++ compiler.
> Here is code to reproduce the issue in VC++ 2010:
> Concurrency::parallel_for (int(0), int(10), [&](int i)
> {
> if (::log4cxx::Level::getWarn() == NULL)
> {
> throw std::exception();
> }
> });
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (LOGCXX-367) Build fails on Linux with g++ 4.4
[ https://issues.apache.org/jira/browse/LOGCXX-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13903811#comment-13903811 ] Florian Seydoux commented on LOGCXX-367: sounds strange to me - if it's really required to add the C headers (instead of the C++ ones, or working with the name resolution) - it means that the std lib on that specific buildchain is broken. Should we really have log4cxx to build on such specific buildchain, or instead hosting the required patch against the official source code on the wiki (for example). > Build fails on Linux with g++ 4.4 > - > > Key: LOGCXX-367 > URL: https://issues.apache.org/jira/browse/LOGCXX-367 > Project: Log4cxx > Issue Type: Bug > Components: Build >Affects Versions: 0.10.0 > Environment: Debian GNU/Linux - sid (unstable) >Reporter: Andreas Tscharner >Assignee: Curt Arnold > Fix For: 0.10.1 > > Attachments: log4cxx-example.patch, log4cxx-include.patch > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > When I try to build Log4cxx, it fails, because it misses a few include files. > andy@shannara:~$ g++ --version > g++ (Debian 4.4.4-8) 4.4.5 20100728 (prerelease) > Copyright (C) 2010 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: Freezing trunk?
On 11.02.2014 22:18, Thorsten Schöning wrote: > > Why do you think that? I've thought that besides getting apr and > apr-util in the right directory it's more or less a simple "mvn > compile" or something? Except if I missed something, it's really not that simple. With ant, you have the choice to generate (a) Visual studio project, or (b) compile directly the source (aka make). But it's first required to add ant-contrib + a slightly patched version of cpptask. (a) makes visual studio 6 projects, which cannot be used by Visual studio versions above 2008; so you have to convert them with a VS2008 before being able to build with 2010, 2012 or later. The (b) path is more straightforward (direct call to the compiler In both case, the unit-test are not built :-/ -- flo
Re: How to deal with files from third persons?
On 10.02.2014 16:29, Thorsten Schöning wrote: > [...] > The reporter provided two file with one containing a copyright of his > own in opposite of a Apache one in the other file. notice that in any case, it's not something that we should apply now (new appenders would not have place on a bugfix release). (but the question must be answered, I totally agree) -- flo
