... | ... | @@ -13,7 +13,7 @@ You have some possibilities to control server creation with Sparkling: |
|
|
* Add __several handler objects__ to the server with `Sparkling.addHandler2Server(..)`. You can specify a subpath for each handler object. The only difference to `Sparkling.startServer(..)` it that `Sparkling.startServer(..)` specifies the port of the server also.
|
|
|
* Make cleanups at __server shutdown__, when you e.g. have to close some database connections, with `Sparkling.addShutdownRoutine(Runnable runnable)`.
|
|
|
* __Suppress documentation__ creation with `createDocumentation=false` as parameter of `Sparkling.addHandler2Server(..)` and `Sparkling.startServer(..)`.
|
|
|
* Log __invocation statistics__ with `logInvocationStatsEveryNCalls=N`. The server will log every `N` method invocation the counts which method was called how often since the last server (re)start.
|
|
|
* Log __invocation statistics__ with `logInvocationStatsEveryNCalls=N`. The server will log every `N` method invocations the counts which method was called how often since the last server (re)start.
|
|
|
* You can __suppress__ that values of specified __parameters will be logged__ by Sparkling. Sometimes, in the case of an error, Sparkling will log parameter values for debugging reasons. If you e.g. for some reason have a password parameter, you don't want the passwords to appear in the logs. Suppress the logging by annotating the parameter with `@HideValueLogs` inside the handler method code.
|
|
|
|
|
|
### Spark as underlying micro framework
|
... | ... | @@ -50,7 +50,7 @@ The following capabilities exist: |
|
|
* __Big data transfers__ (e.g. file uploads and downloads) are supported by InputStream parameters and return types.
|
|
|
* The HTTP return values are of type `application/octet-stream`
|
|
|
* The parameters must be specified as multipart message parts: `Content-Type: multipart/form-data; boundary=...`
|
|
|
* Each parameter values is sent in a separate part: `Content-Disposition: form-data; name="...PARAMETER_NAME..." `
|
|
|
* Each parameter value is sent in a separate part: `Content-Disposition: form-data; name="...PARAMETER_NAME..." `
|
|
|
* InputStream parameters must use mime-type `application/octet-stream`
|
|
|
* All other parameters go as `application/x-www-form-urlencoded; charset=UTF-8`
|
|
|
|
... | ... | @@ -91,7 +91,7 @@ __Maven:__ |
|
|
</build>
|
|
|
```
|
|
|
|
|
|
In the case you have to work with Java <8 or you don't want or can set the `-parameters` flag for some reason, we offer an annotation `@Named` as alternative. Using this, the parameter name will specified as parameter annotation instead of bytecode metadata. The pro is that you are independent from the compiler flag. The con is that you have to provide the parameter name for each parameter on your own. Use it as follows:
|
|
|
In the case you have to work with Java <8 or you don't want or can set the `-parameters` flag for some reason, we offer an annotation `@Named` as alternative. Using this, the parameter name is specified as parameter annotation instead of bytecode metadata. The pro is that you are independent from the compiler flag. The con is that you have to provide the parameter name for each parameter on your own. Use it as follows:
|
|
|
|
|
|
```java
|
|
|
// gives the first parameter the name 'ping'
|
... | ... | |