I'm currently working on a Quarkus based API that is due to be hosted on an API gateway that requires our application to be running with a base-path and I found out that by setting quarkus.resteasy.path in application.properties I can run the application with a base-path and it is being added to the specification automatically.
I am generating an OpenAPI 3 specification by using org.eclipse.microprofile.openapi.annotations. My problem is that in the specification this base-path is added to every single operation. I am instead trying to only apply the base-path within the servers declaration basically like the equivalent of what basePath used to be in OpenAPI 2.0.
Current outcome:
servers:
- url: https://dev.example.com
description: Development
- url: https://example.com
description: Production
security:
- jwt: []
paths:
/api/capacity/availability:
get:
...
/api/capacity/consume:
post:
...
Desired outcome:
servers:
- url: https://dev.example.com/api
description: Development
- url: https://example.com/api
description: Production
security:
- jwt: []
paths:
/capacity/availability:
get:
...
/capacity/consume:
post:
...
Any help would be appreciated.
You can also use config to set the servers: quarkus.smallrye-openapi.servers
See https://quarkus.io/guides/openapi-swaggerui#quarkus-smallrye-openapi_quarkus.smallrye-openapi.servers
Related
I am just started with Kong API with One API
I am able to run kong api locally using its official docker image available.
And on other side I am having another Spring-Boot microservice locally running inside same Docker engine.
Problem : What configuration needs in kong api yaml file so that I can connect to my spring-boot microservice ?
My kong -api yaml file
services:
- name: control-service-integration
url: http://localhost:8080/
plugins:
- name: oneapi
config:
edgemicro_proxy: edgemicro_demo_v0
add_application_id_header: true
authentication:
apikey:
header_name: "x-api-key"
upstream_auth:
basic_auth:
username: username
password: password
routes:
- name: control-service-route
request_buffering: false
response_buffering: false
paths:
- /edgemicro-demo-v0
From kon-one api service i am getting always 502 Bad Gateway error.
Let me know if anything information required.
I found the solution for this
in above YAML
services:
- name: control-service-integration
url: http://localhost:8080/
add this value in-front of url section http://host.docker.internal:8080/ after doing lot of trials and errors finally now I am able to connect my app which is running on host.
I'm running a spring cloud gateway instance that relies on spring cloud configuration server. My application starts up with the given following configuration.
cloud:
gateway:
routes:
- id: route-foo
uri: lb://foo
predicates:
- Path=/api/foo/**
filters:
- name: RewritePath
args:
regexp: "/api/foo/(?<remaining>.*)"
replacement: "/${remaining}"
Say I make a modification to my configuration and add an additional route below
- id: route-bar
uri: lb://bar
predicates:
- Path=/api/bar/**
filters:
- name: RewritePath
args:
regexp: "/api/bar/(?<remaining>.*)"
replacement: "/${remaining}"
Executing a POST to http://localhost:8080/actuator/refresh returns the following error.
500 Server Error for HTTP POST "/actuator/refresh" (Encoded)
java.lang.IllegalArgumentException: Could not resolve placeholder 'remaining' in value "/${remaining}"
at org.springframework.util.PropertyPlaceholderHelper.parseStringValue(PropertyPlaceholderHelper.java:178)
It appears that spring is trying to parse my RewritePath replacement and substitute it with environment variables. What are my options?
You're running into spring trying to replace variables in your configuration.
There are two solutions
Escape the replacement syntax (Preferred)
change replacement: "/${remaining}"
to replacement: "/$\\{remaining}"
The RewriteGatewayFilterFactory does a replace on the configuration before running the filter.
Enable ignoreUnresolvableNestedPlaceholders
#Bean
#Primary
public StandardReactiveWebEnvironment standardReactiveWebEnvironmentCustomizer(StandardReactiveWebEnvironment environment) {
environment.setIgnoreUnresolvableNestedPlaceholders(true);
return environment;
}
This will leave all unresolvable placeholders alone in your configuration and not fail during the refresh. I would recommend against this approach as it may end up delaying some issues into runtime if you're relying on a field to be populated correctly.
Theoretically you should be able to accomplish this same functionality with the PropertySourcesPlaceholderConfigurer, I had a hard time getting that to cooperate.
I’m trying to migrate JHipster from using Zuul to Spring Cloud Gateway. JHipster uses Eureka to look up routes and I believe I’ve configured Spring Cloud Gateway correctly to look up routes and propagate the access token to them. Here’s my config:
spring:
cloud:
gateway:
default-filters:
- TokenRelay
discovery:
locator:
enabled: true
lower-case-service-id: true
route-id-prefix: /services/
httpclient:
pool:
max-connections: 1000
The problem I’m experiencing is the access token is not sending an Authorization header to the downstream services.
Here's how things were configured with Zuul in my application.yml:
zuul: # those values must be configured depending on the application specific needs
sensitive-headers: Cookie,Set-Cookie #see https://github.com/spring-cloud/spring-cloud-netflix/issues/3126
host:
max-total-connections: 1000
max-per-route-connections: 100
prefix: /services
semaphore:
max-semaphores: 500
I created a pull request to show what's changed after integrating Spring Cloud Gateway.
https://github.com/mraible/jhipster-reactive-microservices-oauth2/pull/4
Steps to reproduce the issue:
git clone -b reactive git#github.com:mraible/jhipster-reactive-microservices-oauth2.git
Start JHipster Registry, Keycloak, and the gateway app:
cd jhipster-reactive-microservices-oauth2/gateway
docker-compose -f src/main/docker/jhipster-registry.yml up -d
docker-compose -f src/main/docker/keycloak.yml up -d
./mvnw
Start MongoDB and the blog app:
cd ../blog
docker-compose -f src/main/docker/mongodb.yml up -d
./mvnw
Navigate to http://localhost:8080 in your browser, log in with admin/admin, and try to go to Entities > Blog. You will get a 403 access denied error. If you look in Chrome Developer Tools at the network traffic, you'll see the access token isn't included in any headers.
I was able to solve this using this answer.
spring:
cloud:
gateway:
discovery:
locator:
enabled: true
predicates:
- name: Path
args:
pattern: "'/services/'+serviceId.toLowerCase()+'/**'"
filters:
- name: RewritePath
args:
regexp: "'/services/' + serviceId.toLowerCase() + '/(?<remaining>.*)'"
replacement: "'/${remaining}'"
I also had to add .pathMatchers("/services/**").authenticated() to my security config, which wasn't needed for Zuul. You can see my commit here.
As the title suggests, I'm trying to configure a deployment in GCP. At the moment, all the deployment consists of is a single Compute instance, although I am having trouble trying to add the http-server and https-server tags into the config file. The instance is created fine without trying to add the tags. Here is the top of my yaml file:
resources:
- type: compute.v1.instance
name: [redacted]
properties:
zone: europe-west1-b
# Allow http and https traffic
tags:
- http-server
- https-server
machineType: https://www.googleapis.com/compute/v1/projects/[redacted]/zones/europe-west1-b/machineTypes/f1-micro
.......etc
The error I get is:
ERROR: (gcloud.deployment-manager.deployments.create) Error in Operation [operation-1548860751491-580ae3ee63331-467fd040-1f00fce0]: errors:
- code: CONDITION_NOT_MET
location: /deployments/[redacted]/resources/[redacted]>$.properties
message: '"/tags": domain: validation; keyword: type; message: instance does not
match any allowed primitive type; allowed: ["object"]; found: "array"'
This is my first attempt at writing a yaml config file so there could be some simple context issues.
I managed to fix it myself:
tags:
items:
- http-server
- https-server
Add tag to compute instance properties:
tags:
items: ["http-server"]
Add new resource (below the compute instance network interface):
- type: compute.v1.firewall
name: default-allow-http
properties:
targetTags: ["http-server"]
sourceRanges: ["0.0.0.0/0"]
allowed:
- IPProtocol: TCP
ports: ["80"]
I have the following URIs I want to support:
/api/ice-cream-service/sizes
/api/ice-cream-service/flavors
I do not want:
#Path("/api/ice-cream-service/sizes")
#Path("/api/ice-cream-service/flavors")
I do want:
#Path("/sizes")
#Path("/flavors")
How can I define an application level, default base URL for my Dropwizard App?
Dropwizard currently supports an appRoot configuration point that can be defined in the application YAML.
Docs at the time of this post: 1.3.0 Configuration Reference
And example application configuration could look like:
server:
applicationConnectors:
- type: http
port: 8080
adminConnectors:
- type: http
port: 8081
rootPath: /api/ice-cream-service