[SPRING] 사용자 정의 스프링 범위?

사용자 정의 스프링 범위?

Servlet Context Scope와 ThreadScope보다 다른 커스텀 스프링 스코프를 아는 사람은 누구입니까?

폐쇄 형 소스 사용자 정의 범위를 만든 경우에는 실제로 수행 할 작업과 작동 방식을 청취하는데도 관심을 가질 것입니다. (누군가 데스크톱 애플리케이션에서 WindowScope를 만들 것이라고 생각합니까?)

나는 모든 유스 케이스에 개방적이며, 여기에 나의 지평을 넓히고 싶다.

해결법

1. ==============================

   1.우리는 우리 자신의 커스텀 Spring scope를 구현했다. 많은 코드는 데이터베이스에 가깝고 상대적으로 낮은 수준에서 작동하며 데이터 소스, 링크, 속성 등의 자체 객체 모델을 사용하여 개념 수준을 유지합니다.

   우리는 우리 자신의 커스텀 Spring scope를 구현했다. 많은 코드는 데이터베이스에 가깝고 상대적으로 낮은 수준에서 작동하며 데이터 소스, 링크, 속성 등의 자체 객체 모델을 사용하여 개념 수준을 유지합니다.

   어쨌든 많은 bean은 소위 StorageDictionary (이 객체 그래프의 캡슐화)가 필요합니다. 객체 그래프를 변경하지 않을 때 사전을 날려 버리고 재 작성해야하는 경우가 있습니다. 결과적으로 사전 범위가 지정된 개체의 사용자 지정 범위를 구현했으며 지정된 사전의 무효화 부분은이 사용자 지정 범위를 지우는 작업을 포함합니다. 이를 통해 Spring은 이러한 객체에 대한 자동 캐싱의 멋진 형태를 처리 할 수 ​​있습니다. 사전이 무효화 될 때까지 매번 동일한 객체를 가져옵니다.이 시점에서 새 객체를 얻습니다.

   이는 일관성을 유지할뿐만 아니라 오브젝트 자체가 사전에있는 엔티티에 대한 참조를 캐시 할 수있게 해줍니다. 캐시가 스프링에 의해 검색 될 수있는 한 캐시가 유효하다는 지식 내에서 안전합니다. 이것은 차례대로 우리가 이들을 불변의 객체로 만들 수있게합니다 (생성자 주입을 통해 유선이 될 수있는 한). 가능한 한 언제나 그렇게하는 것이 매우 좋은 방법입니다.

   이 기술은 모든 곳에서 작동하지 않으며 소프트웨어의 특성에 크게 의존합니다 (예 : 사전이 정기적으로 수정 된 경우 이는 매우 비효율적이며 업데이트 된 적이없는 경우 절대 필요하지 않으며 직접 액세스보다 약간 효율적입니다). 그러나 개념적으로 직접적이고 내 의견으로는 꽤 우아한 방식으로 Spring에 대한 라이프 사이클 관리를 전달하는 데 확실히 도움이되었습니다.

2. ==============================

   2.우리 회사에서는 두 개의 사용자 지정 범위를 만들었습니다. 하나는 스레드 또는 요청을 사용하고 다른 하나는 스레드 또는 세션을 사용합니다. 단일 실행 범위는 실행 환경 (JUnit 또는 Servlet 컨테이너)을 기반으로 구성을 변경하지 않고 범위가 지정된 bean에 사용될 수 있다는 개념입니다. 이것은 또한 Quartz에서 아이템을 실행하고 더 이상 Request 또는 Session 스코프를 사용할 수없는 경우에 유용합니다.

   우리 회사에서는 두 개의 사용자 지정 범위를 만들었습니다. 하나는 스레드 또는 요청을 사용하고 다른 하나는 스레드 또는 세션을 사용합니다. 단일 실행 범위는 실행 환경 (JUnit 또는 Servlet 컨테이너)을 기반으로 구성을 변경하지 않고 범위가 지정된 bean에 사용될 수 있다는 개념입니다. 이것은 또한 Quartz에서 아이템을 실행하고 더 이상 Request 또는 Session 스코프를 사용할 수없는 경우에 유용합니다.

3. ==============================

   3.배경:

   배경:

   동일한 서블릿 컨텍스트에서 4 개의 다른 웹 사이트를 실행하는 단일 웹 응용 프로그램에서 작업합니다. 각 사이트에는 자체 도메인 이름이 있습니다 (예 : www.examplesite1.com, www.examplesite2.com 등

   문제:

   사이트는 때때로 앱 컨텍스트 (일반적으로 사용자 정의 된 메시지 표시 또는 객체 형식 지정)를 위해 사용자 정의 된 빈 인스턴스를 필요로합니다.

   예를 들어, 사이트 1과 2 모두 "standardDateFormatter"bean을 사용하고 사이트 3은 "usDateFormatter"bean을 사용하고 사이트 4는 "ukDateFormatter"bean을 사용한다고 가정하십시오.

   해결책:

   "사이트"범위를 사용할 계획입니다.

   우리는 다음과 같은 사이트 enum을 가지고 있습니다 :

   enum Site {
       SITE1, SITE2, SITE3, SITE4;
   }
   

   그런 다음 ThreadLocal을 사용하여 요청의 스레드에 이러한 사이트 값 중 하나를 저장하는 필터가 있습니다. 이것은 사이트 범위의 "대화 ID"입니다.

   그런 다음 응용 프로그램 컨텍스트에서 "scope ="site " '인"dateFormatter "라는 bean이 있습니다. 그런 다음 날짜 포맷터를 사용하려는 곳이면 사용자의 현재 사이트에 맞는 올바른 형식이 사용됩니다.

   나중에 추가됨 :

   샘플 코드는 다음과 같습니다.

   http://github.com/eliotsykes/spring-site-scope

4. ==============================

   4.Oracle Coherence는 스프링 빈에 대한 DataGrid 범위를 구현했습니다. 그것을 요 ​​약하기:

   Oracle Coherence는 스프링 빈에 대한 DataGrid 범위를 구현했습니다. 그것을 요 ​​약하기:

   나 자신을 사용한 적은 없지만 멋지게 보입니다.

5. ==============================

   5.Apache Orchestra는 SpringConversationScope를 제공합니다.

   Apache Orchestra는 SpringConversationScope를 제공합니다.

6. ==============================

   6.웹 응용 프로그램에서 사용자의 로켈을 기반으로하는 스프링 로캘 범위

   웹 응용 프로그램에서 사용자의 로켈을 기반으로하는 스프링 로캘 범위

   관련 위키 페이지보기

7. ==============================

   7.우리 회사에서는 스프링 맞춤 범위를 구현했습니다. 우리는 모든 고객이 설정을 사용자 정의 할 수있는 멀티 테넌트 시스템을 보유하고 있습니다. 우리의 인스턴스 기반 범위는 고객 고유의 빈을 캐시합니다. 따라서 고객의 사용자가 로그인 할 때마다 동일한 고객의 다른 사용자가 로그인 할 때이 설정이 캐시되고 다시 사용됩니다.

   우리 회사에서는 스프링 맞춤 범위를 구현했습니다. 우리는 모든 고객이 설정을 사용자 정의 할 수있는 멀티 테넌트 시스템을 보유하고 있습니다. 우리의 인스턴스 기반 범위는 고객 고유의 빈을 캐시합니다. 따라서 고객의 사용자가 로그인 할 때마다 동일한 고객의 다른 사용자가 로그인 할 때이 설정이 캐시되고 다시 사용됩니다.

8. ==============================

   8.Spring Batch 응용 프로그램에서는 항목 범위를 구현했습니다.

   Spring Batch 응용 프로그램에서는 항목 범위를 구현했습니다.

   현재 일괄 처리 항목을 기반으로 무언가를 계산하는 @Service 구성 요소가 많이 있습니다. 이들 중 많은 사람들이 동일한 워크 플로가 필요합니다.

   워크 플로우를 기본 클래스 템플릿 메소드로 옮겼습니다. 따라서 하위 클래스는 findItemParts (Item) (1과 2) 및 computeSomething (ItemPart) (3을 수행) 만 구현합니다. 따라서 상태가 바뀌 었습니다 (findItemParts에서 초기화 된 항목이 computeSomething에 필요합니다). 그리고 그 상태는 다음 항목보다 먼저 지워 져야합니다.

   이러한 서비스 중 일부는 또한 현재 항목에서 파생 된 이후 나중에 제거해야하는 삽입 된 스프링 빈을 포함합니다.

   우리는 항목을 등록하고 하위 클래스가 파생 된 bean을 등록 할 수있게하는 AbstractScopeRegisteringItemProcessor를 구현했습니다. 프로세스 메서드가 끝나면 범위 컨텍스트에서 항목을 제거하고 DefaultSingletonBeanRegistry.destroySingleton을 사용하여 파생 된 Bean을 제거합니다.

   작동하지만 다음과 같은 문제점이 있습니다.

   @Eliot Sykes의 솔루션과 공유 코드와 @ Cheetah의 BeanDefinition 등록을 통해 싱글 톤으로 등록을 제거 할 수있었습니다. 대신 ItemScopeContext (프로세서와 Scope 구현에 사용되는 저장소, 정적 @Bean 메서드를 통해 Java로 구성된 저장소)는 BeanDefinitionRegistryPostProcessor를 구현합니다. getObject ()가 현재 항목을 리턴하는 FactoryBean을 등록하거나, 존재하지 않으면 예외를 던집니다. 이제 @Scope (scopeName = "Item", proxyMode = ScopedProxyMode.TARGET_CLASS) 주석이 붙은 @Component는 단순히 항목을 삽입 할 수 있으며 범위 끝내기 정리에 등록 할 필요가 없습니다.

   결국 결국 효과가있었습니다.

9. ==============================

   9.한 번 일종의 대화 범위를 사용하여 세션 범위에 개체를 저장하여 동일한 페이지를 다시 입력 할 때 개체를 유지하지만 세션에서 쓸모없는 개체를 남기지 않도록 단일 페이지로 제한했습니다. 구현은 방금 페이지 URL을 저장하고 각 페이지 변경시 대화 범위를 지 웠습니다.

   한 번 일종의 대화 범위를 사용하여 세션 범위에 개체를 저장하여 동일한 페이지를 다시 입력 할 때 개체를 유지하지만 세션에서 쓸모없는 개체를 남기지 않도록 단일 페이지로 제한했습니다. 구현은 방금 페이지 URL을 저장하고 각 페이지 변경시 대화 범위를 지 웠습니다.

from https://stackoverflow.com/questions/450557/custom-spring-scopes by cc-by-sa and MIT license