몰랐던 문법 & 각종 ERROR

스트림은 파라미터로 제공되는 함수function 관련된 함수형 인터페이스를 적용해서 기존 요소를 새로운 요소로 Mapping 기존 값을 변경한다는 개념보다는, 새로운 값을 만든다. 즉, 변환에 매핑이라는 단어 여러 매서드가 존재하는데 => mapToInt, mapT

BufferedReader로 라인을 읽고, 그 라인 안에서 특정 문자열로 읽어 드릴 수 있으려면 StringTokenizer 클래스를 사용. new StringTokenizer(br.readLine)으로 하면, 라인을 읽어드릴 수 있고, nextToken()으로 공백

Spring-jcl을 사용한 표준 Commons Logging 탐지: 이 메시지는 스프링의 JCL (Java Common Logging) 지원이 활성화되어 있고 작동 중임을 나타냅니다. commons-logging.jar 를 클래스패스에서 제거하여 잠재적

Spring-jcl을 사용한 표준 Commons Logging 탐지: 이 메시지는 스프링의 JCL (Java Common Logging) 지원이 활성화되어 있고 작동 중임을 나타냅니다. commons-logging.jar 를 클래스패스에서 제거하여 잠재

Expected :110123456789 Actual :100000000 AccountServiceImpl에 1000000으로 설정해놓고는.... 휴 ㅜㅡㅜ 잘 통과된다.

Mockito 사용중 Unnecessary Stubbing Exception 해소하기 Spring Boot에서 JUnit5와 이에 포함된 Mockito Core 3.x 버전을 사용할 때 아래와 같이 UnnecessaryStubbingException 에러가 나면서 테스

파라미터를 캡처하는데 사용이 되어야 하는데 verify 부분에 파라미터 캡처 하고 있지 않아서 발생한 문제! 변경!!!

040000 tree 646ae6dc42fca376860c71a36f8bcdcadbdf8556 .gradle040000 tree 76905f9849adf7760f5bf6d6335ed11960d4812a .idea100644 blob 5957b8a1c3a689

더티체킹이란 상태 변화가 생긴 정도 = 상태 변경 검사 변화가 있는 모든 엔티티 객체를 데이터베이스는 자동으로 반영 변화가 있다 기준은 최초 조회 상태 JPA에서는 엔티티를 조회하면 해당 엔티티의 조회를 그대로 스냅샷을 만들어 놓는다. 스냅샷과 비교해 다른점이 있다면

@Test Annotaion과 @ParameterizedTest 둘 다 Test 객체로 동작둘중 하나 지워야 함\[출처: https://well-made-codestory.tistory.com/56 SJ BackEnd Log:티스토리](@Test Annotai

버전이 맞지 않아서 뜨는 오류. 버전만 맞게 설정해준다면 잘 실행 될 것이다.

Socket 클래스는 client에서 서버로 접속하거나 Server에서 accept 하는데 필요한 클래스다. 이 설명을 이해 하려면 TCP/IP 접속 송수신 과정이해가 선행 되어야 한다.출처: https://jink1982.tistory.com/182 돼민이:

HttpEnitity라는 클래스 -> HTTP 요청 응답에 해당한는 HTTPHeader와 HTTPBody를 포함하는 클래스 ResponseEntity는 사용자의 HttpRequest에 대한 응답 데이터를 포함하는 클래스. HttpStatus, HttpHeaders, H

testCode 작성중 h2와 연결해 test를 해보려고 하는데 동작이 되질 않았다 우선 DataSource를 자동으로 구성하려고 하는데 문제가 발생했다고 보인다... 해결방법으로 사용했던 것 중 첫번째는 h2에 쿼리를 다시 작성해보는 것이다. 두번재는 yml의 설정을

test을 깨끗하게 하기 위해 Transactional을 추가했다. SaveMember 테스트:이 테스트는 BankMember 객체를 데이터베이스에 저장하고 그 결과를 검증. 이 테스트는 데이터베이스 상태를 변경하므로 @Transactional 애너테이션을 추가find

?????? 왜 안되지 싶었다.. 찾아보니 깃의 원격저장소오 ㅏ연재 로컬저장소가 동기화 되지 않았기 때문에 나타나는 문제라고 하더라...여기 블로그 참고해결!!!

getAccountNumber() 메서드를 사용하여 계좌 번호만을 추출합니다. 이 단계는 리스트에서 각 계좌의 번호만을 가져오게함

Description:The dependencies of some of the beans in the application context form a cycle:┌──->──┐| transactionRepositoryImpl defined in file C:\\Use

이 에러는 파라미터 값을 읽을 수 없다는 이야기인데. 우선 Dto 값에 NoArgsConstructor가 빠졌고, implementation 부분도 빠져있었다. 해당 클래스에 기본 생성자를 자동으로 생성합니다. 기본 생성자는 인자가 없는 생성자로, 객체를 생성할 때 필

SpringFrameWork에서 이메일을 보낼때 사용하는 인터페이스 \-- 주요기능 간단한 텍스트 이메일 전송 HTML 이메일 전송 첨부파일 포함 이메일 전송 이메일 헤더 설정 (수신자, 발신자, 제목 등) \-- 사용방법 의존성 추가 application.proper

Test 도중 Cache 하는 부분이 Bean 인식을 못했다는 이야기인 것 같다.. SpringCache 활성화 @EnableCaching 어노테이션을 추가해 캐시 활성화. SpringBootTest 통합 테스트 수행 통합 테스트에서는 애플리케이션의 모든 컨텍스트가 로

음... 한마디로 말하자면 진짜 삽질했다... 우선 이건 내 회원가입 기능을 구현한 것이다. 그리고 이건 SpringSecurity를 구현한 것이다. 구글링을 했을떄는 RequestMapping에 대한 경로가 잘못된 case들이 많아 나도 그런가? 싶었다. 그래서 여러

서비스 계층 메서드 원자성 보장 : CRUD의 연산이 하나의 트랜젝션으로 묶여야 할때 사용 ex) -> 사용자의 계좌에서 돈 인출 -> 다른 계좌에 돈을 입금하는 경우, 두 연산 중 하나라도 실패하면 rollback 되어야 함. 일관성 유지 : DB의 상태를 일관되게

HTML 폼 요소에서 발생하는 이벤트 헨들러, 사용자가 폼을 제출할 때 실행되는 자바스크립트 코드를 지정하는데 사용. 폼 제출 시 서버로 데이터를 정송하기 전에 추가 작업을 하거나 기본적 폼 제출 동작을 방지하고자 할때 사용 자바스크립트로 폼 유효성 검사 폼이 제출되기

자바스크립트에서 폼을 제출하거나, 버튼을 클릭하거나, 키보드를 누르는 등 특정 사용자 동작이 발생할 때 브라우저가 자동으로 전달하는 객체, 브라우저가 이벤트 핸들러 함수에 전달하는 매개변수 역할브라우저가 자동으로 생성하는 이벤트 정보를 담고 있는 객체입니다. 이 객체는

존재하는 물건을 "객체" Java는 클래스를 통해 객체를 만든다. Java Virtual Machine = 자바 가상 머신 여러가지의 기기위에 Java 프로그램을 실행시킬 수 있는 가상의 기기를 형성 어느 장비에서든 JVM을 까라주면 Java 실행 가능 작성한 코드를

값의 타입 : 저장공간의 종류 (ex.. int)값의 이름 : 저장공간 이름 (ex.. int number;)선언과 동시에 저장 -> 초기화 int number = 10; 값을 담는과 동시에 저장 선언 이후에 값을 저장한다면 ? -> 덮어쓰기 number = 20; -

boolean default 값 = false얕은 복사 참조형 변수, 실제값이 아닌 실제값의 주소값을 갖는다. "="을 사용하면 주소값만 복사 주소값만 복사되고 실제 값은 1개로 유지 -> 얕은 복사 \-깊은 복사 진짜 새로운 배열을 똑같이 만들고 싶을때 깊은 복사를

ip를 통해 접속한 컴퓨터에서 어떤 곳으로 연결할지 구분시키는 역할자 서버 데이터에 들어올 수 있는 규칙을 의미. 서버에 접속하고 해당 데이터들을 읽을 수 있으며, 권한 여부에 따라서 생성, 수정, 삭제도 허용되는 규칙클라이언트가 서버의 데이터에 접속하는 권한, 기본적

요청 매핑에서 쿼리 파라미터를 선택적으로 받을 수 있게 해주는 어노테이션. 즉 클라이언트가 해당 파라미너터를 전달하지 않더라도 기본 값 없이 처리 API 유연성 + 필요한경우 특정 로직에서 추가 처리 가능 필요하다면 파라미터가 없을 때 기본값을 지정 사용 가능.book

중간 테이블 처리 비용 증가 두개의 엔티티 사이에 중간 테이블을 자동으로 생성해 관계를 관리 중간 테이블에는 두 엔티티의 ID가 저장되어 있어 각 레코드 간의 메핑 관리 읽기 작업 : 두개의 엔티티를 읽을 때 두번의 JOIN 필요 각각의 엔티티와 중간 테이블을 조인한

여러 작업을 하나로 묶는 단위 -> Transaction (all or Nothing) Biz 로직 실행 중 하나의 작업이 멈춘다면?? 해당 db나 결과가 날라감 트렌젝션은 이런 상황이 발생하는 것을 방지 Atomicity(원자성)모든 작업이 반영되거나 모두 롤백되는

getter로 접근하지 않으면 proxy일때 계산 안됨 getter로 호출해야 proxy일때 접근 가능. 특히 JPA를 사용할때는 equals and hashcode를 구현해서 사용하는 것이 좋다.

GET 메소드(조회)는 안전하다.저장된 데이터를 변환하지 않는다.POST, DELETE, PUT, PATCH는 안전하지 않다.데이터를 생성, 수정, 삭제한다.한번 호출하거나 수천번 호출하거나 항상 결과는 같다 \-> POST의 경우 멱등성을 보장하지 않음 요청이 실패한

결과중 몇개 까지만 가져오기 출처 Code(출처: https://inpa.tistory.com/entry/MYSQL-📚-LIMIT-OFFSETlimit은 가져올 데이터 양, offset은 가져올 초기 값 Paging 을 하기위해서 0 부분을 변수로 지정하여,

요청을 완료, 추가 행동이 필요 3xx 응답 + Location HTTP Header 있으면 Location 위치로 Redirect URL이 영구적으로 변경된 경우, 기존 URL을 사용하지 않는다.URI가 일시적으로 변경된 경우, PRG(Post, Redirect, G

HTTP API는 설계시 항상 리소스 식별을 기준으로 삼아야한다.위 예시에서 리소스는 게시글이다.URI에 들어갈 리소스는 단수 형태가 아닌 복수 형태로 사용을 권장한다. board → boardsURL에 동사를 사용하지 않는다.HTTP Method의 역할을 URL에 포

Cache-Control: max-age캐시 유효 시간(초)캐시 유효 시간이 지나면 다시 서버를 통해 데이터를 응답받고 캐시를 갱신한다.Cache-Control: no-cache캐시 가능한 데이터지만, 서버에 검증하고 사용해야 한다.Cache-Control: no-st

서버에서 동적으로 HTML을 만들어 클라이언트에게 제공하는 기술로 백엔드 개발자 영역에 속한다. Java에서는 JSP, Thymeleaf가 대표적으로 사용Was -> HTML -> DB -> HTML 동적 생성 -> HTML Response장점초기 페이지 로드 시 서버

Groovy기반의 스크립트 언어를 사용하며 다양한 소프트웨어를 빌드(Build)할 수 있는 유연한 빌드 자동화 도구소스 코드를 컴퓨터가 실행 가능한 파일로 변환빌드 자동화 도구 빌드 라이브러리 관리, test, 배호 등을 자동화 하여 수행Gradle 특징 유연성 복잡한

Json 객체에 인증에 필요한 정보들은 담은 비밀키 서명한 토큰 => 인터넷 표준 인증 방식 인증 & 권한 허가인증 : 유저가 누구인지 확인 하는 절차 (회원 가입 & 로그인)비밀번호, 일회용 핀, 인증 앱, 생체인식 등이 있음 인가 : 유저에 대한 권한을 허락, 엑세

쿠키는 클라이언트 측에서 확인이 가능, 세션은 서버에서 저장하기 때문에 확인 할 수 없음 참고로 Session은 JSESSIONID 같은 클라이언트마다 고유 ID를 부여하여 요청시 쿠키의 값을 확인하여 구분HttpSession을 이용해 처리 내부적으로 Servlet C

외부 소셜 계정을 기반으로 간편 인증하는 인증 서비스 제공 ex) facebook, kakao 등Third-party 프로그램이 client를 대신해 리소스 서버에 제공하는 자원에 대한 접근 권한을 위임 받는 형식1) Resource Owner리소스 소유자. 외부 소셜

트랜잭션은 ACID(원자성, 일관성, 격리성, 지속성)을 보장. 트랜잭션은 원자성, 일관성, 지속성을 보장하지만 문제는 격리성. 트랜잭션간 원벽한 격리를 보장하기 위해서는 동시성 측면에서 손해 봄. ASNI 표준에서 트랜잭션 격리 수준을 4단계로 구분하여 병행성과 격리

서버와 클라이언트 간의 메시지 교환을 위한 통신 규약 양방향 통신 (Full-Duplex)데이터 송수신을 동시에 처리 할 수 있는 방법 통상적인 HTTP 통신은 client가 요청을 보내는 경우에만 Server가 응답하는 단방향 통신 웹 소켓은 양방향 통신이 가능 실시

SSE VS Socket SSE단방향 (서버 -> 클라이언트) & HTTP 기반HTTP 기반 (Keep alive)단순한 텍스트각 클라이언트마다 하나의 HTTP 연결 필요 서버에서 과도한 데이터 전송시, 클라이언트 쉽게 과부하 발생단일 서버 부하 증가 => HTTP

Spring Boot 앱이 Redis에 연결하지 못하고 다음과 같은 예외 발생:애플리케이션 기동 성공Redis 연결 정상RedisTemplate을 통한 데이터 read/write 정상 작동디버깅 환경(docker logs, exec)에서도 정상 반영됨

✅ 장점최고 수준 보안: 탭을 닫는 즉시 토큰이 완전 삭제됨세션 격리: 탭별로 독립된 로그인 세션메모리 효율: 브라우저 메모리만 사용, 디스크에 기록되지 않음자동 정리: 브라우저가 메모리 관리 자동 수행❌ 단점사용성 최악: 페이지 새로고침, 링크 이동 시 로그아웃됨SP