scala DynamicProperty bindings:

• create a central trait for Dynamic Properties.
• simplified implementations for each binding.
• consistent naming for common attributes like propertyName, defaultValue, etc.
• correct apply() definition to be scala-y.
• update addCallback() definition to take a scala-y function.
• provide a map implementation which takes a conversion function, allowing DynamicProperty implementations of arbitrary type to be created.
• use JavaConverters in collection-y dynamic properties instead of JavaConversions.
• killed deprecated DynamicProperties trait.

Is it possible to refactor and eliminate dependency on commons-configuration?

In Hystrix I'm exploring whether I should eliminate use of Archaius in core due to different environments having conflicts. The primary source of conflicts is the Apache Commons libraries (https://github.com/Netflix/Hystrix/issues/252 as example).

If Archaius truly needs commons-configuration, does the usage of it need to be part of the public API, or can the usage be shaded internally so it's not a dependency seen by consumers?

…rty is stored as Object instead of String.

This PR covers two issues. One is to be able to set a new delimiter. The other is treat Property value as Object instead of String. For now, only turns on the storing for Settable config. In the future, it's possible we need to extend to MapConfig.

Is there any way (or will be) to read configuration values from Typesafe Config[1]?

If not, are you willing to accept a patch? should it be a different artifact?

BTW I'm asking this here since I couldn't find a mailing list for the project and @netflixOSS (Twitter) was unresponsive.

[1] http://github.com/typesafehub/config

How would one go about integrating this library with Spring? Would I just need to create a org.springframework.beans.factory.config.PropertyPlaceholderConfigurer that gets properties from a Archaius configuration source?

Would I do something like:

• Configure a WatchedConfigurationSource or PolledConfigurationSource (either in Java or with Spring )
• Pass it to an "ArchaiusPropertyPlaceholderConfigurer"
• Use Spring properties like normal e.g., "${foo}"

This is an optimization to reduce the cpu hotspots I was seeing under load with usage of DynamicBooleanProperty/DynamicIntProperty getValue implementation. As we use DynamicBooleanProperty's very frequently for feature-flagging in zuul, I was seeing this quite high up when profiling zuul under high load. It seems to be caused by overhead around autoboxing of the value objects to primitives (although I haven't verified this).

I initially added a helper class in zuul for this - https://github.com/Netflix/zuul/blob/2.x/zuul-core/src/main/java/com/netflix/zuul/properties/CachedProperties.java - but would like to apply the same principle in archaius itself, and so have done this PR.

The PR basically changes the Dynamic{Primitive}Property classes to store the cached primitive value, and update it using the callback mechanism. And then change the existing get() method to return this cached value instead of boxing the property value object.

I've included a basic benchmarking class that compares performance of the old and new implementations for boolean. See CachedPropertiesPerfTest.

Requires the following refactorings in archaius-core:

1. extract out the property-updating functionality into a common utility that can be used by both the PollingScheduler's poller as well as the new WatchedConfiguration's callback method.

2. create a generic ConfigurationUpdateResult to encapsulate the createFull() and createIncremental() functionality. PollResult can extend this to add the Checkpoint functionality.

Note: my latest implementation has a dependency on Curator.

Modify DefaultAppConfig to be a DelegatingConfig instead of a CascadingCompositeConfig to avoid exposing all of the CascadingCompositeConfig functionality. Remove withLoadSystem from ConfigLoader Expose getting any layer from AppConfig

I am trying to use Archaius out of the box( without programming any Configuration myself) . How can I use Deployment Context and cascaded property files. There are two ways to supply property files to Archaius - One make it default property file which limits to only 1 configuration file(config.properties) other is additional URLs. I tried using additional URL's and supplied property files. Looks like default configuration is not respecting the "archaius.deployment.environment" system parameter.

I know default implementation use URLConfigurationSource.java when you load additional URL'S but it is not cascading the property files.

I tried calling "ConfigurationManager.loadCascadedPropertiesFromResources(configName)" method which actually did the cascading but when i change any value in source property file it does not pick up the change(polling is not working).

Is there any easy way to do following things - a) load more than one property file b) cascade property according to the environment while making sure any update to the source property file will sync the in memory version. c) it could be a stretch but support @next attribute ..

If it requires me creating my own configuration source, can you give any references about the approach ??

An Etcd watched configuration source very similar to the ZooKeeperConfigurationSource.

Uses the Boon Etcd client https://github.com/boonproject/boon/blob/master/etcd/README.md. Seems to be the most widely adopted Etcd client.

Tests included.

Ran some tests with this recently to verify some assumptions. Glad that I did. Here's my testing code and properties:

public class ArchaiusTest {
    public static final String KEY = "test.message";
    public static final String DEFAULT = "No Message Found";

    public static void main(String[] args) throws Exception 
    {
        DynamicStringProperty message
                = DynamicPropertyFactory.getInstance().getStringProperty(KEY, DEFAULT);

        Configuration configuration = ConfigurationManager.getConfigInstance();

        while (true)
        {
            System.out.println("dynamic : " + message.get());
            System.out.println("config  : " + configuration.getString(KEY, DEFAULT));
            TimeUnit.SECONDS.sleep(30);
        }
    }
}

And the properties file that I'm using :

message.default=default
message.new=new

test.message=This is the ${message.default} message

If I launch the process, the two outputs are the same. If I change the message.default property to be something else (lets say "old"), the dynamic property will remain as "default", but the Configuration object will correctly update the variable interpolation to use "old" in the place holder.

Also, if I completely change the variable (lets say to message.new) the dynamic property picks up the raw, un-interpolated variable name, but the configuration object correctly interpolates the value.

I've posted the program output. __Text surrounded by asterisks are my interactions with the environment**

* Start Program *

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details. dynamic : This is the default message config : This is the default message

* Update configuration - 'message.default=old' *

dynamic : This is the default message config : This is the default message dynamic : This is the default message config : This is the default message

* Program picks up updated configuration *

dynamic : This is the default message config : This is the old message dynamic : This is the default message config : This is the old message

* Update configuration - 'test.message=This is the ${message.new} message' *

dynamic : This is the default message config : This is the old message dynamic : This is the default message config : This is the old message

* Program picks up updated configuration *

dynamic : This is the ${message.new} message config : This is the new message

* Kill Program *

Process finished with exit code 137

Is this expected behavior?

Hi all,

I have prepared the initial integration https://github.com/CodeIntelligenceTesting/oss-fuzz/commit/13929c25e1301978cab9d05efd39799cefd7f8d8 of archaius-core into google oss-fuzz. This will enable continuous fuzzing of this project, which will be conducted by Google. Bugs that will be found by fuzzing will be reported to you. After the initial integration of this project into oss-fuzz, I will continue to add additional fuzz tests to improve the code coverage over time.

The integration requires a primary contact, someone to deal with the bug reports submitted by oss-fuzz. The email address needs to belong to an established project committer and be associated with a Google account as per here. When a bug is found, you will receive an email that will provide you with access to ClusterFuzz, crash reports, and fuzzer statistics. More than 1 person can be included. Please let me know who I should include, if anyone.

Jazzer is used for fuzzing Java applications. Jazzer is a coverage-guided, in-process fuzzer for the JVM platform developed by Code Intelligence. It is based on libFuzzer and brings many of its instrumentation-powered mutation features to the JVM. Jazzer has already found several bugs in JVM applications: Jazzer Findings

Please let me know if you have any questions regarding fuzzing or the oss-fuzz integration.

Parallel builds. This project contains multiple modules. Parallel builds can improve the build speed by executing tasks in parallel. We can enable this feature by setting org.gradle.parallel=true.

Configuration on demand. Configuration on demand tells Gradle to configure modules that only are relevant to the requested tasks instead of configuring all of them. We can enable this feature by setting org.gradle.configureondemand=true.

gradle caching. Shared caches can reduce the number of tasks you need to execute by reusing outputs already generated elsewhere. This can significantly decrease build times. We can enable this feature by setting org.gradle.caching=true.

Gradle daemon. The Daemon is a long-lived process that help to avoid the cost of JVM startup for every build. Since Gradle 3.0, Gradle daemon is enabled by default. For an older version, you should enable it by setting org.gradle.daemon=true.

===================== If there are any inappropriate modifications in this PR, please give me a reply and I will change them.

DynamicProperty#notifyCallbacks for (Runnable r : callbacks) { try { r.run(); } catch (Exception e) { logger.error("Error in DynamicProperty callback", e); } }

Otherwise (String)newValue fails and there's no way to know which property it was for.

There's currently one failing test, though for me it is failing on a clean branch as well.

Filter out empty file name in the config urls. This could also be solved with one line like https://github.com/leancloud/archaius/pull/2 but at least java8 is required:

fileNames = Arrays.stream(fileNames).filter(s -> !s.isEmpty()).toArray(String[]::new);