구기네 블로그

[이전 블로그 백업글][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는 쿼리가 수행되는 매번 결과세트 메타데이터를 검사하고 언제나 적절한 결과를 반환할것이다. 이 기능은 몇가지의 성능상의 자원을 소모한다. 그래서 결과세트가 동적일 때와 같은 필요한 경우에만 사용하는게 좋다.

[블로그 백업글][2005.11.22]
JDK1.4에서 소개된 내장된 로깅기능을 사용할때, 콘솔에 뿌려지는 것을 막기 위해 다음과 같은 방법을 사용하면 된다.

(JAVA_HOME)\jre\lib\logging.properties 파일을 열어서. 아래의 부분을

java.util.logging.ConsoleHandler.level = INFO java.util.logging.ConsoleHandler.level = OFF

[블로그 백업글][2005.11.21]

원제는 Twelve Best Practices for Spring XML Configuration Files 이다.
원문의 위치는 http://lizjason.com/blog/?p=12


Spring은 강력한 자바 애플리케이션 프레임워크이고 자바 애플리케이션의 넓은 범위에서 사용된다. 이것은 단순함과 테스트의 용이성을 달성하기 위해 의존성삽입(Dependency Injection)을 사용한다. 의존성과 bean생성은 XML설정파일에 대개 명시된다. XML설정은 장황하고 큰 프로젝트에서는 관리하기가 어려울수도 있다. 설정파일의 가독성과 관리의 용이성이 고려되는 만큼, 나는 다음의 사항이 매우 유용하리라고 생각한다.

1. autowire를 사용하지 말라.
내 의견에서, autowire는 시장광고용(marketing) 기능이다. 이것은 실제 프로젝트에서 결코 사용되지 말아야 한다. 이것은 몇몇 타이핑의 수고와 설정조각을 줄이지만, 명백함과 설정의 유지보수성을 희생한다.


2. 명명 규칙을 사용하라.
이것은 자바코드와 같은 의도이다. 예를 들면 bean id를 위해, 당신은 자바 클래스 필드 명명규칙을 따를수 있다. OrderServiceDAO의 인스턴스를 위한 bean id는 orderServiceDAO가 될것이다.

3. 단축형태(shortcut forms)를 사용하라.
단축형태는 자식요소에서 속성으로 프라퍼티값과 참조를 이동시켜 다소 덜 장황하게 만든다. 이 단축형태는 1.2버전 이후 지원된다.

단축형태는 다음과 같은 기능이다. 1.2이전버전에서는 다음과 같이 셋팅한다.

<bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"> <property name="driverClassName"><value>com.mysql.jdbc.Driver</value></property> <property name="url"><value>jdbc:mysql://localhost:3306/mydb</value></property> <property name="username"><value>root</value></property> </bean>

1.2이후 단축형태를 사용하면 다음과 같이 셋팅이 가능하다.

<bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"> <property name="driverClassName" value="com.mysql.jdbc.Driver" /> <property name="url" value="jdbc:mysql://localhost:3306/mydb" /> <property name="username" value="someone" /> </bean>
4. 인자를 맞추기 위한 인덱스보다 타입을 선호하라.
인덱스를 사용하는 것은 때때로 다소 덜 장황하게 만든다. 하지만 이것은 에러를 좀더 생성하고 읽기 어렵다.

다음의 소스는 인덱스를 사용하는 예제이다.

<bean id="billingService" class="com.lizjason.spring.BillingService"> <constructor-arg index="0" value="lizjason"/> <constructor-arg index="1" value="100"/> </bean>

하지만 다음처럼 타입을 사용하는 것이 추천한다.

<bean id="billingService" class="com.lizjason.spring.BillingService"> <constructor-arg type="java.lang.String" value="lizjason"/> <constructor-arg type="int" value="100"/> </bean>

5. 가능하다면 bean정의를 재사용하라.
당신은 중복을 제거하기 위한 기법처럼 상속을 사용할수 있다. 당신이 할 필요가 있는 모든것은 상위 bean에 abstract=true를 명시하고 자식 bean에 parent참조를 두는 것이다. 당신이 클래스나 factory메소드를 명시하지 않는다면, bean은 함축적으로 abstract상태가 된다.

예를 들면 다음과 같이 셋팅한다.

<bean id="txProxyTemplate" abstract="true" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"> <property name="transactionManager"> <ref bean="transactionManager" /> </property> <property name="transactionAttributes"> <props> <prop key="save*">PROPAGATION_REQUIRED</prop> <prop key="remove*">PROPAGATION_REQUIRED</prop> <prop key="*">PROPAGATION_REQUIRED,readOnly</prop> </props> </property> </bean> <bean id="userManager" parent="txProxyTemplate"> <property name="target"> <bean class="org.appfuse.service.impl.UserManagerImpl"> <property name="userDAO" ref="userDAO" /> </bean> </property> </bean>

6. import 보다는 ApplicationContext를 통해 bean정의를 조립(assembling)하는 것을 선호하라.
Ant스크립트내 import처럼, 그것들은 모듈화된 bean정의를 조립하는데 유용하다. 어쨌든, 이것은 ApplicationContext를 통해 그것들을 조립하기 위해 좀더 유연하다. 당신은 ApplicationContext의 생성자를 위해 bean정의의 배열을 전달할수 있다.

다음은 import를 조합하여 xml을 설정하는 소스이다.

<beans> <import resource="billingServices.xml"/> <import resource="shippingServices.xml"/> <bean id="orderService" class="com.lizjason.spring.OrderService"/> <beans>

import를 사용하여 xml을 조합하는 방식보다는 아래와 같이 ApplicationContext를 사용하는 것이 좀더 유연한 개발을 도와준다.

String[] serviceResources = {"orderServices.xml", "billingServices.xml", "shippingServices.xml"}; ApplicationContext orderServiceContext = new ClassPathXmlApplicationContext(serviceResources);

7. 가능하다면, bean 확인자로 id를 사용하라.
id를 사용하는 것은 가독성을 증가시키지 않는다. 하지만 이것은 bean참조를 확인하기 위해 XML파서에 영향을 끼칠수 있다. 만약 id가 XML IDREF제한을 위해 사용될수 없다면, 당신은 이름(name)을 사용할수 있다.

8. 개발시에는 의존성체크(dependency-check)를 사용하라.
당신은 bean정의의 dependency-check속성을 디폴트인 none이 아닌 다른값으로 셋팅할수 있다. 그래서 컨테이너는 당신을 위해 의존성체크를 할수 있다.

<bean id="orderService" class="com.lizjason.spring.OrderService" dependency-check="objects"> <property name="companyName" value="lizjason"/> <constructor-arg ref="orderDAO"/> </bean>

9. 각각의 XML파일을 위해 헤더(header) 주석을 추가하라.
XML파일내 내부 주석대신에 서술적인 id와 name을 사용하는것이 선호된다. 어쨌든, 각각의 파일이 정의된 bena을 요약하는 헤더를 가진다면 이해하기가 쉽다.

<beans> <description> 이 파일은 거래(billing) 서비스 관련 bean을 정의하고 서비스 bean템플릿을 제공하는 baseService.xml파일을 의존한다. </description> ... </beans>

10. 변경을 위해 팀멤버간 의사소통을 하라.
당신이 자바소스코드를 리팩토리할때, 당신은 설정파일을 그 상황에 따라 변경하고 팀멤버에게 알릴 필요가 있다.

11. 생성자 삽입(constructor injection)보다 setter 삽입(setter injection)을 선호하라.
생성자 삽입은 bean들이 비정상적인 상태에서 생성될수 없다는 것을 확인할수 없다. 하지만 setter 삽입은 좀더 유연하고 관리가 가능하다. 특히 클래스가 다중 프라퍼티를 가진다면 더욱 그러하다.

다음은 생성자 삽입을 사용하는 예이다.

<bean id="orderService" class="com.lizjason.spring.OrderService"> <constructor-arg ref="orderDAO"/> </bean>

다음은 setter삽입을 사용하는 예이다.

<bean id="billingService" class="com.lizjason.spring.BillingService"> <property name="billingDAO" ref="billingDAO"> </bean>

12. 의존성 삽입을 남용하지 말라.
마지막에, Spring ApplicationContext는 당신을 위해 자바객체를 생성할수 있다. 하지만 모든 자바객체가 의존성삽입을 통해서 생성될수는 없다. 기억하라. 강력한 IDE인 Eclipse와 IntelliJ를 사용하여, 자바코드는 좀더 읽고, XML파일보다 유지및 관리가 쉽다. 즉 의존성삽입을 설정하는 XML파일보다는 자바코드가 개발자의 입장에서는 가독성이 좋다.

오늘은 기분도 꿀꿀한게 왠지 낚시성 글을 올려보고 싶어서 제목을 저렇게 했는데, 역시 낚시성 글에는 소질이 없나 봅니다.

eclipse ganymede가 릴리즈가 임박했습니다.
아직 홈페이지는 저렇게 나오는데 Download Ganymede 버튼은 클릭이 되지 않습니다.

어제 저녁부터 firefox 3.0 릴리즈 소식으로 이런저런 사이트가 시끄럽습니다.
Eclipse Ganymede 도 이제 릴리즈를 눈앞에 두고 있습니다.
6월 25일 이니까.. 딱 일주일 남은 셈인가요..??

이런저런 릴리즈 소식은 개발자로 하여금 기대로 되게 하지만 일을 더 많이 많들기도 하네요.

Java로 DB프로그래밍을 작성하는 것이 불편한 면이 많이 있나 봅니다. 하긴 저도 Java에는 익숙한 편이지만 Java가 편하다 내지 간편하다라는 느낌을 항상 가지지는 못하는 것 같습니다. Java개발에 관련된 프레임워크에는 Presentation Layer에 해당되는 제품이 가장 많고 그 다음이 아마도 DB에 관련된 제품일것입니다. iBATIS도 있고 hibernate도 있고 나아가 TopLink 등등 다양한 제품이 있습니다.
그외 JEQUEL (Java Embedded QUEry Language), Quaere, EoD SQL 이라는 것도 있나 봅니다.
간단히 샘플 소스를 볼까요..?
아래는 일반적인 JDBC코드입니다.
public void printClassicRobots() { Calendar dobThreshold = new GregorianCalendar(1980, 0, 1); PreparedStatement statement = null; try { Connection connection = getConnection(); statement = connection.prepareStatement( "SELECT ID, Name" + " FROM Robots" + " WHERE DateOfBirth < ?"); statement.setDate(1, new Date( dobThreshold.getTimeInMillis())); ResultSet rs = statement.executeQuery(); while (rs.next()) { System.out.format("%08d: %s\n", rs.getInt(1), rs.getString(2)); } } catch (SQLException e) { e.printStackTrace(); } finally { cleanup(statement); } }
JEQUEL 라는 제품을 사용하는 샘플입니다.
public static class Robots extends BaseTable<Robots>{ public final Field<Integer> id = integer(); public final Field<String> name = string(); public final Field<Date> dateOfBirth = date(); { initFields(); } } public void printClassicRobots() { Calendar dobThreshold = new GregorianCalendar(1980, 0, 1); Robots robots = new Robots(); Sql query = Select(robots.id, robots.name) .from(robots) .where(robots.dateOfBirth.lt(named("dob"))) .toSql(); query.executeOn(getDataSource()) .withParams("dob", dobThreshold) .handleValues(new ValueRowHandler() { public void handleValue(int id, String name) { System.out.format("%08d: %s\n", id, name); } }); }
EoD SQL 샘플입니다. EoD의 경우에는 JDK 6의 초기 베타에 포함된 EoD라는 기능을 JDK 6 정식버전에는 제거된 것을 그대로 다시 구현한 것이랍니다. Sun에서 기능을 버렸다면 아무래도 이유가 있을텐데 말이죠.
public static class Robot { public int id; public String name; } public static interface RobotDAI extends BaseQuery { @Select("SELECT ID, Name FROM Robots " + "WHERE DateOfBirth < ?{1}") public DataSet<Robot> getRobotsOlderThan( final Date date); } public void printClassicRobots() { Calendar dobThreshold = new GregorianCalendar(1980, 0, 1); try { RobotDAI query = QueryTool.getQuery( getConnection(), RobotDAI.class); DataSet<Robot> robots = query.getRobotsOlderThan( dobThreshold.getTime()); for (Robot robot : robots) { System.out.format("%08d: %s\n", robot.id, robot.name); } } catch (SQLException e) { e.printStackTrace(); } }
재밌다는 생각이 드시지 않나요..?? 왠지 하나 만들어보고 싶은 충동을 느끼게 합니다.