- 06 Apr, 2018 1 commit
-
-
trisberg authored
- 1.5.10 to 1.5.11 - 2.0.0 to 2.0.1
-
- 26 Mar, 2018 2 commits
- 21 Mar, 2018 1 commit
-
-
Dave Syer authored
Avoids instantiating beans if not necessary, and allows user to provide Function as a @SpringBootApplication (for instance), or more generally as a source to the application context (as opposed to being component scanned).
-
- 20 Mar, 2018 2 commits
- 18 Mar, 2018 1 commit
-
-
Dave Syer authored
User can switch off source or sink behaviour (the default is to bind to input and output streams), and then configure the name of a supplier (for a source) or consumer (for a sink).
-
- 16 Mar, 2018 6 commits
-
-
Dave Syer authored
-
Dave Syer authored
-
Dave Syer authored
-
Dave Syer authored
When a Supplier<Flux<Foo>> is composed with a Function<Foo,Bar> the resulting handler (supplier) should have Flux as its output wrapper still (the most general output wrapper type in the chain).
-
Dave Syer authored
-
Dave Syer authored
A Spring Boot 2.0 app should behave the same as a Spering Boot 1.5 app with this change. The key thing was to change the return type of the FunctionController and move the computation of single valuedness for the output there (instead of trying to do it in the return value handler, which isn't used in Spring 5).
-
- 15 Mar, 2018 2 commits
- 09 Mar, 2018 1 commit
-
-
Dave Syer authored
That was the samples still work with Spring Boot 2.0.0. Fixes gh-157 (but we should add some tests)
-
- 02 Mar, 2018 1 commit
-
-
Dave Syer authored
Fixes gh-153
-
- 01 Mar, 2018 1 commit
-
-
Dave Syer authored
Since a function is wrapper in a FluxWrapper (and possibly also an Isolated), the link is lost between the bean and the type metadata without this change.
-
- 28 Feb, 2018 3 commits
-
-
Dave Syer authored
-
Dave Syer authored
Makes it possible to support other "function" types in the future. The user is always taking a risk with the lookup that the object returned has the generic type desired (but that hasn't changed with this commit). FunctionCatalog is a lot simpler as a result and also a lot more flexible.
-
Kamesh Sampath authored
Signed-off-by:
Kamesh Sampath <kamesh.sampath@hotmail.com>
-
- 27 Feb, 2018 1 commit
-
-
Dave Syer authored
-
- 26 Feb, 2018 5 commits
- 24 Feb, 2018 1 commit
-
-
Dave Syer authored
Fixes #109
-
- 23 Feb, 2018 5 commits
-
-
trisberg authored
-
Dave Syer authored
-
Dave Syer authored
The web module doesn't really need to depend on tomcat and all of the Spring Boot web stack, but users need a way to grab that stuff quickly if they want it (hence the new starter). Also removed all spring-boot-starter dependencies from core and context modules.
-
Dave Syer authored
-
Dave Syer authored
-
- 21 Feb, 2018 1 commit
-
-
Dave Syer authored
-
- 20 Feb, 2018 1 commit
-
-
Dave Syer authored
-
- 16 Feb, 2018 2 commits
-
-
Dave Syer authored
-
Dave Syer authored
Functions with Flux and Message (as well as POJOs and Flux of POJO which were already supported) should now work if they are created in an isolated class loader. Preconditions: * The class loaders must have the reactor-core (and reactive-streams) shared between the app and the function. Practically speaking this means there has to be a parent class loader with just reactive types, and sibling children for the app and the function. This is not a new requirement (it was needed for Flux of POJO anyway). * Message types are handled reflectively, so they don't have to be in a shared class loader. But they do have to be on the class path on both sides (obviously).
-
- 14 Feb, 2018 2 commits
- 09 Feb, 2018 1 commit
-
-
Kamesh Sampath authored
-