covesa / capicxx-core-runtime Goto Github PK

View Code? Open in Web Editor NEW

82.0 20.0 77.0 4 MB

Common API C++ core runtime

License: Mozilla Public License 2.0

CMake 5.73% C++ 93.73% Makefile 0.54%

commonapi genivi genivi-alliance

capicxx-core-runtime's Introduction

CommonAPI C++ Core Runtime

Copyright

This file is part of COVESA Project IPC Common API C++. Contributions are licensed to the COVESA under one or more Contribution License Agreements or MPL 2.0.

License

This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0. If a copy of the MPL was not distributed with this file, you can obtain one at http://mozilla.org/MPL/2.0/.

CommonAPI C++ Specification and User Guide

The specification document and the user guide can be found in the CommonAPI documentation directory of the CommonAPI-Tools project as AsciiDoc document. A pdf version can be found at https://github.com/GENIVI/capicxx-core-tools/releases.

Further information

https://covesa.github.io/capicxx-core-tools/

Build Instructions for Linux

Use CMake to build this library. We assume that your source directory is common-api-runtime:

$ cd common-api-runtime
$ mkdir build
$ cd build
$ cmake -D CMAKE_INSTALL_PREFIX=/usr/local ..
$ make
$ make install

You can change the installation directory by the CMake variable CMAKE_INSTALL_PREFIX or you can let it uninstalled (skip the make install command). Please refer to the installation description of the binding runtime how to use uninstalled versions of CommonAPI.

For further build instructions (build for windows, build documentation, tests etc.) please refer to the CommonAPI tutorial.

Build Instructions for Android

In general for building the Android source tree the instructions found on the pages from the Android Open Source Project (AOSP) apply (https://source.android.com/setup/build/requirements).

To integrate the CommonAPI Core Runtime library into the build process, the source code together with the Android.bp file has to be inserted into the Android source tree (by simply copying or by fetching with a custom platform manifest). When building the Android source tree, the Android.bp file is automatically found and considered by the build system.

In order that the CommonAPI Core Runtime library is also included in the Android image, the library has to be added to the PRODUCT_PACKAGES variable in one of a device/target specific makefile:

PRODUCT_PACKAGES += \
    libCommonAPI

capicxx-core-runtime's People

Contributors

Stargazers

Watchers

Forkers

mcencora invy catalinmihaighita harriche gunnarx 007herelsp ponniahn happy-ferret clivelau1990 thunder2005 neverpanic lucianopalmeida banshenyunxin nkh-lab thorsten-klein jayhou xrzong fchen9 pprajap maingig alanchenboy hongjunxin anotherkote luminartech guningyi soaland syfchao soa-lab barbieri kkretsch mymellivora jjzhang166 blguru20 xujianbin123 fengtuo58 19900824 t00101659 wapeasy mingpuwu luckyclovertt sensokame apexai khoa-io rschrader marques-bruno github-ljw-github yoongool liuting0809 joimson lrunhub taikt harkeryx barryliu1984 sonatus qpc-github quantum-platinum-cloud ek-org donotsmoking duksubbc chrsch youyuanshanren yanxiaochun1005 yangjietadie goncaloalmeida hefroy alexiscompain commonapi-someip lilei11 kheaactua umairasghar-max meziaur ahmed147 nnayar-r2c xbroquer phongt

capicxx-core-runtime's Issues

Compilation problem: error: 'visibility' attribute ignored when parsing type (enum)

In file included from /home/gabriel/git/capicxx-core-runtime/src/CommonAPI/Address.cpp:10:
/home/gabriel/git/capicxx-core-runtime/include/CommonAPI/Logger.hpp:31:37: error: 'visibility' attribute ignored when parsing type [-Werror,-Wignored-attributes]
    enum class Level : std::uint8_t COMMONAPI_EXPORT {
                                    ^~~~~~~~~~~~~~~~
/home/gabriel/git/capicxx-core-runtime/include/CommonAPI/Export.hpp:19:46: note: expanded from macro 'COMMONAPI_EXPORT'
    #define COMMONAPI_EXPORT __attribute__ ((visibility ("default")))
                                             ^~~~~~~~~~~~~~~~~~~~~~
1 error generated.
make[2]: *** [CMakeFiles/CommonAPI.dir/build.make:63: CMakeFiles/CommonAPI.dir/src/CommonAPI/Address.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:132: CMakeFiles/CommonAPI.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

I'm using Ubuntu 20.04 and the last release of Common API (3.2).

std::chrono::high_resolution_clock is used to calculate timeout interval

Hi,

Inside mainloop context implementation chrono::high_resolution_clock is used to calculate timeout interval which can easily result into a bug if the system time is updated by some other source [Ref: MainLoopContext::getCurrentTimeInMs]. Although high_resolution_clock is replaced by steady_clock in capicxx-dbus-runtime, but the same change seems to be missed out in capicxx-core-runtime.

Please correct me if I am wrong.

Thanks & Regards,
Sandeep Arjun

Getting issue while cloning

Hi,
I am following below steps for cloning the common-api-runtime but getting the fatal.
Can anyone help me on this.

$ git clone http://git.projects.genivi.org/ipc/common-api-runtime
Cloning into 'common-api-runtime'...
fatal: unable to access 'http://git.projects.genivi.org/ipc/common-api-runtime/': Couldn't resolve host 'git.projects.genivi.org'

also same issue if trying below :
$ git clone git://git.projects.genivi.org/ipc/common-api-runtime.git
Cloning into 'common-api-runtime'...
fatal: Unable to look up git.projects.genivi.org (port 9418) (No such host is known. )

Could you please help me.

Thank you.
Regards,
Biswa

About tag 2.1.5 again

Sorry to post this issue here :(
Is there any way for me to check what does 2.1.5 directories(or files) look like which comes from git.projects.genivi.org/ipc/common-api-dbus-runtime.git?
Becase the 2.1.5 tag I download from your github repo looks that it is a eclipse plugin.
Please give me more info :)

error: ‘dbus_connection_send_with_reply_set_notify’ was not declared in this scope #23

vishwa@ubuntu:~/vishwa/myCode/trydbus/capicxx-core-runtime/build/capicxx-dbus-runtime/build$ make
[ 4%] Building CXX object CMakeFiles/CommonAPI-DBus.dir/src/CommonAPI/DBus/DBusConnection.cpp.o
/home/vishwa/vishwa/myCode/trydbus/capicxx-core-runtime/build/capicxx-dbus-runtime/src/CommonAPI/DBus/DBusConnection.cpp: In member function ‘virtual bool CommonAPI::DBus::DBusConnection::sendDBusMessageWithReplyAsync(const CommonAPI::DBus::DBusMessage&, std::unique_ptrCommonAPI::DBus::DBusProxyConnection::DBusMessageReplyAsyncHandler, const CommonAPI::CallInfo*) const’:
/home/vishwa/vishwa/myCode/trydbus/capicxx-core-runtime/build/capicxx-dbus-runtime/src/CommonAPI/DBus/DBusConnection.cpp:877:26: error: ‘dbus_connection_send_with_reply_set_notify’ was not declared in this scope; did you mean ‘dbus_connection_send_with_reply_and_block’?
877 | libdbusSuccess = dbus_connection_send_with_reply_set_notify(connection_,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| dbus_connection_send_with_reply_and_block
make[2]: *** [CMakeFiles/CommonAPI-DBus.dir/build.make:102: CMakeFiles/CommonAPI-DBus.dir/src/CommonAPI/DBus/DBusConnection.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:188: CMakeFiles/CommonAPI-DBus.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

Patch command :
vishwa@ubuntu:/$ sudo patch -d/ /home/vishwa/vishwa/myCode/trydbus/capicxx-core-runtime/build/capicxx-dbus-runtime/src/CommonAPI/DBus/DBusConnection.cpp <~/vishwa/myCode/trydbus/capicxx-core-runtime/build/capicxx-dbus-runtime/src/dbus-patches/capi-dbus-add-send-with-reply-set-notify.patch
patching file /home/vishwa/vishwa/myCode/trydbus/capicxx-core-runtime/build/capicxx-dbus-runtime/src/CommonAPI/DBus/DBusConnection.cpp
Hunk #1 FAILED at 3482.
1 out of 1 hunk FAILED -- saving rejects to file /home/vishwa/vishwa/myCode/trydbus/capicxx-core-runtime/build/capicxx-dbus-runtime/src/CommonAPI/DBus/DBusConnection.cpp.rej
patching file /home/vishwa/vishwa/myCode/trydbus/capicxx-core-runtime/build/capicxx-dbus-runtime/src/CommonAPI/DBus/DBusConnection.cpp
Hunk #1 FAILED at 229.
1 out of 1 hunk FAILED -- saving rejects to file /home/vishwa/vishwa/myCode/trydbus/capicxx-core-runtime/build/capicxx-dbus-runtime/src/CommonAPI/DBus/DBusConnection.cpp.rej

Not issue, just example how to use under Android NDK

Example how to use CommonAPI via SOME/IP in Android application for communication between two services from native (C/C++) parts.
Project: https://github.com/nkh-lab/ndk-capi-hello-world

how to do common api environment set up on windows

Hi,
I need compiled dll and binaries for capi on windows.
Could any one help how to build on windows I am not finding any document on this.

Thanks in advance.

How to isolate library specific configuration?

Hello everybody 😉

Suppose I have written a library MyLib that uses internally a CommonAPI. How can the library be configured without exposing the details to the user of the library. Currently loading the correct binding library can only be done by forcing the application to write an .ini file that contains the mapping. Every application that depends on MyLib needs to know the internal requirements of the library, e.g. which concrete instance should be used.

Is that a use case not covered or do I miss something here?

runtime->registerService return false

std::shared_ptrCommonAPI::Runtime runtime = CommonAPI::Runtime::get();
std::string domain = "local";
std::string instance = "commonapi.examples.HelloWorld";
std::string connection = "service-sample";
std::shared_ptr myService =
std::make_shared(); runtime->registerService(domain, instance, myService, connection); return false

How to resolve this? Why false? please give me some suggestion:)

error: ‘dbus_connection_send_with_reply_set_notify’ was not declared in this scope; did you mean ‘dbus_connection_send_with_reply_and_block’? 877 | libdbusSuccess = dbus_connection_send_with_reply_set_notify(connection_, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | dbus_connection_send_with_reply_and_block

error: ‘dbus_connection_send_with_reply_set_notify’ was not declared in this scope; did you mean ‘dbus_connection_send_with_reply_and_block’?
877 | libdbusSuccess = dbus_connection_send_with_reply_set_notify(connection_,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| dbus_connection_send_with_reply_and_block

error: ‘dbus_connection_send_with_reply_set_notify’ was not declared in this scope

make giving the below error:
CommonAPI/DBus/DBusConnection.cpp:875:26: error: ‘dbus_connection_send_with_reply_set_notify’ was not declared in this scope
libdbusSuccess = dbus_connection_send_with_reply_set_notify(connection_,

CommonAPI/DBus/DBusConnection.cpp:875:26: note: suggested alternative: ‘dbus_connection_send_with_reply_and_block’
libdbusSuccess = dbus_connection_send_with_reply_set_notify(connection_,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dbus_connection_send_with_reply_and_block
CMakeFiles/CommonAPI-DBus.dir/build.make:101: recipe for target 'CMakeFiles/CommonAPI-DBus.dir/src/CommonAPI/DBus/DBusConnection.cpp.o' failed
make[2]: *** [CMakeFiles/CommonAPI-DBus.dir/src/CommonAPI/DBus/DBusConnection.cpp.o] Error 1
CMakeFiles/Makefile2:106: recipe for target 'CMakeFiles/CommonAPI-DBus.dir/all' failed
make[1]: *** [CMakeFiles/CommonAPI-DBus.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2

Please help. Thanks

DLT logging property not used

I tried to use DLT logging, but never got any lines until I changed the source.

In Logger.cpp is a line:

#ifdef USE_DLT
        if (useDlt_) {
            std::string app = Runtime::getProperty("LogApplication");

which always gets back an empty app object. The Runtime class only reads a predefined amount of values out of the commonapi.ini not including anything like LogApplication or LogContext.

And if I try to define those values in my client application like shown in some examples:

int main() {
std::cout << "Start of client main" << std::endl;
    CommonAPI::Runtime::setProperty("LogApplication", "CAPI");
    CommonAPI::Runtime::setProperty("LogContext", "SYNC");
std::cout << "End of setRuntime in client main" << std::endl;

I can see that the init function of the lib is executed before the very first lines of my own main function (what is the expected order, first init the base, then the top).

In init
prop LogApplication='
In register app
prop LogContext='
In register context
Start of client main
End of setRuntime in client main

All with the latest 3.2.0 tagged from this git.

Solution might be to add those two properties to the preloading steps of the Runtime class.

questions regarding the establishment of connections between clients and services

I have two questions about some details how connections between clients and services are established:

At least with the SomeIP binding, it seems to be possible to create a proxy object before the requested service is registered. Then the proxy is prebooked for a connection with the requested service in the routing component of vsomeip. As soon as the service gets available the proxy is conntected. I guess this behavior is the reason for the user code pattern for the proxy creation that is recommended by the CommonAPI UserGuide. This pattern suggests to call 'isAvailable()' cyclically until the service is really available before you call remote procedures via the proxy.
Is this feature of delayed connection establishment a general requirement that has to be fulfilled by any binding implementation to be compliant with the CommonAPI standard? As we implement our own bindings it is important to know which features we have to provide.
As far as I know, a proxy object is not automatically reconnected when the service instance it refers to is stopped and restarted. You have to create another proxy object to establish to connection to the restarted service instance again. Is that really correct?
If that is true it seems to be inconsistent in comparison to the feature described in my first question above. The connection is automatically established when the service instance gets available for the first time but not again later on?
Maybe I misunderstand or oversee something here. Please explain to me the ideas behind the way connections are established a little bit more in detail.

Regards,
Torsten Görg
itemis AG

when support dds communication binding?

Hi
CommonAPI currently supports vsomeip and dbus communication bindings. Are there any current plans to add dds communication bindings?

Can we use someip tags for extensible communication or it needed to be developped

CommonAPI::DBus::DBusServiceRegistry::insertServiceNameMapping Segmentation fault

Hello,

I am base on CommonAPI 3.1.5.
I have a segmentation fault from DBusServiceRegistry.

It is a known issue corrected on more recent release ?

Regards

#0 0x419fe530 in std::_Hashtable<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::pair<std::__cxx11::basic_string<char, std::char_traits, std::allocator > const, CommonAPI::DBus::DBusServiceRegistry::DBusUniqueNameRecord*>, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits, std::allocator > const, CommonAPI::DBus::DBusServiceRegistry::DBusUniqueNameRecord*> >, std::__detail::_Select1st, std::equal_to<std::__cxx11::basic_string<char, std::char_traits, std::allocator > >, std::hash<std::__cxx11::basic_string<char, std::char_traits, std::allocator > >, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<true, false, true> >::_M_find_before_node (this=this@entry=0x18d18c, __n=1, __k="Lifecycle.Interface.LifecycleAPI", __code=__code@entry=2571721365) at /usr/include/c++/6.2.0/bits/hashtable.h:1417
#1 0x419fe5f0 in std::_Hashtable<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::pair<std::__cxx11::basic_string<char, std::char_traits, std::allocator > const, CommonAPI::DBus::DBusServiceRegistry::DBusUniqueNameRecord*>, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits, std::allocator > const, CommonAPI::DBus::DBusServiceRegistry::DBusUniqueNameRecord*> >, std::__detail::_Select1st, std::equal_to<std::__cxx11::basic_string<char, std::char_traits, std::allocator > >, std::hash<std::__cxx11::basic_string<char, std::char_traits, std::allocator > >, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<true, false, true> >::_M_find_node (__c=2571721365, __key="Lifecycle.Interface.LifecycleAPI", __bkt=, this=0x18d18c) at /usr/include/c++/6.2.0/bits/hashtable.h:634
#2 std::_Hashtable<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::pair<std::__cxx11::basic_string<char, std::char_traits, std::allocator > const, CommonAPI::DBus::DBusServiceRegistry::DBusUniqueNameRecord*>, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits, std::allocator > const, CommonAPI::DBus::DBusServiceRegistry::DBusUniqueNameRecord*> >, std::__detail::_Select1st, std::equal_to<std::__cxx11::basic_string<char, std::char_traits, std::allocator > >, std::hash<std::__cxx11::basic_string<char, std::char_traits, std::allocator > >, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<true, false, true> >::find (this=this@entry=0x18d18c, __k="Lifecycle.Interface.LifecycleAPI") at /usr/include/c++/6.2.0/bits/hashtable.h:1294
#3 0x419f2e34 in std::unordered_map<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, CommonAPI::DBus::DBusServiceRegistry::DBusUniqueNameRecord*, std::hash<std::__cxx11::basic_string<char, std::char_traits, std::allocator > >, std::equal_to<std::__cxx11::basic_string<char, std::char_traits, std::allocator > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits, std::allocator > const, CommonAPI::DBus::DBusServiceRegistry::DBusUniqueNameRecord*> > >::find (__x="Lifecycle.Interface.LifecycleAPI", this=0x18d18c) at /usr/include/c++/6.2.0/bits/unordered_map.h:851

#4 CommonAPI::DBus::DBusServiceRegistry::insertServiceNameMapping (this=this@entry=0x18d148, dbusUniqueName=":1.93", dbusServiceName="Lifecycle.Interface.LifecycleAPI") at /usr/src/debug/mm-common-api-c++-dbus/3.1.5.0+gitAUTOINC+eab540f476-r4/git/dist/CommonAPIDbus/src/src/CommonAPI/DBus/DBusServiceRegistry.cpp:1345
#5 0x419f6ecc in CommonAPI::DBus::DBusServiceRegistry::onDBusServiceAvailable (this=this@entry=0x18d148, dbusServiceName="Lifecycle.Interface.LifecycleAPI", dbusServiceUniqueName=":1.93") at /usr/src/debug/mm-common-api-c++-dbus/3.1.5.0+gitAUTOINC+eab540f476-r4/git/dist/CommonAPIDbus/src/src/CommonAPI/DBus/DBusServiceRegistry.cpp:1122
#6 0x419f73e8 in CommonAPI::DBus::DBusServiceRegistry::onDBusDaemonProxyNameOwnerChangedEvent (this=0x18d148, affectedName="Lifecycle.Interface.LifecycleAPI", oldOwner="", newOwner=":1.93") at /usr/src/debug/mm-common-api-c++-dbus/3.1.5.0+gitAUTOINC+eab540f476-r4/git/dist/CommonAPIDbus/src/src/CommonAPI/DBus/DBusServiceRegistry.cpp:1113
#7 0x419c85a0 in std::function<void (std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)>::operator()(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&) const (__args#2=":1.93", __args#1="", __args#0="Lifecycle.Interface.LifecycleAPI", this=) at /usr/include/c++/6.2.0/functional:2136
#8 CommonAPI::Event<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::__cxx11::basic_string<char, std::char_traits, std::allocator > >::notifyListeners (eventArguments#2=":1.93", eventArguments#1="", eventArguments#0="Lifecycle.Interface.LifecycleAPI", this=0x18d30c) at /usr/include/CommonAPI-3.1/CommonAPI/Event.hpp:183
#9 CommonAPI::DBus::DBusEvent<CommonAPI::Event<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::__cxx11::basic_string<char, std::char_traits, std::allocator > >, std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::__cxx11::basic_string<char, std::char_traits, std::allocator > >::handleSignalDBusMessage<0, 1, 2> (_message=..., this=0x18d30c) at /usr/src/debug/mm-common-api-c++-dbus/3.1.5.0+gitAUTOINC+eab540f476-r4/git/dist/CommonAPIDbus/src/include/CommonAPI/DBus/DBusEvent.hpp:112
#10 CommonAPI::DBus::DBusEvent<CommonAPI::Event<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::__cxx11::basic_string<char, std::char_traits, std::allocator > >, std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::__cxx11::basic_string<char, std::char_traits, std::allocator > >::onSignalDBusMessage (this=0x18d30c, _message=...) at /usr/src/debug/mm-common-api-c++-dbus/3.1.5.0+gitAUTOINC+eab540f476-r4/git/dist/CommonAPIDbus/src/include/CommonAPI/DBus/DBusEvent.hpp:73
#11 0x419b7c04 in CommonAPI::DBus::notifyDBusSignalHandlers<std::unordered_map<std::tuple<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::__cxx11::basic_string<char, std::char_traits, std::allocator > >, std::pair<std::shared_ptrstd::recursive_mutex, std::set<CommonAPI::DBus::DBusProxyConnection::DBusSignalHandler*, std::lessCommonAPI::DBus::DBusProxyConnection::DBusSignalHandler*, std::allocatorCommonAPI::DBus::DBusProxyConnection::DBusSignalHandler* > >, std::hash<std::tuple<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::__cxx11::basic_string<char, std::char_traits, std::allocator > > >, std::equal_to<std::tuple<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::__cxx11::basic_string<char, std::char_traits, std::allocator > > >, std::allocator<std::pair<std::tuple<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::__cxx11::basic_string<char, std::char_traits, std::allocator > > const, std::pair<std::shared_ptrstd::recursive_mutex, std::set<CommonAPI::DBus::DBusProxyConnection::DBusSignalHandler*, std::lessCommonAPI::DBus::DBusProxyConnection::DBusSignalHandler*, std::allocatorCommonAPI::DBus::DBusProxyConnection::DBusSignalHandler* > > > > > > (dbusHandlerResult=, dbusMessage=..., signalEntry=, dbusSignalHandlerstable=std::unordered_map with 1 elements = {...}) at /usr/src/debug/mm-common-api-c++-dbus/3.1.5.0+gitAUTOINC+eab540f476-r4/git/dist/CommonAPIDbus/src/src/CommonAPI/DBus/DBusConnection.cpp:1433
#12 CommonAPI::DBus::DBusConnection::onLibdbusSignalFilter (this=0x1895d0, libdbusMessage=) at /usr/src/debug/mm-common-api-c++-dbus/3.1.5.0+gitAUTOINC+eab540f476-r4/git/dist/CommonAPIDbus/src/src/CommonAPI/DBus/DBusConnection.cpp:1490
#13 0x41684784 in dbus_connection_dispatch (connection=0x189960) at /usr/src/debug/dbus/1.10.10-r0/dbus-1.10.10/dbus/dbus-connection.c:4858
#14 0x419b3894 in CommonAPI::DBus::DBusConnection::singleDispatch (this=0x1895d0) at /usr/src/debug/mm-common-api-c++-dbus/3.1.5.0+gitAUTOINC+eab540f476-r4/git/dist/CommonAPIDbus/src/src/CommonAPI/DBus/DBusConnection.cpp:916
#15 0x419d3468 in CommonAPI::DBus::DBusMainLoop::dispatch (this=0x18c378, this@entry=0x419d33f4 CommonAPI::DBus::DBusMainLoop::dispatch()+580) at /usr/src/debug/mm-common-api-c++-dbus/3.1.5.0+gitAUTOINC+eab540f476-r4/git/dist/CommonAPIDbus/src/src/CommonAPI/DBus/DBusMainLoop.cpp:546
#16 0x419d41c0 in CommonAPI::DBus::DBusMainLoop::doSingleIteration (this=0x419d33f4 CommonAPI::DBus::DBusMainLoop::dispatch()+580, this@entry=0x18c378, timeout=@0x41a476ec: -5261985641223916076) at /usr/src/debug/mm-common-api-c++-dbus/3.1.5.0+gitAUTOINC+eab540f476-r4/git/dist/CommonAPIDbus/src/src/CommonAPI/DBus/DBusMainLoop.cpp:340
#17 0x419d4304 in CommonAPI::DBus::DBusMainLoop::run (this=0x18c378, timeoutInterval=@0x41a1ff18: 9223372036854775807) at /usr/src/debug/mm-common-api-c++-dbus/3.1.5.0+gitAUTOINC+eab540f476-r4/git/dist/CommonAPIDbus/src/src/CommonAPI/DBus/DBusMainLoop.cpp:210
#18 0x418afaf4 in std::execute_native_thread_routine (__p=0x1836f8) at ../../../../../../../../../../work-shared/gcc-6.2.0-r0/gcc-6.2.0/libstdc++-v3/src/c++11/thread.cc:83
#19 0x414360f0 in start_thread (arg=0xaf0fe410) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:458
#20 0x413c0768 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:86 from /data2/corecrunch/TBM/rels/TBM2_L1_19082A_D/rootfs/lib/libc.so.6

No way to construct empty Variant

Based on the description the default ctor should construct an empty variant value:

**
     * \brief Construct an empty variant
     *
     * Construct an empty variant
     */
    Variant();

hasValue method always returns 'true' even for the following simple scenario:

assert (Variant<char, int>{}.hasValue() == false); // expectation to have an empty variant here

and there is not bad_cast exception

const auto value Variant<char, int>{}.get<char>();  // there is no `bad_cast` exception, why?

Could you please clarify what is an excepted behavior?

Fix cppy-windows error (clang_cl)

Clang_cl complains about exported deleted function, remove the export fixes the issue

is fixed by #43

SIGSEV: Logger not properly initialized

Because of using the compiler extension __attribute__((constructor)) the order of initialization is compiler dependent which results in SIGSEV when accessing the LoggerImpl in Logger::init.

Is it possible to use commonapi with in the same process? Do we have any configuration to achieve this.

We are using COMMONAPI DBUS IPC with FIDL to communicate between process. Now I have new requirement, where I want to communicate within the process modules using the same FIDL.
Is there any way to achieve this with-out posting via proxy to dbus daemon.

Some Tags point to bad repository

I can't get old version of CommonAPI C++.
Tag 3.1.5-2.1.6 point to CommonAPI-Tools repository and
tag 2.1.5-2.0.0 point to CommonAPI-D-Bus one.

Thanks in advance.

Comments on configuration file are not handled correctly

It seems comments on the configuration file are not handled correctly, since they are shown as errors on the log:

[CAPI][ERROR] Missing '=' in key=value definition (line 6)

That is while using a configuration file like this:

[logging]
console=true
level=verbose

[proxy]
; comment

The solution to that problem, would be to simply ignore the comments while loading the configuration file (src/CommonAPI/IniFileReader.cpp, line 47):

// Ignore comments on the configuration file
std::size_t comment = line.find(';');
if (comment == 0) {
   continue;
}

The callback function never call

Hi everyone,
I use the commonapic++ to build my application, and in my application have used ivn::Handle in some services, but when I try to add them, the problem is the callback function from the someip never calls. It is normal when I remove the ivn::Handle. Can Everyone have the same trouble?

How to stop/terminate the application properly using CommonAPI? Which CommonAPI method I have to call?

I created one sample Helloworld application to register the service using CommonAPI. If I directly exit the application, I've faced crash issue during multiple times execution(approx 15:1 ratio).

Error snippet:
Successfully Registered Service! [ 7153.988687]~DLT~14482~WARNING ~Lost log messages in user buffer when exiting: 1 2021-09-25 19:49:21.340402 [info] io thread id from application: d039 () is: ffff8b61a000 TID: 14486 2021-09-25 19:49:21.340848 [info] Client d039 successfully connected to routing ~> registering.. terminate called recursively terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::log::v2_mt_posix::system_error> >' what(): Failed to set TLS value: Invalid argument terminate called recursively

From my analysis, this issue due to abrupt exit of the application. Now I want to terminate the application gracefully(not abruptly) using CommonAPI. Please help me to sort out the issue.

Runtime.hpp member defaultCallTimeout_

defaultCallTimeout_ is not initialize, will be error

Yocto failed to fetch tag 2.1.5

In my yocto environment(bitbake version is 1.24.0)
I found yocto failed to download the specified tag 2.1.5 of capicxx-core-runtime
my bb file's content is like blow:

SRCREV = "210ce21e5763e7dcb164803e3d21b8302f87e2e9" // this commit id is tag 2.1.5

SRC_URI = "git://github.com/GENIVI/capicxx-core-runtime.git; "

After this error, I tracked bitbake execution route, and found these commands:

git -c core.fsyncobjectfiles=0 clone --bare --mirror git://github.com/GENIVI/capicxx-core-runtime.git github.com.GENIVI.capicxx-core-runtime.git
cd the directory github.com.GENIVI.capicxx-core-runtime.git generated by the first step
git -c core.fsyncobjectfiles=0 branch --contains 210ce21 --list master 2> /dev/null | wc -l

output "0"

For validating result，I did a test on an github project poco

git -c core.fsyncobjectfiles=0 clone --bare --mirror git://github.com/pocoproject/poco.git github.com.pocoproject.poco.git
cd directory github.com.pocoproject.poco.git
git -c core.fsyncobjectfiles=0 branch --contains bfbe6a328744eaa84cb443b93ee20947aa0be91f --list master 2> /dev/null | wc -l

the commit id belongs to poco's tag 1.7.9
output "1"

I wonder, why capicxx-core-runtime doesn't work with above steps?

Linking Dependency Build Error

With CommonAPI library iam able to generate code and build binary in ubuntu 14, but unable to build the binary in ubuntu 22. What should be the possible reasons?

issue: std::string incomplete type in Types.hpp

Hello it seems this would lead some error in some enviroments when compiling, I was trying on Fedora 38, I compiled successfully in order envs. but not for this so it would be good idea to include it, at the top of the file where should it be.

this is from master branch, I haven't tested in other branchs.

.../capicxx-core-runtime/include/CommonAPI/Types.hpp:113:40: error: return type ‘std::string’ {aka ‘class std::__cxx11::basic_string<char>’} is incomplete
  113 |     virtual std::string getEnv() const {
      |                                        ^

How server get client's connect by CommonApi?

environment: vsomeip+CommonApi
As server, whether there is a interface or function to get client connected now by CommonApi?
And how to get the count of all clients connected to server?
thx!

not possible to use an interface type with multiple bindings

Principally, multiple bindings can be used in parallel. But I found a surprising restriction. It seems to be not possible to make use of the same interface type with multiple bindings inside of one executable. I.e., the core runtime library is not prepared to provide an interface instance based on a particular binding and another instance of the same interface type based on another binding. In the methods 'Runtime::createProxyHelper' and 'Runtime::registerStubHelper' there is an algorithm that just iterates the availabe factories on a call of 'buildProxy' respectively 'registerService'. The first factory that can provide a proxy respectively stub object for the requested interface type randomly wins. It seems to be not possible to control the choice of a binding here. I.e., the configuration in "commonapi.ini" does not affect this choice. Principally, in the [proxy] and [stub] sections of "commonapi.ini" you can specify binding hints per address. But it seems that these hints only support the loading of dynamically linked libraries.
Have I overseen anything? Or is the use of the same interface type with multiple multiple really not supported yet?
If it is not supported I suggest to modify the runtime library implementation to make the binding choce controllable.