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

Aberta
  • Algo errado?
#401 7 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
45/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Estagnada
Stack de tecnologia
aws, java, spring-boot
Domínio
api, backend, cloud

Direção de pesquisa

Comece com o LambdaHandler e sua configuração SpringBootProxyHandlerBuilder e, em seguida, compare o SAM HttpApi StageName e o caminho do proxy mostrados na issue com o caminho da requisição recebido pelo Spring Boot. Verifique como handler.stripBasePath é usado e torne o nome do stage desnecessário por padrão; considera-se concluído quando requisições como /dev/api/v1/some/resource forem roteadas como /api/v1/some/resource sem um 404.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Java
Estrelas
1.6k
Forks
575
Merge médio
1d 15h
PRs com merge (30d)
12

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de aws/serverless-java-container

Todas as issues de aws/serverless-java-container

Issues semelhantes

Mais issues de Java

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.