학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 중첩 클래스 또는 내부 클래스를 사용하는 이유로 "중첩 클래스는 특정 클래스가 다른 하나의 클래스 안에서만 사용되거나, 둘이 아주 긴밀하게 연결되어 있는 특별한 경우에만 사용해야 한다. 외부 여러곳에서 특정 클래스를 사용한다면 중첩 클래스로 사용하면 안된다." 라고 언급이 되었는데, 본질적인 질문이 있습니다. 정적 중첩 클래스 같은 경우는 타 클래스에서 쓰는 경우가 별로 없고 외부클래스 내에서만 사용하는 경우에 쓴다는건데.. 그럼 정적의 의미가 뭔지 궁금합니다. 그냥 내부클래스만 쓰면 되는거 아닌가요? 내부클래스의 기능에서 인스턴스변수 접근이 제한되는 게 정적 중첩 클래스라는 생각이 들어서.. 외부에서 사용하지도 않는데 왜 정적클래스를 굳이 사용하는지 궁금합니다.
utf-8에서 맨 앞에 1의 개수를 확인하고 이 데이터는 몇 바이트짜리구나. 라고 알 수 있다고 하셨잖아요. 그럼 빅엔디안에서는 시작하는 바이트의 값을 보고 확인 할 수 있는데, 리틀엔디안에서는 어디가 시작하는 바이트인지 명확하지 않게 되는거 같아요. 내가 사용하는 시스템(윈도우, 리눅스)?에 따라 내부적을 알아서 작동하는건가요? 10으로 시작하지 않는 바이트를 찾아서 이게 '시작바이트구나' 하고 여기서부터 거꾸로 읽어들이는 식인가요?
안녕 킬구횽. 정성 가득한 강의 감사한 마음으로 공부하고 있다. 고맙다. 다름이 아니라, 해당 작전에서 설명한대로 TransactionManager을 분리해서 사용하고 있었는데, 이때 이해가 가지 않는 상황이 있다. 글이 조금 길어서, 요약을 먼저 하겠다. 요약 비즈니스용 트랜잭션 매니저(JPA) 과 메타데이터용 트랜잭션 매니저(JDBC) 을 분리한 경우 , UnexpectedRollbackException 이 발생한 후에 OptimisticLockingFailureException 까지 추가로 발생한다. 그러나 트랜잭션 매니저를 분리하지 않은 경우 , UnexpectedRollbackException 은 발생하지만 OptimisticLocking 예외는 발생하지 않는다 . 이유가 궁금하다. 상황 설명 다음은 @Configuration 클래스다. @Bean @Primary @ConfigurationProperties("spring.datasource.service") public DataSource dataSource() { return DataSourceBuilder.create() .type(HikariDataSource.class) .build(); } @Bean @BatchDataSource @ConfigurationProperties("spring.datasource.batch") public DataSource batchDataSource() { return DataSourceBuilder.create() .type(HikariDataSource.class) .build(); } @Bean @Primary public PlatformTransactionManager transactionManager(EntityManagerFactory entityManagerFactory) { return new JpaTransactionManager(entityManagerFactory); } @Bean @BatchTransactionManager public PlatformTransactionManager batchTransactionManager(@BatchDataSource DataSource dataSource) { return new JdbcTransactionManager(dataSource); } 다음은 job을 구성하는 ( 잘못 작성된 ) tasklet이다. 트랜잭션 전파 속성은 Propagation.REQUIRED를 사용하고 있다. class TestTasklet implements Tasklet{ private final TestRepository testRepository; @Override public RepeatStatus execute(StepContribution contribution, ChunkContext chunkContext) throws Exception { try{ // testRepository의 @Transactional method 호출 // but @Transactional method에서 RuntimeException을 throw } catch(RuntimeException e){ // sucess process logic } return RepeatStatus.FINISHED; } 위 코드에서, 예외를 캐치하는 것으로 예외를 처리한 것은 나의 실수였다. 런타임 예외를 던지는 트랜잭션은 rollback-only 마킹 처리되어 해당 트랜잭션이 커밋될 수 없었기 때문이다. 이해가 가지 않는 지점은 지금부터다. 이를 설명하기 위해 내가 파악한 흐름을 정리해봤다. 오류가 있을 수 있다. (비즈니스: JPA / 메타 데이터: JDBC) 트랜잭션 매니저를 분리하는 경우 TransactionTemplate의 execute 메서드 실행 doInTransaction 메서드 실행 시작 TestTasklet의 execute 메서드의 실행 * transaction from JPA execute 메서드 내부에서 런타임 예외가 발생하는 트랜잭션 메서드 호출 -> 트랜잭션에 rollback-only 마킹됨 내부적으로 정상 처리하였으므로 RepeatStatus.FINISHED 반환 StepExecution update (version 1 -> version 2) 커밋 * 메타데이터용 DB 커넥션 사용하는 것을 확인함 doInTransaction 메서드 실행 완료 TransactionTemplate의 execute 메서드에서 커밋 시도 * transaction from JPA UnexpectedRollbackException 발생 * rollback-only 마킹으로 인함 롤백 시작 version 1 -> version 2로 StepExecution update 시도 이때 다음 예외가 발생한다. OptimisticLockingFailureException: Attempt to update step execution id=4 with wrong version (1), where current version is 2 반면, 트랜잭션 매니저를 분리하지 않으면 OptimisticLocking 예외가 발생하지 않는데, 왜 OptimisticLocking 예외가 발생하지 않는지 궁금하다. (비즈니스, 메타 데이터: JPA ) 트랜잭션 매니저를 분리하지 않는 경우 TransactionTemplate의 execute 메서드 실행 doInTransaction 메서드 실행 시작 TestTasklet의 execute 메서드의 실행 execute 메서드 내부에서 런타임 예외가 발생하는 트랜잭션 메서드 호출 -> 트랜잭션에 rollback-only 마킹됨 내부적으로 정상 처리하였으므로 RepeatStatus.FINISHED 반환 StepExecution update (version 1 -> version 2) 커밋 doInTransaction 메서드 실행 완료 TransactionTemplate의 execute 메서드에서 커밋 시도 UnexpectedRollbackException 발생 롤백 시작 version 1 -> version 2로 StepExecution update 시도 OptimisticLock 예외가 터지지 않고 정상적으로 버전 업데이트가 완료된다. 이때 OptimisticLocking 예외가 발생하지 않았다는 것은, 현재 stepExecution의 버전이 1 이라는 것으로 받아들여진다. 의문인 점은, StepExecution update (version 1 -> version 2)이 커밋되는 것을 디버깅을 통해 확인했는데, 어째서 롤백 시점에서 stepExecution의 버전이 1이냐는 것이다. 무언가 엔티티 매니저와 관련이 있는 것 같은데, 잘모르겠다. 도움이 될까하여, 로그 일부를 첨부한다. 트랜잭션 매니저 분리하는 경우 2025-07-27T22:16:13.626+09:00 TRACE 141032 --- [server] [ main] o.s.jdbc.core.StatementCreatorUtils : Setting SQL statement parameter value: column index 1, parameter value [28], value class [java.lang.Long], SQL type unknown 2025-07-27T22:16:13.626+09:00 TRACE 141032 --- [server] [ main] o.s.t.i.TransactionInterceptor : Completing transaction for [org.springframework.batch.core.repository.support.SimpleJobRepository.update] 2025-07-27T22:16:13.626+09:00 DEBUG 141032 --- [server] [ main] o.s.jdbc.support.JdbcTransactionManager : Initiating transaction commit 2025-07-27T22:16:13.626+09:00 DEBUG 141032 --- [server] [ main] o.s.jdbc.support.JdbcTransactionManager : Committing JDBC transaction on Connection [HikariProxyConnection@33286612 wrapping org.postgresql.jdbc.PgConnection@6ae1d5f1] 2025-07-27T22:16:13.627+09:00 DEBUG 141032 --- [server] [ main] o.s.jdbc.support.JdbcTransactionManager : Releasing JDBC Connection [HikariProxyConnection@33286612 wrapping org.postgresql.jdbc.PgConnection@6ae1d5f1] after transaction 2025-07-27T22:16:13.627+09:00 DEBUG 141032 --- [server] [ main] o.s.jdbc.support.JdbcTransactionManager : Resuming suspended transaction after completion of inner transaction 2025-07-27T22:16:13.627+09:00 DEBUG 141032 --- [server] [ main] o.s.orm.jpa.JpaTransactionManager : Initiating transaction commit 2025-07-27T22:16:13.627+09:00 DEBUG 141032 --- [server] [ main] o.s.orm.jpa.JpaTransactionManager : Committing JPA transaction on EntityManager [SessionImpl(858762286<open>)] 2025-07-27T22:16:13.630+09:00 INFO 141032 --- [server] [ main] o.s.batch.core.step.tasklet.TaskletStep : Commit failed while step execution data was already updated. Reverting to old version. 2025-07-27T22:16:13.630+09:00 DEBUG 141032 --- [server] [ main] o.s.orm.jpa.JpaTransactionManager : Closing JPA EntityManager [SessionImpl(858762286<open>)] after transaction 2025-07-27T22:16:13.630+09:00 DEBUG 141032 --- [server] [ main] o.s.batch.repeat.support.RepeatTemplate : Handling exception: org.springframework.transaction.UnexpectedRollbackException, caused by: org.springframework.transaction.UnexpectedRollbackException: Transaction silently rolled back because it has been marked as rollback-only 2025-07-27T22:16:13.631+09:00 DEBUG 141032 --- [server] [ main] o.s.batch.repeat.support.RepeatTemplate : Handling fatal exception explicitly (rethrowing first of 1): org.springframework.transaction.UnexpectedRollbackException: Transaction silently rolled back because it has been marked as rollback-only 2025-07-27T22:16:13.633+09:00 ERROR 141032 --- [server] [ main] o.s.batch.core.step.AbstractStep : Encountered an error executing step switchAliasTargetStep in job addressIndexingJob 분리하지 않는 경우 2025-07-27T22:18:22.239+09:00 TRACE 114800 --- [server] [ main] o.s.jdbc.core.StatementCreatorUtils : Setting SQL statement parameter value: column index 1, parameter value [8], value class [java.lang.Long], SQL type unknown 2025-07-27T22:18:22.240+09:00 TRACE 114800 --- [server] [ main] o.s.t.i.TransactionInterceptor : Completing transaction for [org.springframework.batch.core.repository.support.SimpleJobRepository.update] 2025-07-27T22:18:22.240+09:00 DEBUG 114800 --- [server] [ main] o.s.orm.jpa.JpaTransactionManager : Initiating transaction commit 2025-07-27T22:18:22.240+09:00 DEBUG 114800 --- [server] [ main] o.s.orm.jpa.JpaTransactionManager : Committing JPA transaction on EntityManager [SessionImpl(707576293<open>)] 2025-07-27T22:18:22.241+09:00 INFO 114800 --- [server] [ main] o.s.batch.core.step.tasklet.TaskletStep : Commit failed while step execution data was already updated. Reverting to old version. 2025-07-27T22:18:22.242+09:00 DEBUG 114800 --- [server] [ main] o.s.orm.jpa.JpaTransactionManager : Closing JPA EntityManager [SessionImpl(707576293<open>)] after transaction 2025-07-27T22:18:22.242+09:00 DEBUG 114800 --- [server] [ main] o.s.batch.repeat.support.RepeatTemplate : Handling exception: org.springframework.transaction.UnexpectedRollbackException, caused by: org.springframework.transaction.UnexpectedRollbackException: Transaction silently rolled back because it has been marked as rollback-only 2025-07-27T22:18:22.242+09:00 DEBUG 114800 --- [server] [ main] o.s.batch.repeat.support.RepeatTemplate : Handling fatal exception explicitly (rethrowing first of 1): org.springframework.transaction.UnexpectedRollbackException: Transaction silently rolled back because it has been marked as rollback-only 2025-07-27T22:18:22.246+09:00 ERROR 114800 --- [server] [ main] o.s.batch.core.step.AbstractStep : Encountered an error executing step switchAliasTargetStep in job addressIndexingJob
13. jpa reader,writer 까지만 보고 질문드립니다. JpaPagingItemReader , JpaItemWriter 를 사용해서 JPA 기반으로 DB에 직접 접근해 처리할때, Writer나 Processor에서 복잡한 비즈니스 로직이 필요한 경우 에는 어떻게 설계하는 것이 좋은지 궁금합니다. 만약 주문을 처리하는 배치가 있다고 했을 때 배치 작업에서 주문을 조회 ( JpaPagingItemReader -Entity 리턴) writer에서 주문 상태 변경 주문 내역 추가 배송 테이블에 적재 등 여러 도메인을 걸치는 비즈니스 로직 수행 필요 이렇게 되면 reader에서 조회한 것을 processor에서 command와 같은 객체로 변환해서 writer에서는 service 로직을 호출하는 것이 좋을까요?
안녕하세요 토비님, 우선 강의를 통해 제가 알고 있던 헥사고날 과 DDD(도메인 주도 설계) 에 대해 다시 한번 깊이 생각해볼 수 있는 소중한 경험이 되었습니다. 좋은 강의 만들어주셔서 정말 감사합니다. 토비님께서 생각하시는 헥사고날에, DDD 과 멀티 모듈 의 바람직한 설계에 대해 궁금해서 질문을 남기게 되었습니다. 여기서의 멀티 모듈은 우선 MSA 를 제외하고 순수 멀티 모듈을 통해 시스템을 설계를 한다는 것을 전제하고 있습니다. 가장 흔하게 보이는 멀티 모듈 구성의 패턴은 Storage (JPA), External (외부 Dependency), N 개의 서비스에 해당하는 Web Server 모듈 & 기타 등이 있는 것 같은데요. 멀티 모듈을 현 강의에서 보여주고 말씀해주시는 헥사고날과 DDD 와 결합했을 때, 어떻게 구성하면 좋을지 많은 생각이 들고 또한 현업에서 비슷한 고민을 하고 있어서 토비님의 생각이 궁금해 질문을 남기게 되었습니다. 감사합니다.
Client의 close()에 synchronized를 사용하는 것은 이해가 됐습니다. ReadHanlder, WriteHandler 양쪽에서 동시에 호출할 수 있기 때문이라고 생각하면 바로 이해되는데... ReadHandler, WriteHandler의 close()에는 어떤 이유로 동기화 처리를 하는건지 궁금합니다. (해당 스레드들은 Client에서만 접근되는게 아닌가요?) 그리고 모든 IO 스트림이 Client 클래스에서 관리되는데 굳이 핸들러에도 close()를 두신 이유가 궁금합니다!
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 안녕하세요. 강의 따라하는데, indexing이 무한히 로드 중이여서 아래 문구와 같이 자동 import를 하고 싶어도 할 수가 없습니다 ㅠㅠ.. 구글링을 통해 invalidate cache 하고 restart 해보기 compiler>excludes에 해당 프로젝트 파일 제외시켜보기 appearance&behavior에서 sync기능 비활성화 시켜보기 ( https://eottabom.github.io/post/intellij-indexing/ 참고함) jdk 17로 잘 설정되어 있는지 등등 확인해보았지만 인덱싱이 무한히 실행되고 있어 어노테이션 임포트를 못하고 있습니다... 조언 부탁드리겠습니다! 😂 😂
thread1.join(); thread2.join(); 메인스레드 내에서 thread1,2를 join()을 하는데요. thread1.join()을 먼저 만났으니 메인 스레드는 thread1이 종료 될때까지 다음 코드를 실행하지 않을텐데요. 여기서 메인스레드가 thread1의 결과를 기다리는 것이므로 thread1,2는 무관하게 그대로 번갈아가며 실행 되는 것이 맞나요? CPU((코어)가 1개라고 가정했을때요. 그래서 메인은 thread1이 종료되고 결과를 기다릴뿐 thread1과 2의 종료 순서는 보장되지않는 것이 맞을까요? 따라서 thread2가 먼저 작업을 끝낸 실행일 때도 있을 수 있겠죠? 단지 메인이 thrad1의 결과를 먼저 받으려고 기다릴뿐인거죠?
========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 17:13경 하신 설정이 최신 intellij와 스프링부트에서도 필요한 설정인가요? 어떤 기능을 하는 설정인지 궁금합니다. 2025년 기준 인텔리제이에서 확인할 수 없어 여쭙습니다.
안녕하세요 토비님! 좋은 강의 정말 감사드립니다. @TestConfiguration 에 대한 설명을 해주신 부분 중에서 테스트 결과와 다른 부분이 있는 것 같아 확인차 질문 드립니다. <28. 회원 애플리케이션 서비스 테스트 (2)> 의 11:38에서 " @TestConfiguration 에 어떤 Bean을 정의하면 이게 우선이 되어 돌아갑니다." 라는 말씀을 해주셨는데요. 해당 말씀이 맞는지 테스트해 보기 위해, 현재의 강의 예제 코드에서 @TestConfiguration 이 붙은 클래스의 PasswordEncoder 를 정의한 Bean 메서드의 이름을 testPasswordEncoder로 변경하고 테스트를 돌려 보니 아래와 같은 오류가 발생하였습니다. ( EmailSender 의 경우 DummyEmailSender에 @FallBack 이 붙어 있어서 @TestConfiguration 의 EmailSender Bean 메서드의 이름을 다르게 구성하더라도 테스트는 정상적으로 동작합니다.) @TestConfiguration 이 정의되었다고 해서 우선순위로 동작하지는 않는 것으로 보이고, 기존 Bean의 적용 우선순위에 따라 @TestConfiguration 에서 정의한 메서드 이름과, 이를 사용하는 곳의 필드 이름이 동일한 경우 해당 Bean을 찾아서 동작하는 것으로 보였습니다. 혹시 제가 잘못 이해하고 있거나 보완이 필요한 부분이 있다면 편히 말씀 부탁드립니다. 확인 부탁드립니다. 감사합니다 :)
안녕하세요, 삼코치님. 최근 LDO 설계 및 시뮬레이션을 진행하면서 안정성 분석에 어려움이 있어 질문드립니다. 매번 빠르고 정확한 답변 주셔서 감사합니다. 1. LDO 안정성 PM 변화 경향에 대한 분석 및 질문 일반적으로(삼코치님, 다른분들 과제 결과) LDO 설계에서는 Light Load Current에서 PM이 좋지 않고, Max Load Current로 갈수록 PM이 좋아지는 경향을 보이는 것으로 알고 있습니다. 하지만 제 LDO는 초기 시뮬레이션에서 정반대의 경향 을 보였습니다. 초기 제 LDO의 관찰된 PM 경향: No Load / Very Light Load : PM이 양수로 (예: +40도) 비교적 좋게 나왔습니다. Load Current 증가 (중간 부하 ~ 최대 부하): PM이 급격히 감소하여 음수(예: -50도 이하)가 되었습니다. (즉, PM(경부하) > PM(최대부하)의 경향을 보였습니다.) 저의 초기 분석 (당시의 오해): Load Current 증가에 따른 Wp(load)가 Wp(pass)와 근접하다가 다시 멀어지게 되어 PM을 확보하지 못했다고 생각했습니다. 즉, 급격한 Wp(Load)의 변동이 핵심이라 생각했습니다. 2. 원인 발견: RHP Zero와 그 영향 다시 분석 결과, 제 LDO가 특이한 PM 변화 경향을 보였던 핵심 원인은 다름 아닌 'RHP Zero'였음을 알게 되었습니다. AMP(오류 증폭기) 내부 설계 문제: 저는 AMP만 따로 설계할 때, PM을 55도에 맞춰 설계하기 위해 RHP Zero가 발생하는 회로 구성을 그대로 두었습니다. 당시에는 PM이 90도까지 올라가면 반응이 느려질 것이라고 판단하여 LHP Zero로의 변환(Rz 값 증가)을 의도적으로 하지 않았습니다. 하지만 이 RHP Zero가 전체 LDO 루프의 안정성 마진을 깎아먹어, 결과적으로 Load Current 변동 시 PM이 다른 LDO들과 반대 방향으로 변동하는 원인이 되었던 것 같습니다. 3. 현재까지의 해결 시도 및 추가 질문 현재 RHP Zero 문제를 해결하고 안정성을 개선하기 위한 시도를 진행 중이며, 몇 가지 질문이 있습니다. (3-1) AMP 단독 설계 기준에 대한 질문: LDO 설계 시, AMP(오류 증폭기)만 따로 설계할 때 기준으로 삼는 PM 스펙 이 있는지 궁금합니다. ex) LDO설계시 AMP의 PM은 90도 이상 확보 필요 (3-2) RHP Zero 해결 시도 및 결과: AMP 내부에 있던 Rz, Cc 값(이전의 44kΩ, 150fF)이 너무 작아 Zero 역할을 제대로 못 한다고 판단했습니다. (이는 UGB 이전으로 Zero를 앞당겨 위상 보상을 해야 함에도 불구하고, 해당 Zero가 너무 높은 주파수에 위치했기 때문입니다.) 이를 해결하기 위해 Rz, Cc 값을 증가시켜 LHP Zero를 형성 및 UGB근처에 형성되도록 하였습니다. 결과: 시뮬레이션 결과, 제 LDO의 Mag/Phase 그래프가 이제는 다른분들 LDO 및 코치님의 시뮬레이션과 같은 방향(고주파에서 PM이 좋아지는)으로 변화 하였습니다. (이 변화는 RHP Zero를 LHP Zero로 전환하거나, 기존 Zero의 위치를 UGB 근처로 앞당긴 결과로 판단하고 있습니다.) 질문: 이처럼 LHP Zero를 형성하여 Mag/Phase 그래프의 형태를 개선한 것이 올바른 접근 방식이었는지 확인 부탁드립니다. (3-3) 고주파에서의 Loop Gain 증가 현상: UGB 이후 Loop Gain이 감소했다가, 급격히 증가하는 부분이 있었는데, 이러한 현상은 그대로 두어도 괜찮은지 궁금합니다. (3-4) ESR Zero 조절 방법에 대한 질문: ESR 저항은 캐패시터에 존재하는 고유한 저항으로 알고 있습니다. Zero 삽입 시 ESR Zero를 조절하는 방법이 캐패시터 자체의 종류를 선택하거나 외부 저항을 직렬로 삽입하는 방법 외에, 혹시 다른 직접적인 방법이 있는지 궁금합니다.
안녕하세요 삼코치님, 과제6 삼코치님이 이미 설계해두신거 에서 Jitter성분하고 Power(current)확인을 해봤는데요. Comparator한개 쓴 버전에서 확실히 Jitter는 확실히 100kHz에서 더 뾰족해졌음을 확인했지만 전류는 다음 사진과 같이 I(V5)(comparator1개)가 I(V4)(comparator2개) 짜리보다 더 크게 나와서 제가 측정을 잘못한건지 아니면 다른 원인이 있는지 궁금하여서 여쭈어봅니다. 삼코치님의 말씀대로 전류를 측정하기위해 0V voltage source를 달아놓고 전류를 측정해보았습니다. 항상 친절한 답변 감사드립니다.
킬구형, 테스트 할 때 JobLauncherTestUtils 빈을 주입받는 부분에서 궁금한 게 있어. @Autowired private JobLauncherTestUtils jobLauncherTestUtils; spring batch 테스트를 할 때 JobLauncherTestUtils 을 AutoWired 를 사용해서 필드 주입을 받으면 테스트가 잘 동작하는데, @RequiredArgsConstructor class InFearLearnStudentsBrainWashJobConfigTest { private final JobLauncherTestUtils jobLauncherTestUtils; 생성자 주입으로 받으려고 하면 아래처럼 에러가 나는 이유가 뭘까? No ParameterResolver registered for parameter [final org.springframework.batch.test.JobLauncherTestUtils jobLauncherTestUtils] in constructor ~~ 그리고 AutoWired 로 필드 주입을 받으면 동작은 잘 하지만, IDE에서 Could not autowire. No beans of 'JobLauncherTestUtils' type found. 이렇게 빨간 줄이 뜨는 건 왜일까? 인터넷 서칭해봐도 플러그인 설치를 통한 해결 방법은 있지만 해답은 못 찾았고, 지피티 설명은 이해가 안돼서 여기에 물어봐. 미리 고마워!
