As a service author I can use the abstractions provided by Spring Cloud Deployer as part of a multi-flow reactive pipeline about spring-cloud-app-broker HOT 5 CLOSED

The simplest way to achieve this is introducing a new class CloudFoundryAppDeployerOperations that contains all the functionality needed by both the blocking and non-blocking interface.

from spring-cloud-app-broker.

I don't think it is feasible to introduce Reactive versions of the existing S-C-Deployer implementations without the risk of breaking other consumers. This is because a lot of functionality is with an abstract base class

I tried introducing a shared operations class that could be used by both reactive and non-reactive implementations. This quickly started falling apart because a lot of the functionality that would need to be shared via composition exists in the abstract class.

I think it is reasonable to not use Reactor directly to begin with, instead using deployer with an ExecutorService when parallel deployments are required

from spring-cloud-app-broker.

Maybe I wrote this off too early..
There was another discussion about this some time age spring-cloud/spring-cloud-deployer#19

I think my fears about changing the abstract base class could be rectified by removing it completely and replacing with delegate. Would be good to discuss @royclarkson @scottfrederick

from spring-cloud-app-broker.

@royclarkson Do you think it would be possible to remove the .block() call here: https://github.com/spring-cloud/spring-cloud-deployer-cloudfoundry/blob/master/src/main/java/org/springframework/cloud/deployer/spi/cloudfoundry/CloudFoundryAppDeployer.java#L101-L104

from spring-cloud-app-broker.

We can certainly improve that code if we are returning reactive types. IIUC, blocking there was because they wanted the exception thrown. If you are working with imperative expectations, then blocking might be the best option. I'd have to get it loaded up in an IDE and play with it to confirm.

from spring-cloud-app-broker.