파이썬 진영 대표 웹 애플리케이션 프레임워크 Django  

보편적으로 Layer단위로 나누고 그 안에서 도메인 별로 로직을 분리하는 스프링 과 다르게

장고는 도메인 단위로 분리한 뒤에 그 안에서 Layer를 나눈다.

Django는여러개의 App을 가진다 (현 이미지에서는 member orders payments product webPage가 장고의 애플리케이션이다.)

이러한앱들을 ROOT Application(현이미지에서는 configuration)의 settings.py 파일에서 @Configuration객체 에서 작업해는 것처럼  설정 작업을 해준다.

그리고 모든 HTTP 요청들은 ROOT Application의 url 을 통해서 각자의 App으로 로직을 타고 들어가는 방식이다. 

장고의 구조 이해의 가장 중요한 부분은 settings.py의 구성을 이해하는 것이다.

Settings.py의 구조 

1. INSTALLED_APPS

# Application definition
INSTALLED_APPS = [
     #최초 장고 프로젝트 생성시 등록되있는 Application 
    'django.contrib.admin', # 장고의 꽃 관리자 App이다 
    'django.contrib.auth', # 장고 기본제공 회원 관리앱 장고프로젝트를 생성하는 동시에 회원관리하는 App 개발이 끝나있다. 
    'django.contrib.contenttypes', # http contenttype이 아니라 장고 App별 컨텐츠들 관리
    'django.contrib.sessions',  # 우리가 아는 그 세션,쿠키.  장고 회원관리 앱과 더불어 인증 로직을 지원한다.
    'django.contrib.messages',
    'django.contrib.staticfiles', # 장고의 정적 파일들 관리 해주는 app
    
    'django_extensions', # 장고의 유틸리티 기능 확장 이건 다양해서 구글링 해서 찾아보시는게 

    'rest_framework', # 순수 장고는 html을 반환해주는 전통적인 웹 프로젝트를 목적으로 만들어 졌습니다. 
                      # 그래서 API 형식에 대해서는 커스터마이징 해줘야하는 부분이 많아요 
                      # 그래서 장고가 REST API를 지원해주는 APP DRF를 만들어 두었습니다 그게 이거입니다
    'drf_yasg',       # 장고 API 문서 자동화 도구  이건 다른 포스트에서 따로 설명드리겠습니다... 
    
    # 위 이미지에 만들어져있는 APP들을 등록한것 이렇게 등록안하면 
    # 스프링에서 @Bean 안붙이면 그냥 자바 객체이듯이 그냥 장고에서도 파이썬 패키지에 불과함
    'member.apps.MemberAppConfig',
    'product.apps.ProductAppConfig',
    'orders.apps.OrdersAppConfig',
    'payments.apps.PaymentsConfig',
    'webpage.apps.WebpageConfig',

]

2. MIDDLEWARE

3. DATABASES

React.js

HTML이 메인이고 JavaScript는 그걸 보조해주던 시대는 이제 가버렸고

Javascrpit 가 메인이고  Javascrpit Application 위에서 HTML로 구조를 만드는? 시대이다.

실행환경

window10

스프링부트 
Intellij 
Mybatis 3.4.6 
Maven3

IDE위에서는 전부 정상적으로 실행되는데

배포파일로 실행하면 문제가 생긴다.

mvn package 로 jar 파일로
java -jar demo.jar 이렇게 실행하면 
TypeAliasePackage를 못찾고 에러가 뜬다

정말 기묘한 에러였다.

해결방법

스프링 부트이면 저렇게 SpringVFS을 설정에 세팅해주면 바로 해결된다.

또다른 방법은 pom.xml에 라이브러리 추가

해결방법 출처 

해당 에러 해결법 제공

https://bluesky-devstudy.blogspot.com/2016/06/spring-boot-war-mybatis-typehandler.html

Mybatis 커뮤니티  질문 

https://www.facebook.com/groups/mybatis/permalink/1960436807309419/?comment_id=1960536903966076

첫번째 url에서는

스프링부트에서 

버젼 java8 mybatis3.4 이후 
typeHandler scan은 없다고 되어있는데

해당 문제가 해결되었다고 써있었지만

나는 java8 mybatis3.4.6 springboot1.5.3 &2.x.x 
환경에서도 같은 문제가 발생했다


차이점은 

윗 url에서는 war로 배포했고

나는 jar로 배포했다는 점이다

집가는데 친구가 이런 질문을 던졌다. 

설명해주는김에 

마이바티스를 예제로 들어서 설계 관련 내용을 써보았다.

우선 위에 질문에 대한 정답은 

SqlSessionFactoryBuilder는 개발자들을 위한 ,단순히 가독성을 좋은 소스코드를 작성하기위한

객체이다.

이 객체는 서버를 최초 1회 실행시에 SqlSessionFactory를 생성하는데 한번 쓰이고

사라지는 객체이다.

이거 이외에  설명을 좀 길게하려했는다.

한번의 db 요청하려면 SqlSession를 사용해야한다 써야된다.

Session이란 인스턴스안에 있는 논리적인 실체로 현재 유저의 로그인 상태를 말한다

우리가 서블릿 공부할때 쓰는 Session Cookie 과 같은  그 세션의 개념이다. 

즉 JDBC 프로그래밍에서

Connection con= DriverManager.getConnection(url, id, pw);

이코드로 Db에 접속해있는 하나의 논리적인 연결 상태를 의미하는것

Conntection이란 단순히 물리적(네트워크)인 연결을 말하는 것

SqlSession이란 RDB에 인증을 거친 논리적인 연결 상태를 말하는 것이다.

하나의 SqlSession을 만들기 위해서는

jdbc프로그래밍에서 필요한것처럼 기본적으로

1. Url

2. Id

3. password

3개의 정보가 필요하고 

그 이외에도

Mybatis에서는

캐싱정책의 사용유무,

지연 로딩 등등

많은 설정 정보들이 존재한다.

이러한 정보들을 SqlSession을 생성할때마다 전부 다시 정의하는 것은 매우 힘들다.

이거는 마치 JDBC 로 db 접속할때

매번 id pw url을 그때그때 서블릿 클래스마다 클래스내 전역변수로 지정해주는 것처럼 번거로운 일이다.

그렇기 때문에 이러한 설정값들을

한곳에 모아놓고 그 모아놓은 곳에서 객체를 가져오는 것이 효율적인데

이것이 SqlSessionFactory 이다

mybatis 의  DefaultSqlSessionFactory  클래스 내부 모습 

정말 별거 없다  

여기서 문제가 한 개 더 있다.

SqlSessionFactory를 만들기위해서는 엄청 많은 정보들을 넣어줘야하는데 (id url AliasesPackage.....)

이거를 그냥 인스턴스를 쉽게 생성자를 사용해서 

new SqlSessionFactory() 이렇게 만드는 거는

매우 불안하다 

왜냐면 "생성자 인자가 많은 경우에는 Constructor 방식은 가독성이 매우 떨어진다"

--Effective Java edition2 규칙2 생성자 인자가 많을때는 

Builder패턴 적용을 고려하라 page16 --

그렇기에 이런경우에는 디자인패턴중에서  BuilderPattern을 사용하는데

이것이 SqlSessionFactoryBuilder이다.

SqlSessionFactoryBuilder 내부 소스코드 

SqlSessionFactoryBuilder는 개발자들을 위한 ,단순히 가독성을 좋은 소스코드를 작성하기위한

객체이다.

이 객체는 서버를 최초 1회 실행시에 SqlSessionFactory를 생성하는데 한번 쓰이고

사라지는 객체이다.

마이바티스를 사용하여 db에 접속된 세션을 얻기 위해서는 

SqlSessionFactory 가 필요하다 

이거를 만드는 방법은 여러방식이 있는데 

SqlSessionFactoryBuilder를 이용해서 mybatis-config.xml을 가져와서 만드는 방법도 있지만 

XML 을 배척하는 JavaConfig를 선호함으로 다른 방식을 사용하겠다.

Mybatis-Spring  라이브러리를 사용하면

SqlSessionFactoryBean 이 있는데 

이 객체를 사용하면 mybatis-config.xml 파일 없이도

클린한 JavaConfig 를 구성할수있다.

import javax.sql.DataSource;

import org.apache.ibatis.session.SqlSessionFactory;
import org.apache.ibatis.type.BooleanTypeHandler;
import org.apache.ibatis.type.DateTypeHandler;
import org.apache.ibatis.type.TypeHandler;
import org.mybatis.spring.SqlSessionFactoryBean;
import org.mybatis.spring.SqlSessionTemplate;
import org.mybatis.spring.annotation.MapperScan;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.core.io.Resource;
import org.springframework.core.io.support.PathMatchingResourcePatternResolver;

@Configuration
@MapperScan(value="org.prj.arachne.infrastructure.mapper")
public class MybatisConfiguration {

 @Bean
 public SqlSessionFactory sqlSessionFactory(DataSource dataSource)throws Exception{
  SqlSessionFactoryBean sessionFactory=new SqlSessionFactoryBean();
  sessionFactory.setDataSource(dataSource);
  
  Resource[] res=new PathMatchingResourcePatternResolver()
       .getResources("classpath:/mappers/*_mapper.xml");
  
  //sessionFactory.setEnvironment("dev");
  
  sessionFactory.setMapperLocations(res);
  sessionFactory.setTypeAliasesPackage("org.prj.arachne.domain");
  sessionFactory.setTypeHandlers(new TypeHandler[] {
    new DateTypeHandler(),
    new BooleanTypeHandler()
  });

 
  return sessionFactory.getObject();
 }
 
   /**
     * 마이바티스 {@link org.apache.ibatis.session.SqlSession} 빈을 등록한다.
     *
     * SqlSessionTemplate은 SqlSession을 구현하고 코드에서 SqlSession를 대체하는 역할을 한다.
     * 쓰레드에 안전하게 작성되었기 때문에 여러 DAO나 매퍼에서 공유 할 수 있다.
     */
    @Bean
    public SqlSessionTemplate sqlSession(SqlSessionFactory sqlSessionFactory) {
        return new SqlSessionTemplate(sqlSessionFactory);
    }
    
    
    
    
    
    
 
}

@MapperScan : @Mapper 인터페이스들의 패키지 위치를 선언하는 설정이다.

sqlSessionFactoryBean 에서 

Datasource : 데이터베이스 접속을위한 계정, db드라이버, 비번 과 같은 정보들 

MapperLocation  : sql 들이 들어있는 xml 파일들의 위치를 지정한다

위 설정을 가지고 

userMapper.java(인터페이스) 와 user_mapper.xml 이렇게가 한쌍이되어서 

mybatis가 구현체를 알아서 생성해준다. 

TypeAliasesPackage : 디비에서 가져온 데이터들을 담을 자바 빈들이 모여있는 패키지 등록    쉽게말하면 MVC 패턴에서 Model에 해당하는 패키지를 등록하는 것이다.

추가 옵션 설정은 이렇게 해주면된다 

다양한 옵션들은 mybatis공식 사이트 들어가서 확인해보시기를 

Properties properties = new Properties();
properties.setProperty("mapUnderscoreToCamelCase", "true");
sessionFactory.setConfigurationProperties(properties);

이 문서는 개인적인 목적이나 배포하기 위해서 복사할 수 있다. 출력물이든 디지털 문서든 각 복사본에 어떤 비용도 청구할 수 없고 모든 복사본에는 이 카피라이트 문구가 있어야 한다.

22.1 소개

스프링은 JDBC API를 통합했듯이 JMS API도 사용하기 쉽게 JMS 통합 프레임워크를 제공한다.

JMS는 기능적으로 대략 두 부분으로 나눌 수 있는데 메시지의 생산(production)과 소비(consumption)이다. JmsTemplate 클래스는 메시지 생산과 동기적인 메시지 수신에 사용한다. Java EE의 메시지주도 빈(bean) 방식과 유사한 비동기적인 수신에 대해서 스프링은 메시지주도 POJO(MDP, Message-Driven POJOs)를 생성하는데 사용하는 다수의 메시지 리스너 컨테이너를 제공한다.

org.springframework.jms.core 패키지는 JMS 사용에 핵심적인 기능을 제공한다. 이 패키지에 JdbcTemplate가 JDBC에 하듯이 리소스의 생성과 소멸을 다뤄줌으로써 JMS를 간편하게 사용하게 하는 JMS 템플릿 클래스가 있다. 스프링 템플릿 클래스와 공통되는 설계 원리는 더 세련된 사용방법을 위해서 공통되는 작업을 수행하는 헬퍼 메서드를 제공하고 작업을 처리하는 부분을 콜백 인터페이스를 구현한 사용자에게 맡기는 것이다. 이 클래스는 동기적으로 메시지를 보내고 메시지를 소비ㅎ고 JMS 세션와 메시지 생산자(producer)를 사용자에게 노출하는 다양한 편의 메서드를 제공한다.

org.springframework.jms.support 패키지는 JMSException 변환 기능을 제공한다. 이 변환기능은 체크드 JMSException 계층을 동일한 계층의 언체크드 예외로 변환한다. 프로바이더에 특화된 체크드 javax.jms.JMSException의 하위클래스가 있다면 이 예외는 언체크드 UncategorizedJmsException로 감싸진다.

org.springframework.jms.support.converter 패키지는 Java 객체와 JMS 메시지간에 변환을 하는 MessageConverter 추상화를 제공한다.

org.springframework.jms.support.destination 패키지는 JNDI에 저장된 목적지에 대한 서비스 로케이터를 제공하듯이 JMS 목적지를 관리하는 다양한 전략을 제공한다.

마지막으로 org.springframework.jms.connection 패키지는 독립 어플리케이션에서 사용하는데 적합한 ConnectionFactory의 구현체를 제공한다. 이 패키지에는 JMS를 위한 스프링 PlatformTransactionManager의 구현체도 있다.(이 이름은 JmsTransactionManager이다) 이는 JMS를 트랜잭션 리소스처럼 스프링의 트랜잭션 관리 메카니즘으로 어려움없이 통합할 수 있게 한다.

22.2 스프링 JMS 사용

22.2.1 JmsTemplate

JmsTemplate 클래스는 JMS 코어 패키지의 핵심 클래스다. JmsTemplate 클래스는 메시지를 보내거나 동기적으로 메시지를 받을 때 리소르를 생성하고 제거하는 처리를 해주므로 JMS의 사용을 간단하게 해준다.

JmsTemplate을 사용하는 코드는 고수준의 계약을 명확하게 정의해주는 콜백 인터페이스만 구현하면 된다. MessageCreator 콜백 인터페이스는 JmsTemplate에서 코드를 호출해서 제공한 Session의 메시지를 생성한다. JMS API의 더 복잡한 사용을 위해서 SessionCallback 콜백은 JMS 세션을 가진 사용자와 Session과 MessageProducer 쌍을 노출하는 ProducerCallback 콜백을 노출한다.

JMS API는 두 종류의 send 메서드를 노출하는데 하나는 전송모드, 중요도, 서비스품질 (QOS, Quality of Service)로 time-to-live를 받고 하나는 QOS 파라미터를 받지 않고 기본값을 사용한다. JmsTemplate에 다수의 send 메서드가 있으므로 QOS 파라미터를 설정하는 것은 다수의 send 메서드의 중복을 피하기 위해 빈 프로퍼티로 노출된다. 비슷하게 동기적인 receive 호출의 타임아웃값은 setReceiveTimeout 프로퍼티로 설정한다.

일부 JMS 프로바이더는 관리상(administratively) ConnectionFactory의 설정으로 기본 QOS 값을 설정할 수 있게 한다. MessageProducer의 send 메서드 send(Destination destination, Message message)를 호출해서 JMS 명세서에 나온 것과는 다른 QOS 기본값을 사용하게 할 것이다. 일관된 QOS 값의 관리를 위해서 JmsTemplate은 특히 isExplicitQosEnabled 프로퍼티를 true로 설정해서 자신만의 QOS 값을 사용하도록 되어야 한다.

Note

JmsTemplate 클래스의 인스턴스는 설정되고 나면 스레드 세이프하다. 이는 하나의 JmsTemplate 인스턴스를 설정해서 공유되는 참조로 여러 협력객체에 안전하게 주입할 수 있다는 의미이므로 중요하다. 좀 더 분명하게 JmsTemplate은 상태를 가지지만(ConnectionFactory에 대한 참조를 유지한다는 점에서) 이 상태는 대화식 상태는 아니다.

22.2.2 연결

JmsTemplate는 ConnectionFactory에 대한 참조를 필요로 한다. ConnectionFactory는 JMS 명세에 포함되어 있고 JMS와 동작하는 진입점으로 제공된다. 클라이언트 어플리케이션이 ConnectionFactory를 JMS 프로바이더의 연결을 생성하는 팩토리로 사용하고 다양한 설정 파라미터(대부분은 SSL 설정옵션 같은 벤더에 특화된 설정이다.)를 캡슐화한다.

EJB에서 JMS를 사용하는 경우 벤더가 JMS 인터페이스의 구현체를 제공하므로 구현체가 선언적인 트랜잭션 관리에 참여하고 연결과 세션의 풀링을 수행한다. 이 구현체를 사용하려면 Java EE 컨테이너는 보통 EJB내의 resource-ref로 JMS 커넥션 팩토리나 서블릭 배포 디스크립터를 선언하도록 요구한다. EJB에서 이 기능과 JmsTemplate를 함께 사용하려면 클라이언트 어플리케이션이 ConnectionFactory의 관리된 구현체를 참조한다는 것을 보장해야 한다.

22.2.2.1 메시징 리소스 캐싱

표준 API에는 다수의 중간객체의 생성하는 API가 포함되어 있다. 메시지를 보내려면 다음의 'API'가 실행된다.

C-like

ConnectionFactory->Connection->Session->MessageProducer->send

ConnectionFactory와 Send 작업사이에는 생성되고 소멸되는 세개의 중간 객체가 있다. 리소스의 사용을 최적화하고 성능을 높히기 위해 IConnectionFactory의 두 구현체를 제공한다.

22.2.2.2 SingleConnectionFactory

스프링은 ConnectionFactory 인터페이스의 구현체로 SingleConnectionFactory를 제공하고 SingleConnectionFactory는 모든 createConnection() 호출에서 같은 Connection을 반환하고 close() 호출은 무시할 것이다. 이는 다수의 트랜잭션이 걸친 여러 JmsTemplate 호출에 같은 연결을 사용할 수 있으므로 테스트와 독립적인 환경에 유용하다. SingleConnectionFactory는 일반적으로 JNDI에서 받은 표준 ConnectionFactory에 대한 참조를 받는다.

22.2.2.3 CachingConnectionFactory

CachingConnectionFactory는 SingleConnectionFactory의 기능을 확장하고 Session, MessageProducer, MessageConsumer에 캐싱을 추가한다. 초기 캐시크기는 1이고 캐시되는 세션의 수를 증가시키려면 SessionCacheSize 프로퍼티를 사용해라. 실제 캐시된 세션의 수는 승인 모드(acknowledgment mode)에 기반해서 캐시된 세션의 수보다 많을 것이므로 SessionCacheSize를 1로 설정한 경우(각 AcknowledgementMode마다 1) 캐시된 세션 인스턴스는 4까지 될 수 있다. MessageProducer와 MessageConsumer는 이들이 소유한 세션에 캐시되고 캐싱할 때 생산자(producer)와 소비자(consumer)의 유일한 프로퍼티를 고려한다. MessageProducer는 목적지에 기반해서 캐시된다. MessageConsumer는 목적지, 셀렉터, noLocal deliver 플래그, (durable consumer를 생성한다면)장기 구독 이름(durable subscription name)로 구성된 키에 기반한 캐시된다.

22.2.3 목적지 관리

ConnectionFactory같은 목적지는 JNDI로 저장하고 획득할 수 있는 JMS가 관리하는 객체다. 스프링 어플리케이션 컨텍스트를 설정할 때 JMS 목적지에 대한 객체의 참조에 의존성 주입을 하기 위해 JNDI 팰토리 클래스 JndiObjectFactoryBean / 를 사용할 수 있다. 하지만 어플리케이션에 아주 많은 목적지가 있거나 JMS 프로바이더에 특화되 고급 목적지 관리기능이 있다면 이 전력을 다루기 어려울 수 있다. 고급 목적지 관리에는 동적 목적지 생성이나 목적지의 계층적 네임스페이스 지원등이 있다. JmsTemplate은 목적지 처리를 JMS 목적지 객체나 DestinationResolver 인터페이스의 구현체에 위임한다. JmsTemplate이 기본 구현체로 DynamicDestinationResolver를 사용하고 동적 목적지를 처리한다. 제공된 JndiDestinationResolver는 JNDI에 있는 목적지의 서비스 로케이터처럼 동작하고 선택적으로 DynamicDestinationResolver의 동작으로 장애 복구를 한다.

드물기는 하지만 JMS 어플리케이션이 상요하는 목적지를 런타임에서만 알 수 있는 경우에는 어플리케이션을 배포할 때 생성할 수 없다. 이러한 상황은 상호장용하는 시스템 컴포넌트가 잘 알려진 작명관례에 따라 런타임에서 목적지를 생성하고 이 시스템 컴포넌트간에 어플리케이션 로직을 공유하기 때문에 발생한다. 동적 목적지생성이 JMS 명세에 나와있지 않지만 대부분의 벤더는 이 기능을 제공하고 있다. 동적 목적 목적지는 임시 목적지와 구별할 수 있는 사용자가 정의한 이름으로 생성되고 JNDI에 등록되지 않기도 한다. 목적지와 관련된 프로퍼티가 벤더에 특화되어 있으므로 동적 목적지를 생성하는 API는 프로바이더마다 다양하다. 하지만 벤더가 만든 간단한 구현체는 JMS 명세의 경고를 무시하고 TopicSession 메서드 createTopic(String topicName)나 QueueSession 메서드 createQueue(String queueName)를 기본 목적지 프로퍼티로 새로운 목적지를 생성하는데 사용한다. 벤더 구현체에 따라서는 DynamicDestinationResolver가 목적지를 처리하는 것이 아닌 물리적인 목적지를 생성하기도 한다.

불리언 프로퍼티인 pubSubDomain를 JmsTemplate이 어떤 JMS 도메인을 사용하는지 설정하는데 사용한다. 이 프로퍼티의 기본값은 false로 point-to-point 도메인인 Queue를 사용할 것임을 나타낸다. JmsTemplate이 사용하는 이 프로퍼티는 DestinationResolver 인터페이스의 구현체로 동적 목적지 처리의 동작을 결정한다.

defaultDestination 프로퍼티를 사용해서 기본 목적지로 JmsTemplate를 설정할 수도 있다. 기본 목적지는 목적지를 명시하지 않은 보내기/받기 작업에 사용할 것인다.

22.2.4 메시지 리스너 컨테이너

EJB에서 JMS 메시지의 가장 일반적인 경우는 메시지주도 빈(MDB, message-driven beans)를 사용하는 것이다. 스프링은 사용자가 EJB 컨테이너에 의존하지 않는 방법으로 메시지 주도 POJO(MDP, message-driven POJO)를 생성하는 방법을 제공한다. (스프링의 MDP 지원의 자세한 내용은 Section 22.4.2, “비동기 수신 - 메시지 주도 POJO”를 참고해라.)

메시지 리스너 컨테이너는 JMS 메시지 큐에서 메시지를 받고 큐에 주입할 MessageListener를 생성하는데 사용한다. 리스너 컨테이너는 메시지 접수와 처리할 리스너로 디스패치하는 모든 스레드를 책임진다. 메시지 리스너 컨테이너는 MDP와 메시지 프로바이더 사이의 중개자의 역할을 하고 받은 메시지의 등록, 트랙잭셤 참여, 리소스 획득과 릴리즈, 예외 변환등을 담당한다. 이를 통해서 어플리케이션 개발자는 메시지를 받는(그리고 응답을 해야할 수도 있다) 비즈니스 로직(복잡할 수도 있다.)을 작석할 수 있고 JMS 인프라스트럭처의 보일러플레이트에 대한 걱정을 프레임워크에 위임할 수 있다.

스프링에는 두개의 표준 JMS 메시지 리스너 컨테이너가 있고 각 컨테이너는 전문화된 기능을 가진다.

22.2.4.1 SimpleMessageListenerContainer

이 메시지 리스너 컨테이너는 두 표준보다 간단하다. 구동할 때 고정된 수의 JSM 세션과 컨슈머를 생성하고 표준 JMS MessageConsumer.setMessageListener() 메서드를 사용해서 리스너를 등록하고 JMS 프로바이더나 리스너 콜백을 실행하도록 한다. 이 컨테이너는 동적으로 런타임 요구사항에 맞출 수 없고 외부에서 관리하는 트랜잭션에 참여할 수는 없다. 호환성을 위해서 독립적인 JMS 명세서에 아주 가깝지만 보통 Java EE의 JMS 제약사항에는 호환되지 않는다.

22.2.4.2 DefaultMessageListenerContainer

이 메시지 리스너 컨테이너는 가장 많이 사용하는 것 중 하나이다. SimpleMessageListenerContainer와는 달리 런타임 요구사항을 동적으로 맞출 수 있고 외부에서 관리하는 트랜잭션에 참여할 수 있다. JtaTransactionManager를 설정한 경우 받는 각각의 메시지를 XA 트랜잭션에 등록하므로 처리할 때 XA 트랜잭션의 장점을 가질 수 있다. 이 리스너 컨테이너는 JMS 프로바이저의 낮은 요구사항과 트랜잭션 참여같은 고급 기능과 Java EE 환경에 호환성 간의 균형을 잘 맞추고 있다.

22.2.5 Transaction management

스프링은 단일 JMS ConnectionFactory의 트랜잭션을 관리하는 JmsTransactionManager를 제공한다. JmsTransactionManager는 Chapter 11, 트랜잭션 관리에서 설명한 스프링이 관리하는 트랜잭션 기능을 JMS 어플리케이션이 사용하도록 한다. JmsTransactionManager는 로컬 리소스 트랜잭션을 수행하고 JMS 연결/세션 쌍을 지정한 ConnectionFactory에서 스레드로 바인딩한다. JmsTemplate는 자동으로 이러한 트랜잭션이 가능한 리소스를 탐지해서 적절하게 리소스상에서 작업을 실행한다.

Java EE 환경에서 ConnectionFactory는 연결과 세션의 풀을 사용하므로 이러한 리소스를 트랜잭션사이에서 효율적으로 재사용한다. 독립적인 환경에서 스프링의 SingleConnectionFactory를 사용하면 공유된 JMS Connection를 사용하게 되고 각 트랜잭션은 자신만의 독립적인 Session을 갖게 된다. 아니면 ActiveMQ의 PooledConnectionFactory 클래스처럼 프로바이더에 특화된 풀링(pooling) 어댑터를 사용하는 것을 고려해 봐라.

JmsTemplate를 JtaTransactionManager나 분산 트랜잭션을 위해서 XA 기능을 가진 JMS ConnectionFactory와 함께 사용할 수도 있다. 이 경우 XA로 잘 설정한 ConnectionFactory같은 JTA 트랜잭션 관리자를 사용해야 한다! (사용하는 Java EE 서버나 JMS 프로바이더의 문서를 참고해라.)

Connection에서 Session을 생성하려고 JMS API를 사용하는 경우 관리하는 트랜잭션 환경과 관리하지 않는 트랜잭션 환경사이에서 코드를 재사용하는 것이 혼란스러울 수 있다. 이는 JMS API가 Session을 생성하는 팩토리 메서드를 딱 하나만 가지고 있고 트랜잭션과 승낙(acknowledgement) 모드에 대한 값을 필요로 하기 때문이다. 관리되는 환경에서는 해당 환경의 트랜잭션 인프라가 이러한 값을 설정하므로 JMS 연결을 감싸는 벤더의 랩퍼는 이러한 값을 무시한다. 관리되지 않는 환경에서 JmsTemplate을 사용하는 경우 sessionTransacted와 sessionAcknowledgeMode 프로퍼티를 사용해서 이러한 값을 지정할 수 있다. PlatformTransactionManager와 JmsTemplate를 같이 사용하는 경우 템플릿은 항상 트랜잭션이 가능한 JMS Session을 가질 것이다.

출처: <https://blog.outsider.ne.kr/985> 

Domain Driven Develop 

도메인 지향 개발 방법론 

국내에 DDD 관련 책을 다양하게 있는 것도 아니고 

에릭 에반스 개발자 분의 책은 정말 어렵다 .. 

번역체 문제 같은 것들이 아니라   내용이 매우 추상적이고   

개발 경험이 적은 나로써는  그 내용들을 받아들이기 매우 어려웠다.

DDD start 라는 최범균 개발자님이 쓰신 책으로 DDD를 다시 읽는데 

역시 소스코드를 직접 보는게 제일 좋은 방법인듯 싶다.

소스코드 품질 관리 측면에서 DDD는 매우 좋은 방법론이다.

단순히 비지니스 로직을 작성하는데

user.changePassword("4321"); 으로 도메인 내부에 로직을 정의하는 것과

user.setPassword("4321") 로  getter setter로 이렇게 정의 하는 것은 

직관적인 내용에서 차이가 있다. 

(비밀번호 변경이라는 로직이 단순히 password 문자열 변경으로 

끝나지 않는다는 것을 고려한다면 

로직은 Service 계층이랑은 관련없는 소스코드들로 가득 채워 질수 도 있다.

사소하다 생각할수 있겠지만 

이러한 사소한 내용들 하나하나가 모여서 소스코드의 품질을 좌우한다

)

DDD 는 실무에서 사용할수 있는가?       

최범균 개발자님께 물어봤다.

내 친구들은 아무도 최범균 개발자님이 누구인지도 모르고 나만 신났다. 

이러니까 내가 아싸지......

내가 느끼는 DDD는 마치 f-32 전투기 같았다.  

최고의성능을 가진 전투기가 주력전투기가 아니다.

 가성비가 좋은 f-15가 주력 전투기가 되듯이

DDD는  이것을 모르고 이해하려고 들지도 않는 개발자들과 같이 협업을 했을때 

나혼자 DDD 한다면 그것은 오히려 소스코드의 통일성을 깰수도 있고

DDD를  모르는 사람 입장에서 그저 getter setter로 작업할수 있는 내용을 

2~3 개의 클래스를 더 만들어서 

더욱 소스코드를 복잡하게 만들었다고 느낄 수있다. 

10명의 개발자중 3명만 그내용을 몰라서  

3명의 작업량이 기존 방식대로 작업을 했을때 낼수있는 생산성에 비해 현저히 떨어진다면 

이것을 과연 우두머리 급들이 좋아 할까?

특히나 국내 SI 업계 처럼 소스코드의 품질을 무시하는 이러한 분위기에서 DDD는 빛좋은 개살구가 아닐까 

현업을하면서 나는 

"아 이렇게 짜면 안되는데 DDD를 써야지 " 라고  불평해서

다른사람들을 귀찮게 하는  불편한 존재가 되지는 않을까

서버를 공부겸 

졸작에 사용할 기반이될 서버를 구축하려한다.

AWS  프리티어 :  

학부생 입장에서 서버 올려둘 곳으로 AWS 보다 좋은곳이 있을까  

----------------------Database -------------------------------------------

RDB  MeriaDB  : 

      서비스에 필요한 정형적인 데이터들 회원정보 , 비지니스 도메인 전반 을 관리 

Nosql (doc타입) MongoDB : 

개발하고자하는 서비스에 채팅이 들어간다 . 채팅로그를 서버에 저장하는데 mongoDB를 사용하려한다.

기타 접속 기록, 서비스 사용 시간 기록 과 같은 로그 데이터도 NoSQL로 관리하려한다.

토큰저장 DB (key Value 타입)  Redis:

memoryDB로 사용할것이다 서버를 Rest하게 구성할것이고 

인증서버에서 access_token을 저장해놓은 db가 필요하다 

Redis는 AWS 에서 서비스 제공을 안해주기때문에 WAS 올려둘 인스턴스에 같이 올려두려고 한다.

실 서비스를 하려한다면 이것저것 물리적으로 분리되어야 하겠지만(auth서버 ) 

-----------------------------------------------------------------------------------

-------------------------------Web Application Server----------------

   Spring Framework   4.3.xx    :  이번에 ver 5가 나왔는데 졸업작품이 내년까지 진행되니 버젼을 5.xx 로 올려보고 한번 사용해볼수 있지 않을까 라는 기대와 의지가 있다.

java 1.8  : 람다식과 스트림문법를 공부하고 실제 짜보는 것을 목적으로 버젼 을 선택함   

JPA+Hibernate  :  ORM으로 역시 자바 표준이 무난하다 이에 대해 이의가 없다.

Mybatis (Sql Mapper 프레임 워크) :  jpa와 mybatis를 동시에 쓰고자함은 두마리 토끼

를 이번에 좀더 숙련도를 올려보고자함이다.

mybatis를 무시하는 경향이 있었는데 심익찬 개발자님을 만나고 생각이 많이 바뀌었다.

Netty :  2017 스프링 캠프에서 본 새로운 기술들의 핵심 키워드는 NIO였다

네트워크 프레임워크인 네티도 한번 만져보고싶고 ....

이건좀 내 무리한 욕심이 아닐까 싶다..

기타 :

lombok  :  실무 하시는 분들은 롬북에 굉장히 회의적인 입장을 보이셨다. 

일단 JPA 에서도 무한 루프 같은 자잘한 문제 땜시 별로 안좋아 하는것같지만

편.하니까 일단 쓴다

Swagger2 :  그냥 설정만 잡으니까 이렇게 편하게  api를 문서화 해준다니 완전 개꿀~

Node.js : 졸작은 어플로 클라이언트를 구축할것이지만 웹으로도 어느정도 필요할수             있다. 

굳이 Rest하게 잘갗춰놓은 두고 새로 서버를 만들이유는 없겠지만 

공부겸 한번 사용해볼 기회가 있었으면 좋겠다