Java-buildpack: Support disabling auto-reconfiguration

Created on 4 Aug 2014  ·  10Comments  ·  Source: cloudfoundry/java-buildpack

I do not want CF to reconfigure my Java application for me, but the autoconfigure: false option does not appear to be respected in a manifest, and the Maven plugin does not have any option for disabling it. This option is available on buildpacks for other languages (e.g., Ruby).

Most helpful comment

Hi, yes this is now possible.
Any configuration can now be set through an environment variable instead of forking the buildpack to change the config files directly. For example, to disable Auto reconfiguration you should set an environment variable like this one.

cf set-env myapp JBP_CONFIG_SPRING_AUTO_RECONFIGURATION '[enabled: false]'

More information is in the documentation https://github.com/cloudfoundry/java-buildpack#configuration-and-extension

All 10 comments

What reconfiguration are you trying to avoid? In practice, the Spring auto-reconfiguration JAR is put on the class path, but may not actually do any auto-reconfiguration. Auto-reconfiguration only happens when _both_ a service that is a candidate for reconfiguration _and_ a bean that is a candidate for reconfiguration exist. Therefore, you can avoid auto-reconfiguration by not binding services you do not want to auto-reconfigure with. In addition, auto-reconfiguration is avoided completely if there are any spring-cloud beans defined.

I want to avoid any magic that I haven't specifically asked for. I have no way to debug what fiddling the auto-reconfiguration may be doing server side, including whether it's accurately analyzing user-provided services, and I'd rather free up the droplet memory for a bit more cache or whatever than extra code I don't need and don't want. Furthermore, the auto-reconfiguration is almost completely undocumented (that I've been able to find, at least) and therefore unpredictable as a practical matter.

@chrylis The last point @nebhale mentioned about auto-reconfig turning itself off when it sees a spring-cloud (or even vcap-java) based bean should take care of the situations where an app wants to configure service very specifically. Assuming you use spring-cloud, auto-reconfig will never interfere with your app. I don't think auto-reconfiguraiton will consume any noticeable amount of memory, either.

With all that said, we did offer auto-reconfig to be turned off in v1 (see https://spring.io/blog/2011/11/04/using-cloud-foundry-services-with-spring-part-2-auto-reconfiguration). Now a days, there is a big hammer of forking the buildpack and modifying it to fit any needs. So whether such a switch is still warranted in the java buildpack itself, I will let @nebhale make a call.

At the moment, I believe that auto-reconfiguration behaves appropriately by only acting under a very predictable set of circumstances. I base this on the fact that this is the first issue requesting a way to disable it. I am however open to reconsidering this position if we end up with a number of requests similar to this one. Until we see a reproducible situation where auto-reconfiguration misbehaves and cannot be modified to work properly, I'm inclined to keep things as they are.

As with all components, auto-reconfiguration can be disabled by removing its entry from the list of components. The best location for documentation on auto-reconfiguration is in its GitHub repository and on the framework documentation page.

If there's specific improvements to either the behavior of the auto-reconfiguration or the documentation surrounding it, please let us know and we'll be happy to make them.

In addition, auto-reconfiguration is avoided completely if there are any spring-cloud beans defined.

In my experience there are timing issues in that behavior. If the spring-cloud bean is defined in a profile then it may be identified after an "earlier" declared bean (i.e., one defined outside a specific profile) has already been munged by auto-reconfiguration.

For example, given a configuration that defines two DataSource beans: an embedded data source and an external data source which can vary based on environment/profile. References to the embedded data source will be reconfigured to point to the external data source unless you modify the configuration to inline the embedded data source bean definition.

I would also like to disable auto-reconfiguration, for similar reasons as the original poster: I don't want any magic to happen that I don't understand.
Has it changed? Is it possible to disable it in any other way than forking the buildpack?

Hi, yes this is now possible.
Any configuration can now be set through an environment variable instead of forking the buildpack to change the config files directly. For example, to disable Auto reconfiguration you should set an environment variable like this one.

cf set-env myapp JBP_CONFIG_SPRING_AUTO_RECONFIGURATION '[enabled: false]'

More information is in the documentation https://github.com/cloudfoundry/java-buildpack#configuration-and-extension

I am already using this technique for the memory calculator settings. I guess I had better check all the config files and see what is inside them before I ask questions again.
Thank you.

To do this in a manifest file a different format is required.

Try this,

JBP_CONFIG_SPRING_AUTO_RECONFIGURATION: '[enabled: false]'

Notice the extra :

Is there a plan for this auto-reconfiguration library to support partially disabling the services connections? Specifically, in our use case, we need a customized RedisConnectionFactory (as we use SSL connection to Azure Redis service), however, we want this auto-reconfiguration lib to reconfigure our RabbitMQ (as we using PCF provided RabbitMQ service).

Was this page helpful?
0 / 5 - 0 ratings