Life with Programming

 ?: 이후가 기본 값(default) @Value("#{systemProperties['mongodb.port'] ?: 27017}") - 그 외 * PropertySourcesPlaceholderConfigurer * ${property:default value} from : https://www.mkyong.com/spring3/spring-value-default-value/

    @Bean     public ResourceAwareItemReaderItemStream<A> flatFileReader() {         FlatFileItemReader<A> fileReader = new FlatFileItemReader<>();         fileReader.setEncoding("UTF-8");         fileReader.setLineMapper(LINEMAPPER);         return fileReader;     }     @Bean     @StepScope     public ItemReader<A> multipleFileReader(         @Value("#{jobParameters[target]?:null}") String target     ) throws IOException {         String filePath = ~~~;         filePath += "/*";         ClassLoader loader = this.getClass().getClassLoader();         PathMatchingResourcePatternResolver resolver = new PathMatchingResourcePatternResolver(loader);         MultiResourceItemReader<A> reader = new M...

* springframework jar 버전이 안맞는 경우에 발생하는 듯.. * maven 기반 프로젝트인 경우에, 필요로하는 spring버전이 아닌, 다른 버전이 딸려들어온 경우 발생!!   * 관련 pom.xml 파일 Maven Pom Editor로 open하여, Dependency Hierarchy View로 잘못 딸려들어온 dependency 찾아서 exclusion 처리가 필요함...

대충 @Schedule annotation으로 주기적 호출하도록 설정가능   * 단, scheduler 등록이 되어 있어야 하는 듯.. 아래 처럼 등록하면 되는 듯... <task:scheduler id="target" pool-size="10"/> <task:annotation-driven scheduler="target"/>     * fixedDelay와 fixedRate차이 ** fixedDealy : 이전 수행이 종료된 시점부터 delay후에 재호출 ** fixedRate : 이전 수행이 시작된 시점부터 delay후에 재호출(동시에 여러개가 돌고 있을 가능성도 있는 듯...)  

-  Transactional사용시 주의사항 * junit에서 테스트용으로 돌리다 보면, 아래와 같은 케이스가 있는데 이럴 때 주의할 사항. --------------------------------  class A {  @Transactional  void aa() {   }    void bb() {       aa();   } } --------------------------------   junit에서 위와 같이 transactional이 걸려있는 메소드(aa();)를 호출하는 메소드(bb())에 대해서 transaction 테스트를 하려고 하면 transaction이 정상동작하지 않음(rollback 안됨 현상)... (proxy기반이라 하나의 클래스의 진입점 transaction을 따르는 거 같음... @.@ ) 즉, 테스트 대상 bb();에 @Transactoinal이 걸려 있어야 하는 듯...      - Propagation (기본적으로 spring propagation은 Exception을 기본으로 동작(즉, 내부에서 exception이 발생하는 것을 바탕으로 rollback할지 여부 결정하는 듯..)) * Required : 가장 기본 transaction으로 trasaction 연결이 하나의 connection안에서 동작하며, 계속해서 required가 붙으면 붙을 수록 각 요청을 기록해두었다가 하나라도 exception이 발생하면 모두 rollback되는 Propagation   * nested : 제일 헷갈렸는데, nested로 기존 transaction안에서 실행되나, nested안에서 exception 발생시에는 자기것만 rollback하는 듯.. ( 단, 해당 exception을 내부 로직단에서 catch해서 뭔가 후처리가 있어야 함... 없으면 exception이 계속 상위로 전...