0

In a project, I have a org.apache.commons.configuration.PropertiesConfiguration object registered as a Bean, to provide configuration values around the application, with hot-reloading capabilities.

Example: I defined a DataSource singleton Bean. I then created a ReloadingDataSource object, which wraps and delegate to the "real" DataSource, and each time the configuration file changes, it is able to recreate it in a thread-safe manner.

I'd like to do something similar for simple properties values.
I'd like to create a simple, Autowireable object that delegate retrieval to the Apache PropertiesConfiguration Bean.

The usage should be similar to:

@Property("my.config.database")
private Property<String> database;

And the call site would simply be:

final String databaseValue = database.get()

You'll say, just pass around the PropertiesConfiguration object. Maybe you're right, but I'd like to provide another abstraction over that, a simpler-to-use one.

I know that with ProxyFactoryBean it is possible to create an AOP proxy for method calls. Is this the right path, or are there better alternatives? Maybe pure Spring AOP/AspectJ?

I don't want to use Spring Cloud or similar dependencies.

LppEdd
  • 20,274
  • 11
  • 84
  • 139

1 Answers1

0

Spring Cloud will recreate the beans, so keep in mind whatever solution you come up with, if you have another bean which only reads this value once for instance when it is initiated, it won't re-initialize itself, that is the problem Spring Cloud Config takes care of.

AOP only works at the method level as I understand, so you can definitely intercept a call to somebean.getFoo(). But within somebean, there is no way to proxy calls to the variable itself: somebean.foo. You would have to reset foo every time your PropertiesConfiguration changed, and again keep in mind that, if anything else needs the new value of foo you would need to handle this or bite the bullet use Spring Cloud.

The overhead you have with changing stuff at run-time to avoid a re-deploy should really be thought carefully about. For Netflix, this makes sense because they have thousands and thousands of servers. But for smaller players I can't see the justification, the decision adds much complexity. Nightmare to test.

  • Do you test changing your configuration at run-time or accept the risk and assume it works?
  • Do you test changing from A -> B whilst under load of a user performing a transaction to the database?
  • Test other raise conditions where foo is changing?

Some things to think about.

Derrops
  • 7,651
  • 5
  • 30
  • 60
  • I understand the overhead, and I'll certainly consider what you've wrote. For the AOP thing, take a look at this https://stackoverflow.com/questions/39493383/spring-aop-pointcut-expression-for-annotated-field – LppEdd Feb 08 '19 at 06:50