달력

1

« 2021/1 »

  •  
  •  
  •  
  •  
  •  
  • 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
  •  
  •  
  •  
  •  
  •  
  •  
기다렸던 사람들이 많았을 것 같다. 이제야, 오늘에야 Spring 3.0.0 RC1이 나왔으니까 말이다. 물론 Toby(일민)이를 비롯한 몇몇 선행적인 개발자들이 이미 열심히 공부하고 있고, 이의 전달도 열심인 것에 비하면, 최근에 나는 크게 관심을 두려고 노력하지 않았다. 개인적으로는 다른 사업부로 옮겨와서, 새로운 일을 맡아서 관심이 적어진(?) 것도 있지만, 사실은 그것 보다도, 기존에 내가 만든 Framework는 스프링 2.5.5 또는 2.5.6을 기반으로 설계되어 있다. 그리고 이것을 이용하여 여러 솔루션들이 개발되고 있는 중이어서, 자체 개발한 Framework의 Minor 체인지가 아닌 Big 체인지를 결정하기 쉽지 않기 때문이다. 만약 그것을 결정해야 한다고 해도 2년 후가 될 것이다. (상품으로 그리고 서비스를 하고 있는 시스템을 변경하기란 많은 결정해야할 문제에 직면해야 하는 용기가 필요한다. 그러나 이것은 모험이 아니다.)

현재 Springframework에서 제공하고 있는 메이져 Branch는 2가지이지만 앞으로는 3가지가 될 것이다.
Springframework 1.2 와 2.5 그리고 향후 주축이될 3.0이다.
그리고 이제는 3.0 Release Candidate 1이 나왔다. 이제는 또 열심히 공부할 시점이 된 것이다.
여러가지 변경된 API라이브러리들도 있고, 추가된 라이브러리들이 있는데, 이중에서 가장 먼저 눈에 들어왔던 것은 Jackson JSON라이브러리이다. 이른 아침에 Jackson 투터리얼을 보면서 시간 가는줄 몰랐다.
앞으로 정식 버전이 나올날이 멀지 않았지만, 언제가 될지는 잘 모르겠다. 올해 안에는 나오지 않을지...

Springframework 3.0 RC1의 변경 사항은 다음의 링크를 보면된다.

그리고, 아래는 이번에 RC1에 추가된 내용이다.

Changes in version 3.0.0.RC1 (2009-09-25)
-----------------------------------------

* upgraded to CGLIB 2.2, AspectJ 1.6.5, Groovy 1.6.3, EHCache 1.6.2, JUnit 4.7, TestNG 5.10
* introduced early support for JSR-330 "javax.inject" annotations (for autowiring)
* introduced early support for JSR-303 Bean Validation (setup and MVC integration)
* added default editors for "java.util.Currency" and "java.util.TimeZone"
* refined PathMatchingResourcePatternResolver's treatment of non-readable directories
* PathMatchingResourcePatternResolver understands VFS resources (i.e. works on JBoss 5.x)
* revised AccessControlContext access from BeanFactory
* AbstractBeanDefinitionParser can deal with null return value as well
* PropertyOverrideConfigurer's "ignoreInvalidKeys" ignores invalid property names as well
* PropertyPlaceholderConfigurer supports "${myKey:myDefaultValue}" defaulting syntax
* BeanFactory's default type conversion falls back to String constructor on target type
* BeanFactory tries to create unknown collection implementation types via default constructor
* BeanFactory supports ObjectFactory as a dependency type for @Autowired and @Value
* BeanFactory supports JSR-330 Provider interface as a dependency type for @Inject
* BeanFactory prefers local primary bean to primary bean in parent factory
* protected @Autowired method can be overridden with non-annotated method to suppress injection
* private @Autowired methods with same signature will be called individually across a hierarchy
* @PostConstruct processed top-down (base class first); @PreDestroy bottom-up (subclass first)
* ConfigurationClassPostProcessor detect @Bean methods on registered plain bean classes as well
* support for default "conversionService" bean in an ApplicationContext
* MBeanServerFactoryBean returns JDK 1.5 platform MBeanServer for agent id "" (empty String)
* changed NamedParameter/SimpleJdbcOperations parameter signatures to accept any Map value type
* refined logging in JMS SingleConnectionFactory and DefaultMessageListenerContainer
* introduced "ui.format" package as an alternative to PropertyEditors for data binding
* @RequestMapping annotation now supported for annotated interfaces (and JDK proxies) as well
* @RequestParam and co support placeholders and expressions in their defaultValue attributes
* @Value expressions supported as MVC handler method arguments as well (against request scope)
* JSR-303 support for validation of @MVC handler method arguments driven by @Valid annotations
* refined response handling for @ExceptionHandler methods
* @ResponseStatus usage in handler methods detected by RedirectView
* all @SessionAttributes get exposed to the model before handler method execution
* @Event/ResourceMapping uniquely mapped to through event/resource id, even across controllers
* MultipartRequest is available as a mixin interface on (Native)WebRequest as well
* removed outdated "cacheJspExpressions" feature from ExpressionEvaluationUtils
* introduced common ErrorHandler strategy, supported by message listener container
* Jpa/JdoTransactionManager passes resolved timeout into Jpa/JdoDialect's beginTransaction
* HibernateJpaDialect applies timeout onto native Hibernate Transaction before begin call
* Spring's Hibernate support is now compatible with Hibernate 3.5 beta 1 as well
* Spring's JPA support is now fully compatible with JPA 2.0 as in EclipseLink 2.0.0.M7
* SpringJUnit4ClassRunner is now compatible with JUnit 4.5, 4.6, and 4.7
* SpringJUnit4ClassRunner once again supports collective timeouts for repeated tests
* deprecated @NotTransactional annotation for test classes in favor of @BeforeTransaction








Posted by 행복상자

댓글을 달아 주세요

지난번에 글을 쓸때는, 예상했던 것보다 시간이 많이 필요했는데, 어느덧 이른 6시, 출근할 시간이 되어서 이야기를 다 마무리 못하고 펜을 집어 넣어야만 했다.

지난번 글에서는 자바에서 Exception Handling이 어떻게 생성되고, 호출하는 코드로 어떻게 알려주게 되는지를 간략하게 이야기 하였다. (뭐 간략하다고 했지만, 이미 알고 있는 내용들이 었을 것이다.)
그리고 RuntimeException의 유형의 예외들은 컴파일러에서 신경을 쓰지 않기 때문에, 반드시 Try-Catch로 블록을 만들어 줄 필요가 없다는 것을 이야기 했다. (이 경우는 개발자가 코드상에서 해결해 주어야 한다는 것도 같이 이야기 했다.)

마지막으로, Eclipse와 같은 IDE에서 자동으로 생성되는 예외 처리 코드에 관해서도 이야기 했는데, 자동으로 생성되는 메커니즘도 이야기 했었는데, 더불어서 사용할 때 주의해야 할 것은 자동으로 생성된 코드로 인해서 예외처리가 끝났다고 착각하지 말아야 한다는 것이다. 실제 예외에 대해서 프로그램 또는 클래스에서 예외처리에 대한 코드가 들어가야하고, 이를 로그로 저장하거나 화면에 뿌려줄때는 좀더 사용자 친화적인 내용으로 저장하고, 보여주어야 추후에 유지보수하기 쉽다.

오늘은 이전에 시간이 모자라서 하지 못했던 이야기를 하려고 한다.
일반적으로 try-catch블럭의 사용을 잘 알고 있을 것이고, 더불어서 finally의 사용 또한 잘 알고 있을 거라 생각한다. 호출해야 할 코드는 try블록에다 정의하고 만약 예외가 호풀되면, 이를 제어하기 위해서 catch 블록에서 정의한 코드가 호출되고, 그리고 다시 코드가 실행된다. (try 블록에서 예외가 발생했던 코드 라인 이후는 호출이 되지 않는다.)

만약, 여기에 finally구문을 사용할 경우가 있는데, 아시다 시피 이는 try 또는 catch블록에 정의된 내용이 실행과 상관없이 정의되어 있다면 만드시 실횅되도록 정의되어 있다.
이 경우에 try 또는 catch구문에 return 문이 있다면 어떻게 될까?
try 또는 catch 블록에 return 문이 있다면, 일단 finally구문에 정의된 소소 코드들을 실행하고 나서 다시 return문으로 돌아 온다는 점에 유의 해야 한다.

예외도 객체이기 때문에 이를 상속받아서 새로운 예외들을 만들수 있다. 때문에 예외처리시에 아래와 같이 모든 예외를 한번에 다 잡을 수도 있지만, 이는 바람직하지 않다. 이전글에서 설명한 것처럼 어떤 메소드를 호출할때 어떤 메소드가 호출될 것인지가 클래스와 메소드 정의서가 정의된 문서를 보면 확인할 수 있다.

try {
      runAnyCode();
} catch (Exception ex) {
     recoveryCode();
}

위의 코드의 경우는 예외느 다 잡을수 있을지 모르지만, 어떤식으로 예외를 관리할지는 전혀 알수 없다. (물론 때에 따라서는 상위의 예외로 부터 하위의 것을 모두 잡는 것이 유용할 수도 있다. 따라서 유의해서 사용해야 한다.) 꼭 필요한 경우가 아니라면, 예외별로 잘 정의해서 사용해야 한다. 아래는 예이다.

try {
      runAnyCode();
} catch (anyCodeException aex) {
     recoveryCode();
}

마지막으로 정말 중요한 것은, 예외 처리에서 순서가 있다는 것이다.
그렇기 때문에 다중으로 예외를 선언한 경우에 주의가 필요하다. 만약 어떤 예외를 상속 받아서 새로운 Exception 들을 만들었다면, 상속 받았던 에외들을 먼저 선언해 주어야 한다. 그렇지 않다면, 원하지 안는 결과를 얻을 수도 있다.
왜냐하면, JVM 에서는 첫번째 Catch블록에서 부터 호출된 예외를 처리한 Catch블럭을 찾아 내려오기 때문이다. 만약 가능한 예외 블록이 있다면, 비교를 멈추고 catch블록에 정의된 예외처리 코드들을 실행하게 된다.
따라서 만약에 첫번째 catch블록이 catch(Exception ex)라고 정의되어 있다면, 컴파일러는 다른 catch블록이 전혀 필요 없다고 생각할 것이다. (왜냐하면 이외의 catch 블록의 코드는 전혀 실행되지 않을 것이기 때문이다.) 
아래 코드에서 어떤 코드는 실행되지 않을 까요? 
try {
      runAnyCode();
} catch (Exception ex) {
     recoveryCode();
} catch (anyCodeException aex) {
     recoveryCodeNotRun();
}

내가 하고 싶은 이야기는 사실 마지막에 이야기 하고 싶은 내용이었다. Exception에도 순서가 있고 진행되는 방향이 있다. 하지만 이를 모르고서 코드를 작성한다면 의미없는 코드를 생성하게 되고 결국은 나중에 코드의 문제를 찾는데 많은 시간을 들여야 한다는 것이다. 가장 기본 적인 이야기지만 간과하는 부분이기도 해서 이야기 하고 싶었다.

이전에 인도 개발자들이 만들어 낸 코드들 분석하면서, 내가 경험했던 것들인데, 예외 처리를 했기 때문에 문제가 없을 거라는 막연한 믿음보다는 예외처리시에 필요한 코드상에서 처리해 부분(RuntimeException)들과 catch문을 사용할 때도 우선 순위를 생각하면서 정의할 것등을 반드시 숙지해야한다.
무엇보다도 가장 판단하기 어려눈 것은 try-catch문을 아무 생각 없이 중첩해서 사용하는 경우인데, 이 경우는 가독성도 떨어지지만, 예외 처리 코드를 분석하기 매우 어렵기 때무에 되도록이면 피해야 한다.




Posted by 행복상자

댓글을 달아 주세요

일반적으로 자바에서는 C++와 마찬하지로 try catch 구문을 사용하여 예외 처리(exception handling)을 하게 되어 있다. 하지만, 개발자들이 잘 알지 못하고 사용한다면, 양날의 검처럼 작용할 수 도 있고, 유익하지 않을 수도 있다.

작년과 올 상반기까지 회의 연구소 인력들과 같이 협업하는 프로젝트가 있어서, 설계와 구현을 이들과 일정 부분 코드를 나누어서 진행하였다.
일반적으로 인도쪽 개발자들은 인건비가 싸고, 개인적인 개발 능력이 뛰어 나다고 알려져 있는데, 근 1년 이상 협업을 하면서 느낀점은 사실은 그렇지 않을 수도 있다는 것이다. 일반적으로 인도는 Windows 애플리케이션 개발과 C/C++ 을 잘사용하는 개발자들은 많기 때문에 쉽게 구할수 있기 때문에 그 중에는 능력있는 개발자들이 많이 있을수 있다. 하지만 Java라는 언어를 알고 있는 개발자는 적고, 그 중에서 웹과 J2EE의 영역들을 이해할 수 있는 개발자는 지극히 드물다. 따라서 실력있는 개발자를 Java쪽에서는 찾기가 매우 힘들다.

이야기가 길어졌는데, 인도 개발자들이 작성한 코드를 우리쪽에서 Prevent라는 툴을 이용하여 정적분석을 시켰는데, 몇가지 Critical한 내용들이 보고되었다. 그래서 이를 인도 개발자에게 코드 리뷰를 하고 수정하도록 했는데, 정적분석 수행시 마다, 동일한 위험요인에 대해 지속적으로 검출되었다. 개발자는 매번 확인하고 수정했고 코드에는 예외처리가 다 되어 있어서, 문제가 있을 수 없다고 했는데도 툴은 지속적으로 문제점을 검출하고 있었다. 그래서 결국은 내가 그들이 작성한 코드를 분석하고 리뷰를 하였는데, 여러 면에서 놀라야만 했다.
이들은 자바 프로그래밍에 대한 초보자들이었다. 거의 C/C++ 방식의 코딩과 Excepion 처리를 통한 회피에만 집중하고 있었다. 너무나도 복잡하고 다중적인 예외처리 문을 사용하는 것에 대해서 혀를 내둘러야 했다. 일단 좋은 코드는 보기도 좋아야 하는데, 무슨일을 하고 무엇을 말하려고 하는지 알수 없을 정도록 예외 처리문을 반복적으로 사용하였다. 어떤 식으로든 예외를 처리하고 나오도록 코드는 되어 있지만, 몇가지 간과한 점들이 있었는데, 그 중에 중요한 점은 예외 처리에도 순서가 있다는 것이다.

예외 처리(exception handling)시에도 지켜주어야할 순서거 있고, 이를 잘못하면 원하는 결과를 얻을 수 없을 뿐더러, 코드가 복잡해 진다.

일반적으로 예외를 처리한다는 것은 어떤 메소드를 호출하고 실행할 때, 그 메소드가 어떤식으로 동작할지 아로 있어야 한다. 이는 메소드가 결과값을 반환할 뿐만 아니라, 어떠한 경우에 예외를 호출할지를 정확히 알고 있어야 한다. 

예를 들어 "java.lang.ClassLoader"라는 클래스를 사용하려고 한다면, 이 API는 아래와 같이 정의된다.

loadClass

public Class <? > loadClass(String  name)
                   throws ClassNotFoundException 
지정된바이너리명을 가지는 클래스를 로드합니다. 이 메소드는,loadClass(String, boolean) 메소드와 같은 방법으로 클래스를 검색합니다. Java 가상 머신이 이 메소드를 호출해, 클래스 참조를 해결합니다. 이 메소드를 호출하는 것은,loadClass(name, false) 를 호출하는 것에 상당합니다.

파라미터:
name - 클래스의바이너리명
반환값:
결과적으로 얻을 수 있는 Class 객체
예외:
ClassNotFoundException - 클래스가 발견되지 않았던 경우

위처럼 정의되는 API는 실행해서 결과값을 정상적으로 반환하고, 만약 실행 중에 문제가 될 경우, 이를 어떤식으로 호출하는 메소드에 알려 줄지를 정의하고 있는 경우이다. 위의 예제는 ClassLoder 클래스를 실행시 클래스가 발견되지 않는 경우에 "ClassNotFoundException"이 호출된다.
따라서 위와 같은 명세를 정확히 개발자가 알고 있어야 메소드 호출시에 어떻게 동작할지를 예측하고 코드를 작성할 수 있다.

try-catch 구문을 사용하는 것은 호출할 메소드에서 예외를 발생시킬수 있다는 것을 알고, 이를 컴파일러에 알려주는 역할을 하는 것이다. 그리고 이때 호출되는 exception도 객체로 정의되어 사용되어 진다.
그렇다면, Exception 객체는 어디에서 정의 되는 것일까? 이 객체는 개발자가 사용하고자 하는 메소드에서 정의되게 되는데, 메소드에서 "throws"구문을 찾으면 된다. 이렇게 정의된 예외는 예외가 정의된 메소드를 를 호출하는 곳으로 던져지게 된다.

자바 개발자들이 많이 사용하는 Eclipse와 같은 IDE에서는 어떤 메소드를 호출할 때 자동으로 try-catch문으로 호출하는 메소드를 감싸주는 기능을 자주 사용하게 된다. 이는 내부적으로 호출되는 메소드 내부에 "throw"구문이 호출된다는 것을 IDE툴이 알고 있기 때문이다.

한가지 더 나아가서, 자동으로 생성하는 예외코드는 보통 아래의 예외 같은 형태로 IDE상에 추가된다.
java.io.File file = new java.io.File("c:\\test.txt");
try{
    file.getCanonicalFile();
catch (IOException e) {
    e.printStackTrace();
}

한가지 주위해야 하는 것은 위와 같이 "e.pringStackTrace()"를 툴에서 자동으로 생성해 주었다고, 예외 처리가 모두 끝나는 것이 아니다. 
1. 위에서 처리해야할 예외에 대한 후 작업이 있다면 코드를 생성해 주어야 한다.
   ==> 이것은 대부분의 개발자들이 잘하고 있다.
2. 위의 예외를 Log에 남길지를 결정해야 한다. 
   ==> 이 부분은 개발자와 개발팀 내부의 결정에 따라서 정리하면 된다.
3. 위와 같은  형태가 아니라, 개발자가 나중에 알수 있는 형태의 메시지 형태로 재 정의 해서
    메시지를 뿌려 주어야 한다.
   ==> 결국은 개발자가 어떤 상황에서 에러가 발생했는지를 알수 있어야 하고, 이를 로그로
        남겨야 후처리에 도움이 될 것이다.
위와 같이 간략하게 3가지로 정리하였지만, 대부분(?)의 개발자들이 IDE툴에서 제공하는 원형 그대로의 메시지를 사용한다. Log를 남길때도 "e.printStackTrace()"의 원형 그대로 남기는데, 어떤 경우에 예외가 호출되었는지에 대한 정보를 남겨주어야 제대로 된 예외처리라 할 수 있다.

컴파일러에서는 RuntimeException과 특수한 유형을 제외한 Exception을 관리하게 되는데, RuntimeException을 확장한 예외 클래스는 그냥 모두 통과된다. (자동으로 무시된다는 의미)
이는 대부분의 RuntmeException들은 실행 중에 어떤 조건에 문제가 생기는 경우보다는 코드의 논리에 예측 및 예방할수 없는방시으로 문제가 생기는 경우에 발생하기 때문이다.
예를 들면, 배열에서 인덱스의 범위를 벗어났는지에 대해서는 배열의 길이(Size 또는 Length)를 이용해서 확인하고 방지할 수 있다.

예외 처리에 대해서, 이야기 했는데 아직 내가 하고 싶은 이야기에는 도달하지 못했다. 이는 다음에 계속 이어서 말하려 한다.

Posted by 행복상자

댓글을 달아 주세요

미국 시간으로 지난 9월3일 (한국 시간으로 9월 4일)자로 Release 되었다. 이번에 릴리즈된 버전은 Java와 Python 버전으로 각각 제공되는데, 이는 XAPP를 지원하기 위한 것이다.
XMPP는 eXtensible Messaging and Presence Protocol (XMPP) 로 알려져있는 XML기반의 Real time Messaging 서비스이다.

아래의 링크에서 다운로드 하면된다.
- Download: http://code.google.com/p/googleappengine/downloads/list

이번 1.2.5 릴리즈에 포함된것은 그동안 이슈트랙커에 올라온 신규 기능들에 요청중에 많은 사람들의 우선적으로 지원해 주기를 바랬던 기능이었기 때문이이다.

이번에 제공되는 새로운 API들을 이용하면, XMPP기반의 네트워크 프레임워크 상에서 다른 사용자들과 메시지 교환이 가능해 진다. Google Talk와 Google Wave와 같은 Application 과도 마찮가지로 메시지를 교환할 수 있다.

다음 링크를 살려보면, Google App에 포함된 XMPP의 간략한 설명과 예제를 살펴볼수 있다. Java와 Python버전이 있다.

- Java: http://code.google.com/intl/ko-KR/appengine/docs/java/xmpp/
- Python: http://code.google.com/intl/ko-KR/appengine/docs/python/xmpp/

위 링크들을 따라가면, 예제를 살펴볼수 있는데, 코드와 이를 App Engine에서 사용하기 위해서 Config에 추가할 내용들이 있는데, 이는 간단하지만, 주의 깊게 살펴볼 필요가 있다.

그리고, 마지막으로 googlel app engine의 API들은 제약조건들이 있는데, 이것들을 잘 살펴보아야 한다.
예전에 Twitter의 Open API를 테스트하다 보니, 테스트 코드를 몇번 실행을 안했는데, 계속 서버에서 블록킹 되고 결과는 정상적으로 나오지 않았던 적이 있었다. 알고보니 트위터에서는 시간당 100개의 Request와 하루에 2000개의 Request를 사용할 수 있다는 제약이 있었다.

Quter와 제약에 대한 내요은 아래와 같다.

Each XMPP service request counts toward the XMPP API Calls quota.

Each outgoing XMPP chat message counts toward the following quotas:

  • XMPP Data Sent
  • XMPP Recipients Messaged
  • Outgoing Bandwidth (billable)

Each outgoing XMPP chat invitation counts toward the following quotas:

  • XMPP Data Sent
  • XMPP Invitations Sent
  • Outgoing Bandwidth (billable)

Each incoming XMPP message counts toward the following quotas:

  • CPU Time (billable) (50 ms/message)
  • Requests
  • Incoming Bandwidth (billable)

Computation performed in a request handler for incoming XMPP messages applies toward the same quotas as with web requests and tasks.

For more information on quotas, see Quotas, and the "Quota Details" section of the Admin Console.

In addition to quotas, the following limits apply to the use of the XMPP service:

Limit Amount
incoming message size 100 kilobytes
outgoing message size 100 kilobytes


Posted by 행복상자

댓글을 달아 주세요