달력

52024  이전 다음

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
[이전 블로그 백업글][2007.9.10]

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


AOP를 적용하기 위한 인터페이스입니다.


위 인터페이스를 구현한 클래스입니다.


다음은 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라는 글자를 포함하는 클래스의 모든 메소드가 실행시 자동으로 작동하게 됩니다.


실행을 시켜보기 위한 소스입니다. 다음처럼 실행하면 일단 concatService 아이디를 가지는 빈인 example.ConcatServiceImpl의 concat메소드가 작동하게 됩니다. 그리고 앞서 설정한 사항에 의해 각각의 AOP가 작동하게 됩니다.


결과물을 보면 다음처럼 작동하는것을 볼수 있습니다.


http://blog.interface21.com/main/2006/03/22/pojo-aspects-in-spring-20-a-simple-example/
Posted by fromm0
|
[이전 블로그 백업글][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인터페이스를 구현하는 클래스를 생성해야만 한다.

그리고나서, message제공자가 필요할 것이다. 이 코드는 Spring 2.0이전의 것과 같다. 그래서 당신이 이미 이 코드가 있다면, 어떠한 수정도 가하지 않아도 된다.

다음에, 이 bean으로 메시지를 보내는 MessageListenerContainer를 생성하기 위한 컨텍스트를 설정할 필요가 있다. 이 예제에서는 ActiveMQ구현물 클래스를 사용하여 알릴것이다. 이것은 많은 JMS구현물중 하나가 될것이다.

MQ가 시작될 필요가 있을것이고 main메소드가 컨텍스트에 시동될 필요가 있을것이다. 당신이 필요한 나머지 소스를 볼수 있도록 이 예제의 프로젝트를 제공한다.

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

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

내가 노트하고자 하는 하나는 Topic으로 동시 소비자를 사용하지 않는것을 확인하는 것이다. JMS Topic내에서, 모든 메시지가 Topic의 모든 소비자에게 전달되는 것을 기억하라. 이것은 topic에서 동시 소비자를 가진다면, 모든 소비자는 같은 메시지를 받을것이라는 것을 의미한다. 어쨌든, 당신이 queue를 사용한다면, 연속적인(round-robin) 방식으로 소비자에게 새로운 각각의 메시지를 분리시킬것이다.

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

원제는 Twelve Best Practices for Spring XML Configuration Files 이다.
원문의 위치는 http://lizjason.com/blog/?p=12
2006년 1월 26일 :
ONJava.com의 Twelve Best Practices For Spring XML Configurations 글을 기반으로 예제및 설명에 대한 일부 수정


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

1. autowire를 사용하지 말라.
내 의견에서, autowire는 시장광고용(marketing) 기능이다. 이것은 실제 프로젝트에서 결코 사용되지 말아야 한다. 이것은 몇몇 타이핑의 수고와 설정조각을 줄이지만, 명백함과 설정의 유지보수성을 희생한다.
trollswagen, naimdjon, Johannes Brodwall, 토지님께서 autowire는 오히려 xml이 커지면 커질수록 xml의 구조를 쉽게 파악하게 해주는 정말 좋은 기능중에 하나라는 의견을 주셨습니다. autowire에 관련된 사항은 프로젝트 도입시 장,단점을 다시 살펴 사용하길 권합니다.


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

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

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



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


4. 인자를 맞추기 위한 인덱스보다 타입을 선호하라.
인덱스를 사용하는 것은 때때로 다소 덜 장황하게 만든다. 하지만 이것은 에러를 좀더 생성하고 읽기 어렵다.

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



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



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

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



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

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



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



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

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



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



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

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

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



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



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