| Summary: | svc.conf.xml file support broken with ACE_HAS_VERSIONED_NAMESPACE | ||
|---|---|---|---|
| Product: | ACE | Reporter: | milan.cvetkovic |
| Component: | ACEXML | Assignee: | Krishnakumar B <kitty> |
| Status: | NEW --- | ||
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 5.7.6 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Attachments: |
fixes Service_Config_Test for ACEXML, and adds plug in svcconf parser
Automated test for dynamically chosing the .conf file parser based on file extension |
||
Created attachment 1253 [details]
fixes Service_Config_Test for ACEXML, and adds plug in svcconf parser
cd $ACE_ROOT
patch -p1 <ace-5.7.6-user-svcconf.patch
#define ACE_HAS_XML_SVC_CONF 1
#define ACE_HAS_VERSIONED_NAMESPACE 1
- Added new ACE_FILE_EXT_BASED_SVC_CONF which would modify behaviour
of ACE_HAS_CLASSIC_SVC_CONF so:
. default conf file is svc.conf
. declarations of ACE_STATIC_SERVICE_DIRECTIVE and
ACE_STATIC_SERVICE_DIRECTIVE are with "traditional" syntax
. It is possible to load other config file parsers based on the file
extensions.
- Fixed ACE_HAS_XML_SVC_CONF output to LM_DEBUG instead of LM_ERROR in
case of missing service, since the $ACE_ROOT/ace/run_test.pl expects
no LM_ERRORS in output log file for successful test
- Fixed ACE_HAS_XML_SVC_CONF parser to correctly load "dynamic" services
with ACE_VERSION manked in the name of initializer function, by using
$ACE_ROOT/ace/Parse_Node hierarchy
I tried the modifications with the following options in
$ACE_ROOT/ace/config.h
-config.h (1)
#define ACE_HAS_VERSIONED_NAMESPACE 1
#define ACE_HAS_CLASSIC_SVC_CONF 1
#include "config-linux.h"
-config.h (2)
#define ACE_HAS_VERSIONED_NAMESPACE 1
#define ACE_HAS_XML_SVC_CONF 1
#include "config-linux.h"
-config.h (3)
#define ACE_HAS_VERSIONED_NAMESPACE 1
#define ACE_HAS_CLASSIC_SVC_CONF 1
#define ACE_FILE_EXT_BASED_SVC_CONF 1
#include "config-linux.h"
I have tried to make the modifications the least intrusive, in hope to get them included in mainstream,
Some of the classes or functions might need a name change, since they are no longer "XML" only.
I modified ACEXML/apps/conffile only to make sure "dynamic" works correctly. The stream test fails in the original build, and I am not too familiar how this should work...
The above patch is tested with $ACE_ROOT/ace/Service_Config_Test. No new tests are needed? The bug originally described in "Summary" is already tested with Service_Config_Test for known configurations (traditional and xml conf files), and it fails with .xml.conf in ACE-5.6.7, and passes with the patch. I could add a new test case for ACE_FILE_EXT_BASED_SVC_CONF, but this is new feature that nobody (yet) relies on. For new features we do need a test, else if someone starts using it and there are problems, we have problems Created attachment 1256 [details]
Automated test for dynamically chosing the .conf file parser based on file extension
Ok, here is the test program to verify the new feature:
load .xml config file when
#define ACE_HAS_CLASSIC_SVC_CONF 1
#define ACE_FILE_EXT_BASED_SVC_CONF 1
is in config.h
Test only loads .conf.xml. file, since with this configuration, Service_Config_Test would have tested loading .conf file.
btw, while working on the test program, I noticed something suspicious in $ACE_ROOT/tests/Service_Config_Test.cpp: Inside two functions, namely testLoadingServiceConfFile and testLoadingServiceConfFileAndProcessNo there is a copy of ACE_Service_Config created on the stack with the comment: // We need this scope to make sure that the destructor for the // <ACE_Service_Config> gets called. ACE_Service_Config daemon; after which, daemon.open() is invoked. I believe that ACE_Service_Config is a monostate, and the second invocation of "ACE_Service_Config::open" simply returns "nah, I am already open" with status 0. This would mean that second of these two tests isn't really testing anything. |
ACE VERSION: 5.7.6 HOST MACHINE and OPERATING SYSTEM: Sun Solaris 10 on x86 Linux Debian Lenny on x86 THE $ACE_ROOT/ace/config.h FILE [if you use a link to a platform- specific file, simply state which one]: #define ACE_HAS_VERSIONED_NAMESPACE 1 #define ACE_HAS_XML_SVC_CONF 1 #if defined (SOLARIS) # define ACE_HAS_LKSCTP 1 # include "config-sunos5.10.h" #else # include "config-linux.h" # if !defined (ACE_HAS_STRBUF_T) # include <stropts.h> # define ACE_HAS_STRBUF_T 1 # endif # undef ACE_LACKS_STRRECVFD #endif THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE: UNAME=$(shell uname) ifeq (${UNAME},Linux) include ${ACE_ROOT}/include/makeinclude/platform_linux.GNU else GREP=/usr/xpg4/bin/grep -E include ${ACE_ROOT}/include/makeinclude/platform_sunos5_g++.GNU ifneq ($(shell uname -r), 5.8) AR=gar endif ifneq ($(GNU_LD),1) LDFLAGS+=-lgcc_s -lstdc++ endif endif BUILD METHOD USED: traditional CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features: UNMODIFIED AREA/CLASS/EXAMPLE AFFECTED: ACE_Service_Config, ACEXML DOES THE PROBLEM AFFECT: EXECUTION? YES SYNOPSIS: XML service configurator fails to load dynamic symbols, due to failure to mangle the version name into _make_My_Svc() function name. DESCRIPTION: Service configurator tries to load service without ACE_5_7_6 in its name. For example, $ACE_ROOT/tests/Service_Config_Test.conf.xml lists "_make_Service_Config_DLL" as the factory function to initialize the service. However, the actual name of the functions is mangled to contain the string ACE_5_7_6 (I believe the proper name in library is "_make_ACE_5_7_6_Service_Config_DLL"). This is correctly handled by "traditional" Svc_Config loader. However ACEXML/apps/svcconf does not do this properly, and it tries to load the symbol "_make_Service_Config_DLL" from the dynamic library. REPEAT BY: compile ACE, run tests/Service_Config_Test