'개발'에 해당되는 글 285건

windows - preferences - Install/Update - Available Sofrware에 가서,

The Eclipse Project Updates에 있는 url 가장 뒤에 / 를 붙여주고,

이클립스 p2 폴더에 있는 cache를 날려주고, 이클립스 재시작 후에 다시 시도하면 해결된다. 

filter로 필터링 후에 collect로 새로운 Collection을 만들고, foreach를 돌리는 경우

필터링을 하고 새로운 Collection을 만들었기 때문에, 필터에서 걸러진 것들은 최종 결과물에서 안나올 거라고 생각을 했다.

그런데.. 필터링 되었던 항목이 그대로 포함이 되어 있었다.

이럴 경우에는 collect함수를 사용하면서 기존의 list에 덮어씌우는 작업 후에,

forEach를 돌리면.. 원하던대로 동작한다.

정리하면 아래 코드는 서로 다르게 동작한다는 거다.

체인 메소드 특성상, 내부적으로만 새로운 스트림을 만들기 때문인 것 같다.

list.stream().filter().collect(Collectors.toList()).forEach();

list.stream().filter().collect(Collectors.toList());
list.forEach();

동접 그래프를 만들일이 있어서, 차트 라이브러리를 찾던 도중에 어떤 자료구조를 사용할지에 대해 고민을 하게 되었다.

사용될 자료구조의 요구조건은 다음과 같다.

1. 사이즈가 fix되어 있어야 함.

2. 데이터가 순차적으로 들어가야 함.

3. fix된 사이즈가 초과되면, 저장되어 있던 데이터들을 하나씩 뒤로 밀고 새로운 것을 앞에다가 넣어주어야 함.

java에서 제공하는 Collection만 보았을 때는 2번의 경우 LinkedList를 사용하면 되고, 3번의 경우 Queue를 사용하면 되는데..

1번이 문제였다. 결국 만들어야 하는 상황이 왔는데, 귀찮아서 이리저리 검색을 해보니.. Google Guava Library에서 EvictingQueue라는 훌륭한 자료구조를 제공해주고 있었다.

아래와 같이 사용하면, 위 1~3번의 조건을 모두 만족하는 자료구조가 만들어진다.

EvictingQueue<T> queue = EvictingQueue.create(size);

뭐 굳이 만드는걸 좋아하는 분들은 만드는 것도 나쁘진 않겠지만..

내가 만드는거보단 google code에 올라가 있는 library가 더 안정적이겠지하고 이걸 가져다 쓰기로 했음.

앞으로 자주 사용하게 될 것 같다.

spring에는 많은 어노테이션들이 있죠.

그 중에서 편하게 사용할 수 있는 ModelAttribute에 대해 알아보도록 합시다.

파라미터를 넘길 때 보통은 아래와 같이 사용하는게 일반적이죠.

@RequestMapping("/test/abc")
@ResponseBody
public Object test(@RequestParam(value="a") String a,
                     @RequestParam(value="b") int b) {
   return "";
}

하지만 저것을 Model을 이용하여 한번에 넘길 수 있는 방법이 있답니다.

바로 ModelAttribute!!

일단 Model을 하나 만들어봅시다.

public Class testClass {
    String a;
    int b;
}

모델을 만들었으면 아래와 같이 사용합니다.

@RequestMapping("/test/abc")
@ResponseBody
public Object test(@ModelAttribute testClass test) {
   return "";
}

testClass에 멤버로 String a, int b가 있기 때문에,

파라미터로 a, b에 값을 담아서 보내면, test라는 클래스변수에 자동으로 값이 세팅되는 편리한 기능입니다.

게시판 같은 경우 Model단위로 파라미터를 넘기고 받는 경우가 많기 때문에, 유용할 것입니다.

현재 진행 중인 프로젝트에 로컬라이징을 적용하다가

스프링의 강력한 기능 중 하나인 ReloadedResourceBundleMessageSource에 대하여 정리가 되어, 포스트를 작성합니다.

[요구사항 및 해결]

1. 다국어 지원  

  - 서버가 한국에 있다고 무조건 korean으로 나와서는 안되며, 클라이언트에서 컨트롤이 가능하도록 해야 함.

  > 해결 : LocaleChangeInterceptor를 등록하고, 옵션 값인 ParamName을 이용하여,  

     해당 파라미터가 클라이언트로부터 도착하면 Locale을 변경하도록 설정.  

     추가로 SessionLocaleResolver라는 것을 localeResolver라는 Bean이름으로 등록해 주어야함. 

     그 뒤에 messageSource.getMessage()를 이용하면, 파라미터로 Locale을 지정해주지 않아도,  

     서버의 Locale을 참조하여, 원하는 메시지를 찾음!!

  * 결론 : 기본적으로 LocaleChangeInterceptor를 등록하면, localeResolver라는 이름을 가진 Bean을 찾아서 처리를 하게 되는데,

              SessionLocaleResolver를 localResolver라는 이름으로 등록하지 않으면,  

              기존에 이미 존재하던 default Resolver(AcceptHeaderLocaleResolver)에 대하여 처리가 되버림.

              AcceptHeaderLocaleResolver는 구현부를 보면 알겠지만, 특정 파라미터에 의해서 Locale을 바꾸는 것을 지원하지 않음.

              따라서, SessionLocaleResolver로 교체를 해주면, 위에 Interceptor에서 지정한 ParamName으로 Locale을 바꾸는 기능을  

              사용할 수 있게 됨.

2. 서버 재시작 없이 메시지 내용 변경

   - 텍스트를 하나 바꾸었다고 재시작을 한다는 것이 말이 안된다고 느끼는 분들이 좀 많음.  

     (php만 했던 사람들은 당연히 그렇게 느끼던..) 

   > 해결 : ReloadedResourceBundleMessageSource에 옵션으로 CacheSeconds라는게 있음.

               이게 기본으로는 -1 (영원히 캐싱, 따라서 리로드도 하지 않음)으로 되어 있기 때문에,

               1초라도 넣어주어야 해당 주기만큼 캐싱을 하고, 캐싱된 게 없으면 변경내역을 바로 불러와서 적용을 해준다.

               Tomcat을 사용하는 경우 reloadable옵션을 false로 해줘야 사용이 가능함. (true로 쓰는 경우는 거의 없지만...)

  ※ .properties은 모든 부분에서 사용이 가능함. 

해결은 했는데, getMessage 자체의 defaultMessage 기능이 좀 이상하게 동작하더군요.

파라미터로 온 값에 해당하는 Locale을 못찾았으면 localeResolver에 defaultLocale로 지정한 Locale에 해당하는 메시지를 찾을 줄 알았는데, 무작정 defaultMessage에 써놓은걸 뿌려버리던.... 그래서 전 try catch를 이용해서 구현을 했답니다.ㅠㅠ

이거 말고는 특별히 문제는 없는듯... 

Java Config를 이용하는 경우에 해당합니다. (xml 설정은 1년전에 안쓰기로 버렸기 때문에... 본 포스트에는 내용이 없습니다.)

4.1.0으로 넘어오면서 override되는 메소드가 두개정도 추가되었습니다만..  

필수로 구현해야 하는건 아닌거 같더군요. 

1. 설정 

@Configuration
@EnableCaching
public class CachingConfig implements CachingConfigurer {

    @Bean(destroyMethod="shutdown")
    public net.sf.ehcache.CacheManager ehCacheManager() {
        CacheConfiguration staticConfig = new CacheConfiguration();
        staticConfig.setName("StaticConfig");  // 캐시 이름
        staticConfig.setMemoryStoreEvictionPolicy("LRU");  // 메모리에 저장되는 방식을 결정
        staticConfig.setMaxEntriesLocalHeap(100);  // 최대로 캐싱할 수 있는 Entries의 수
        staticConfig.setTimeToIdleSeconds(3600);   
        staticConfig.setTimeToLiveSeconds(3600);
        
        net.sf.ehcache.config.Configuration config = new net.sf.ehcache.config.Configuration();
        config.addCache(staticConfig);

        return net.sf.ehcache.CacheManager.newInstance(config);
    }
    
    @Bean
    @Override
    public CacheManager cacheManager() {
        return new EhCacheCacheManager(ehCacheManager());
    }

    @Bean
    @Override
    public KeyGenerator keyGenerator() {        
        return new SimpleKeyGenerator();
    }

    @Override
    public CacheResolver cacheResolver() {
        // TODO Auto-generated method stub
        return null;
    }

    @Override
    public CacheErrorHandler errorHandler() {
        // TODO Auto-generated method stub
        return null;
    }

2. 사용     

@Cacheable(value="StaticConfig", key="#configNum")   // StaticConfig라는 캐시에 configNum을 기준으로 캐싱한다.
    public Object selectStaticConfig(int configNum) {
        // TODO
    }

    @CacheEvict(value="StaticConfig")    // StaticConfig에 캐싱되어 있던 내용을 초기화한다.
    public Object selectStaticConfigInitCache(int configNum) {
        // TODO
    } 

매우 간단합니다. 

@Before : Point cut 표현식에 해당하는 메소드를 처리하기 이전에 실행됨.

@After : Point cut 표현식에 해당하는 메소드를 처리한 후에 실행됨.

@Around : Point cut 표현식에 해당하는 메소드 주위에서 실행됨.

검색해서 @Around에 대한 정보를 찾다보면, 메소드 주위라는 말이 정확하게 이해가 안되더군요.

그래서 테스트를 해봄으로써 확실히 알게되었습니다.

@Around의 경우 다른 것들과는 달리 ProceedingJoinPoint라는 것을 argument로 가질 수 있는데요.

ProceedingJoinPoint에는 proceed() 라는 메소드가 존재합니다.

메소드 주위라는 말은 전과 후를 모두 처리할 수 있는 것이며,

전과 후를 구분하는 기준은 proceed() 메소드가 호출된 시점으로부터, 전 후를 의미합니다.

역시 글만 대충 읽어보고 적용할지 여부를 결정할 게 아니라, 테스트를 해봐야 정확한 결과를 얻을 수 있다는.. ㅠㅠ 

DB서버를 Scale Out 해서 사용하는 경우나, DB서버가 원격지에 분리되어 있는 경우

단일 트랜잭션만으로는 한계가 있기 때문에 (물론 사용하지 않도록 설계하는 것이 가장 좋겠지만...) 글로벌 트랜잭션을 사용하게 됩니다.

많이 알려진 게 아래 세가지 인데요..

2번은 3번으로 기능이 넘어가면서 Deprecated되었더군요. 

1. Atomikos XA TransactionManager 

2. Neo4j ChainedTransactionManager (Deprecated) 

3. Spring Data Commons ChainedTransactionManager

1번과 3번의 차이는 1번의 경우 2Phase Commit을 지원하는 것이고, 3번의 경우 2Phase Commit까지는 아니지만, 비슷하게 지원을 한다는 점과,  

가장 큰 것은 1번의 경우 설정이 매우 복잡하다는 점과, 3번은 설정이 매우 간편하다는 점 및 스프링과 통합이 쉽다는 점 입니다.

개인적인 생각으로 굳이 2Phase Commit까지 지원해야 되나.. 라는 생각과 왠지 Spring Data Commons의 경우 Spring Web MVC에서 사용하면, 안정적이지 않을까라는 생각으로 3번을 선택하게 되었습니다.

설정은 매우 간단합니다.

@Bean           // Bean 등록 시 이름이 매우 중요합니다. 이름이 다른 경우 defaultTransactionManager를 사용하게 됨.
public ChainedTransactionManager transactionManager() {
    ChainedTransactionManager transactionManager = new ChainedTransactionManager(transactionManagerGame(), transactionManagerGame_2(), transactionManagerGame_3(), transactionManagerGame_4(), ...);
    return transactionManager;
}
 
@Override        // @Transactional을 사용할 때 사용할 transactionManager를 지정해줌. (xml설정에서의 annotation-driven)
public PlatformTransactionManager annotationDrivenTransactionManager() {
    return transactionManager();
}

먼저 SpringFramework를 3.2버전 이상 사용하시는 분만 보시기 바랍니다.

(ControllerAdvice가 3.2버전때 만들어졌습니다.) 

@ControllerAdvice는 @Controller 나 @RestController(4.0부터 지원)에서 발생하는 작업을 캐치해주는 기능을 가지고 있습니다.

(특정 컨트롤러만 캐치하는 것도 가능.. 4.0부터 지원이라네요. ControllerAdvice Annotation Documentation 참조) 

저는 이것을 에러핸들링 용도로 사용해보았습니다. 

클래스 위에 @ControllerAdvice를 붙여주고 어떤 Exception을 캐치할 것인지, 

내부 메소드를 선언하여 메소드 상단에는 @ExceptionHandler(Exception.class) 와 같이 붙여줍니다.

최종적으로 아래와 같은 모습이 됩니다. 

@ControllerAdvice
@RestController 
public class ControllerAdviceHandler {
       @ExceptionHandler(NullPointerException.class)
       public Object nullPointerHandle(HttpServletRequest request, Exception e) {
            return "null"; 
       } 
        
       @ExceptionHandler(Exception.class)
       public Object exceptionHandle(HttpServletRequest request, Exception e) {
            return "exception"; 
       }

}

Exception의 가장 상위인 Exception을 핸들링하고, 그 하위인 NullPointerException을 핸들링하는 메소드가 따로 있는 경우,

NullPointerException은 NullPointerException 핸들링 메소드로 들어가서 처리가 됩니다. 

● execution 명시자 : Advice를 적용할 메서드를 명시할 때 사용

  ▶ 수식어패턴 : public, private 등등의 수식어를 명시, 생략 가능

  ▶ 리턴타입 : 리턴 타입을 명시

  ▶ 클래스이름, 이름패턴 : 클래스 이름 및 메서드이름을 패턴으로 명시

  ▶ 파라미터패턴 : 매칭될 파라미터에 대해 명시

  ▶ '*' : 모든 값을 표현

  ▶ '..' : 0개 이상을 의미

출처 : http://0px.kr/296

저 위에 명시된 것들은 &&나 ||를 활용해서 확장이 가능하다.

공통으로 처리해야될 일이 많다보니, 참고할 일이 많아서 퍼옴.. ㅠㅠ