'2010/03'에 해당되는 글 4건
- 2010/03/26 갑자기 Ant task를 실행했는데 콘솔에 아무런 메세지가 안 나올 때는 이렇게 하세요!
- 2010/03/25 오랜만에 자기 전 담소... (2)
- 2010/03/22 Bean Validator 확장 방법
- 2010/03/16 새로운 교육에 대한 의견수렴 합니다.
가끔 이런 일이 있습니다.. import한 프로젝트거나 이클립스를 업그레이드 했거나, 때로는 따로 변경한게 없는 것 같은데 갑자기 태스크를 실행해도 이상하게 콘솔에 아무런 메세지가 나오지 않을 때가 있습니다.
저는 주로 이클립스를 업그레이드 했을 때와 Ant(+ivy, grand등) 라이브러리 업데이트 시에 겪었었는데요..
해결책은 간단합니다. 실행하는 앤트 태스크가 돌아가서,
JVM을 웍스페이스에서 사용하는 JVM과 동일한 JVM으로 맞춰주시면 됩니다.
최소한 이틀에 하나씩은 블로그 글쓰자고 마음을 먹었지만 쉽지 않군요..
물론 블로그가 삶의 목적이 아니기에 크게 신경쓰지는 않습니다^^;
요즘들어 이런 저런 생각을 많이 하게 되는데..
삶이란게 일관된 생각을 가지고 살아가기 쉽지 않다는 거..
그만큼 유혹에 약한게 사람이고.. 내제적이든, 외부적인 요인든..
개인의 고민을 결정하는데 고려해야 할 점이 이렇게 많은데,
조직이나 집단이 처한 문제는 더 심하겠죠..
이해관계란게 있을테고..
해오던 '형태'가 있을테니..
누구나 개선해야 할 점으로, 현재 발생하는 문제의 원인이라고 말하지만 어느 누구도 고치려 하지 않는 그런 문제요..
누군가 나서면 오해의 소지가 되기도 하고 말이죠..
무언가 그럴싸한 말로 풀어내기에는 아직 겪어봐야 할 일들이 너무 많습니다..
'일관 된 꿈'을 향해 '더 많은 세상'을 겪어 보기 위해 움직일 필요가 있습니다..
조직이 힘들면, 저 자신이라도 움직여야죠.
처음에 가졌던 원대한 꿈은 펼쳐 놓을 수 있는 상황이 될때까지 잠시 가슴 속에 간직하고 말이죠..
아니, 그 꿈을 목적으로 더 나아가는 거겠네요..
그건 그거고,
다음 주면 10달간 일뿡맘 배 속에서 조용히 지내던 우리 일뿡이가 세상에 나올 때가 됩니다.
아이가 작아서 조금 늦게 나올 듯하기는 한데, 건강히 나오기를 바랄 뿐입니다!
3번째 스프링 강의도 무사히 저번 주에 마쳤습니다.
3번째라 따로 후기를 쓸건 없을 것 같고.. 그 보다는 수강생 분들이 주신 피드백을 정리하고, 다음 번 강의(아니면 또 다른 강의)에 반영하면 될 것 같습니다. 열안한 조건(후반부로 갈수록 강의실이 너무 더웠습니다..)에서도 열심히 들어주신 수강생 분들께 감사 메일이라도 한 번 드려야겠네요..
번역은 막판을 향해 열심히 달리고 있는데, 다리는 열심히 움직이는 데 속력이 잘 나지 않네요.. 첫 도전이기에 완주를 목적으로, 그러나 부끄럽지 않은 내용이 되기 위해 열심히 하고 있으니 조만간 정리되지 않을까 싶습니다.(그랬으면 좋겠네요..)
이번 주부터 스프링과 삐리리 RIA와의 연계에 대해 정리도 시작했습니다. 제가 UI나 RIA에 관련된 지식이 없기도 하고, 실제로 그 기술 자체에 대한 기술보다는 실제 업무 시스템 개발할 때 이슈가 되는 꼭지에 대한 정리니 재밌는 결과가 나오면 공유할 수도 있겠죠^^.
주저리 말이 길어졌는데..
아마도 제가 '말'을 하고 싶었는지도 모릅니다..
제 모든 컨텍스트를 열어 놓고 자유롭게..
그럴 수 없기에 혼자 술 한 잔을 기울이는가 봅니다..(그래도 우리 일뿡이 나올때까지는 기다려야 합니다!)
무심코 들어왔다 무심코 쓰고 갑니다~
스프링 3.0에서는 "Bean Validation(이하 BV로 줄이겠습니다)"(JSR-303)을 @MVC와 연계하여 사용할 수 있도록 Hibernate Validator를 기반으로 하는 팩터리를 구현해 제공합니다. 물론, MVC 외의 모듈에서 Validator API를 통해 이용할 수도 있습니다.
BV의 명세를 잠깐 살펴봤는데 확장 방법이 어렵지 않고, 단순한 검증 뿐만 아니라 데이터베이스와 연계한다던지 부가 정보를 내린다던지 등 다양하게 구성할 수가 있을 것 같습니다. 자세한 내용은 조금 더 살펴보기로 하고 오늘은 강의 자료 겸 간단히 테스트 해본 확장 방법만 남겨두도록 하겠습니다.
검증을 확장하고 싶을 때작성해야 할 클래스는 간단히 두 가지 입니다.
첫 번째는 검증 대상을 지정할 때 사용할 애노테이션.
두 번째는 실제 검증 로직을 수행할 검증기(Validator).
제가 간단히 시험해본 검증 시나리오는 '특정 필드의 값이 데이터베이스에 이미 존재하는지 확인'하는 내용입니다.
먼저 이 시나리오에 적합한 이름을 선정해 애노테이션을 작성합니다.
@Documented
@Target( { ElementType.FIELD })
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = MenuNameConflictValidator.class)
public @interface Unique {
String message() default "메뉴 명이 중복되었습니다";
Class<?>[] groups() default {};
Class<? extends Payload>[] payload() default {};
}
@Constraint 애노테이션을 통해 실제 검증을 수행하는 검증기를 지정해주면 됩니다.
주의해야 할 점은 반드시 groups()와 payload()를 추가해야 합니다. 그렇지 않으면 왜 작동하는지 쉽게 알 수 없는 예외를 받게 됩니다.(그래서 처음에 조금 해맸습니다..)
그 다음으로는 검증기를 작성합니다.
public class MenuNameConflictValidator implements ConstraintValidator<Unique, String> {
@Autowired
private MenuDao dao;
@Override
public void initialize(Unique mark) {
}
@Override
public boolean isValid(String menuName, ConstraintValidatorContext context) {
if (dao.existMenuName(menuName) != 0) {
return false;
}
return true;
}
}
Menu라는 객체의 'menuName' 프로퍼티의 값을 중복 체크하는 로직입니다. isValid()에서 검증 로직 구현 후 통과 여부를 true/false로 지정하면 됩니다. 검증기 자체가 빈으로 등록되니 기존 서비스를 충분히 재활용할 수 있습니다. (다양한 표준/기술/기법과의 통합을 중요시 하는 스프링의 전략을 놀라울 따릅입니다..)
확장이 끝났습니다. 그럼 실제로 사용을 해봐야겠죠..
public class Menu implements Serializable {
@Unique
@NotNull
@Pattern(regexp = "[\uAC00-\uD7A3, a-z, A-Z, 0-9]+", message = "메뉴 이름에 영문,한글,숫자만 가능합니다!")
private String menuName;
}
menuName 프로퍼티는 기존의 유효성 검증 로직과 함께 확장한 @Unique 애노테이션을 통함 검증까지 함께 거치게 됩니다.
이상입니다.
그간 스프링 교육을 해왔지만 그보다 한 발 더 나아가고, 더 많은 고민을 통해 구성한 교육을 만들기 위해 의견 수렴을 합니다.
많은 의견 주세요.
감사합니다.
Prev
Rss Feed