Autoconfigure CF Admin Deployer about spring-cloud-dataflow-server-cloudfoundry HOT 14 CLOSED

Has anybody tried to use this on CF? I'm getting the following error when I deploy the admin app:

2016-02-08T11:02:52.52-0500 [APP/0]      ERR Caused by: org.springframework.beans.factory.NoUniqueBeanDefinitionException: No qualifying bean of type [javax.sql.DataSource] is defined: expected single matching bean but found 2: mydb,dataSource

Also CloudFoundryModuleDeployerConfiguration now has spaces instead of tabs for indentation. It should also have copyright year of 2015-2016. Same for ContextLoadsTests.

from spring-cloud-dataflow-server-cloudfoundry.

This seems to be an issue with DataSourceAutoConfiguration not detecting that there is already a DataSource available. If you rename your explicit db from mysql to dataSource, then everything is fine.

from spring-cloud-dataflow-server-cloudfoundry.

before my bad merge. It had been working with binding a 'mysql' service to the admin, which also used DataSourceAutoConfig I would assume. The new enable annotation should be impacting just how the SPI impl is discovered, but there is some odd side effect it would seem.

from spring-cloud-dataflow-server-cloudfoundry.

These seem to be side-effects when a config is moved into auto-configuration and things happen on a different order. spring-cloud/spring-cloud-dataflow#366 is one of those ticking bombs which will blow up if i.e. EnableDataFlowServer is moved into auto-config or something else is kicking different order of config use.

Also DataSourceAutoConfiguration is a little brittle and I had to exclude its auto-config from gpfdist sink. One thing in DataSourceAutoConfiguration may be that it's checking beans of DataSource and XADataSource and if explicitly created bean only implements one of those, I think boot does(maybe, possibly) it's own magic.

from spring-cloud-dataflow-server-cloudfoundry.

One of the problems with our current approach is that
@EnableAutoConfiguration (and hence its excludes) is set on a class that is
in the starter, and so can't be overridden by consumers

On Tue, Feb 9, 2016 at 3:17 PM, Janne Valkealahti [email protected]
wrote:

These seem to be side-effects when a config is moved into
auto-configuration and things happen on a different order.
spring-cloud/spring-cloud-dataflow#366
spring-cloud/spring-cloud-dataflow#366 is one
of those ticking bombs which will blow up if i.e. EnableDataFlowServer is
moved into auto-config or something else is kicking different order of
config use.

Also DataSourceAutoConfiguration is a little brittle and I had to exclude
its auto-config from gpfdist sink. One thing in
DataSourceAutoConfiguration may be that it's checking beans of DataSource
and XADataSource and if explicitly created bean only implements one of
those, I think boot does(maybe, possibly) it's own magic.

—
Reply to this email directly or view it on GitHub
#32 (comment)
.

from spring-cloud-dataflow-server-cloudfoundry.

@ericbottard which starter? Because that's really bad and may cause something I tracked down in spring-cloud/spring-cloud-dataflow#367.

from spring-cloud-dataflow-server-cloudfoundry.

TBH, we have taken the most simple thing in Spring 1.0 - different apps inject a different impl of a strategy interface and made it complex. That commit in the issue you point to is not an obvious solution. Maybe we can have several @EnableDataFlow annotation, one for each SPI impl so that they can control what they need to themselves.

from spring-cloud-dataflow-server-cloudfoundry.

@EnableDataFlowServer is only enabling shared stuff from admin server(controllers, repos, etc) and afaik there's currently nothing spi specific.

from spring-cloud-dataflow-server-cloudfoundry.

What @jvalkeal said... also, let's avoid doing anything drastic at the @EnableDataFlowServer level until we have a better understanding of the boundaries of the generic app-deployer SPI, and specifically what, if anything, has to be configured in addition to that to support the Data Flow Server on each target platform.

from spring-cloud-dataflow-server-cloudfoundry.

I'm talking about AdminConfiguration, which is the one that bears @EnbleAutoConfiguration

from spring-cloud-dataflow-server-cloudfoundry.

lol, ok, 367 was about removing that @EnableAutoConfiguration. We're on a same page here ;)

from spring-cloud-dataflow-server-cloudfoundry.

So w/ the rant over, I think I understand the issue ATM, thanks Janne. We prob don't even need this configuration class at all (cf auto-reconfiguration would inject the right stuff). An @ConditionalOnMissingBean for the datasource here seems to work and also if there are tested configuration classes (not needed here, prob a cut-n-paste thing wrt to moving config out of a common admin) they should have @conditional on them (as ilaya also found in the mesos admin). I'll try out a few things and hope to get this resolved today.

from spring-cloud-dataflow-server-cloudfoundry.

Long term, want to get away from auto-reconfiguration anyway.

from spring-cloud-dataflow-server-cloudfoundry.

Fixed this by simply removing the explicit configuration and let auto-reconfig handle it for now.
2d7e051

from spring-cloud-dataflow-server-cloudfoundry.