programming

구글 로그인 구현 이후 사용자 이름이 뜨지 않는 문제

'스프링 부트와 AWS로 혼자 구현하는 웹 서비스' 책 진도를 나가던 도중 구글 로그인에서 막히는 문제가 생겼다. 사실 기능적인 작동은 잘 되었다. 구글 로그인을 통해 로그인을 했지만, 로그인한 사용자의 이름이 뜨지 않고 로그인하지 않은 것 같은 화면이 계속 나왔다. 기능적인 부분: DB에 사용자 정보 저장 / 권한 변경하고 글 작성하는 것들은 잘 되었다. 요약하자면, 변수명이 일치하지 않아서 나는 문제였다. (index.mustache / IndexController.java)

핸들러 메서드의 응답 데이터 순서 변경

핸들러 메서드를 ResponseEntity와 HashMap을 이용하여 응답 데이터의 반환값을 확인해보는 연습을 해보았다. 처음 코드는 위와 같이 작성되어 있었고 postman을 통해 리턴된 JSON내용을 확인해 봤는데 내가 생각했던 결과와 조금 달랐다. map안에 데이터는 잘 매칭이 되었지만 내가 의도했던 방식은 engName / korName / price의 순서였는데 순서가 맞지 않게 나오는 문제였다. 검색을 해봤는데 HashMap을 그냥 쓰지 말고 LinkedHashMap으로 변경을 하라는 글이 있었다. 그 후 자료구조에서 배운 map의 특징이 생각났다. put 한 순서대로 데이터를 넣고 싶을때는 LinkedList처럼 Linked를 붙여야 하고, 그렇지 않고 그냥 map을 사용하면 순서에 관련이 ..

gradle reload는 중요해

스터디 책 진도를 나가던 도중 import를 할 수 없는 문제를 만나게 되었다. (구글 연동 구현 p.180) "org.springframework.security cannot be resolved" 프레임워크에서 security를 불러오지 못한다는데 아무리 검색을 해봐도 나만 문제를 겪고 있는 상황이었다. gradle.build에 의존성도 추가했고 오타도 없는데 왜 이럴까 하면서 찾다가 아래의 블로그에서 답을 찾았다. 이클립스 : The import org.springframework cannot be resolved 깃헙의 이클립스 스프링 프로젝트 가져왔을 때 생긴 문제다. 이클립스 우측 상단의 open perspective를 통해 Git perspective를 가져온다. clone git repos..

[TBC]AOP(Aspect Oriented Programming)

Aspect Oriented Programming(AOP - 관심 지향 프로그래밍 Application의 핵심 업무 로직에서 보안, 트랜잭션 같은 공통 기능 로직들을 분리하는 것 Application을 보는 관점을 '하나하나의 기능'에서 '공통 관심사' 관점으로 보는 것 OOP만 단독적으로 설계를 하게 된다면, 여러 군데에서 공통적으로 쓰이는 부가 기능의 중복 코드가 발생한다. 만약 부가 기능에 변경점이 생긴다면 사용된 모든 곳에 대한 수정 작업을 해야 하는데 이런 경우 유지보수가 힘들어지는 단점이 있다. AOP는 이를 보완하기 위한 개념으로, OOP의 불필요한 반복을 해결하기 위한 방법이다. 지속적으로 공부하면서 업데이트 예정 [TBC] AOP 관련 포스팅 Advice Pointcut 표현식 / 지시자..

AOP - Annotation (AspectJ)

Spring에서의 AOP는 Spring에서의 IoC를 보완하는 것에 큰 목적을 갖는다. Spring AOP는 스키마 기반 접근 방법과 @AspectJ 애너테이션 스타일을 지원한다. @AspectJ @AspectJ는 Annotation이 있는 일반 Java클래스로, 관점을 선언하는 스타일을 의미함 Spring AOP vs AspectJ Spring AOP Spring IoC에서 기본적으로 제공하는 AOP기능으로, Spring Container가 관리하는 Bean에만 사용이 가능하다. VS AspectJ 자바에서 동작하는 모든 객체에 대해 AOP를 적용이 목적이다. 좋은 성능 + 강력한 기능 BUT 복잡하다 외에 더 다른 차이점 들이 있지만 지금 단계에서는 많이 복잡하다고 판단되어 스킵 Comparing S..

AOP - Join Point

Join Point Application의 '진행 흐름에서의 특정 포인트'를 의미하며 메서드의 실행, 객체의 인스턴스화, 클래스 초기화, 필드 접근, 예외 처리 같은 것들이 포인트가 된다. AOP를 수행하는 메서드는 Join point의 인스턴스를 인자로 받아야 한다. = Join Point 해당 포인트의 정보를 얻어야 하기 때문이다. AspectJ를 사용하여 컴파일 타임과 클래스 로딩 시점에 적용하는 AOP는 바이트 코드를 실제 조작하기 때문에 해당 기능을 모든 지점에서 다 적용 가능하다. 다만 스프링의 AOP에서는 프록시 방식을 사용하기 때문에 1. Join point를 메서드 실행 지점 (a method execution)으로 한정한다 2. 스프링 컨테이너가 관리할 수 있는 스프링 Bean에만 AO..

AOP - Pointcut 표현식 / 지시자

Pointcut Join Point 중에서 Advice가 적용될 위치를 설정하는 기능 AspectJ 표현식을 사용해서 지정 스프링의 AOP는 메서드 실행 지점만 Pointcut으로 설정 가능 포인트컷은 관심 Join Point를 결정하기 때문에 Advice가 실행되는 시기를 통제할 수 있다. 그리고 포인트컷을 편리하게 표현하기 위해 AspectJ 표현식을 사용한다. @Pointcut("execution(* transfer(..))") // 포인트컷 표현식 private void anyOldTransfer() {} // 포인트컷 서명 Introduction to Pointcut Expressions in Spring | Baeldung A quick and practical intro to Spring A..

AOP - Advice

Advice Join Point에서 실행되는 코드 Aspect를 언제 핵심 코드에 적용할지 정의한다. 부가 기능(Cross-Cutting Concern)에 해당한다 시스템 전체 aspect에 API 호출 제공 각 상세 정보와 모든 메서드를 로그로 남기기 때문에 메서드 시작 전의 포인트를 선택한다. Orders of Advice Advice는 기본적으로 순서를 보장하지 않는다. 순서를 지정하고 싶다면 @Aspect 애너테이션을 적용 단위로 사용하여 org.springframework.core.annotation.@Order를 적용해야 한다. Advice단위가 아니라 클래스 단위로 적용한다. 하나의 Aspect에 여러 Advice가 존재하면, 순서 보장 X Aspect를 별도의 클래스로 분리해야 한다. Ty..

[TBC]IoC 와 DI

IoC(Inversion of Control) Inversion of Control(IoC)은 애플리케이션 흐름의 주도권이 뒤바뀐 것을 말한다. 일반적인 자바 자체의 코드만으로 실행을 하면 main() 메서드를 먼저 호출한 뒤에 프로세스가 순차적으로 진행되는데 이것은 개발자가 작성한 코드를 순차적으로 실행하는 application의 일반적인 제어 흐름이다. 서블릿 기반의 application을 예로 들어본다면 서블릿 기반 프로그램은 클라이언트에서 요청이 들어올 때마다 서블릿 컨테이너의 로직(service() 메서드)이 직접 서블릿을 실행시켜 주기 때문에 main() 메서드가 없다. 이런 경우, 서블릿 컨테이너가 서블릿을 제어하고 있는 상황이기 때문에 application의 주도권은 서블릿 컨테이너가 쥐고..

PSA

PSA (Portable Service Abstraction - 서비스 추상화) PSA는 추상화의 개념을 application에서 사용하는 서비스에 대입하여 적용하는 방법이다. Application의 특정 서비스(어떠한 구현된 기능)를 이용할 때, 해당 서비스의 기능에 접근하는 방식 자체를 일관되도록 유지함과 동시에, 기술 자체를 유연하게 사용할 수 있게 하는 것이 핵심 개념이다. Dependency Injection의 '느슨한 결합(Loose Coupling)'과 연관되는 개념인 것 같이 느껴진다. 예 ) 추상화 된 상위 클래스를 일관되게 바라보며 하위 클래스의 기능을 사용하는 것 예2) 인터페이스를 통해 간접적으로 연결되어(느슨한 결합) 구현된 기능 사용 -참고- 서버 - 클라이언트 관계의 관점에서는..

Spring Framework

*서블릿 컨테이너 부분 추가할 것 프로그래밍 관점에서 Framework는 기본적으로 프로그래밍을 하기 위해 어떠한 틀이나 구조를 제공한다. 자바에서 배웠던 Collections Framework가 바로 이 기능을 한다. List, Set 그리고 Map 같은 인터페이스와 그걸 구현한 클래스의 집합이다. 개발자가 바닥부터 모든 기능을 전부 개발하면서 진행하는 것이 아니라, 다양한 기능들(Application 간의 통신, 데이터를 데이터 저장소에 저장 등)을 Framework가 Library 형태로 제공하기 때문에 개발자는 프로그램의 핵심 기능의 개발에만 온전히 집중할 수 있게 된다. Framework와 Library가 무슨 차이가 있는지 많이 헷갈렸는데 Application에 대한 제어권을 기준으로 생각하면..

POJO(Plain Old Java Object)

POJO POJO 프로그래밍이란 순수한 자바 객체[POJO]가 다른 기술이나 환경에 종속되지 않도록 하는 개발 기법이다. POJO 프로그래밍을 지향하기 위해 IOC/DI, AOP, PSA라는 기술을 Spring이 제공한다. POJO 프로그래밍을 위해선 다음의 큰 두가지 규칙을 지켜주어야 한다. Java나 Java의 스펙(사양)에 정의된 것 이외에 다른 기술이나 규약에 얽매이지 않아야 한다. 특정 환경에 종속적이지 않아야 한다. 결론적으로 항상 객체지향 사고방식 + JDK의 API 지식을 잘 함양하는 것이 중요하다. 추가적으로 객체지향 원칙 SOLID와 연관 지어 생각하면 좋을 듯하다. POJO 프로그래밍이 필요한 이유 특정 환경이나 기술에 종속적이지 않으면 재사용과 확장이 가능한 유연한 코드를 작성할 수..