OpenClovis / SAFplus-Availability-Scalability-Platform

Middleware that provides libraries, GUI, and code generator to design multi-node (clustered) applications that are highly available, redundant, and scalable. Provides sub-second node and application fault detection and failover, and useful application libraries including distributed hash tables (checkpoint), event, logging, and communications. Implements SA-Forum APIs where applicable. Used anywhere reliability is a must -- like telecom, wireless, defense and enterprise computing. Download stable release with installer from: ftp.openclovis.com
www.openclovis.com
GNU General Public License v2.0
19 stars 13 forks source link

A specific log severity for a user comp. using envs tag #75

Closed CangTranOC closed 11 years ago

CangTranOC commented 11 years ago

We’re using CL_LOG_STREAM_SEVERITY_CUSTOM env. to set a log severity for all streams of User components. App. guy wants to overwrite the Env. in order to change a log severity of specific user component using envs tag in clAmfDefinitions.xml as below.

But, Overwriting Env. failed due to below lines in cpmSetEnvs. / * Set component specific environment variables. / for (i = 0; comp->compConfig->env[i]; ++i) { setenv(comp->compConfig->env[i]->envName, comp->compConfig->env[i]->envValue, 0); }

Please let me know if Overwriting existing env. could be provided. In my opinion, App guy might want to have a specific log severity for a user comp. using envs tag in clAmfDefinitions.xml

Could you please give me a solution for a specific log severity using envs tag?

CangTranOC commented 11 years ago

We actually have 3 levels.

  1. Variables set by user before running SAFplus
  2. Variables set by AMF
  3. Component specific env variables

The reason the original code for "setenv" is passing 0 is so that 1 can override 3. This lets you push customization via environment variable before running SAFplus.

I think the ideal order is 1 overrides 3 overrides 2. But I am not sure if that is achievable because at the time the component is spawned it may be impossible to distinguish case 1&2. So I am OK with this patch. If a customer wants 1 to "override" (imagine a variable DEBUG=TRUE as an example case), he can always NOT define the variable in 2,3 and write his code like "if (getenv(...)==NULL) { variable=default;} else { variable=getenv(...);}

Please write a bug and apply across 5.0,6.0,6.1

Regards, Andy