Bug 3823 - svc.conf.xml file support broken with ACE_HAS_VERSIONED_NAMESPACE
Summary: svc.conf.xml file support broken with ACE_HAS_VERSIONED_NAMESPACE
Status: NEW
Alias: None
Product: ACE
Classification: Unclassified
Component: ACEXML (show other bugs)
Version: 5.7.6
Hardware: All Linux
: P3 normal
Assignee: Krishnakumar B
URL:
Depends on:
Blocks:
 
Reported: 2010-02-11 13:24 CST by milan.cvetkovic
Modified: 2010-02-12 11:29 CST (History)
0 users

See Also:


Attachments
fixes Service_Config_Test for ACEXML, and adds plug in svcconf parser (28.73 KB, patch)
2010-02-11 13:27 CST, milan.cvetkovic
Details
Automated test for dynamically chosing the .conf file parser based on file extension (2.86 KB, text/x-c++src)
2010-02-12 11:23 CST, milan.cvetkovic
Details

Note You need to log in before you can comment on or make changes to this bug.
Description milan.cvetkovic 2010-02-11 13:24:01 CST
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
Comment 1 milan.cvetkovic 2010-02-11 13:27:21 CST
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...
Comment 2 milan.cvetkovic 2010-02-11 13:29:47 CST
The above patch is tested with $ACE_ROOT/ace/Service_Config_Test.


Comment 3 Johnny Willemsen 2010-02-11 13:33:08 CST
No new tests are needed?
Comment 4 milan.cvetkovic 2010-02-11 16:15:31 CST
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.

Comment 5 Johnny Willemsen 2010-02-12 04:13:56 CST
For new features we do need a test, else if someone starts using it and there are problems, we have problems
Comment 6 milan.cvetkovic 2010-02-12 11:23:09 CST
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.
Comment 7 milan.cvetkovic 2010-02-12 11:29:27 CST
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.