Support multiple deployer implementations on the classpath

[markpollack]

Some applications would like to have multiple deployer impls on the classpath which is not currently possible. One approach to support this is to give each deployer bean a unique name so that one can have Spring dependency inject a Map<String,Deployer> of the implemetatations. There maybe some tweeking of conditional annotations needed.

[jvalkeal]

This may be a bit more complex issue than just removing use of hard-coded bean names. Having support for multiple deployers also mean that same server should support multiple instances of a same deployer type(i.e. dataflow server to be able to use PCF deployer targeted for different environments.).

• where/how we choose deployer when app is deployed.
• where do we track which deployer own an app. In case of infrastructure failures, how do we choose which deployer we check for status.

Feels a bit unrealistic to get this feature fully done for 1.1.x as it should be almost done for RC1 if next release is GA.

[markpollack]

This is a feature for use outside the SCDF server, so it doesn't enter into any feature requirements for dataflow. An example is usage in the spring cloud cli launcher.... https://spring.io/blog/2016/11/02/introducing-the-spring-cloud-cli-launcher

[jvalkeal]

Oh, just realised this ticket was on a deployer project. Carry on then :)

[ilayaperumalg]

Submitted PRs for local deployer by adding a profile to the configuration. The local app deployer/task launcher will only be available when this local profile is active. This will help having multiple deployers in the classpath and choose one selectively.

Once we are OK with this approach, other deployers can also be updated with specific profiles.

[markpollack]

what about the different bean name approach?

[ilayaperumalg]

I thought having profile name would be convenient than using bean name as this applies to both app deployer and task launcher. But given @jvalkeal's comment, we can switch back to bean name approach.

[markfisher]

maybe a qualifier instead of just the bean name?

[coopstah13]

+1 for me on this issue, it is preventing a multiple deployer use case for me as well. I would advocate for not using qualifiers or profiles and leave that up to the developer using the deployer implementations. They will have to bind the beans in their own configurations themselves, so they can do it either way. You should leave any configuration elements that are required to instantiate Deployers or TaskLaunchers still. Obviously this puts a bit more work onto the developer but is ultimately more flexible because you can support either case, rather than forcing us into a path. Qualifiers would still not work for my case, though I suppose I could work around it at least.