New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support disabling auto-reconfiguration #77

Closed
chrylis opened this Issue Aug 4, 2014 · 10 comments

Comments

Projects
None yet
7 participants
@chrylis

chrylis commented Aug 4, 2014

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).

@nebhale

This comment has been minimized.

Show comment
Hide comment
@nebhale

nebhale Aug 4, 2014

Member

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.

Member

nebhale commented Aug 4, 2014

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.

@chrylis

This comment has been minimized.

Show comment
Hide comment
@chrylis

chrylis Aug 4, 2014

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 commented Aug 4, 2014

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.

@ramnivas

This comment has been minimized.

Show comment
Hide comment
@ramnivas

ramnivas Aug 5, 2014

@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.

ramnivas commented Aug 5, 2014

@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.

@nebhale

This comment has been minimized.

Show comment
Hide comment
@nebhale

nebhale Aug 6, 2014

Member

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.

Member

nebhale commented Aug 6, 2014

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.

@nebhale nebhale closed this Aug 18, 2014

@celkins

This comment has been minimized.

Show comment
Hide comment
@celkins

celkins Aug 27, 2014

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.

celkins commented Aug 27, 2014

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.

@wujek-srujek

This comment has been minimized.

Show comment
Hide comment
@wujek-srujek

wujek-srujek Sep 13, 2015

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?

wujek-srujek commented Sep 13, 2015

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?

@cgfrost

This comment has been minimized.

Show comment
Hide comment
@cgfrost

cgfrost Sep 15, 2015

Contributor

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

Contributor

cgfrost commented Sep 15, 2015

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

@wujek-srujek

This comment has been minimized.

Show comment
Hide comment
@wujek-srujek

wujek-srujek Sep 15, 2015

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.

wujek-srujek commented Sep 15, 2015

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.

@cgfrost

This comment has been minimized.

Show comment
Hide comment
@cgfrost

cgfrost Sep 15, 2015

Contributor

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

Try this,

JBP_CONFIG_SPRING_AUTO_RECONFIGURATION: '[enabled: false]'

Notice the extra :

Contributor

cgfrost commented Sep 15, 2015

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

Try this,

JBP_CONFIG_SPRING_AUTO_RECONFIGURATION: '[enabled: false]'

Notice the extra :

@imarchuang

This comment has been minimized.

Show comment
Hide comment
@imarchuang

imarchuang Dec 1, 2017

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).

imarchuang commented Dec 1, 2017

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment