구기네 블로그

[이전 블로그 백업글][2008.2.14]

* 기존의 3.8을 사용하는 테스트 코드

package openframework.dao.impl.junit3; import java.util.List; import openframework.dao.MenuDao; import openframework.model.Menu; import org.springframework.test.AbstractTransactionalDataSourceSpringContextTests; /** * @author fromm0 */ public class MenuDaoTest extends AbstractTransactionalDataSourceSpringContextTests { private MenuDao dao = null; public void setMenuDao(MenuDao menuDao) { this.dao = menuDao; } protected String[] getConfigLocations() { setAutowireMode(AUTOWIRE_BY_NAME); return new String[] { "file:WebContent/WEB-INF/classes/applicationContext*.xml" }; } @Override protected void onSetUp() throws Exception { super.onSetUp(); } @Override protected void onTearDown() throws Exception { super.onTearDown(); } public void testGetMenuList() { List<Menu> menuList = dao.getMenuList(""); assertNotNull(menuList); assertTrue(menuList.size() > 0); } } 3.8버전을 사용하는 기존의 소스에서 볼껀 getConfigLocations() 메소드의 내용과 onSetUp(), onTearDown() 메소드의 오버라이드 그리고 일반적인 형태의 testGetMenuList() 라는 테스트 메소드입니다. 일단 4.x 용 코드를 보면서 차이점을 알아보겠습니다.

* 4.x를 사용하는 테스트 코드

package openframework.dao.impl.junit4; import static org.junit.Assert.assertNotNull; import static org.junit.Assert.assertTrue; import java.util.List; import openframework.dao.MenuDao; import openframework.model.Menu; import org.junit.After; import org.junit.Before; import org.junit.Test; import org.junit.runner.RunWith; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.test.context.ContextConfiguration; import org.springframework.test.context.junit4.SpringJUnit4ClassRunner; /** * @author fromm0 */ @RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(locations={"file:WebContent/WEB-INF/classes/applicationContext*.xml"}) public class MenuDaoTest { @Autowired private MenuDao dao = null; @Before public void onSetUp() throws Exception { } @After public void onTearDown() throws Exception { } @Test public void getMenuList() { List<Menu> menuList = dao.getMenuList(""); assertNotNull(menuList); assertTrue(menuList.size() > 0); } }
클래스 정의 상단에 다음과 같은 코드가 있습니다.

@RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(locations={"file:WebContent/WEB-INF/classes/applicationContext*.xml"})
1. @ContextConfiguration 기존에 getConfigLocations() 메소드에서 해주던 컨텍스트 설정파일의 위치를 어노테이션으로 처리하도록 변경되었습니다.

2. @RunWith Junit4를 사용하도록 RunWith 어노테이션을 사용합니다.

3. @Autowired, @Resource MenuDao 타입의 변수위에는 @Autowired 어노테이션을 사용중입니다. 이것은 타입에 의한 autowire를 하도록 지정하는 것입니다. 만약에 name에 의한 autowire를 하고자 한다면 @Resource 어노테이션으로 대체하면 됩니다.

4. @Before, @After 앞서 오버라이드되었던 두개의 메소드 onSetUp(), onTearDown() 는 메소드 이름 자체는 의미가 없고 각각 @Before, @After라는 어노테이션을 사용함으로써 각각의 기능을 수행합니다.

5. @Test 그리고 실제 테스트용 메소드는 @Test 어노테이션을 사용해서 인식하도록 하고 있습니다.

[이전 블로그 백업글][2007.11.3]

일을 하다보면 될꺼 같은데.. 해보면 에러가 뜨는 경우가 있습니다.
에러가 뜨면 음. 될줄 알았으나 역시 안되는 거였구나. 하고 넘어가는 부분이 있습니다.
물론 꼭 필요하거나 급하지 않은 경우에는 왜 에러가 뜨지 하면서 문제를 파악하곤 하는데 바쁘거나 필수 기능이 아니라면 우회적인 방법을 선택하게 되는것 같습니다.
이번에 프로젝트 하면서 그런 경우가 jsp에서 Spring의 ApplicationContext를 가져오는 것이었습니다.
처음에는 당연(?)하게도 ClassPathXmlApplicationContext 를 사용하면 되겠구나 해서 사용했습니다. 멀정히 Web Context가 올라가고도 ClassPathXmlApplicationContext 를 사용했으니 설정파일 가져오기를 최소한 두번이상 하는 셈이지요.
그래서 이런 경우라면 WebApplicationContext 라면 되겠구나 해서. 했던 기억이 있는데. 역시 에러가 잠깐 발생했던 기능도 있네요. 뭐. 이건 제 삽질 얘기구요..
방법은 다음처럼



기선님이 정리하셨던 참고글.. : http://whiteship.tistory.com/1349

[이전 블로그 백업글][2007.11.3]

머리가 굳어가는지 잘 까먹는다. 이래선..

1. xml에 설정하는 간단한 방법

<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSource" /> </bean> <bean id="sqlMapClient" class="org.springframework.orm.ibatis.SqlMapClientFactoryBean"> <property name="dataSource" ref="dataSource" /> <property name="configLocation" value="classpath:/sql-map-config.xml" /> </bean> <bean id="baseTransactionProxy" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean" abstract="true"> <property name="transactionManager" ref="transactionManager" /> <property name="transactionAttributes"> <props> <prop key="save*">PROPAGATION_REQUIRED</prop> <prop key="insert*">PROPAGATION_REQUIRED</prop> <prop key="update*">PROPAGATION_REQUIRED</prop> <prop key="delete*">PROPAGATION_REQUIRED</prop> <prop key="get*">PROPAGATION_REQUIRED,readOnly</prop> </props> </property> </bean> <bean id="commonDao" class="CommonDao"> <property name="sqlMapClient" ref="sqlMapClient" /> </bean> <bean id="commonManagerProxy" parent="baseTransactionProxy"> <property name="target" ref="commonManager" /> </bean>
xml설정에서는 위처럼 트랜잭션 프록시에 대상 비즈니스 객체를 삽입한 뒤 호출을 다음과 같은 형식으로 한다. 간혹 깜박깜박하는게 빈을 가져올때 commonManagerProxy를 아이디로 사용해야 하는데 commonManager를 아이디로 사용해서 왜 트랜잭션이 작동 안하지 하면서 삽질을 하곤한다.

ApplicationContext ac = new ClassPathXmlApplicationContext(new String[] { "classpath:/ac*.xml" }); CommonManager bean = (CommonManager) ac.getBean("commonManagerProxy"); 2. AOP를 사용하는 방법

<!-- Enable @Transactional support --> <tx:annotation-driven/> <!-- Enable @AspectJ support --> <aop:aspectj-autoproxy/> <aop:config> <aop:advisor id="managerTx" advice-ref="txAdvice" pointcut="execution(* *..service.*Manager.*(..))"/> </aop:config> <tx:advice id="txAdvice"> <tx:attributes> <tx:method name="get*" read-only="true"/> <tx:method name="*"/> </tx:attributes> </tx:advice>
빈을 가져올때 1번의 경우와는 달리 아이디로 commonManager 를 전달하면 된다. AOP에 의해 자동으로 처리가 된다. 위 aop의 advisor에 설정되어 있는 pointcut의 * *..service.*Manager.*(..) 는 service로 끝나는 패키지에서 Manager로 끝나는 클래스의 모든 메소드에 작동한다는 것이다.

[이전 블로그 백업글][2007.10.8]

WebWork 단위테스트중에 Action로직에서 Session에 값을 셋팅하는 로직이 있다면 테스트 코드에 명시적으로 세션정보를 생성해둘 필요가 있다.

protected void onSetUp() throws Exception { super.onSetUp(); ActionContext.getContext().setSession(new HashMap()); }
생각해보면 당연하지만 놓치기 쉬운일은 많다.

[이전 블로그 백업글][2007.9.10]

AOP에 의해 처리가 되는지 체크하기 위한 로깅용 소스입니다.

package example; import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; public class SimpleLogger { private static Log log = LogFactory.getLog(SimpleLogger.class); public void logOneString(String s) { log.info("string=" + s); } public void logTwoStrings(String s1, String s2) { log.info("string1=" + s1 + ",string2=" + s2); } }
AOP를 적용하기 위한 인터페이스입니다.

package example; public interface ConcatService { public String concat(String s1, String s2); }
위 인터페이스를 구현한 클래스입니다.

package example; import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; public class ConcatServiceImpl implements ConcatService { private static Log log = LogFactory.getLog(ConcatServiceImpl.class); public String concat(String s1, String s2) { log.info("## example.ConcatServiceImpl concat"); return s1 + s2; } }
다음은 Spring설정파일입니다. 파일명은 applicationContext.xml 으로 했습니다. 여기서 주의깊게 볼 부분은 부분입니다.

1. aop:before의 경우
- 메소드 실행직전에 작동
- ref=”simpleLogger” 에 의해 참조되는 빈인 example.SimpleLogger의 logTwoString 메소드를 실행
- logTwoString 메소드가 실행되는 시점은 pointcut정의에 의해 example로 시작하는 패키지내 Service라는 글자를 포함하는 클래스의 모든 메소드, 그 메소드 중에 인자를 두개 가지는 메소드가 실행시 자동으로 작동하게 됩니다.

2. aop:after-returning의 경우
- 메소드가 정상적으로 값을 반환한 뒤에 작동
- ref=”simpleLogger” 에 의해 참조되는 빈인 example.SimpleLogger의 logOneString 메소드를 실행
- logOneString 메소드가 실행되는 시점은 pointcut정의에 의해 example로 시작하는 패키지내 Service라는 글자를 포함하는 클래스의 모든 메소드가 실행시 자동으로 작동하게 됩니다.

<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:aop="http://www.springframework.org/schema/aop" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop.xsd"> <aop:config> <aop:aspect id="loggingAspect" ref="simpleLogger"> <aop:before method="logTwoStrings" pointcut="execution(* example..*Service.*(..)) and args(s1,s2)" /> <aop:after-returning method="logOneString" returning="s" pointcut="execution(* example..*Service.*(..))" /> </aop:aspect> </aop:config> <bean id="simpleLogger" class="example.SimpleLogger" /> <bean id="concatService" class="example.ConcatServiceImpl" /> </beans>
실행을 시켜보기 위한 소스입니다. 다음처럼 실행하면 일단 concatService 아이디를 가지는 빈인 example.ConcatServiceImpl의 concat메소드가 작동하게 됩니다. 그리고 앞서 설정한 사항에 의해 각각의 AOP가 작동하게 됩니다.

import org.springframework.context.ApplicationContext; import org.springframework.context.support.ClassPathXmlApplicationContext; import example.ConcatService; public class AOP { public static void main(String[] args) { ApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml"); ConcatService concatService = (ConcatService) context.getBean("concatService"); concatService.concat("some", "thing"); } }
결과물을 보면 다음처럼 작동하는것을 볼수 있습니다.

2007. 9. 10 오후 5:30:02 example.SimpleLogger logTwoStrings 정보: string1=some,string2=thing 2007. 9. 10 오후 5:30:02 example.ConcatServiceImpl concat 정보: ## example.ConcatServiceImpl concat 2007. 9. 10 오후 5:30:02 example.SimpleLogger logOneString 정보: string=something
http://blog.interface21.com/main/2006/03/22/pojo-aspects-in-spring-20-a-simple-example/

[이전 블로그 백업글][2006.4.10]

http://blog.springframework.com/benh/archives/2006/04/09/spring-20s-jms-improvements/

Spring 1.1에서 JMS지원이 추가되었다. 이 지원은 예외번역(exception translation), 메시지 변환, 그리고 JdbcTemplate과 같은 템플릿 클래스를 포함한다. 이 지원은 JMS 1.0.2와 1.1스펙사이의 도메인 단일화를 다룬다. 이 지원의 핵심은 JmsTemplate이고 JMS 1.0.2의 복사본은 JmsTemplate102이다.

이 지원은 기업용 메시징을 위한 하위 레벨의 JMS API를 사용하여 굉장히 크게 발전했다. 어쨌든 이것은 부족한점(JmsTemplate은 JmsTemplate.receive()메소드를 사용하여 메시지의 동기적인 수식만 지원했다.)을 가지고 있었다. 이것은 많은 사람들을 위해 작동을 잘하긴 했지만, 굉장히 많은 사용자는 비동기적인 소비자의 구현물을 사용했다. 간단히 말하면, 그들은 메시지 지향(driven) bean이라고 불리는 EJB2를 원했다.

2.0M1과 추후의 2.0정식버전에서, JMS메시지의 비동기적인 수신을 위한 고유한 지원이 추가되었다. JmsTemplate은 여전히 메시지를 보내기 위해 사용될것이지만, DefaultMessageListenerContainer, SimpleMessageListenerContainer, 과 ServerSessionMessageListener와 같은 AbstractMessageListenerContainer의 하위클래스에 의해 조합되었다.

이러한 MessageListenerContainers를 사용하는 방법을 보자. 첫번째 단계는 메시지를 받는 클래스를 생성하는 것이다. 이것을 위해, MessageListener인터페이스를 구현하는 클래스를 생성해야만 한다.

package jmsexample; import javax.jms.JMSException; import javax.jms.Message; import javax.jms.MessageListener; import javax.jms.TextMessage; public class ExampleListener implements MessageListener { public void onMessage(Message message) { if (message instanceof TextMessage) { try { System.out.println(((TextMessage)message).getText()); } catch (JMSException e) { throw new RuntimeException(e); } } else { throw new IllegalArgumentException( “Message must be of type TestMessage”); } } } 그리고나서, message제공자가 필요할 것이다. 이 코드는 Spring 2.0이전의 것과 같다. 그래서 당신이 이미 이 코드가 있다면, 어떠한 수정도 가하지 않아도 된다.

package jmsexample; import org.springframework.jms.core.JmsTemplate; public class ExampleProducer { private JmsTemplate jmsTemplate; public ExampleProducer(JmsTemplate jmsTemplate) { this.jmsTemplate = jmsTemplate; } public void sendMessage() { jmsTemplate.convertAndSend(“Example Message”); } } 다음에, 이 bean으로 메시지를 보내는 MessageListenerContainer를 생성하기 위한 컨텍스트를 설정할 필요가 있다. 이 예제에서는 ActiveMQ구현물 클래스를 사용하여 알릴것이다. 이것은 많은 JMS구현물중 하나가 될것이다.

<?xml version=“1.0″ encoding=“UTF-8″?> <beans xmlns=“http://www.springframework.org/schema/beans” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” xsi:schemaLocation=“http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd”> <bean id=“messageListener” class=“jmsexample.ExampleListener” /> <bean id=“messageProducer” class=“jmsexample.ExampleProducer”> <constructor-arg ref=“jmsTemplate” /> </bean> <bean id=“jmsTemplate” class=“org.springframework.jms.core.JmsTemplate”> <property name=“connectionFactory” ref=“connectionFactory” /> <property name=“defaultDestination” ref=“destination” /> </bean> <bean id=“destination” class=“org.activemq.message.ActiveMQQueue”> <constructor-arg value=“jmsExample” /> </bean> <bean id=“listenerContainer” class=“org.springframework.jms.listener.DefaultMessageListenerContainer”> <property name=“connectionFactory” ref=“connectionFactory” /> <property name=“destination” ref=“destination” /> <property name=“messageListener” ref=“messageListener” /> </bean> <bean id=“connectionFactory” class=“org.activemq.ActiveMQConnectionFactory”> <property name=“brokerURL” value=“tcp://localhost:61616″ /> </bean> </beans> MQ가 시작될 필요가 있을것이고 main메소드가 컨텍스트에 시동될 필요가 있을것이다. 당신이 필요한 나머지 소스를 볼수 있도록 이 예제의 프로젝트를 제공한다.

마지막으로, 당신은 애플리케이션을 구동하고 출력물을 볼 필요가 있다.

Example Message 여기서 노트할것은 하나의 소비자 쓰레드를 가지고 비동기적인 수신을 다루는 것이다. 이것은 MessageListenerContainer의 동시 소비자(concurrent consumers) 프라퍼티를 사용하여 당신의 소비자를 위한 멀티쓰레드가 가능하다(당신은 여전히 비상태유지나 쓰레드에 안전한것에 대해 기억하라.).

<bean id=“listenerContainer” class=“org.springframework.jms.listener.DefaultMessageListenerContainer”> <property name=“concurrentConsumers” value=“5″ /> <property name=“connectionFactory” ref=“connectionFactory” /> <property name=“destination” ref=“destination” /> <property name=“messageListener” ref=“messageListener” /> </bean> 내가 노트하고자 하는 하나는 Topic으로 동시 소비자를 사용하지 않는것을 확인하는 것이다. JMS Topic내에서, 모든 메시지가 Topic의 모든 소비자에게 전달되는 것을 기억하라. 이것은 topic에서 동시 소비자를 가진다면, 모든 소비자는 같은 메시지를 받을것이라는 것을 의미한다. 어쨌든, 당신이 queue를 사용한다면, 연속적인(round-robin) 방식으로 소비자에게 새로운 각각의 메시지를 분리시킬것이다.

이것은 그다지 충동적이지 않고 몇가지 점에서 당신이 작성하게 되는 것과 매우 유사할것이다. 이것을 iceberg의 팁이라고 말해보자. MessageListenerContainers는 새로운 Spring TaskExecutorabstraction을 사용하는 사용자정의 threadpools을 사용하여 트랜잭션내 일부를 가지는 능력을 가진다. 그리고 소비자에 고유의 JMS세션을 드러낸다.

[이전 블로그 백업글][2006.4.5]
음. iBATIS에 관해 자주(?) 다루고 있지만은.. 유래에 대해서.. 알려진 바는 많지 않아.. 그동안 모르고 있었습니다. 웹 서핑중에 유래에 관련된 부분이 있군요..


http://pxforever.egloos.com/1022231 에서 가져왔습니다.
음 iBATIS 단어의 유래가 저렇다면. 정식 발음은 “아이버티스” 내지 “아이배티스”가 되어야 겠네요..

[이전 블로그 백업글][2006.4.4]

iBATIS의 remapResults페이지

remapResults=”true”의 적절한 사용법
remapResults 속성은 <statement>, <select>, 그리고 <procedure> 에서 사용가능하다. 이것은 선택적인 속성이고 디폴트 값은 false이다.

remapResults속성은 쿼리가 칼럼을 동적으로 반환할때 true로 셋팅되어야만 한다. 예를 들면, 다음의 쿼리를 보자.

SELECT $fieldList$ FROM table 이 예제에서, 비록 테이블은 언제나 같지만 칼럼명의 목록은 동적이다.

SELECT * FROM $someTable$
이 예제에서, 테이블은 다를수 있다. SELECT내 * 의 사용으로, 결과 칼럼이 다를수 있기 때문이다.

결과 세트(result set) 메타데이터가 평범하지 않은것을 알아보기 위한 오버헤드로 인해, iBATIS는 마지막에 쿼리가 수행되는것이 무엇인지 기억할것이다. 이것은 위 예제와 유사한 상황내 문제를 생성할것이다.

remapResults사용에 의존한 첫번째 예제를 보자.

remapResults를 사용하지 않거나 remapResults=”false”로 셋팅하기

$fieldList$ 를 “fld1, fld2″ 로 셋팅하고 첫번째 쿼리를 수행하면. 다음과 같을것이다.

SELECT fld1, fld2 FROM table iBATIS는 fld1 와 fld2가 쿼리의 다음 수행시마다 결과세트가 될것이라고 가정하는 효과를 낼것이다. 애플리케이션이 $fieldList$를 “fld3, fld4″와 같은것으로 변경된다면 문제가 될것이다. iBATIS는 결과세트에서 fld1 와 fld2를 찾을수 없을뿐아니라, 부적절한 결과를 반환할것이다. iBATIS는 첫번째 수행에서 쿼리내 존재하지 않았기 때문에 fld3 와 fld4를 알지못한다.

remapResults=”true”로 셋팅하기

iBATIS는 쿼리가 수행되는 매번 결과세트 메타데이터를 검사하고 언제나 적절한 결과를 반환할것이다. 이 기능은 몇가지의 성능상의 자원을 소모한다. 그래서 결과세트가 동적일 때와 같은 필요한 경우에만 사용하는게 좋다.