[8주차](권용현, 임주민, 이세원) #12
Comments
스프링이란 무엇인가?스프링에 대해 가장 잘 알려진 정의는 다음과 같다.자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션 프레임워크
애플리케이션 프레임워크는 애플리케이션 개발의 전 과정을 빠르고 편리하며 효율적으로 진행하는 것을 목표로 가진, 특정 계층이나 기술, 업무 분야에 국한되지 않고 애플리케이션의 전 영역을 포괄하는 범용적인 프레임워크를 말한다.
스프링이 가볍다고 하는 이유는 불필요하게 무겁지 않다는 의미다. 이러한 표현은 예전의 EJB 같은 과도한 엔지니어링이 적용된 기술과 스프링을 대비시켜 설명하려고 사용했던 표현이다.
스프링은 근본적인 부분에서 엔터프라이즈 개발의 복잡함을 제거해내고 진정으로 개발을 편하게 해주는 해결책을 제시한다.
여러가지 장점을 가지고 있는 것이 오픈소스 방식이지만 언제 지원이 중단될지 알 수 없다는 단점이 있습니다. 스프링의 목적엔터프라이즈 개발이 복잡한 이유?
전통적인 자바 엔터프라이즈 개발 기법은 대부분 비즈니스 로직의 복잡한 구현 코드와 엔터프라이즈 서비스를 이용하는 기술적인 코드가 자꾸 혼재될 수 밖에 없는 방식이었다. 결국 개발자가 동시에 그 두 가지를 모두 신경 써서 개발해야 하는 과도한 부담을 줬고, 그에 따라 전체적인 복잡함은 몇 배로 가중됐다. 복잡함을 해결하려는 도전
기술적인 복잡함을 분리해서 생각하면 그것을 효과적으로 상대할 수 있는 전략을 발견할 수 있다. 스프링은 엔터프라이즈 기술을 적용했을 때 발생하는 복잡함의 문제를 두 가지로 분류하고 각각에 대한 적절한 대응 방법을 제공한다. 첫번째 문제: 기술에 대한 접근 방식이 일관성이 없고, 특정 환경에 종속적이다. 서비스 추상화를 이용. 기술적인 복잡함은 일단 추상화를 통해 로우레벨의 기술 구현 부분과 기술을 사용하는 인터페이스를 분리하고, 환경과 세부기술에 독립적인 접근 인터페이스를 제공하는 것이 가장 좋은 해결책이다. 두번째 문제: 기술적인 처리를 담당하는 코드가 성격이 다른 코드에 섞여서 등장한다. AOP 이용. AOP는 최후까지 애플리케이션 로직을 담당하는 코드에 남아 있는 기술 관련 코드를 깔끔하게 분리해서 별도의 모듈로 관리하게 해주는 강력한 기술이다.
지금까지 보았듯이 기술적인 복잡함을 효과적으로 다루게 해주는 기법은 모두 DI를 바탕으로 하고 있다. 그리고 DI는 객체지향 설계 기술 없이는 그 존재의미가 없다. 스프링은 단지 그것을 더욱 편하고 쉽게 사용하도록 도와줄 뿐이다. POJO 프로그래밍스프링 핵심 개발자들은 "스프링의 정수"는 "엔프라이즈 서비스 기능을 POJO 에 제공하는 것"이라고 했다. 엔터프라이즈 서비스라고 하는 것은 보안, 트랜잭션과 같은 엔터프라이즈 시스템에서 요구되는 기술을 말한다. 이런 기술을 POJO에 제공한다는 말은, 뒤집어 생각해보면 엔터프라이즈 서비스 기술과 POJO라는 애플리케이션 로직을 담은 코드를 분리했다는 뜻이기도 하다. '분리됐지만 반드시 필요한 엔터프라이즈 서비스 기술을 POJO 방식으로 개발된 애플리케이션 핵심 로직을 담은 코드에 제공한다'는 것이 스프링의 가장 강력한 특징과 목표다. 스프링의 핵심: POJO스프링 애플리케이션은 POJO를 이용해서 만든 애플리케이션 코드와, POJO 가 어떻게 관계를 맺고 동작하는지를 정의해놓은 설계정보로 구분된다. DI의 기본 아이디어는 유연하게 확장 가능한 오브젝트를 만들어두고 그 관계는 외부에서 다이내믹하게 설정해준다는 것이다. 스프링의 주요 기술인 IoC/DI, AOP, 서비스 추상화는 애플리케이션을 POJO로 개발할 수 있게 해주는 가능기술이라고 불린다. POJO의 조건
POJO의 장점 특정한 기술과 환경에 종속되지 않게 되므로 깔끔한 코드가 될 수 있다. POJO 프레임워크 기술영역에만 관여하고 비즈니스 로직을 담당하는 POJO에서는 모습을 감춘다. 데이터 액세스 로직이나 웹 UI 로직을 다룰 때만 최소한의 방법으로 관여한다. POJO 프레임워크로서 스프링은 자신을 직접 노출하지 않으면서 애플리케이션을 POJO로 쉽게 개발할 수 있게 지원해준다. 스프링의 기술
DI 활용 방법
AOP
PSA PSA는 환경과 세부 기술의 변화에 관계없이 일관된 방식으로 기술에 접근 할 수 있게 해준다.POJO로 개발된 코드는 특정 환경이나 구현 방식에 종속적이지 않아야 한다. 스프링은 JavaEE를 기존 플랫폼으로 하는 자바 엔터프라이즈 개발에 주로 사용된다. 따라서 다양한 JavaEE 기술에 의존적일 수밖에 없다 .특정 환경과 기술에 종속적이지 않다는 게 그런 기술을 사용하지 않는다는 뜻은 아니다. 다만 POJO 코드가 그런 기술에 직접 노출되어 만들어지지 않는다는 말이다. 이를 위해 스프링이 제공하는 대표적인 기술이 바로 일관성 있는 서비스 추상화 기술이다. |
9장 스프링 프로젝트 시작하기목표 : 애플리케이션 프로젝트를 처음 구성할 때 알아야할 기본적인 내용, 개발에 도움되는 개발 툴과 빌드 방법, 스프링을 애플리케이션에 적용할 수 있는 아키텍처의 종류와 특징 알아보기 자바 엔터프라이즈 플랫폼과 스프링 애플리케이션스프링으로 만들 수 있는 애플리케이션의 종류에는 제한이 X 자바 언어를 사용하는 모든 종류의 프로젝트라면 어디든 사용 가능 스프링은 주로 자바 엔터프라이즈 환경에서 동작하는 애플리케이션을 개발하는 목적으로 사용됨 자바 엔터프라이즈 애플리케이션은 클라이언트의 요청을 받아 그에 대한 작업 수행 후 결과를 돌려주는 것이 기본 동작 방식이나 클라이언트 요청 없이도 정해진 시간이나 특정 이벤트 발생에 따라 독자적으로 작업 수행하기도함 - 클라이언트와 백엔드 시스템'DB를 사용하는 웹 애플리케이션' 구조 : 클라이언트가 웹 브라우저이고 백엔드 시스템이 DB인 구성 클라이언트 : 웹 브라우저, RIA(Rich Internet Application), HTTP 이용해 통신하는 엔터프라이즈 시스템, .NET 애플리케이션 백엔드 시스템 : DB, 메시징 서버, 메일 서버, 메인 프레임, 웹 서비스를 제공하는 서버, 원격 EJB 서버 한 번에 여러 종류의 백엔드 시스템 이용 가능, 여러 개의 DB를 동시에 이용하는 것도 가능 - 애플리케이션 서버스프링으로 만든 애플리케이션을 자바 서버 환경에 배포하려면 JavaEE 표준 따르는 애플리케이션 서버
1) 경량급 WAS/서블릿 컨테이너 톰캣, 제티 같은 가벼운 서블릿 컨테이너만 있어도 핵심기능 모두 이용하기에 충분 기존에 EJB나 WAS를 사용해야 가능했던 선언적인 트랜잭션이나 선언적 보안, DB 연결 풀링, 리모팅, 웹서비스 가능 추가적인 라이브러리 도움 받으면 분산/글로벌 트랜잭션까지 가능 2) WAS 고가의 WAS를 사용할 때의 장점 : 고도의 안정성, 안정적인 리소스 관리, 레거시 시스템의 연동 가능, 관리 기능이나 모니터링 기능이 뛰어나 여러 대의 서버를 동시에 운영할 때 유리 자바 엔터프라이즈 버전(JavaEE) 표준을 최대한 활용할 수 있음 대개는 서블릿 컨테이너로도 충분하기에 무겁고 다루기 힘들고 비싼 WAS를 사용할 때에는 분명한 이유를 가지고 사용하길 권장 스프링소스 tcServer 톰캣을 기반으로 엔터프라이즈 스프링 애플리케이션에 최적화된 경량급 애플리케이션 서버 기존 톰캣에서는 아쉬웠던 고급 서버 관리 기능, 배포 기능과 진단 기능을 포함해 톰캣 전문가에게 받는 기술지원 제공받기 가능 스프링 애플리케이션 개발과 운영에 꼭 필요한 중요한 기능이 많이 제공됨 👉언제 사용? - 스프링애플리케이션의 배포 단위스프링으로 만든 애플리케이션은 다음의 세 가지 단위로 배포 1) 독립 웹 모듈 가장 단순하고 편리한 배포 단위 보통 war로 패키징된 독립 웹 모듈로 배포 서블릿 컨테이너(톰캣) 사용 시 독립 웹 모듈이 유일한 방법이며 WAS 사용해도 대부분 이 방법 2) 엔터프라이즈 애플리케이션 확장자가 하나 이상의 웹 모듈과 별도로 분리된 공유 가능한 스프링 컨텍스트를 엔터프라이즈 애플리케이션으로 묶어주는 방식 3) 백그라운드 서비스 모듈 J2EE 1.4에서 등장한 rar 패키징 방법
운영 플랫폼이나 서버의 종류는 개발 중에도 변경 가능 (설정만 바꾸면 이전이 가능) 특정 서버 환경에서만 제공하는 기능 사용하면 변경 어려움 👉 서버의 기능에 종속되지 않도록 주의하거나 쉽게 다른 서버 기능으로 변경 가능하도록 추상화해서 사용하기 개발도구와 환경- JavaSE와 JavaEEJavaSE/JDK
JavaEE/J2EE
- IDE(통합 개발 환경)자바 5 이상의 언어를 지원하는 자바 개발도구와 스키마를 지원하는 XML 편집기 정도만 있다면 어떤 개발환경에서든 개발 가능 IDE 사용하면 개발 툴을 떠나지 않고도 개발 과정에서 필요한 모든 일 처리 가능 ex)
 - 라이브러리 관리와 빌드 툴필요한 프레임워크 모듈과 라이브러리 파일을 선택해서 프로젝트의 빌드 패스에 넣어주는 일이 어려움 라이브러리 관리의 어려움
라이브러리 의존관계 관리의 가장 큰 난제 같은 라이브러리의 두 가지 버전이 존재하는 애플리케이션의 의존관계가 있을 때, 이름이 같지만 구현이 다른 클래스가 있다면 이에 의존하고 있는 라이브러리 중 하나는 비정상적으로 동작함
재패키징 한쪽 버전의 클래스를 다른 패키지로 옮겨서 서로 구별되는 클래스로 만들어주는 방법 이에 의존하는 라이브러리의 코드도 변경된 패키지 내의 클래스를 사용하도록 수정 필요 모든 소스와 코드를 찾아서 수정해주는 작업이라서, 재패키징을 지원해주는 툴 존재 -> 빌드 툴이 지원하는 의존 라이브러리 관리 기능 자바의 대표적 빌드 툴 : IDE 사용 시 자동 빌드 가능 IDE 사용할 수 없는 환경(서버 배치했을 때나 통합 테스트 환경에서 애플리케이션 직접 빌드할 경우) 일관된 빌드가(IDE에서와 동일하게 애플리케이션 빌드 작업 수행) 가능하도록 만들어야함 👉 자동 빌드 기능 지원하는 IDE 이용하면서 Maven 👉 장점 : 수십 메가에 달하는 라이브러리를 프로젝트 안에 포함시켜 소스코드와 관리하면 부담되는데, Maven 사용시 POM을 통해 의존 라이브러리 정보만 갖게 하고 필요한 라이브러리는 빌드 과정 중에 자동 다운 받거나 로컬 공통 리포지토리에서 가져오게 하면 프로젝트 파일 크기 줄어들고 코드 관리 단순해짐 전이적 의존관계 추적 기능에 의해 해당 그룹의 모든 라이브러리가 프로젝트에 자동으로 등록 애플리케이션 아키텍쳐시스템 레벨의 아키텍처(클라이언트와 백엔드 시스템의 종류와 기술, 연동 방법) 결정 후에는 스프링 웹 애플리케이션의 아키텍처 결정 필요 응집도 높이고 결합도 낮추기 위해 인터페이스 사용 - 계층형 아키텍처책임과 성격이 다른 것을 크게 그룹으로 만들어 분리해두는 것을 아키텍처 차원에서 보통 웹 기반 엔터프라이즈 애플리케이션은 일반적으로 3개의 계층을 가져서 3계층 아키텍처와 수직 계층 1) 데이터 액세스 계층 (DAO 계층, EIS 계층) : 백엔드의 DB나 레거시 시스템과 연동하는 인터페이스 역할 DAO 패턴 보편적으로 사용 ERP, 레거시 시스템, 메인프레임 등에 접근하기 때문에 EIS(Enterprise Information System)계층이라고 함 사용 기술에 따라 다시 세분화된 수직적인 계층으로 구분함 (추상화 레벨 높) DAO코드 - JdbcTemplate - JDBC/트랜잭션동기화 - DataSource (추상화 레벨 낮) 2) 서비스 계층 : 비즈니스 로직 이상적인 POJO로 작성 DAO 계층을 호출하고 이를 활용해서 만들어짐 서비스 계층 코드가 기반 서비스 계층(트랜잭션, 보안, 리모팅, 메일, 스케줄링 등)의 구현에 종속되면 안됨 서비스 계층의 코드는 추상화된 기반 서비스 인터페이스를 통해서만 접근하도록 만들기 서비스 계층은 백엔드 시스템과 연결되는 데이터 액세스 계층이 바뀌고 클라이언트와 연결되는 프레젠테이션 계층이 모두 바뀌어도 그대로 유지될 수 있어야 함 3) 프레젠테이션 계층 : UI 만들어내고 흐름 관리 매우 다양한 기술과 프레임워크의 조합이 가능 클라이언트의 종류와 상관없이 HTTP 프로토콜을 사용하는 서블릿이 바탕이 됨 계층형 아키텍처 설계의 원칙 각 계층은 응집도가 높으면서 다른 계층과는 낮은 결합도를 유지할 수 있어야 함 각 계층은 자신의 계층의 책임에만 충실해야 함 각 계층은 자신과 관련된 기술이 아닌 다른 기술 API 사용 삼가 - 애플리케이션 정보 아키텍처사용자의 작업 상태를 오래 유지할 수 있는 독립 애플리케이션과 달리 엔터프라이즈 애플리케이션은 일반적응로 사용자의 요청을 처리하는 동안만 간단한 상태를 유지 애플리케이션의 주요 상태정보는 클라이언트나 백엔드 시스템에 분산돼서 보관됨 (장기 보관 정보는 DB나 메인프레임 같은 EIS 백엔드 시스템에 저장되고, 임시 정보는 클라이언트나 세션 메모리에 저장) 애플리케이션을 사이에 두고 정보를 어떤 식으로 다룰지 결정하는 일이 중요 데이터 중심 아키텍처 엔터프라이즈 애플리케이션에 존재하는 정보를 단순히 값이나 값을 담기 위한 목적의 오브젝트 형태로 다루는 경우 DB나 백엔드에서 가져온 정보를 값으로 다루고 그 값을 취급하는 코드 만들어 로직 구현하고 값을 그대로 프레젠테이션 계층의 뷰와 연결해주는 것 핵심 비즈니스 로직을 어디에 많이 두는지에 따라 DB에 무게를 두는 구조와 서비스 계층의 코드에 무게를 두는 구조로 구분 가능 하나의 업무 트랜잭션에 모든 계층의 코드가 종속되는 경향이 있음 거대한 서비스 계층 방식 DB에 많은 로직을 두는 개발 방법의 단점(안정성 떨어지고 코드 검증하기 힘들고 확장성 떨어짐)을 피하면서 애플리케이션 코드의 비중을 높이는 방법 DB에는 부하가 걸리지 않도록 저장 프로시저의 사용을 자제하고 복잡한 SQL을 피하면서, 주요 로직은 서비스 계층의 코드에서 처리하도록 만듬 많은 비즈니스 로직을 DB의 저장 프로시저나 SQL에서 서비스 계층의 오브젝트로 옮김으로써 애플리케이션 코드의 비중이 커짐 -> 구조 단순해지고 객체지향적임 - 오브젝트 중심 아키텍처오브젝트를 만들어두고 오브젝트 구조 안에 정보를 담아서 각 계층 사이에 전달하게 만드는 것 데이터 중심 아키텍처와 다른 특징은 도메인 모델을 반영하는 오브젝트 구조를 만들어두고 그것을 각 계층 사이에서 정보를 전송하는데 사용한다는 것 객체지향 분석과 모델링의 결과로 나오는 도메인 모델을 오브젝트 모델로 활용 오브젝트 구조로 정보 갖고 있으면 어떤 식으로든 활용하기 편리 데이터와 오브젝트 방식 비교 데이터 중심의 아키텍처에서는 DAO가 만드는 SQL 결과에 모든 계층의 코드가 의존하게 됨 오브젝트 방식에서는 애플리케이션에서 사용되는 정보가 도메인 모델의 구조를 반영해서 만들어진 오브젝트 안에 담기고 도메인 모델은 애플리케이션 전 계층에서 동일한 의미를 가짐 도메인 오브젝트 사용의 문제점 최적화된 SQL을 매번 만들어 사용하는 경우에 비해 성능 면에서 조금은 손해 DAO는 비즈니스 로직의 사용 방식을 알지 못하므로, 도메인 오브젝트의 모든 필드 값을 다 채워서 전달하는 경우가 대부분인데 하나의 오브젝트에 담긴 필드의 개수가 많아지다 보면 그중에는 드물게 사용되는 필드도 있을 수 있음 -> 낭비 하나의 정보만 필요한 비즈니스 로직에서 오브젝트 하나를 다 가져오는 경우 필요없는 정보도 다 가져오기 때문에 낭비 최적화 방법 지연된 로딩 기법 : 일단 최소한의 오브젝트 정보만 읽어두고 관계하고 있는 오브젝트가 필요한 경우에만 다이내믹하게 DB에서 다시 읽어옴 데이터 액세스 기술 활용 : JPA, JDO, 하이버네이트, TopLinK와 같은 오브젝트/RDB 매핑 기술(ORM)은 기본적으로 지연된 로딩 기법 제공해주고, 많이 사용하는 테이블은 ORM이 제공해주는 오브젝트 캐시에 넣어 활용 가능 👉 빈약한 도메인 오브젝트 방식 오브젝트 중심 아키텍처는 오브젝트의 활용 방법을 기준으로 구분 가능 빈약한 오브젝트 : 도메인 오브젝트에 정보만 담겨있고 활용하는 아무런 기능도 갖고 있지 않을 때 비즈니스 로직은 서비스 계층에 담김 -> 거대 서비스 계층 구조와 유사 풍성(영리)한 도메인 오브젝트 방식 특정 도메인 오브젝트나 관련 오브젝트가 가진 정보와 깊은 관계가 있는 비즈니스 로직을 서비스 계층의 코드가 아니라 도메인 오브젝트에 넣어주고, 서비스 계층의 비즈니스 로직에서 재사용하게 만듬 도메인 오브젝트의 객체지향적인 특징을 잘 활용하였고 코드 간결 *도메인 오브젝트는 스프링 컨테이너가 관리하는 즉 빈이 아니기 때문에 DAO 오브젝트를 DI 받을 수 없음 도메인 계층의 역할과 비중을 극대화하려다 보면 기존의 풍성한 도메인 오브젝트 방식으로는 부족 도메인 계층 방식 도메인 오브젝트가 기존 3계층과 같은 레벨로 격상되어 하나의 계층을 이루게 하는 방식 도메인 오브젝트들이 하나의 독립적인 계층을 이뤄서 서비스 계층과 데이터 액세스 계층의 사이에 존재하게 하는 것이 개념 달라지는 특징 두가지
- 스프링 애플리케이션을 위한 아키텍처 설계3단계로 분리하는 계층형 아키텍처와 정보를 다루는 방법에 따른 아키텍처 정보를 위에서 알아봄. 계층구조를 어떻게 나눌 것인가와 애플리케이션 정보를 어떻게 다룰지를 결정하는 것이 기본, 그 위에 각 계층에 사용될 구체적인 기술의 종류와 수직 추상화 계층의 도입, 세세한 기술적인 조건을 결정하는 일 필요 상태 관리와 빈 스코프 아키텍처 설계에서 신경 써야 할 사항은 서버의 자원이 특정 사용자에게 일정하게 할당되지 않아 지속적으로 유지되는 상태를 갖지 X 스프링은 기본적으로 상태가 유지되지 않는 빈과 오브젝트를 사용하는 것을 권장 상태는 클라이언트, 백엔드에 저장하거나 세션 정도에 일시적으로 저장하는 것이 대부분 장기간 유지되며 중첩될 수 있는 상태 정보는 고급 상태 관리 기법 이용 '스프링이 지원하는 기술'의 의미 스프링은 거의 대부분의 자바 표준 기술과 함께 사용 가능
👉 스프링이 지지하는 개발철학과 프로그래밍 모델을 따라 해당 기술을 사용할 수 있다는 의미 |
📚7.5 ~ 7.7장 정리7.5 DI를 이용해 다양한 구현 방법 적용하기
ConcurrentHashMap 사용하기
private Map<String, String> sqlMap = new HashMap<String, String>();내장형 데이터베이스 이용한 sql 레지스트리 만들기
스프링의 내장형 DB 지원
new EmbeddedDatabaseBuilder()
.setType(내장형DB종류)
.addScript(초기화에 사용할 DB 스크립트의 리소스)
...
.build()
내장형 DB를 이용한 SqlRegistry 만들기
public class EmbeddedDbSqlRegistry implements UpdatableSqlRegistry {
private JdbcTemplate jdbcTemplate;
public void setDataSource(DataSource dataSource) {
jdbcTemplate = new JdbcTemplate(dataSource);
}
...트랜잭션 적용
public class EmbeddedDbSqlRegistry implements UpdatableSqlRegistry {
private JdbcTemplate jdbcTemplate;
private TransactionTemplate transactionTemplate;
public void setDataSource(DataSource dataSource) {
jdbcTemplate = new JdbcTemplate(dataSource);
transactionTemplate = new TransactionTemplate(new DataSourceTransactionManager(dataSource));
}
...
public class EmbeddedDbSqlRegistry implements UpdateSqlRegistry {
SimpleJdbcTemplate jdbc;
TransactionTemplate transactionTemplate;
public void setDataSource(DataSource dataSource) {
jdbc = new SimpleJdbcTemplate(dataSource);
transactionTemplate = new TransactionTemplate(
new DataSourceTransactionManager(dataSource));
// DataSource의 setter 내에서 트랜잭션 템플릿도 트랜잭션 매니저를 생성하면서 DataSource를 받아준다.
}
public void updateSql(final Map<String, String> sqlmap) throws SqlUpdateFailureException {
transactionTemplate.execute(new TransactionCallbackWithoutResult() {
protected void doInTransactionWithoutResult(TransactionStatus status) {
//트랜잭션을 적용해야 하는 updateSql()에서는 execute()를 하고
//템플릿 / 콜백 패턴을 활용하여 sqlmap의 쿼리들을 수정하는 작업을 트랜잭션 내에서 진행하도록 해준다.
for (Map.Entry<String, String> entry : sqlmap.entrySet()) {
updateSql(entry.getKey(), entry.getValue());
}
}
});
}
}
7.6. 스프링 3.1의 DI
애노테이션의 메타정보 활용
정책과 관례를 이용한 프로그래밍
7.6.1~xml을 애노테이션과 자바코드로 대체하기@configuration
@Configuration
public class TestApplicationContext {
...
}@bean
...
@Bean
public MailSender mailSender() {
return new DummyMailSender();
}@Autowired
@Autowired
public void setDataSource(DataSource dataSource) {
this.jdbcTemplate = new JdbcTemplate(dataSource);
}@component
@Component
public class UserDaoJdbc implements UserDao {
...
}메타 애노테이션
@Component
public @interface SnsConnector{
...
}
@componentscan
@ComponentScan(basePackages="springbook.user")
public class TestApplicationContext {
...
}@import (컨텍스트 분리)
@Import(SqlServiceContext.class)
public class AppContext { ... }@Profile, @ActiceProfiles
@Profile("test")
public class TestAppContext { ... }
@ActiveProfile("test")
public class UserServiceTest { ... }
@enable*
@Import(value=SqlServiceContext.class)
public @interface EnableSqlService { ... }
@Import(TransactionManagementConfigurationSelector.class)
public @interface EnableTransactionManagement { ... }
@EnableSqlService
public class AppContext implements SqlMapConfig { ... } |
The text was updated successfully, but these errors were encountered: