.getResult() .getOutput() .getText(); } .getoutput 다음 getContent가 있어야 하는데 gettext만 있습니다. getContent는 생성이 되지 않습니다. 똑같이 수업보면서 했는데 왜그런지 모르겠습니다. 물론 결과값은 설명하신 대로 똑같이 나오는기는 하는데 차이가 없나요?
자바와 스프링 부트로 생애 최초 서버 만들기, 누구나 쉽게 개발부터 배포까지! [서버 개발 올인원 패키지]
안녕하세요 과제를 하나씩 만들고있는데 4일차 과제인 api만들기를 하려고합니다! 그전까지는 위처럼 기존 강의 초기세팅 된곳에 hw폴더를 만들어서 하고있는데 이렇게 말고 강의초반에 배운대로 spring.io에서 초기세팅을 새로해서 과제를 위한 스프링부트 프로젝트를 새로 만들고싶은데요..! 혹시 현재 강의 초기세팅과 같이 하려면 어떻게해야될지 알려주실 수 있으신가요? 1~2강 초기세팅 강의에서 spring.io로 처음부터 만드는걸 배울때 자바나 스프링부트 버전설정이런건 설명이 있었는데 그다음 의존성 이런건 나중에 설명이 나온다했던거같아서 정확히 모르겠습니다. 강의에 혹시 있다면 어디를 참고하면 될지만이라도 알려주시면 감사드리겠습니다!!
안녕하세요, 토비님. 강의를 들으며 많은 인사이트를 얻고 있습니다. 강의를 완강한 후에도 내면적으로 정리되지 않은 부분이 있어 조심스럽게 질문을 드리게 되었습니다. 생성과 관련된 설계는 강의에서 잘 이해가 되었지만, 업데이트(update) 와 관련된 내용은 직접적으로 다뤄지지 않아 고민이 생겼습니다. 특히, 제 고민은 다음과 같습니다. "도메인의 비즈니스 규칙이 Web API 설계에 어느 정도까지 직접적으로 드러나야 하는가?" 현재 도메인 로직에서는 사용자의 여러 정보를 변경할 수 있는 비즈니스 규칙이 존재합니다. 예를 들어: 비밀번호 변경 기타 세부정보 변경 비즈니스적으로는 각각의 규칙이 잘 정의되어 있고, 각각의 변경 로직도 Member 객체 내에 명확히 메서드로 존재합니다. 여기서, 이러한 비즈니스에 대해서 API에 어떻게 노출시켜야 하는가에 대해서 두 가지 선택지가 고려됩니다. 1. 비즈니스 정의를 역할 별로 구성한다. POST /api/v1/members/{id}/change-password POST /api/v1/members/{id}/change-nickname 생각이 나는 장단점은 다음과 같습니다. 장점 : 비즈니스에 따라 API를 관리하여 클라이언트가 이해하기 용이합니다. 단점 : 수정 가능한 필드가 많아질수록 API의 개수가 증가하며, 유지보수가 어려워질 수 있고, Restful 규칙에 위배됩니다. 2. 하나의 update API로 통합한다. PATCH /api/v1/members/{id} { "password": "originalPassword123!", // nullable "detailRequest": { // nullable "email": "user@example.com", "nickname": "nickname123", "password": "newPassword456!" } } 장점 : API가 간결하여 확장이 용이하며, 클라이언트는 필요한 값만 상황에 따라 요청하면 됩니다. 단점 : API가 비즈니스 책임에 명확하지 않을 수 있습니다. 결론적인 질문은 다음과 같이 정리 할 수 있을 것 같습니다. 비즈니스 로직이 도메인 레이어에 잘 분리되어 있는 경우, API 계층에서도 분리하여 표현하는 것이 좋은가요? 도메인의 역할만 명확하다면 API는 통합해서 update 형식으로 만들어도 괜찮은가요? 만약, 후자로 처리를 한다면 어디서 처리를 하는게 좋아보이시나요? 서비스 계층 도메인 계층 // MemberModifyService public void update(Long memberId, MemberUpdateRequest request) { Member member = memberFinder.find(memberId); if (request.password() != null) { member.changePassword(request.password()); } if (request.detailRequest() != null) { member.updateInfo(); } } -------- // MemberModifyService public void update(Long memberId, MemberUpdateRequest request) { Member member = memberFinder.find(memberId); member.update(request); } // Member public void update(MemberUpdateRequest request) { if (request.password() != null) { changePassword(request.password()); } if (request.detailRequest() != null) { updateInfo(); } } 뭔가, 이런 고민이 계속 드는 이유가 외부 계층에 종속적이지 않고 도메인에 의존하여 개발을 하더라도 실제로 저희가 처한 상황은 대부분 WebAPI 계층에서의 요청이 많다보니 외부의 행위 또한 도메인에 종속 되어야 하는가 하는 고민이 생긴 것 같습니다. 양질의 강의 제공해주셔서 감사드립니다!
========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 안녕하세요. 궁금증이 생겨서 질문을 드립니다. requset scope가 웹 스코프 에서 중요한 역할을 한다는것을 어느 정도 인지가 되는 상황이지만, 여러 번을 들어도 "모르겠다"라는 는 말이 저절로 나옵니다... 그래서 일단은 그냥 넘어 갈려고 합니다. 여기서 질문입니다. requset Scope를 더욱더 활용하거나 공부하는 강의가, 다음 강의 및 다른 강의에서 있나요? 추가1 만약에 없다면 어떤 것을 들어야(해야지) 이해 할수 있을까요? 답변 부탁드립니다.
'25. 엔티티의 자연키 지정' 영상의 후반부에 적용한 @NaturalIdCache 에 대해 추가로 학습한 내용이, 저처럼 해당 애노테이션을 처음 접한 분들에게 도움이 될 것 같아서 글을 작성합니다. 강의에서 오해가 있을 수 있는 부분, 그리고 자연키에 캐시를 적용하는 방법을 정리해 보았습니다. 강의 내용과 실제 동작의 차이점 강의에서는 “같은 트랜잭션 안에서 같은 아이디 값을 가지고 여러 번 조회 시 Persistence Context 에 캐시된 값을 꺼내오는 것 처럼. @NaturalIdCache 를 적용하면 이것도 영속 컨텍스트에 캐싱이 된다.”고 말씀하셨습니다. 해당 내용에 대한 이해를 돕기 위해 Hibernate의 두 가지 캐시에 대해 간단히 짚고 넘어가겠습니다. 1차 캐시 (First-Level Cache): 세션(영속성 컨텍스트) 범위의 캐시입니다. 같은 트랜잭션 안에서만 유효하며, 트랜잭션이 끝나면 사라집니다. Spring Data JPA에서는 기본적으로 @Id 에 대한 조회를 1차 캐시합니다. 2차 캐시 (Second-Level Cache): 세션 팩토리 범위의 캐시로, 여러 세션에서 데이터를 공유할 수 있습니다. 적용하려면 별도의 의존성 추가 및 캐시 관련 설정( @Cache 등)이 필요합니다. 따라서, "같은 트랜잭션 안에서 캐시된 값을 꺼내온다."는 말은 세션 범위의 1차 캐시로 해석됩니다. 하지만 제가 직접 테스트해 본 결과, @NaturalIdCache 는 1차 캐시 가 아닌 2차 캐시 와 관련이 있었으며, 1차 캐시를 적용하기 위해서는 다른 방법이 필요했습니다. 테스트를 통한 확인 자연키에 대한 1차 캐시 동작을 확인하기 위해, 강의에서 적용한 Member 엔티티의 @NaturalIdCache 를 제거 하고, 자연키(Email)에 @NaturalId 만 적용 한 상황에서 두 가지 방식으로 테스트를 진행했습니다. 테스트1: findByEmail 메서드를 사용한 조회 @Test void NaturalIdFirstLevelCache() { Member member = Member.register(createMemberRegisterRequest(), createPasswordEncoder()); memberRepository.save(member); entityManager.flush(); entityManager.clear(); System.out.println("회원 저장 및 persistence context 초기화 완료"); // 같은 email(Natural ID)로 두 번 조회 Member findMember1 = memberRepository.findByEmail(member.getEmail()).get(); Member findMember2 = memberRepository.findByEmail(member.getEmail()).get(); assertThat(findMember1).isSameAs(findMember2); } Spring Data의 쿼리 메서드를 사용하여 이메일로 조회하는 findByEmail 메서드를 만들고, 한 트랜잭션에서 같은 회원을 두 번 조회했습니다. 자연키에 대한 1차 캐시가 동작한다면, SELECT 쿼리는 한 번만 실행되어야 합니다. 결과는 SELECT 쿼리가 두 번 실행 되었습니다. 즉, 자연키에 대한 1차 캐시가 동작하지 않았습니다. 테스트2: Hibernate의 자연키 관련 API를 사용한 조회 @NaturalId 를 다루는 글들을 찾아본 결과 Hibernate가 제공하는 자연키 관련 API가 있다는 것을 확인했고, 이를 적용하기 위해 커스텀 리포지토리를 구현했습니다. @Repository @RequiredArgsConstructor public class CustomizedMemberRepositoryImpl implements CustomizedMemberRepository { private final EntityManager entityManager; @Override public Optional<Member> findByNaturalId(Email naturalId) { return entityManager.unwrap(Session.class) .bySimpleNaturalId(Member.class) .loadOptional(naturalId); } } 그리고, 테스트 1과 같은 방식으로 테스트를 진행하였습니다. @Test void NaturalIdApi() { Member member = Member.register(createMemberRegisterRequest(), createPasswordEncoder()); memberRepository.save(member); entityManager.flush(); entityManager.clear(); System.out.println("회원 저장 및 persistence context 초기화 완료"); Member findMember1 = memberRepository.findByNaturalId(member.getEmail()).get(); Member findMember2 = memberRepository.findByNaturalId(member.getEmail()).get(); assertThat(findMember1).isSameAs(findMember2); } 결과는 SELECT 쿼리가 한 번만 실행 되었습니다. 이를 통해 자연키에 대한 1차 캐시는 @NaturalIdCache 애노테이션과 무관하게, 전용 API를 사용해야만 동작 하는 것을 확인했습니다. @NaturalIdCache의 용도 @NaturalIdCache Javadoc에는 다음과 같은 설명이 있습니다. Specifies that mappings from the natural id values of the annotated entity to the corresponding entity id values should be cached in the shared second-level cache. …중략 This annotation is usually used in combination with Cache , since a round trip may only be avoided if the entity itself is also available in the cache. 대략 “natural id와 상응하는 id에 대한 매핑을 2차 캐시에 저장 하는 애노테이션이고, 엔티티가 캐시되어있어야 하기 때문에 일반적으로 Cache 와 함께 사용 된다.”라고 해석됩니다. 즉, 1차 캐시가 아닌 2차 캐시를 위한 애노테이션입니다. 정리 2차 캐시 관련 설정 및 테스트를 마저 진행한 후 최종 정리한 내용은 다음과 같습니다. 자연키의 1차 캐시 @NaturalIdCache 애노테이션과 관련 없습니다. 자연키에 @NaturalId 만 붙이면 됩니다. 반드시 Hibernate Session의 bySimpleNaturalId() 같은 전용 API를 사용해야 적용 됩니다. 자연키의 2차 캐시 @Cache 와 @NaturalIdCache 를 함께 사용해야 동작합니다. @Cache 만 사용 시 @Id 로 조회할 때만 2차 캐시가 동작합니다. @NaturalIdCache 만 사용 시 자연키와 ID에 대한 매핑 정보는 캐시 히트 되는 걸 확인했지만, ID와 엔티티에 대한 캐시가 없어서 캐시가 적용되지 않았습니다. @Cache 와 @NaturalIdCache 모두 사용 시 ID를 통한 조회와 자연키를 통한 조회 모두 2차 캐시가 적용됩니다. 참고 자료 Hibernate6.6 공식 문서 NaturalCache javadocs baeldung: Hibernate Natural IDs in Spring Boot Spring Custom Repository 글의 오류나 부족한 내용을 알고 계신 분은 코멘트를 달아주시면 감사하겠습니다.
2025년 7월 5일 기준으로 학습 레포에서 가져온 main.tf를 기반으로 apply 명령을 실행하면 아래와 같은 에러가 발생합니다. terraform apply ╷ │ Error: Unsupported argument │ │ on main.tf line 279, in resource "aws_eip" "app": │ 279: vpc = true │ │ An argument named "vpc" is not expected here. 에러 발생 이유는 aws_eip 리소스 블록에서 vpc = true 옵션을 더이상 지원하지 않기 때문에 발생한다고 합니다. 따라서 280라인에 vpc = true 를 제거하면 해결됩니다. https://registry.terraform.io/providers/hashicorp/aws/latest/docs/guides/version-5-upgrade?utm_source=chatgpt.com#resourceaws_eip_association
이번 강의 코드에서 서비스 계층 코드인 MemberServiceV3_1 에서 PlatformTransactionManager 같은 스프링 프레임 워크를 사용하고 있는데요, 이전 강의에서 프레젠테이션 계층, 서비스 계층, 데이터 접근 계층에 대해 설명하실 때 서비스 계층에서는 순수 자바 코드로 작성해야한다고 하셨는데요. MemberServiceV3_1 에서 몇몇 코드가 스프링 프레임워크인데 이런 것은 정말 필요에 의해서 사용하는 것이므로 어쩔 수 없는 부분인가요?
안녕하세요, 프로그래밍 좀비님! 팀으로 앱 개발을 하려고 합니다. 플러터로 iOS/안드로이드 앱을 개발하고, 제가 백엔드를 맡게 되었는데 백엔드는 Java, SpringBoot로 구축할 예정이에요.. 앱 해킹 등 보안에 대해 기획자분이 강조하셔서, 아래와 같이 보안 대책을 고민하고 있습니다. 현재 적용 예정인 보안 대책 • JWT 토큰을 이용한 인증/인가 • HTTPS로 통신 암호화 • JPA 사용(PreparedStatement 기반이라 SQL 인젝션 방어) • API Rate Limiting 도입 예정 질문 드리고 싶은 내용 1. 위와 같이 보안 대책을 준비하면, 실제 서비스 운영 시 모바일 앱 백엔드에서 추가로 꼭 신경 써야 할 부분이 있을까요? 2. 강사님께서 실제로 350개 이상의 앱을 개발/배포하시면서 겪으신 보안 관련 실무 경험이나, 꼭 강조하고 싶은 보안 포인트가 있다면 조언 부탁드립니다. 3. 혹시 실무에서 자주 간과되지만, 반드시 챙겨야 하는 보안 체크리스트가 있다면 알려주시면 감사하겠습니다. 실제 현업, 350개 배포 경험을 바탕으로, 실질적으로 도움이 될 만한 조언을 듣고 싶습니다. 감사합니다!
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 안녕하세요 강의를 듣고 프로젝트 진행 도중 궁금한게 생겨 질문드립니다! 현재 강사님이 알려주신대로 유저가 로그인에 성공하면 user 세션을 만들고 세션 아이디를 쿠키로 전달 하고 있습니다. 이후 요청이 올때마다 인터셉터에서 세션이 있는지 user라는 세션이 있는지 확인 후 컨트롤러에 접근하도록 구현했습니다. 여기서 궁금한 점이 만약 유저A가 로그인에 성공한 후에 수정이나 생성 또는 그 외의 과정을 유저B의 아이디로 url 또는 요청 body에 담아 요청을 보내도 인터셉터에선 인증된 것으로 간주 되어 유저A가 유저B를 탈퇴시키는 등의 과정도 가능할거라는 생각이 들었습니다. 이에 대한 해결 방안으로 user 세션의 아이디 값과 요청으로 들어온 아이디 값이 일치하는지 확인하는 로직을 필요한 모든 컨트롤러에 추가하는 것이 일반적일까요? 아니라면 실무에서는 주로 어떻게 처리하는지 궁금합니다.
팬텀리드 갱신모순도 무상태 안지켜서 그런건가요? 이것과 관련하여 트렌젝션 관련된 강의도 듣고 싶습니다. 어디서 들을 수 있는지 알고 싶습니다. 웹 환경에서 메모리 리파지토리 말고 디비 연결해서 개발하면 VO-> db조회 -> entity 인스턴스화 해서 저장/조회 하여야 하나요? - 요지는 간단한 것도 DB조회가 반드시 필요한지 알고 싶어서 질문 드립니다.
안녕하십니까 선생님, 양질의 강의 항상 감사드립니다. AuthenticationManager와 AuthenticationProvider의 구성에 대해서 개념적으로 확인하고 싶은 것이 있어 질문 드립니다. AuthenticationProvider를 직접 구성하여 등록하지 않으면 기본적으로 DaoAuthenticationProvider, BasicAuthenticationProvider, RememberMeAuthenticationProvider 가 등록이 되는데, 직접 커스텀한 Provider를 등록 시 이 3개의 기본 Provider들은 자동 구성에서 제외 되는 것 인가요? 만약 AuthenticationManger를 builder 혹은 직접생성(new)을 통해 생성한다면 기본 제공 되는 Provider들은 자동 구성에서 제외되는 것 인가요? 만약 그렇다면 AuthenticationManager는 직접 등록하고 싶은 Provider가 있을 때에만 생성하는 것 인가요?
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 여기에 질문 내용을 남겨주세요. JPA와 DB 설정, 동작확인 과정에서 3version으로 pdf 파일보고 설정했는데 test 결과가 실패합니다... 원인을 모르겠습니다
안녕하세요 토비님 강의 듣고나서 제 나름대로 API 서버 제작 연습을 좀 해보도가 JPA 및 도메인 상태 변경에 관련해서 질문 드리고 조언을 얻고자 문의 드립니다. 상황은 아래와 같습니다. DDD에 입각하여 Aggregator 가 하위 Entity Life Cycle 담당 Entity 식별자 타입 경우 Long Client 에서 변경 API 요청 시 Aggregator 의 식별자는 존재하지만, 하위 Entity 에 대한 id 는 포함하지않은채 요청 { id: AggregatorId name: AggregatorName list: [ { name: 'modified name1', type: 'type1', status: 'active' }, { name: 'modified name2', type: 'type2', status: 'inactive' }, { name: 'new name3', type: 'type3', status: 'active' } ] } id 가 없이 JPA 변경 요청 시 delete-insert 가 진행 될것 같아 자체적으로 key based diff 라는 함수를 제작하여 변경점과 신규 데이터에 대해서 병합 후 save() 를 호출 할 것같은데 이럴 경우 insert, update 문의 별도로 나가지 않을까 생각이 듭니다. 이런 경우 DB 입장에서 하나의 트랜잭션에서 수행하더라도 부하나 성능에 악영향을 미칠 것 같은데 이럴 경우 어떤식으로 애플리케이션 로직을 세우고 JPA 를 어떻게 활용해야되는지 조언 부탁드려도될까요? 참고로 저는 하위 Entity 변경 시 batchUpsert 를 고려하고 있습니다.
질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 안녕하세요. 궁금증이 생겨서 질문을 드립니다. 제목 그대로 이렇게 해도 되는지 알고 싶어서 질문을 드립니다. 일단 이렇게 한 이유는 "생성 및 끝날 때 만 쓰는 코드 이니까 private로 막는게 좋지 않을까 라는" 생각을 복습하면서 하게 되었습니다. 그래서 이것 저것 실험하다가 밑에 사진의 코드 처럼 나오게 되었습니다. (빈 으로 등록하는것도 private로 바꿀 수 있긴한데 이건 빈 이름을 무조건 넣어야 해서 의미 없네요.) 바꾼 코드들 테스트 결과 사진 처럼 이렇게 잘 실행되는것을 확인할 수 가 있었는데요. 혹 이렇게 바꿔도 되는지 알고 싶습니다. 답변 부탁 드립니다.
토비님 안녕하세요. 강의 너무 즐겁게 잘 수강하고 있는 한 개발자 입니다. 강의 수강 중에 궁금한 점이 생겨서, 토비님의 의견이 궁금해서 한 가지 질문 드리고자 합니다. 33. 엔티티 클래스와 JPA 매핑 정보 분리 강의에서 분리를 xml로 분리해서 매핑 하는 예를 들어주셔서, 이 부분에 대해서 궁금한 점이 있습니다. 개인적으로 xml 매핑작성 생산 비용과 jpa/도메인 엔티티를 분리해서 작성하는 비용이 크게 차이나지 않는것 같단 생각이 들긴합니다. 결국 xml이든, 코드든 분리해서 작성 비용이 필요한 것 같아요. 그렇다면, 여기에서 관리 포인트를 이중(xml,코드)으로 가져가는게 나을지, jpa/도메인 엔티티를 분리해서 코드에서 관리하는게 나을지? 고민이 되는데요. 토비님의 의견은 어떠신지 궁금합니다. ai 자동완성 기능 활용 코드도 마찬가지로, 애노테이션 빼줘, 붙여줘 하면 어느정도 잘 만들어주긴 하더라구요. 이 부분도 어떻게 생각하시는지 궁금합니다. 코파일럿에 xml 매핑정보 만들어줘 하는 내용과, 코드로 애노테이션 붙여줘, 빼줘 해서 복/붙하는 행위 자체가 크게 다르지 않은것 같다는 생각이 들긴해서 이 부분은 어떻게 생각하시는지도 궁금합니다. 유지보수 관점에서 생산비용 보다, 개발 완료 후 유지보수를 하는데 있어서 그래도 xml/코드 두가지 중 1개를 선택해야한다면 어떻게 관리하는것이 나을까요?? 바쁘신 와중에도 질문 확인하고 답변 주시는 점 미리 감사드립니다.
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 5. 회원 관리 예제 - 웹MVC개발을 실습하는 과정에서, 이렇게 홈 화면까지는 뜨는데, 회원 가입을 누르면 에러 페이지가 뜹니다. 구글 드라이브 링크 첨부하겠습니다! https://drive.google.com/file/d/15PPRaCNjmwZQYFxy5s0uY_FST3DapsL4/view?usp=sharing +) 위에가 메인 질문이고 세부사항 질문이 있습니다. 1) Whitelabel 에러 페이지가 뜨는데 인텔리제이 콘솔 창에는 별도의 에러 메시지가 뜨지 않습니다. 이게 콘솔창 최하단인데요. 에러메시지가 안나는게 정상인가요? 2) 위에 사진을 왼쪽에 실행목록을 보면 계속 로드중 표시 두개가 돌아가는데요. 저게 계속 돌아가더라고요. 빌드가 완료되면 초록색이 떠야되는거 아닌가 싶어서 여쭤봅니다. 웹 상에서 localhost:8080 홈페이지에 들어가지긴 합니다.
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (모르겠어요) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예) [질문 내용] 이제 백엔드 개발자로 취업한 새내기 입니다. 제가 학생이 아니라 인텔리제이 유료버전을 사용해서 스프링부트앱을 개발하고자 하는데, 너무 비싸서 회사에서 따로 결제를 해주진 않습니다.. 혹시 그냥 커뮤니티에디션 으로 restapi 구현하는 방식으로 회사 일에 유리하게 가져갈 수 있을까요? 저희 회사는 스프링부트를 백엔드로,프론트는 jsp,jstl 사용중이라 집에서도 한번 해보고 싶은데 커뮤니티 에디션으로는 어려워서요
강의를 보고 궁금한 점이 생겼다가 질문답변 게시판에도 유사 질문은 없는 것같아 gpt에도 물어봤지만 gpt 답변과 조금 다른 것같아 여쭈어봅니다. 11:20초 즈음에 그림에서처럼 8번. 정상 응답 이라고 표현을 하시는데 이것에 대한 기준?같은게 궁금합니다. 아래 코드는 강의의 try catch 코드입니다. try { if (ex instanceof IllegalArgumentException) { log.info("IllegalArgumentException resolver to 400"); response.sendError(HttpServletResponse.SC_BAD_REQUEST, ex.getMessage()); return new ModelAndView(); } } catch (IOException e) { log.error("resolver ex", e); } 먼저 예외가 발생하고 ExceptionResolver 가 넘어온 예외 해결을 시도하는데요. 코드에서 sendError() 로 에러 응답의 상태 코드를 변경하고 메시지를 설정한 후 빈 ModeAndView 를 반환합니다. 이때 찾아본 결과 sendError() 가 있으면 응답은 내부에 완료 표시(커밋)처리를 하기 때문에 reponse에 뷰를 작성?할 수 없어 ModelAndView가 빈 값이던 뷰 값을 주던 상관 없이 뷰 렌더링이 되지 않는다고 하더군요. 이부분 때문에 강의 ModelAndView 지정 부분에서 헷갈렸습니다. 이건 sendError가 없을 경우를 설명하신 것맞나요? 아무튼 본론으로 돌아와서 현재 코드와 과정처럼 최초 발생한 예외를 ExceptionResolver 에서 처리하고 DispatcherServlet 로 넘어간 후 뷰 렌더링을 처리하지 못하고 WAS에 넘기는데요. 이때 비록 뷰 렌더링은 하지 못했지만 ExceptionResolver 에서 상태 코드 등을 설정 후하고 ModelAndView를 반환하면서 에러를 처리하였으므로 WAS에 넘겨도 이것을 정상응답이라고 하나요? 아니면 제가 gpt에서 얻은 답변에서는 ExceptionResolver 가 예외를 처리했더라도 뷰 렌더링을 하지 못하고 WAS에 넘겼으므로 정상 응답으로 보지는 않는다고 하던데.. 정상응답의 기준이 어떻게 되나요? 좀 쓸데 없는 질문 같긴한데 ExceptionResolver 에서 ModeAndView 값 지정에 따른 반환에 대해 궁금해서 찾다가 궁금한점이 여기까지 파생되어 질문드립니다..