David Turanski

depends on https://github.com/spring-cloud/spring-cloud-deployer/issues/351

depends on https://github.com/spring-cloud/spring-cloud-deployer-cloudfoundry/issues/384

see https://github.com/spring-cloud/spring-cloud-dataflow/blob/b6d094924d86fff3530cf83aefe6530f8ce10a55/spring-cloud-dataflow-server-core/src/main/java/org/springframework/cloud/dataflow/server/stream/SkipperStreamDeployer.java#L376

Long story why I was checking for content type header in the first place, it's not relevant to the test. So I discovered this issue by accident.

There's a system property to set for Kryo to ignore the warnings, but I'm not sure which component would do that. We get similar warnings from Spring reflection as well....

@cppwfs - I just hit this issue on K8s.

Changing the title of this issue to support an S3 artifact repository, not necessarily integrated with Maven. The approach described in the OP is a dead end since the code...

@dsyer - Interesting, spring-cloud-stream bindings do not create these components (AmqpInboundChannelAdapter and SimpleMessageListenerContainer) as beans, e.g. [here](https://github.com/spring-cloud/spring-cloud-stream/blob/master/spring-cloud-stream-binders/spring-cloud-stream-binder-rabbit/src/main/java/org/springframework/cloud/stream/binder/rabbit/RabbitMessageChannelBinder.java#L279). So the good news is the bus does not need to be excluded....

Another idea I had is to delegate to the /pause /resume endpoint to call stop() and start() on the app context. The problem is that the app context in that...

I see a few open questions here: * There are a couple of possible mappings from CloudEvent to Message, e.g., `attributes` natural maps to message headers and `data` (plus `extensions`?)...