Spring Boot 2: StageName should be stripped from the path by default

Offen
  • Stimmt etwas nicht?
#401 7 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
45/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Veraltet
Tech-Stack
aws, java, spring-boot
Bereich
api, backend, cloud

Rechercherichtung

Beginne mit dem LambdaHandler und seiner SpringBootProxyHandlerBuilder-Konfiguration und vergleiche dann den im Issue gezeigten SAM HttpApi StageName und Proxy-Pfad mit dem von Spring Boot empfangenen Request-Pfad. Prüfe, wie handler.stripBasePath verwendet wird, und mache den Stage-Namen standardmäßig unnötig; die Aufgabe ist erledigt, wenn Anfragen wie /dev/api/v1/some/resource ohne einen 404 als /api/v1/some/resource geroutet werden.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Serverless Java Container version: 1.5.2

Implementations: Spring Boot 2

Framework version: spring-boot-starter-parent 2.3.8.RELEASE

Frontend service: AWS::Serverless::HttpApi (API Gateway HTTP)

Deployment method: SAM CLI

Scenario

Configure a simple HTTP API proxy to Lambda using Spring Boot 2, and be able to route requests that ignore the stage-name.

Expected behavior

Stage name (which is part of the path by default) is stripped before spring routes/maps to a controller.

Actual behavior

Getting 404's b/c spring is mapping <stage>/<path> vs <path>; requires my code to be 'stage-name aware'.

Steps to reproduce

event-source in sam template for AWS::Serverless::Function

      Events:
        BaseAdmin:
          Type: HttpApi
          Properties:
            ApiId: !Ref Api
            Method: any
            Path: /{proxy+}
            PayloadFormatVersion: "1.0"
            RouteSettings:
              ThrottlingBurstLimit: 100
              ThrottlingRateLimit: 100
            TimeoutInMillis: 29000

api def in sam template:

  Api:
    Type: AWS::Serverless::HttpApi
    Properties:
      FailOnWarnings: true
      StageName: dev

lambda handler

public class LambdaHandler implements RequestStreamHandler {
    private static final SpringBootLambdaContainerHandler<AwsProxyRequest, AwsProxyResponse> HANDLER;

    static {
        Application.envSetup();
        try {
            HANDLER = new SpringBootProxyHandlerBuilder<AwsProxyRequest>().defaultProxy()
                                                                          .asyncInit()
                                                                          .springBootApplication(Application.class)
                                                                          .buildAndInitialize();
        } catch (ContainerInitializationException e) {
            e.printStackTrace();
            throw new RuntimeException(e);
        }
        // Want to not need the line below uncommented to work!
        // HANDLER.stripBasePath(System.getenv("STRIP_BASE_PATH"));
    }

    @Override
    public void handleRequest(InputStream inputStream, OutputStream outputStream, Context context) throws IOException {
        HANDLER.proxyStream(inputStream, outputStream, context);
    }
}

Full log output

Paste the full log output from the Lambda function's CloudWatch logs
dev is the stage name; the mapping is for /api/v1

DEBUG DispatcherServlet - GET "/dev/api/v1/some/resource", parameters={}
DEBUG DispatcherServlet - Exiting from "ERROR" dispatch, status 404

This isn't the worst thing ever...but it's definitely counter-intuitive to me. Would also appreciate any feedback on my solution; I did try some of the config options mentioned on the wiki page, but none of them seemed to do the trick until i found handler.stripBasePath. If there is a way to do this w/o passing in the StageName, that'd be better. Having it work by default would obviously be best.

Vorherrschende Sprache
Java
Sterne
1.6k
Forks
575
Ø Merge
1 T. 15 Std.
Gemergte PRs (30 T.)
12

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus aws/serverless-java-container

Alle Issues in aws/serverless-java-container

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.