Add additional documentation around AWS jar layout
- Add to note explain when resource transformers are needed - Fix relative linking in the adapters directory see #359
This commit is contained in:
committed by
Oleg Zhurakousky
parent
4d9cdb9750
commit
372a3ce49d
@@ -14,6 +14,39 @@ manifest, using the `Start-Class` attribute (which will be added for you by the
|
||||
tooling if you use the starter parent). If there is no `Start-Class` in your manifest you can
|
||||
use an environment variable or system property `MAIN_CLASS` when you deploy the function to AWS.
|
||||
|
||||
If you are not using the functional bean definitions but relying on Spring Boot's auto-configuration,
|
||||
then additional transformers must be configured as part of the maven-shade-plugin execution.
|
||||
|
||||
[source, xml]
|
||||
----
|
||||
<plugin>
|
||||
<groupId>org.apache.maven.plugins</groupId>
|
||||
<artifactId>maven-shade-plugin</artifactId>
|
||||
<dependencies>
|
||||
<dependency>
|
||||
<groupId>org.springframework.boot</groupId>
|
||||
<artifactId>spring-boot-maven-plugin</artifactId>
|
||||
</dependency>
|
||||
</dependencies>
|
||||
<configuration>
|
||||
<createDependencyReducedPom>false</createDependencyReducedPom>
|
||||
<shadedArtifactAttached>true</shadedArtifactAttached>
|
||||
<shadedClassifierName>aws</shadedClassifierName>
|
||||
<transformers>
|
||||
<transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
|
||||
<resource>META-INF/spring.handlers</resource>
|
||||
</transformer>
|
||||
<transformer implementation="org.springframework.boot.maven.PropertiesMergingResourceTransformer">
|
||||
<resource>META-INF/spring.factories</resource>
|
||||
</transformer>
|
||||
<transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
|
||||
<resource>META-INF/spring.schemas</resource>
|
||||
</transformer>
|
||||
</transformers>
|
||||
</configuration>
|
||||
</plugin>
|
||||
----
|
||||
|
||||
== Upload
|
||||
|
||||
Build the sample under `spring-cloud-function-samples/function-sample-aws` and upload the `-aws` jar file to Lambda. The handler can be `example.Handler` or `org.springframework.cloud.function.adapter.aws.SpringBootStreamHandler` (FQN of the class, _not_ a method reference, although Lambda does accept method references).
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
This project provides an adapter layer for a Spring Cloud Function application onto AWS Lambda. You can write an app with a single `@Bean` of type `Function`, `Consumer` or `Supplier` and it will be deployable in AWS if you get the JAR file laid out right. The best way to make it work is to include `spring-cloud-function-context` as a dependency, but not the higher level adapters (e.g. `spring-cloud-function-stream`).
|
||||
|
||||
include::adapters/aws-intro.adoc[]
|
||||
include::aws-intro.adoc[]
|
||||
|
||||
@@ -8,12 +8,12 @@ The https://aws.amazon.com/[AWS] adapter takes a Spring Cloud Function app and c
|
||||
|
||||
== Introduction
|
||||
|
||||
include::adapters/aws-intro.adoc[]
|
||||
include::aws-intro.adoc[]
|
||||
|
||||
== Functional Bean Definitions
|
||||
|
||||
Your functions will start much quicker if you can use functional bean definitions instead of `@Bean`. To do this make your main class
|
||||
an `ApplicationContextInitalizer<GenericApplicationContext>` and use the `registerBean()` methods in `GenericApplicationContext` to
|
||||
an `ApplicationContextInitializer<GenericApplicationContext>` and use the `registerBean()` methods in `GenericApplicationContext` to
|
||||
create all the beans you need. You function need sto be registered as a bean of type `FunctionRegistration` so that the input and
|
||||
output types can be accessed by the framework. There is an example in github (the AWS sample is written in this style). It would
|
||||
look something like this:
|
||||
@@ -40,7 +40,7 @@ public class FuncApplication implements ApplicationContextInitializer<GenericApp
|
||||
}
|
||||
```
|
||||
|
||||
== Platfom Specific Features
|
||||
== Platform Specific Features
|
||||
|
||||
=== HTTP and API Gateway
|
||||
|
||||
@@ -66,4 +66,4 @@ An https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html[AWS Lambda
|
||||
spring.cloud.function.web.export.enabled=true
|
||||
```
|
||||
|
||||
Set the handler name in AWS to the name of your function. Then provide a `bootstrap` script in the root of your zip/jar that runs the Spring Boot application. The functional bean definition style works for custom runtimes too, and is faster than the `@Bean` style, so the example `FuncApplication` above would work. A custom runtime can start up much quicker even than a functional bean implementation of a Java lambda - it depends mostly on the number of classes you need to load at runtime. Spring doesn't do very much here, so you can reduce the cold start time by only using primitive types in your function, for instance, and not doing any work in custom `@PostConstruct` initializers.
|
||||
Set the handler name in AWS to the name of your function. Then provide a `bootstrap` script in the root of your zip/jar that runs the Spring Boot application. The functional bean definition style works for custom runtimes too, and is faster than the `@Bean` style, so the example `FuncApplication` above would work. A custom runtime can start up much quicker even than a functional bean implementation of a Java lambda - it depends mostly on the number of classes you need to load at runtime. Spring doesn't do very much here, so you can reduce the cold start time by only using primitive types in your function, for instance, and not doing any work in custom `@PostConstruct` initializers.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
This project provides an adapter layer for a Spring Cloud Function application onto Azure.
|
||||
You can write an app with a single `@Bean` of type `Function` and it will be deployable in Azure if you get the JAR file laid out right.
|
||||
|
||||
include::adapters/azure-intro.adoc[]
|
||||
include::azure-intro.adoc[]
|
||||
|
||||
== Sample Function
|
||||
|
||||
|
||||
@@ -6,4 +6,4 @@
|
||||
|
||||
The https://azure.microsoft.com[Azure] adapter bootstraps a Spring Cloud Function context and channels function calls from the Azure framework into the user functions, using Spring Boot configuration where necessary. Azure Functions has quite a unique, but invasive programming model, involving annotations in user code that are specific to the platform. The easiest way to use it with Spring Cloud is to extend a base class and write a method in it with the `@FunctionName` annotation which delegates to a base class method.
|
||||
|
||||
include::adapters/azure-intro.adoc[]
|
||||
include::azure-intro.adoc[]
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
== Quick Start
|
||||
|
||||
include::adapters/openwhisk-quick-start.adoc[]
|
||||
include::openwhisk-quick-start.adoc[]
|
||||
|
||||
== Examples
|
||||
|
||||
@@ -10,4 +10,4 @@ The following examples are built based on the details and explanations above, on
|
||||
|
||||
* https://github.com/redhat-developer-demos/ow-scf-greeter[Spring Cloud Function Application Example]. This example shows how to use Spring Cloud Functions with a complete Spring Boot Application that has functions defined by extending `java.util.function.Function` interfaces.
|
||||
|
||||
The base docker images used for above examples is available https://github.com/redhat-developer-demos/openwhisk-scf-docker[here].
|
||||
The base docker images used for above examples is available https://github.com/redhat-developer-demos/openwhisk-scf-docker[here].
|
||||
|
||||
@@ -7,4 +7,4 @@
|
||||
The https://openwhisk.apache.org/[OpenWhisk] adapter is in the form of an executable jar that can be used in a a docker image to be deployed to Openwhisk. The platform works in request-response mode, listening on port 8080 on a specific endpoint, so the adapter is a simple Spring MVC application.
|
||||
|
||||
== Quick Start
|
||||
include::adapters/openwhisk-quick-start.adoc[]
|
||||
include::openwhisk-quick-start.adoc[]
|
||||
|
||||
Reference in New Issue
Block a user