Spring integration for Archaius

[mumrah]

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}"

[allenxwang]

I am not an expert on Spring. But I think one way to do it is to create a class which export all properties held by the configuration container ConfigurationManager. Then pass this class to PropertyPlaceholderConfigurer. Some adapter might be needed to make sure that the properties exported from the class always reflects the up-to-date value of the property, i.e., same as ConfigurationManager.getConfigInstance().getProperty(name).

[chriswhitcombe]

@mumrah did you ever look into this? I was going to take a look but noticed this post so thought i'd check

[mumrah]

@allenxwang @chriswhitcombe,

Here is what I mangled together to get this working with Camel+Spring: https://gist.github.com/mumrah/6439588

We ended up not using Archaius with our Camel/Spring project, so this has not been tested thoroughly. Use at your own risk :)

BTW, we took out Archaius b/c it was determined that dynamic property loading was not a requirement for the project. The library itself has been great and we're using it on other things.
-David

[chriswhitcombe]

Cheers David ill take a look, see if i can't get a nice spring binding setup and working.

[chriswhitcombe]

@mumrah I was wondering why you went down the route you did, any reason you couldnt just subclass the configurer and use it as a proxy to archaius, quick gist here:

https://gist.github.com/chriswhitcombe/6510808

I know this means I loose dynamic properties but spring injects them on load anyway so I dont know of a way to make them dynamic in spring, unless thats what you were going for?

[mumrah]

I did it this way so I could inject the configuration object to get dynamic
properties in java

Sent from my phone

On Sep 4, 2013, at 9:24 AM, chriswhitcombe notifications@github.com wrote:

@mumrah https://github.com/mumrah did you ever look into this? I was
going to take a look but noticed this post so thought i'd check

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/113#issuecomment-23803226
.

[siggimoo]

I don't even bother with trying to integrate the two in this manner. I just call Archaius from @bean methods. For instance:

@Bean
public DatabaseConnection databaseConnection()
{
    DynamicStringProperty jdbcUrl = DynamicPropertyFactory.getInstance().getStringProperty("databaseConnection", null);
    return new DynamicDatabaseConnection(jdbcUrl);
}

[andrewharmellaw]

I'm working on a tiny piece of code which takes a great deal of the goodness above and which will be packaged as a jar. We're also wanting to use it for Camel too.

I'm currently in the process of writing a load of unit tests to check everything works nicely and am hitting that problem that after we hit DynamicPropertyFactory.initWithConfigurationSource(config) once we can't hit it again (i.e in another test) without getting an error. This is making testing hard. Is there a back door to unset the config source in a test teardown? (I had a look around but couldn;t see anything).

[gorzell]

I think that @stujapa had a method for doing this in scala, but I don't remember the details so I am not sure it would apply.

Generally to work around this in application code, I have just made sure that in the beforeEach methods in the test I reset the properties being used to some default values. That of course doesn't work if you want to check if the property exists, but in that case you can remove it in that particular test.

For the testing configuration loading, it is really something we should come up with a better solution for than the current one, which is starting a new JVM for each test case. Hopefully @howardyuan and @allenxwang can put this down as another +1 for a reset feature.

[howardyuan]

I was poking around this topic some time back. What I wanted to do is to introduce a new interface "re-install" which pretty much blows away the existing config and add the new config. This way we maintain the compatibility and provide way to to re-configure. I'll see if I can find some time to get this going.

[siggimoo]

@andrewharmellaw You could abstract Archaius out of your testing altogether. Create something like a Configuration interface for which Archaius is but one implementation, and then use another (e.g. mock) for testing.

[stujapa]

+1 for simple stuff. More difficult when testing items like callbacks.

[stujapa]

(And simple stuff is the 90% case for archaius consumers.)

[gorzell]

@howardyuan lets move the discussion about how to implement re-installation or something similar to #155.

[andrewharmellaw]

Cheers for all the input guys. I've solved my problem for the moment by getting by surefire plugin to fork for every test. I'd +1 a "reset" feature, but it's not essential for us at runtime (as far as I can see for now).

We're getting near the point when we'll be able to make this available (mainly docs and tidying up for now, but with some outstanding features which we personally don't need, but which others might find useful.) When we do, I'll post the repo URL here. I'll make sure we credit everyone here with their input, with especial thanks to @mumrah and @chriswhitcombe

[andrewharmellaw]

Hey guys, as promised (finally) we've got things tidy enough to want to share our repo with you. Its over at https://github.com/Capgemini/archaius-spring-adapter.

We've name checked this thread, and slightly cheekily said we got permission to release it under Apache v2. @mumrah, if you're not happy with this please shout and we can take it down or change the licence, name you more explicitly or directly or whatever. You kicked this off so we want to make sure you're credited sufficiently.

Please take a look, have a fiddle, comment, fork, fix, contribute however you think is appropriate. Oh, and please note, we've not got everything working that we want to yet, but it's usable, and stable.

Thanks again.