검색결과 리스트
2008/Spring Framework에 해당되는 글 33건
- 2008/12/22 Spring Portfolio 현황과 발전 방향 (2)
- 2008/12/17 Spring 프레임워크 관련 링크 모임
- 2008/12/15 스프링 프레임워크 오픈캐스트 시작
- 2008/12/08 JEE development and administration without J2EE Server
- 2008/11/28 스프링의 Common Annotations 1.0 지원 (2)
- 2008/11/25 "Spring Python" 파이썬 개발자에게도 봄(?)을
- 2008/11/20 스프링 구 버전(v2.5.4 이하)의 Java > JDBC 타입 변환 오류 (3)
- 2008/11/13 spring 소스를 대상으로 FindBugs 수행해보기 (5)
- 2008/11/12 Spring, Grails를 품에 안다
- 2008/11/06 KSUG 첫번째 웹비나(Webinar) 계획 중... (3)
- 2008/11/04 국내 기업 및 정부의 오픈소스에 대한 관심 증가
- 2008/10/01 Spring IDE 2.2 출시
- 2008/09/20 KSUG에서 9번째 세미나를 합니다
- 2008/09/08 The Essence of Spring (3)
- 2008/09/04 어떤 책으로 스프링 학습을 해야 할까요? (2)
- 2008/08/01 KSUG 스프링배치 연재 개시 (2)
- 2008/07/28 OSGi에 대한 메모
- 2008/07/22 [KSUG] 회사 전체가 쓰는 프레임웍을 만드는 팀에 바라는 점 (1)
- 2008/07/22 KSUG Forum에 올라온 글에 대한 애니프레임팀의 답변 (2)
- 2008/07/19 애니프레임을 위한 항변 (5)
- 2008/07/02 SDK(Software Development Kit) to SDK(Service Development Kit)
- 2008/06/30 KSUG 포럼 개설... 얼렁 모이세요~ (3)
- 2008/06/16 SDS의 스프링 기반 오픈소스 커뮤니티 개설 (5)
- 2008/06/09 KSUG 블로그 이전
- 2008/05/22 without EJB가 아닌 without Java EE (1)
- 2008/04/29 Spring Security 2.0 예제 (5)
- 2008/04/25 KSUG 7번째 모임은 자바지기와 함께
- 2008/04/21 SpringSource Tool Suite의 문제 해결 정보
- 2008/04/18 자바 개발자 직업 분류
- 2008/04/17 SpringSource의 상업화 전략에 대한 인터뷰 (1)
글
Spring Portfolio 현황과 발전 방향
2008/Spring Framework
2008/12/22 12:24
글
Spring 프레임워크 관련 링크 모임
2008/Spring Framework
2008/12/17 00:01
JCO에서의 인연을 통해 KOSTA 한국SW아키텍트 연합회에서 짧은 발표를 준비하는 과정에서 스프링의 이력을 돌아보다가 흥미로운 링크를 모아봅니다.
이력을 더듬을 수 있는 글
Spring Framework: The Origins of a Project and a Name
2004년 3월 Spring Framework 1.0 릴리즈를 알리는 TSS 기사1
2005년 5월 TSS에 올린 Rod Johnson의 Spring 소개 글
2006년 Jolt Award, Productivity Award Winners 수상(v1.2.6)
2006년 10월 2.0 출시 안내
Rod Johnson의 책을 설명하는 글
J2EE Development without EJB (1) - Why "J2EE Without EJB"?
J2EE Development without EJB (2) - Goal
J2EE Development without EJB (3) - Architecture
J2EE Development without EJB (4) - The Simplicity Dividened
J2EE Development without EJB (5) - EJB, Five Years On
J2EE Development without EJB (6) - Lightweight Container & IoC (이상 토비님)
Expert One-on-One: J2EE Development without EJB (장선진님)
SpringOne 발표 내용 설명
Spring One Americas 2008 리뷰 - 2. Rod Johnson의 기조연설(keynote)
Spring One Americas 2008 리뷰 - 1. SpringSource tc Server
Adrian Coyler 기조 연설 (SpringOneAmerica2008)
Simplifying JSF Development with Spring Faces
Spring One America 2008 참석기 링크 모음
The Spring Experience 2006 참관기
The Spring Experience 첫날
The Spring Experience 둘째날
TSE2006 셋째날 세션1 - Applying DDD int the Enterprise with AspectJ
The Spring Experience 셋째날 - TSE사람잡네
TSE2006 넷째날 세션1 - Meeting Requirements through Acceptance and Stress Testing
TSE2006 넷째날 두번째 세션 - ROO
The Spring Experience 마지막날
Rod Johnson의 Testing with Spring (토비님)
이력을 더듬을 수 있는 글
Spring Framework: The Origins of a Project and a Name
2004년 3월 Spring Framework 1.0 릴리즈를 알리는 TSS 기사1
2005년 5월 TSS에 올린 Rod Johnson의 Spring 소개 글
2006년 Jolt Award, Productivity Award Winners 수상(v1.2.6)
2006년 10월 2.0 출시 안내
Rod Johnson의 책을 설명하는 글
J2EE Development without EJB (1) - Why "J2EE Without EJB"?
J2EE Development without EJB (2) - Goal
J2EE Development without EJB (3) - Architecture
J2EE Development without EJB (4) - The Simplicity Dividened
J2EE Development without EJB (5) - EJB, Five Years On
J2EE Development without EJB (6) - Lightweight Container & IoC (이상 토비님)
Expert One-on-One: J2EE Development without EJB (장선진님)
SpringOne 발표 내용 설명
Spring One Americas 2008 리뷰 - 2. Rod Johnson의 기조연설(keynote)
Spring One Americas 2008 리뷰 - 1. SpringSource tc Server
Adrian Coyler 기조 연설 (SpringOneAmerica2008)
Simplifying JSF Development with Spring Faces
Spring One America 2008 참석기 링크 모음
The Spring Experience 2006 참관기
The Spring Experience 첫날
The Spring Experience 둘째날
TSE2006 셋째날 세션1 - Applying DDD int the Enterprise with AspectJ
The Spring Experience 셋째날 - TSE사람잡네
TSE2006 넷째날 세션1 - Meeting Requirements through Acceptance and Stress Testing
TSE2006 넷째날 두번째 세션 - ROO
The Spring Experience 마지막날
Rod Johnson의 Testing with Spring (토비님)
- 비록 링크는 깨져버렸지만, 포럼 이용자 질문에 답변한 Rod Johnson과 Juergen Hoeller의 글을 볼 수 있고, Spring in action의 저자 Craig Walls의 이름도 확인할 수 있다. [본문으로]
글
스프링 프레임워크 오픈캐스트 시작
2008/Spring Framework
2008/12/15 09:37
네이버 오픈캐스트에서 베타 테스터로 선정해주셨길래
스프링 프레임워크 캐스팅을 만들어서 발행해보았습니다.
오픈캐스트의 '오픈'의 의미는 아무래도 네이버 사용자에 한하나 봅니다.
구독버튼은 누르니 RSS가 아니라 로그인하라고 나오는군요.
(제 기준에) 열린 공간1이 아닌 네이버 커뮤니티에 스프링 사용자에게 정보를 전달하는 용도로 써봐야겠습니다.
스프링 프레임워크 캐스팅을 만들어서 발행해보았습니다.
오픈캐스트의 '오픈'의 의미는 아무래도 네이버 사용자에 한하나 봅니다.
구독버튼은 누르니 RSS가 아니라 로그인하라고 나오는군요.
(제 기준에) 열린 공간1이 아닌 네이버 커뮤니티에 스프링 사용자에게 정보를 전달하는 용도로 써봐야겠습니다.
글
글
스프링의 Common Annotations 1.0 지원
2008/Spring Framework
2008/11/28 07:30
Resource를 보고 그린 그림이다. javax.annotation 패키지에 있는 애노테이션 중심에는 Resource가 있다. javax.annotation 패키지의 다른 애노테이션은 컴포넌트 초기화에 관계된 것이다. (Generated 제외) 이들은 JSR-250(Common Annotations)으로 Java EE 5 에 처음 추가되었고, 다시 Java SE 6 에 포함되었다. 이들 중에서 스프링이 지원하는 애노테이션은 아래 세 가지이다.
이는 한 줄의 코드로 CommonAnnotationBeanPostProcessor를 등록하는 것만으로 가능하다.
<bean class="org.springframework.context.annotation.CommonAnnotationBeanPostProcessor" />
@Resource 의 경우 @Target이 TYPE, FIELD, METHOD 모두 가능한 것을 스프링은 매우 효과적으로 활용했다.
TYPE 타겟은 아래와 같이
@Resource
public class AccountRepositoryImpl ...
FIELD 타겟은 이렇게:
@Resource위와 같은 방법을 쓰면, 스프링 초기에 지적받던 setter-based injection은 immutability 저해도 막을 수 있다.
private DataSource dataSource;
METHOD 타겟은 이렇게 구현했다:
@Resource
public void setDataSource(DataSource dataSource)
스프링은 이들을 좀 더 확장한 애노테이션들을 제공한다.
자세한 사항은 InfoQ의 기사를 통해 살펴볼 수 있다.
글
"Spring Python" 파이썬 개발자에게도 봄(?)을
2008/Spring Framework
2008/11/25 07:30
글
스프링 구 버전(v2.5.4 이하)의 Java > JDBC 타입 변환 오류
2008/Spring Framework
2008/11/20 10:27
최근 스프링을 사용하는 고객이 다음과 같은 문제를 올렸다: Long 타입이 oracle에 integer로 맵핑되는 문제
DTO 객체에서 Long으로 정의한 필드 값이 insert나 update할 때 integer 처럼 들어간다는 것이었다.
확인해보니 integer 처럼이 아니라 Integer로 들어가게 되어 있었다. 동료가 문제를 찾았는데 내가 그 코드를 확인해보니 문제가 없었다. :) 로컬에 서로 첨부한 소스 버전이 달랐다. 구글링을 해보니 쉽게 버그 리포팅을 찾을 수 있었다: SPR-4840
javaTypeToSqlTypeMap.put(long.class, new Integer(Types.INTEGER));
javaTypeToSqlTypeMap.put(Long.class, new Integer(Types.INTEGER));
2.5.3 버전에서 버그를 찾은 Pavel Marinchev은 수정할 코드까지 제시했다:
javaTypeToSqlTypeMap.put(long.class, new Integer(Types.BIGINT));
javaTypeToSqlTypeMap.put(Long.class, new Integer(Types.BIGINT));
StatementCreatorUtils 클래스 소스를 보면 정적 블럭으로 초기화하는 코드 중에 이를 볼 수 있다. 아쉽게도 해당 버그에 대한 테스트 코드1는 찾을 수 없었지만, 2.5.5 ChangeLog에서 변경사항을 찾을 수 있었다:
* BeanPropertySqlParameterSource uses specific integer/decimal SQL types by default now (e.g. TINYINT, BIGINT, DOUBLE)
spring.jar 라는 jar 파일만 보면 버전을 알 수 없다. Manifest를 열어보니 2.5.4 임을 확인할 수 있었다. 이럴 때는 번거롭더라도 Maven을 사용하여 라이브러리를 명시적으로 관리하는 것이 이점이 있어 보인다. 일민형이랑 채팅하다가 'jar 버전 테스트를 해야 한다'는 말에 바로 테스트를 추가하기로 했다. 권남님한테 배운 것인데 SpringVersion 클래스를 이용하면 매우 쉽게 테스트 작성이 가능했다.
참고로 2.5.6 과 2.5.4 버전에서 위에 언급한 코드 차이를 보여주는 부분을 첨부한다.
DTO 객체에서 Long으로 정의한 필드 값이 insert나 update할 때 integer 처럼 들어간다는 것이었다.
확인해보니 integer 처럼이 아니라 Integer로 들어가게 되어 있었다. 동료가 문제를 찾았는데 내가 그 코드를 확인해보니 문제가 없었다. :) 로컬에 서로 첨부한 소스 버전이 달랐다. 구글링을 해보니 쉽게 버그 리포팅을 찾을 수 있었다: SPR-4840
javaTypeToSqlTypeMap.put(long.class, new Integer(Types.INTEGER));
javaTypeToSqlTypeMap.put(Long.class, new Integer(Types.INTEGER));
2.5.3 버전에서 버그를 찾은 Pavel Marinchev은 수정할 코드까지 제시했다:
javaTypeToSqlTypeMap.put(long.class, new Integer(Types.BIGINT));
javaTypeToSqlTypeMap.put(Long.class, new Integer(Types.BIGINT));
StatementCreatorUtils 클래스 소스를 보면 정적 블럭으로 초기화하는 코드 중에 이를 볼 수 있다. 아쉽게도 해당 버그에 대한 테스트 코드1는 찾을 수 없었지만, 2.5.5 ChangeLog에서 변경사항을 찾을 수 있었다:
* BeanPropertySqlParameterSource uses specific integer/decimal SQL types by default now (e.g. TINYINT, BIGINT, DOUBLE)
spring.jar 라는 jar 파일만 보면 버전을 알 수 없다. Manifest를 열어보니 2.5.4 임을 확인할 수 있었다. 이럴 때는 번거롭더라도 Maven을 사용하여 라이브러리를 명시적으로 관리하는 것이 이점이 있어 보인다. 일민형이랑 채팅하다가 'jar 버전 테스트를 해야 한다'는 말에 바로 테스트를 추가하기로 했다. 권남님한테 배운 것인데 SpringVersion 클래스를 이용하면 매우 쉽게 테스트 작성이 가능했다.
assertEquals("2.5.6", SpringVersion.getVersion());
참고로 2.5.6 과 2.5.4 버전에서 위에 언급한 코드 차이를 보여주는 부분을 첨부한다.
- 스프링은 종종 이슈/버그에 대해 별도의 테스트 메소드를 만들어두기도 한다. 매우 훌륭한 프랙티스인데 조만간 관련 글을 쓸 것이다. [본문으로]
글
spring 소스를 대상으로 FindBugs 수행해보기
2008/Spring Framework
2008/11/13 07:59
스크롤 해야 할 만큼 많은 버그가 보인다. 물론, 상당부분이 테스트 코드에서 발생한 것이지만, spring 코드에도 버그가 꽤 있다. 코드를 드려다보면 '과연 이를 버그라고 해야 하나' 의문이 드는 것도 있다. FindBugs는 소스코드를 분석하여 버그 혹은 버그로 의심할 수 있는 코드를 찾는데 도움이 되기는 하지만 만병통치약은 아니다.
글
Spring, Grails를 품에 안다
2008/Spring Framework
2008/11/12 10:32
글
KSUG 첫번째 웹비나(Webinar) 계획 중...
2008/Spring Framework
2008/11/06 01:59
웹과 세미나의 장점만 모은 웨비나(webinar)
아직 KSUG에 공지도 하지 않았는데 일민형이 정보를 흘렸다. 마치 내가 바쁘단 핑계로 안할까봐 못을 박으려는 듯.. ^^
잘 정제한 내용이지만, 좀 더 리얼하게는 이렇다. 어제 오후 요구사항 큰 축을 변경하여 WBS를 새로 짜야 하느라 고민하고 있는데, 호주에서 토비옹이 채팅으로 대뜸 스크린캐스트 대신에 웨비나를 하라고 독촉했다. 순간 머리속에는 '새로운 시도를 할 때 들어가는 노력', '토비옹이 딴지 걸 것을 대비한 부가적인 사전 준비', '시청자가 필요한 웨비나 특성상 공지하고 반응을 기다려야 하는 부담' 등이 스쳐갔다. 그래도, 자꾸 권유를 하니까. 동영상 녹화의 최대 단점이 떠올랐다. NG가 나면 다시 해야 하는 것과 피드백이 없는 것. 지난 IBM DW 시리즈의 경우 3편은 듣기에 거불할 정도였는데, 늑장 등록을 해서 확인을 못해봤다. 그럼에도 불구하고 중간중간 실수한 부분 때문에 다시 녹화했다.1 그렇게 놓고보면 시간대가 문제지 웹비나가 비용 대비 효과가 좋은 듯 하다. 일민형이 좋은 툴을 발견했고 테스트도 해봤고, 단기간 무료로 쓸 수가 있다. 영구적으로 웹비나를 하려면 비용이 꽤 필요하다. 공언한 바대로 KSUG에서 자체 마련하거나 기업에서 필요한 웹비나를 해주고 후원을 받거나 해야 할 듯 하다.
웨비나 주제는 @MVC 즉, 스프링 2.5 스타일의 MVC 구현이다. 기존에 Spring MVC를 써본 분이라면 뭐가 달라졌는지를 데모를 통해 보여드릴 예정이다. Spring MVC를 안 써본 분이라면 Strut류의 타 MVC에 비해 스프링 MVC가 얼마나 유연하고 똑똑한지 확인하는 자리가 될 것이다. 관심있는 분들은 시청하고 싶은 시간대를 올려주시면 참고가 될 듯 하다. 대강 다음 주에 진행할 것인데, 주중이며 늦은 밤이고... 이번주 일요일도 가능은 한데.. 아직 모르겠다.
그래서... 관심 있는 분들은 여기서 혹은 블로그 댓글로 의견 주세요.
아직 KSUG에 공지도 하지 않았는데 일민형이 정보를 흘렸다. 마치 내가 바쁘단 핑계로 안할까봐 못을 박으려는 듯.. ^^
KSUG 지난 세미나에 개인사정으로 SpringMVC관련 세션의 발표를 못했던 영회가 그 내용을 스크린캐스트로 대신 제작해
공개하기로 했는데, 그 보다는 웨비나다 더 낫겠다는 쪽으로 생각을 바꾼 듯 하다. 다음 주중에 진행한다고 하니 많은 기대와
참여가 있으면 좋겠다. 장소의 제약은 없어졌지만, 남은 문제가 시간인데 아무래도 한국은 업무시간 중에 참석이 용이하지 않은
사람들이 많으니 저녁이나 밤시간을 이용하지 않을까 싶다.
잘 정제한 내용이지만, 좀 더 리얼하게는 이렇다. 어제 오후 요구사항 큰 축을 변경하여 WBS를 새로 짜야 하느라 고민하고 있는데, 호주에서 토비옹이 채팅으로 대뜸 스크린캐스트 대신에 웨비나를 하라고 독촉했다. 순간 머리속에는 '새로운 시도를 할 때 들어가는 노력', '토비옹이 딴지 걸 것을 대비한 부가적인 사전 준비', '시청자가 필요한 웨비나 특성상 공지하고 반응을 기다려야 하는 부담' 등이 스쳐갔다. 그래도, 자꾸 권유를 하니까. 동영상 녹화의 최대 단점이 떠올랐다. NG가 나면 다시 해야 하는 것과 피드백이 없는 것. 지난 IBM DW 시리즈의 경우 3편은 듣기에 거불할 정도였는데, 늑장 등록을 해서 확인을 못해봤다. 그럼에도 불구하고 중간중간 실수한 부분 때문에 다시 녹화했다.1 그렇게 놓고보면 시간대가 문제지 웹비나가 비용 대비 효과가 좋은 듯 하다. 일민형이 좋은 툴을 발견했고 테스트도 해봤고, 단기간 무료로 쓸 수가 있다. 영구적으로 웹비나를 하려면 비용이 꽤 필요하다. 공언한 바대로 KSUG에서 자체 마련하거나 기업에서 필요한 웹비나를 해주고 후원을 받거나 해야 할 듯 하다.
웨비나 주제는 @MVC 즉, 스프링 2.5 스타일의 MVC 구현이다. 기존에 Spring MVC를 써본 분이라면 뭐가 달라졌는지를 데모를 통해 보여드릴 예정이다. Spring MVC를 안 써본 분이라면 Strut류의 타 MVC에 비해 스프링 MVC가 얼마나 유연하고 똑똑한지 확인하는 자리가 될 것이다. 관심있는 분들은 시청하고 싶은 시간대를 올려주시면 참고가 될 듯 하다. 대강 다음 주에 진행할 것인데, 주중이며 늦은 밤이고... 이번주 일요일도 가능은 한데.. 아직 모르겠다.
그래서... 관심 있는 분들은 여기서 혹은 블로그 댓글로 의견 주세요.
- 녹화가 거의 끝날 무렵 어머니가 과일을 들고 와서 책상에 내려놓으며, 왜 대답을 안하냐고 해서 처음부터 다시하기도 했다. ㅡㅡ; [본문으로]
글
국내 기업 및 정부의 오픈소스에 대한 관심 증가
2008/Spring Framework
2008/11/04 12:41
토비님이 쓴 기업의 오픈소스제품 공개라는 글을 보니 NHN에서 인수한 제품들을 오픈소스로 공개하는 모양이다. 토비형이 인용한 글을 보면 담당자가 현황을 잘 모르는 것 같다.
'전혀 없다'는 표현은 SDS 애니프레임 공개에 힘을 써온 사람들을 서운하게 할지도 모른다. 공개하는 규모가 어느 정도인지 모르지만, 이미 지난 6월에 SDS에서 공개한 애니프레임 역시 작은 규모는 아니다. 기자의 해석인지, SDS 담당자의 의견인지 모르지만, 기사를 보면 다음과 같이 말하고 있으니까.
기업은 자사의 이익을 위해 행동하게 되어 있지만, 어떤 형태로든 기업이 오픈소스를 활용한다는 측면은 분명 긍정적인 것 같다. 그런 점에서 한중일 3국이 협력하려는 조짐도 눈에 띄고, 정부 부처에서 기업의 오픈소스 활용을 적극적으로 도우려는 조짐도 보인다. 기사에 따르면, 정부 부처가 나서서 라이선스 검증을 위한 시스템을 만든다고 하는데 매우 반가운 일이 아닐 수 없다.
오픈소스를 활용하거나 자사 산출물을 오픈소스화 하려는 기업은 앞 서 소개한 곳 뿐만은 아니다. 이런 일을 추진하는 입장에서 꽤나 큰 장벽은 라이선스 문제다. 기업 내에 존재하는 법무팀의 경우도 오픈소스에 대한 경험이 부족하여 속시원한 답변을 해주지 못하는 경우가 비일비재하기 때문이다.
문두는 오해를 낳을 수 있는 문구를 지적했지만, 근래 보이는 오픈소스 활성화 조짐과 의미있는 정부 부처의 노력이 반가워서 글을 쓴다. 그런데 왜 이런 일을 문화체육관광부가 하는 지는 모르겠다. 이미 이런 곳도 있어왔는데, 컴퓨터프로그램보호위원회도 그렇고.
우리나라에서 이정도 규모로 하나의 기업이 인력과 자본을 투자하여 그 결과물을 오픈소스로 공개하는 사례는 제가 알기로 전혀 없었고… 전 세계적으로도 상당히 드문 케이스로 꼽을 수 있을 만큼 획기적입니다.
'전혀 없다'는 표현은 SDS 애니프레임 공개에 힘을 써온 사람들을 서운하게 할지도 모른다. 공개하는 규모가 어느 정도인지 모르지만, 이미 지난 6월에 SDS에서 공개한 애니프레임 역시 작은 규모는 아니다. 기자의 해석인지, SDS 담당자의 의견인지 모르지만, 기사를 보면 다음과 같이 말하고 있으니까.
애니프레임 자바는 삼성SDS가 지난 10년간 개발, 금융, 제조 공공 등 100여 곳이 넘는 프로젝트에 적용하면서 현장의 검증을 받은 개발자들의 땀과 노하우가 담겨 있는 SDS 집단지성의 산물이다.
기업은 자사의 이익을 위해 행동하게 되어 있지만, 어떤 형태로든 기업이 오픈소스를 활용한다는 측면은 분명 긍정적인 것 같다. 그런 점에서 한중일 3국이 협력하려는 조짐도 눈에 띄고, 정부 부처에서 기업의 오픈소스 활용을 적극적으로 도우려는 조짐도 보인다. 기사에 따르면, 정부 부처가 나서서 라이선스 검증을 위한 시스템을 만든다고 하는데 매우 반가운 일이 아닐 수 없다.
문화체육관광부와 컴퓨터프로그램보호위원회는 국내 SW개발업체들이 오픈소스SW에 대한 라이선스 검증을 통해 저작권 분쟁을 미연에 방지하여 오픈소스SW를 안심하고 활용할 수 있도록「오픈소스SW 검증·활용시스템」을 구축할 계획이다.
내년 5월까지는 오픈소스SW 2만 건을 DB구축하고 오픈소스SW 라이선스 70여종에 대한 정보를 수집·분석하여 서비스 할예정이며, 향후 2년 동안에 오픈소스SW를 12만 건까지 확대하여 본격적인 검증·활용서비스를 운영할 계획이다.
내년 5월까지는 오픈소스SW 2만 건을 DB구축하고 오픈소스SW 라이선스 70여종에 대한 정보를 수집·분석하여 서비스 할예정이며, 향후 2년 동안에 오픈소스SW를 12만 건까지 확대하여 본격적인 검증·활용서비스를 운영할 계획이다.
오픈소스를 활용하거나 자사 산출물을 오픈소스화 하려는 기업은 앞 서 소개한 곳 뿐만은 아니다. 이런 일을 추진하는 입장에서 꽤나 큰 장벽은 라이선스 문제다. 기업 내에 존재하는 법무팀의 경우도 오픈소스에 대한 경험이 부족하여 속시원한 답변을 해주지 못하는 경우가 비일비재하기 때문이다.
문두는 오해를 낳을 수 있는 문구를 지적했지만, 근래 보이는 오픈소스 활성화 조짐과 의미있는 정부 부처의 노력이 반가워서 글을 쓴다. 그런데 왜 이런 일을 문화체육관광부가 하는 지는 모르겠다. 이미 이런 곳도 있어왔는데, 컴퓨터프로그램보호위원회도 그렇고.
글
Spring IDE 2.2 출시
2008/Spring Framework
2008/10/01 08:14
버그나 에러를 해결한 것이 대부분인 듯 하다: Change Log
Update site: http://dist.springframework.org/release/IDE
Archived update site: spring-ide_updatesite_2.2.0_v200809261800.zip
Update site: http://dist.springframework.org/release/IDE
Archived update site: spring-ide_updatesite_2.2.0_v200809261800.zip
글
KSUG에서 9번째 세미나를 합니다
2008/Spring Framework
2008/09/20 00:00
참가신청은 봄날 포럼에서 받습니다. 적어도 제 임기내에서는 지금 같은 형식으로는 마지막일 듯 합니다.
최초로 오전에 세미나를 하는 이유는 많은 세션을 한 번에 소화하기 위해서입니다.
발표자 스케쥴 문제로 주일에 해서 많은 분들이 참석할 수 없다는 것이 아쉽네요.
글
The Essence of Spring
2008/Spring Framework
2008/09/08 08:15
아키텍트라고 칭하기에 손색이 없는 이사님께서 사내 세미나에서 돌연 질문을 했다.
"왜 new를 쓰지 않고, IoC를 하는가?"
질문의 요지는 맹목적으로 기술을 추종하지 말고, 장단점을 알고 적절히 활용할 수 있어야 한다는 메시지였다. 그러던 차에 작년쯤 올라온 The Essence of Spring, 또 댓글을 통해 2006년에 쓰인 The Essence of Spring을 봤다. 스프링에 관심 있는 다른 분들도 한 번쯤 왜 스프링을 공부하거나 사용해야 하는지 반추해보는 기회가 될 수 있다 생각해 글을 소개한다.
먼저 Rossen Stoyanchev는 'Spring is about dependency injection of plain objects'라고 짧게 정의하고 부연 설명과 사연을 달았다. IoC나 DI는 혼용해서 쓰이는 경우가 있는데, 정확하게는 IoC하는 과정에서 객체를 구성하기 위해 DI를 하는 것이다. 여튼 최초의 질문으로 돌아가서 new를 안하고, IoC를 하는 이유는 뭐라고 답할 수 있을까?
그 날은 답을 하지는 못했지만, 이미 오래 전에 답을 알았다. OOAD를 현장에 보급하던 당시 EJB로는 거의 불가능했던 OOD를 가능하게 하는 솔루션이 스프링이었다. OOD 솔루션을 찾던 때, 먼저 발견한 것은 TSS에 올라온 The J2EE Architect's Handbook 이었다. 이를 적용하려던 차에 스프링을 발견했고, 성공적으로 적용했다. 여기서 성공이라는 의미는 분석 모델과 설계 모델, 그리고 코드 사이의 유기적인 전환이 개발자들을 통해 실현했다는 것을 의미했다. EJB를 쓰던 시절에는 정말 어렵고도 어려웠던 일을 너무나도 쉽게 성공했다.
위 글에서 굵은 글로 표현한 것처럼 new 대신 IoC/DI를 활용하는 이유는 업무 외적인 것들 즉, 기술적인 내용을 업무를 표현한 코드와 섞이지 않게 하려는 의도이다. 이것은 EJB가 최초에 등장했을 때 Sun에서 하던 이야기와 다르지 않다. 단지 EJB와 스프링이 공언한 바를 얼마나 실현하는가에 차이가 있을 뿐이다.
인용한 글과 같은 맥락이지만, 좀 더 친근한(게다가 한글로 된) 표현은 얼마전 올린 토비형의 글에서 찾을 수 있다. 가서 읽어 보시길... 짧다. ^^
그리고, 키스 도날드의 글은 스프링의 효용성을 간명하게 말하고 있다.
"왜 new를 쓰지 않고, IoC를 하는가?"
질문의 요지는 맹목적으로 기술을 추종하지 말고, 장단점을 알고 적절히 활용할 수 있어야 한다는 메시지였다. 그러던 차에 작년쯤 올라온 The Essence of Spring, 또 댓글을 통해 2006년에 쓰인 The Essence of Spring을 봤다. 스프링에 관심 있는 다른 분들도 한 번쯤 왜 스프링을 공부하거나 사용해야 하는지 반추해보는 기회가 될 수 있다 생각해 글을 소개한다.
먼저 Rossen Stoyanchev는 'Spring is about dependency injection of plain objects'라고 짧게 정의하고 부연 설명과 사연을 달았다. IoC나 DI는 혼용해서 쓰이는 경우가 있는데, 정확하게는 IoC하는 과정에서 객체를 구성하기 위해 DI를 하는 것이다. 여튼 최초의 질문으로 돌아가서 new를 안하고, IoC를 하는 이유는 뭐라고 답할 수 있을까?
그 날은 답을 하지는 못했지만, 이미 오래 전에 답을 알았다. OOAD를 현장에 보급하던 당시 EJB로는 거의 불가능했던 OOD를 가능하게 하는 솔루션이 스프링이었다. OOD 솔루션을 찾던 때, 먼저 발견한 것은 TSS에 올라온 The J2EE Architect's Handbook 이었다. 이를 적용하려던 차에 스프링을 발견했고, 성공적으로 적용했다. 여기서 성공이라는 의미는 분석 모델과 설계 모델, 그리고 코드 사이의 유기적인 전환이 개발자들을 통해 실현했다는 것을 의미했다. EJB를 쓰던 시절에는 정말 어렵고도 어려웠던 일을 너무나도 쉽게 성공했다.
Once you let that happen you open the door to powerful AOP-style
services through a proxy mechanism that intercepts calls to your
objects and adds behavior in a transparent way. Want transaction
demarcation or access to remote services without "polluting" your
business objects? It's easy to do with a few more lines of
configuration (no coding!).
위 글에서 굵은 글로 표현한 것처럼 new 대신 IoC/DI를 활용하는 이유는 업무 외적인 것들 즉, 기술적인 내용을 업무를 표현한 코드와 섞이지 않게 하려는 의도이다. 이것은 EJB가 최초에 등장했을 때 Sun에서 하던 이야기와 다르지 않다. 단지 EJB와 스프링이 공언한 바를 얼마나 실현하는가에 차이가 있을 뿐이다.
인용한 글과 같은 맥락이지만, 좀 더 친근한(게다가 한글로 된) 표현은 얼마전 올린 토비형의 글에서 찾을 수 있다. 가서 읽어 보시길... 짧다. ^^
그리고, 키스 도날드의 글은 스프링의 효용성을 간명하게 말하고 있다.
The real
value of Spring is that they have not tried to specialize in any one
area. It glues together a variety of frameworks in order to provide
consistent interfaces for them and make application developers more
productive.
Sure, an
application developer could choose their personal favorites in each
area and glue them together by hand. But that is not what they are paid
to do. Every piece of code not providing business value is just
overhead.
글
어떤 책으로 스프링 학습을 해야 할까요?
2008/Spring Framework
2008/09/04 10:38
얼마전 부산대 석사분들과 이야기할 기회가 있었다. Hibernate 공부를 하고 싶은데 변변한 국내서가 없어 어렵게 Hibernate in action을 읽는다고 했다. 국내서로 Hibernate 책을 하나 본 듯 한데 자세히 살펴본 것은 아니지만, 어떻게 사용하는지 사례 같은 인상이었다. Hibernate와 마찬가지로 Spring의 경우도 국내에서 활발하게 쓰인 것은 그리 오래되지 않았다. 반면에 다행히도 저서와 역서가 좀 있는 편이다. 최근에 2.5 관련 서적이 나왔고, 판매부수가 꽤 높다고 한다. 하지만, 구성이 레퍼런스와 유사해 실무에 응용에 관한 이야기는 많지 않았던 듯 하다. 그래서, Spring 버전 차이가 꽤 있음에도 불구하고 여전히 Spring 프레임워크 워크북을 보는 분들이 꽤 많다.
스프링은 역서도 꽤 있다. 가장 두꺼운 책으로 기억하는데 Spring in action 역서도 있다. 최근에 2판이 나왔는데 회사 동료가 공동역자로 참여해 현재 리뷰중이다. Spring in action 역시 레퍼런스 스타일이라 실무 적용과는 괴리가 좀 있다. 개인적으로 Spring in action을 통해 가장 큰 도움을 받았던 부분은 Acegi 개념을 이해할 때 였다. Spring in action은 스프링 레퍼런스보다는 개념 설명이 좋다. 그림도 많고, 설명이 간결하다. 반면 실무 적용에 참고할 용도로는 Pro Spring이 좋다. 이 책은 개념 설명보다는 활용법 측면이 강하다.
2.5를 다루고 있지는 않지만, 스프링을 이해하는데는 여전히 로드 존슨의 빨간책 세 권이 최고라는 점은 많은 사람이 동의할 것이다. 아쉽게도 역서는 없거나 부실하다. 1권만 역서가 있는데, 번역 시점 상 책 내용을 이해할만한 사람이 드물 시점에서 무리하게 번역을 시도한 것이 아닌가 하는 짐작이 간다. 특정 페이지만 읽었던 기억이 있는데 역자가 내용을 이해하지 못했다는 인상을 받았다. 로드 존슨의 세 권은 마지막 서적은 주로 사용법 관점이고, 첫 책은 설계 철학을 이야기하고 있다. 세 권 중에 가장 마음에 드는 2권 without EJB는 양자를 적절히 다뤘다. 하지만, 이 세 권은 꽤나 어렵다.
현실은 이러한데, 토비형이 나름 심혈을 기울여서 스프링 책을 쓰고 있다. Agile Spring이라고, 전에 소개한 바 있는 Agile Java 에서 이름을 따왔다고 한다. 기획안을 들어보니 3부로 구성했는데, 1부는 점차 진화하는 형태로 코드를 따라가면서 스프링 설계 철학을 다룬다고 한다. 2부는 전반적인 스프링 기능 소개를 하고, 마지막 3부는 아키텍처에 대한 이야기를 담고 싶다고 한다. 흥행을 떠나 스프링 사용자라면 흥미를 가질 수 밖에 없는 구성이다. 수십권의 책은 물론이고, 오랜 ACM 논문까지 뒤척이며 집필 삼매경에 빠졌다고 한다. 즐거운 마음으로 책을 쓰고 있다는 점이 출간하는 서적에 기대를 갖게 만든다. 오는 9월말을 목표로 기획하고 있는 세미나에서 책 내용을 일부 공개하자고 제안을 했다. 토비형도 흥미로워했는데, 세미나에 대한 구체적인 계획이 나오지 않아서 자세히 언급은 못하겠다.
![]() | Spring 프레임워크 워크북 박재성 지음/한빛미디어 |
스프링은 역서도 꽤 있다. 가장 두꺼운 책으로 기억하는데 Spring in action 역서도 있다. 최근에 2판이 나왔는데 회사 동료가 공동역자로 참여해 현재 리뷰중이다. Spring in action 역시 레퍼런스 스타일이라 실무 적용과는 괴리가 좀 있다. 개인적으로 Spring in action을 통해 가장 큰 도움을 받았던 부분은 Acegi 개념을 이해할 때 였다. Spring in action은 스프링 레퍼런스보다는 개념 설명이 좋다. 그림도 많고, 설명이 간결하다. 반면 실무 적용에 참고할 용도로는 Pro Spring이 좋다. 이 책은 개념 설명보다는 활용법 측면이 강하다.
2.5를 다루고 있지는 않지만, 스프링을 이해하는데는 여전히 로드 존슨의 빨간책 세 권이 최고라는 점은 많은 사람이 동의할 것이다. 아쉽게도 역서는 없거나 부실하다. 1권만 역서가 있는데, 번역 시점 상 책 내용을 이해할만한 사람이 드물 시점에서 무리하게 번역을 시도한 것이 아닌가 하는 짐작이 간다. 특정 페이지만 읽었던 기억이 있는데 역자가 내용을 이해하지 못했다는 인상을 받았다. 로드 존슨의 세 권은 마지막 서적은 주로 사용법 관점이고, 첫 책은 설계 철학을 이야기하고 있다. 세 권 중에 가장 마음에 드는 2권 without EJB는 양자를 적절히 다뤘다. 하지만, 이 세 권은 꽤나 어렵다.
현실은 이러한데, 토비형이 나름 심혈을 기울여서 스프링 책을 쓰고 있다. Agile Spring이라고, 전에 소개한 바 있는 Agile Java 에서 이름을 따왔다고 한다. 기획안을 들어보니 3부로 구성했는데, 1부는 점차 진화하는 형태로 코드를 따라가면서 스프링 설계 철학을 다룬다고 한다. 2부는 전반적인 스프링 기능 소개를 하고, 마지막 3부는 아키텍처에 대한 이야기를 담고 싶다고 한다. 흥행을 떠나 스프링 사용자라면 흥미를 가질 수 밖에 없는 구성이다. 수십권의 책은 물론이고, 오랜 ACM 논문까지 뒤척이며 집필 삼매경에 빠졌다고 한다. 즐거운 마음으로 책을 쓰고 있다는 점이 출간하는 서적에 기대를 갖게 만든다. 오는 9월말을 목표로 기획하고 있는 세미나에서 책 내용을 일부 공개하자고 제안을 했다. 토비형도 흥미로워했는데, 세미나에 대한 구체적인 계획이 나오지 않아서 자세히 언급은 못하겠다.
글
KSUG 스프링배치 연재 개시
2008/Spring Framework
2008/08/01 01:13
정상혁님이 필진으로 합류한 뒤, KSUG 블로그가 제대로 KSUG 다워져간다. 체격만큼이나 장타를 치는 토비형이 잠적1한 뒤에 나타는 구세주다.
[Spring Batch] 스프링배치 연재(1) - 배치처리의 특징
월간마소 기고글을 마소의 허락을 얻어 온라인 연재하는 것이다. 상혁님이 올린 이전 글도 대박이다.
회사 전체가 쓰는 프레임웍을 만드는 팀에게 바라는 점
양으로는 불가능하더라도 스프링 관련 컨텐츠에 있어서는 InfoQ의 질을 목표로 삼아야겠다. 지난 해에는 오프라인 세미나로 청중들에게 "스프링 청량감"을 전달해주었다. 사람들의 반응을 피부로 느낄 수 있는 현장감은 좋았지만 자산으로 남은 것이 별로 없다. 올해는 온라인 위주로 활동을 전개하고 있다. 6월부터 기획해서 6월에 블로그도 열고, 6월 21일 포럼을 열었다. 대충 한달쯤 지났는데 나름 차곡차곡 쌓이고 있다.
[Spring Batch] 스프링배치 연재(1) - 배치처리의 특징
월간마소 기고글을 마소의 허락을 얻어 온라인 연재하는 것이다. 상혁님이 올린 이전 글도 대박이다.
회사 전체가 쓰는 프레임웍을 만드는 팀에게 바라는 점
양으로는 불가능하더라도 스프링 관련 컨텐츠에 있어서는 InfoQ의 질을 목표로 삼아야겠다. 지난 해에는 오프라인 세미나로 청중들에게 "스프링 청량감"을 전달해주었다. 사람들의 반응을 피부로 느낄 수 있는 현장감은 좋았지만 자산으로 남은 것이 별로 없다. 올해는 온라인 위주로 활동을 전개하고 있다. 6월부터 기획해서 6월에 블로그도 열고, 6월 21일 포럼을 열었다. 대충 한달쯤 지났는데 나름 차곡차곡 쌓이고 있다.
- 요즘 블로깅 안한다고 그의 근황을 묻는 사람들이 있는데, 영어 써야 한다고 남들 모르는 아이디로 영어 블로깅을 한다나... [본문으로]
글
OSGi에 대한 메모
2008/Spring Framework
2008/07/28 10:47
OSGi 전도사 Peter Kriens의 왜 자바가 OSGi 기반이냐에 대한 발표자료
그리고, HA(home automation)쪽에서 출발한 OSGi의 기원에 대한 기록
출처: Cool OSGi Panel
위 글에는 그 외에 HA, Car, Mobile 분야에서 OSGi 적용 사례 소개가 있다.
EEG에서 요구사항 정의가 지나고 설계가 논의되는 상황인데... 이 시점에서 Distributed OSGi에 대한 EEG 공동 의장의 설계 원칙을 돌아보는 포스팅 하나
그래서 얻으려는 이점
distributed 서비스를 개발에 필요한 인간의 노력을 줄일 수 있게
어떻게 가능한가?
출처: Abstraction and control in REST vs RPC
이 글의 주요 메시지는 기술적인 기준보다 사람들이 사용하기 쉽게 하는 것이 더 중요하다는 점이 역사를 통해 증명되어왔다는 것이다.
It is simply saying that ease of use - making it easier for humans to do something like distributed computing - can sometimes be more important than technical concerns such as being too verbose or too slow.
그리고, HA(home automation)쪽에서 출발한 OSGi의 기원에 대한 기록
In 1998 our goal was to create a standard for applications that run on
home gateways. We were faced with a couple of hard problems: no defined
hardware platform or operating system, a bewildering number of network
standards and devices, unattended devices, and last but not least the
requirement to enable competition in implementations.
....
From this problem analysis, I sketched the vision of where we want to go: To become the component model of choice for embedded, desktop, and server applications.
....
From this problem analysis, I sketched the vision of where we want to go: To become the component model of choice for embedded, desktop, and server applications.
출처: Cool OSGi Panel
위 글에는 그 외에 HA, Car, Mobile 분야에서 OSGi 적용 사례 소개가 있다.
EEG에서 요구사항 정의가 지나고 설계가 논의되는 상황인데... 이 시점에서 Distributed OSGi에 대한 EEG 공동 의장의 설계 원칙을 돌아보는 포스팅 하나
The goal of distributed OSGi is to standardize how existing distributed
software systems work with OSGi, extending the OSGi programming model
to include remote services (today the standard only describes single
JVM service invocations).
그래서 얻으려는 이점
In our case, therefore, making it easier for OSGi developers to create
and deploy distributed services is more important than the loss of
flexibility and control available when using local services only. The
biggest cost of software development is still human labor, and
providing helpful abstractions, incluiding RPC, continues to be an
important goal.
distributed 서비스를 개발에 필요한 인간의 노력을 줄일 수 있게
어떻게 가능한가?
but the benefits of introducing distributed computing through
configuration changes to an OSGi framework far outweigh the liabilities
출처: Abstraction and control in REST vs RPC
이 글의 주요 메시지는 기술적인 기준보다 사람들이 사용하기 쉽게 하는 것이 더 중요하다는 점이 역사를 통해 증명되어왔다는 것이다.
It is simply saying that ease of use - making it easier for humans to do something like distributed computing - can sometimes be more important than technical concerns such as being too verbose or too slow.
글
[KSUG] 회사 전체가 쓰는 프레임웍을 만드는 팀에 바라는 점
2008/Spring Framework
2008/07/22 13:20
KSUG 블로그에 필진으로 새로 참여한 정상혁님이 올린 좋은 글이 있어 소개합니다.
정말 생생하고, 구체적인 현장에 대한 소회를 그대로 담은 글이군요. 이글은 다음과 같은 말로 마무리를 하고 있는데요.
지금까지 나온 내용을 정리해보면 다음과 같습니다. 오픈소스 모듈을 래핑하거나 중복된 기능을 구현할 때는 의도를 개발자에게 알리고, 기존 모듈에 대해서도 개선을 해나가면서 때로는 과감히 범용적인 모듈로 교체할 수 있어야 합니다. 그리고 개발과정 중에서도 주요 결정사항과 설계안을 공유해서 피드백을 받고, 최종배포 전에는 설계안과 코드를 엄격하게 검증해야 합니다. 그리고 배포 후에는 유연한 선택 사항들과 구체적인 선택 기준을 제공하는 적용가이드를 제공하고, 회사 조직의 경계를 넘어선 협업도 모색해 보는 것이 좋습니다
전체적으로 문서를 통한 개발 산출물에 대한 정보 전달, 개발 과정의 문서화를 통한 의사소통의 중요성을 강조한 점이 가장 눈에 띄네요.
정말 생생하고, 구체적인 현장에 대한 소회를 그대로 담은 글이군요. 이글은 다음과 같은 말로 마무리를 하고 있는데요.
지금까지 나온 내용을 정리해보면 다음과 같습니다. 오픈소스 모듈을 래핑하거나 중복된 기능을 구현할 때는 의도를 개발자에게 알리고, 기존 모듈에 대해서도 개선을 해나가면서 때로는 과감히 범용적인 모듈로 교체할 수 있어야 합니다. 그리고 개발과정 중에서도 주요 결정사항과 설계안을 공유해서 피드백을 받고, 최종배포 전에는 설계안과 코드를 엄격하게 검증해야 합니다. 그리고 배포 후에는 유연한 선택 사항들과 구체적인 선택 기준을 제공하는 적용가이드를 제공하고, 회사 조직의 경계를 넘어선 협업도 모색해 보는 것이 좋습니다
전체적으로 문서를 통한 개발 산출물에 대한 정보 전달, 개발 과정의 문서화를 통한 의사소통의 중요성을 강조한 점이 가장 눈에 띄네요.
글
KSUG Forum에 올라온 글에 대한 애니프레임팀의 답변
2008/Spring Framework
2008/07/22 08:48
얼마전 올린 애니프레임을 위한 항변에 이어 기선군이 봄날포럼에 애니프레임 문제를 지적한 내용을 자세히 올렸고, 애니프레임팀 팀장님께서 의견을 보내오셨네요. 자세한 내용은 포럼에 들르셔서 보시고, 한마디씩 거들어주시면 좋구요:
[애니프레임] KSUG Forum에 올라온 글에 대한 애니프레임팀의 답변
* 봄날포럼은
RSS 로 구독이 가능합니다.
[애니프레임] KSUG Forum에 올라온 글에 대한 애니프레임팀의 답변
* 봄날포럼은
글
애니프레임을 위한 항변
2008/Spring Framework
2008/07/19 13:12
한 3년쯤 전에 스프링이나 블로그의 존재부터 배웠던 백기선군이 많이 컸습니다. 꾸준한 노력은 정말 아무것도 모르던 친구도 3년이면 수준에 오르게 하는게 확실하군요. 급성 편도염1으로 누워있다 인터넷 기사가 깨워서 인터넷 재개통 기념2으로 서핑을 하는데 Anyframe 보다가 흥분 해버렸네요.를 보고, 저 역시 사석에서 애니프레임을 저평가하는 발언을 했던 점을 떠올리면, 이번에는 애니프레임을 위한 항변을 해봅니다. 하지만, 몇 가지 항목에 대한 항변일 뿐입니다. ^^
처음으로 지적한 유틸리티의 중복 문제는 저 역시 고민한 바 있습니다. 학습비용을 중요하게 생각하는 SI 환경을 고려하면, Commons 산하의 엄청난 API를 그대로 노출하는 것보다는 숨기는 것이 도움을 줍니다. 물론, public 메소드 들이기 때문에 jar로 포함시키는 이상 완전히 숨긴다고 볼 수는 없지만, 인터페이스 래핑만으로 어느 정도는 API 혹은 API 문서 분량을 줄일 수 있죠. 이런 내용은 스프링이 3rd 파티 코드를 수용할 때도 사용했죠. 물론, 단순 복사는 없었지만. 기선군이 아직 현장에서 한 번의 프로젝트도 참여한 적이 없기 때문에 이런 경험은 알 수가 없는 것이죠. 하지만, 논리적으로 일리 있는 반론이기 때문에... 블로그가 아닌 포럼에 글을 올려보는게 어떨까 싶네요. 물론, 그 분들 감정을 고려해서 표현은 정화를 해야겠죠.
로거문제는 중요3 하지만, 기선군이 제시한 문제는 잘 모르겠습니다. Xinternet - iBatis 연동 부분은 애니프레임 개발시 현업 요구가 가장 많았던 부분입니다. 코드를 자세히 보지 않아 몰랐는데, 패키지 구성에서 일관성은 취약한 모양이군요. Hibernate 부분은 뭘 더 구현할 수 있을까 싶어 보지도 않았는데, 문제가 있었나 보네요. 이거 항변한다고 해놓고선... 다시 항변으로 가보죠.
마지막으로 전후처리 부분에 대해서는 preprocess(), postprocess()는 나름 이유가 있죠. 가장 큰 이유는 전, 후 처리는 대형 프로젝트에서는 마치 패턴처럼 고착화 한 용어입니다. 메대규모 프로젝트에서 웹은 일부에 지나지 않이 filter나 interceptor로 무조건 해결할 수는 없습니다. 정리하면, 내부에서 사용하는 라이브러리를 제대로 쓰는 것이 오랫동안 해오던 SI/SM의 업무 방식을 무조건 바꿀 수는 없죠. 설득과 보급의 과정이 필요합니다. 우리 프로젝트에서도 웹과 채널 연계에서 전/후처리를 공동화 하려고 할 때 현장 경험이 풍부한 친구는 역시 preprocess(), postprocess()를 선택했습니다. :) 스마트한 고객이 문제제기를 한 탓에 바닥에서부터 재검토를 했고, AOP로 비즈니스 서비스 전/후처리를 하는 것으로 변경했다가 지금은 웹에서는 유겐할러가 만든 HandlerInterceptor를 쓰고, 채널 등에서는 유겐할러가 만든것과 유사하게 인터페이스를 재정의하는 것으로 결론을 내렸습니다. 권장안은 Interceptor이지만, AOP와 Intercptor 두 개의 옵션을 제공하기로 했죠.
전체적으로 보면 Anyframe 보다가 흥분 해버렸네요.에서 기선군이 애니프레임에 묻어있는 스프링, 하이버네이트에 대한 무지함을 자극적인 말로 질타했습니다. 하지만, 무모함까지 엿보이는 표현의 이면에는 수행 프로젝트가 0이라는 기선군의 현장에 대한 무지함이 있습니다. 이것을 단순히 싸움의 논리로 보면, 서로 약점이 있으니 물고 늘어지면 되겠죠. 하지만, 저는 기선군과 같은 스타일의 공격성 발언이 점잖빼고 일면 위선적이기도 한 우리 SI 현실에 많이 필요하다고 생각합니다. 기선군의 스프링에 대한 이해는 상당한 수준입니다. 애니프레임을 만들어낸 SDS의 현장 경험은 아마 국내 최고 수준이 아닐까 생각합니다. web 2.0 시대 운운하는데 다른 유형의 지식이 MASH UP을 이뤄서... 생산적인 결과물을 만들어내면 좋겠습니다. 그런 의미에서 KSUG에 오셔서 한 판 하세요. 듬직한 토비님과 새로 합류한 젊은 피(?) setq4님이 싸움으로 번지면 말려줍니다. 결국 광곤가... 일민형이 좋아하겠군. :)
처음으로 지적한 유틸리티의 중복 문제는 저 역시 고민한 바 있습니다. 학습비용을 중요하게 생각하는 SI 환경을 고려하면, Commons 산하의 엄청난 API를 그대로 노출하는 것보다는 숨기는 것이 도움을 줍니다. 물론, public 메소드 들이기 때문에 jar로 포함시키는 이상 완전히 숨긴다고 볼 수는 없지만, 인터페이스 래핑만으로 어느 정도는 API 혹은 API 문서 분량을 줄일 수 있죠. 이런 내용은 스프링이 3rd 파티 코드를 수용할 때도 사용했죠. 물론, 단순 복사는 없었지만. 기선군이 아직 현장에서 한 번의 프로젝트도 참여한 적이 없기 때문에 이런 경험은 알 수가 없는 것이죠. 하지만, 논리적으로 일리 있는 반론이기 때문에... 블로그가 아닌 포럼에 글을 올려보는게 어떨까 싶네요. 물론, 그 분들 감정을 고려해서 표현은 정화를 해야겠죠.
로거문제는 중요3 하지만, 기선군이 제시한 문제는 잘 모르겠습니다. Xinternet - iBatis 연동 부분은 애니프레임 개발시 현업 요구가 가장 많았던 부분입니다. 코드를 자세히 보지 않아 몰랐는데, 패키지 구성에서 일관성은 취약한 모양이군요. Hibernate 부분은 뭘 더 구현할 수 있을까 싶어 보지도 않았는데, 문제가 있었나 보네요. 이거 항변한다고 해놓고선... 다시 항변으로 가보죠.
마지막으로 전후처리 부분에 대해서는 preprocess(), postprocess()는 나름 이유가 있죠. 가장 큰 이유는 전, 후 처리는 대형 프로젝트에서는 마치 패턴처럼 고착화 한 용어입니다. 메대규모 프로젝트에서 웹은 일부에 지나지 않이 filter나 interceptor로 무조건 해결할 수는 없습니다. 정리하면, 내부에서 사용하는 라이브러리를 제대로 쓰는 것이 오랫동안 해오던 SI/SM의 업무 방식을 무조건 바꿀 수는 없죠. 설득과 보급의 과정이 필요합니다. 우리 프로젝트에서도 웹과 채널 연계에서 전/후처리를 공동화 하려고 할 때 현장 경험이 풍부한 친구는 역시 preprocess(), postprocess()를 선택했습니다. :) 스마트한 고객이 문제제기를 한 탓에 바닥에서부터 재검토를 했고, AOP로 비즈니스 서비스 전/후처리를 하는 것으로 변경했다가 지금은 웹에서는 유겐할러가 만든 HandlerInterceptor를 쓰고, 채널 등에서는 유겐할러가 만든것과 유사하게 인터페이스를 재정의하는 것으로 결론을 내렸습니다. 권장안은 Interceptor이지만, AOP와 Intercptor 두 개의 옵션을 제공하기로 했죠.
전체적으로 보면 Anyframe 보다가 흥분 해버렸네요.에서 기선군이 애니프레임에 묻어있는 스프링, 하이버네이트에 대한 무지함을 자극적인 말로 질타했습니다. 하지만, 무모함까지 엿보이는 표현의 이면에는 수행 프로젝트가 0이라는 기선군의 현장에 대한 무지함이 있습니다. 이것을 단순히 싸움의 논리로 보면, 서로 약점이 있으니 물고 늘어지면 되겠죠. 하지만, 저는 기선군과 같은 스타일의 공격성 발언이 점잖빼고 일면 위선적이기도 한 우리 SI 현실에 많이 필요하다고 생각합니다. 기선군의 스프링에 대한 이해는 상당한 수준입니다. 애니프레임을 만들어낸 SDS의 현장 경험은 아마 국내 최고 수준이 아닐까 생각합니다. web 2.0 시대 운운하는데 다른 유형의 지식이 MASH UP을 이뤄서... 생산적인 결과물을 만들어내면 좋겠습니다. 그런 의미에서 KSUG에 오셔서 한 판 하세요. 듬직한 토비님과 새로 합류한 젊은 피(?) setq4님이 싸움으로 번지면 말려줍니다. 결국 광곤가... 일민형이 좋아하겠군. :)
글
SDK(Software Development Kit) to SDK(Service Development Kit)
2008/Spring Framework
2008/07/02 02:04
토비형 푸쉬에 의해 우리를 포럼을 만들었고, 이제 7월의 봄을 준비하고 있다. 7월의 봄이란 엽이가 올린 포럼 홍보 글에 등장하는 문구를 차용해서, 그럴싸하게 해석을 붙였다. 우선 봄이란 스프링(Spring)을 의미하기도 하지만, 역시 토비형이 밀고 있는 스크린캐스팅 서비스(보다 + 명사형 어미)를 뜻하기도 한다.
OSGi 기초 실습을 해보고 나서 어떻게 스크린캐스팅을 구성하느냐 고민을 하는데, 처음에는 이클립스 같은 IDE를 쓰지 않고, 아주 간단한 예제로 명령행과 메모장으로 하는 것이 괜찮아 보였다. 그야말로 없어서는 안되는 요소가 무엇인지 몸으로 배우는 좋은 기회이기 때문이다. 이클립스에 들어있는 jar1를 특정 디렉토리에 복사하고, javac나 jar 등을 명령행에서 실행하기 위해 Path 환경 변수를 잡아준다. 이런 행위들은 오랜만인지라 옛날 기억이 났다. 자바를 처음 배우던 시절이.. :)
SDK. Software Development Kit. JDK라고 부르던 것이, 1.2 부터였나 Java2 SDK라고 불렀다. DE(Development Environment)에 비해서는 좀 가벼운 느낌이 나는 Kit.
문득 이런 생각이 들었다. 실습하던 내용에도 OSGi SDK라고 이름 붙일 수 있을까? OSGi 스펙에 SDK 따위의 말은 없다. OSGi 최초 스펙인 R(Release)1은 서비스 프레임워크(Service Framework)에 대한 스펙이고, R2부터는 핵심 서비스 번들(a set of core service bundles)을 더한 서비스 플랫폼(Service Platform) 스펙이다.
SDK따위는 정의하고 있지 않지만, 명령행에서 메모장을 써서 만든 간단 샘플은 SDK 느낌 그대로다. 하여 SDK(Service Development Kit)라는 말은 없지만 그렇게 불러봄직도 하다.
왜냐? SDK(Software ...)와 다른 점을 들어 번들의 유용함을 배울 수 있기 때문이다. 촉류방통법(觸類旁通法)2이 슬쩍 떠오른다. Software Development Kit에서 Software에는 모듈화 개념이 없다. 하지만, OSGi의 서비스는 번들(bundle)로 배포하여 소프트웨어를 모듈화 할 수 있다. 가장 세련된 모듈화이자 그야 말로 원론에 가까운 CBD(Compoent-based Development)이다.
결론, 조금은 억지스런 SDK(Software ...)에서 SDK(Service ...)로 라는 모토는 학습용으론 괜찮은 것 같아. :)
OSGi 기초 실습을 해보고 나서 어떻게 스크린캐스팅을 구성하느냐 고민을 하는데, 처음에는 이클립스 같은 IDE를 쓰지 않고, 아주 간단한 예제로 명령행과 메모장으로 하는 것이 괜찮아 보였다. 그야말로 없어서는 안되는 요소가 무엇인지 몸으로 배우는 좋은 기회이기 때문이다. 이클립스에 들어있는 jar1를 특정 디렉토리에 복사하고, javac나 jar 등을 명령행에서 실행하기 위해 Path 환경 변수를 잡아준다. 이런 행위들은 오랜만인지라 옛날 기억이 났다. 자바를 처음 배우던 시절이.. :)
SDK. Software Development Kit. JDK라고 부르던 것이, 1.2 부터였나 Java2 SDK라고 불렀다. DE(Development Environment)에 비해서는 좀 가벼운 느낌이 나는 Kit.
문득 이런 생각이 들었다. 실습하던 내용에도 OSGi SDK라고 이름 붙일 수 있을까? OSGi 스펙에 SDK 따위의 말은 없다. OSGi 최초 스펙인 R(Release)1은 서비스 프레임워크(Service Framework)에 대한 스펙이고, R2부터는 핵심 서비스 번들(a set of core service bundles)을 더한 서비스 플랫폼(Service Platform) 스펙이다.
SDK따위는 정의하고 있지 않지만, 명령행에서 메모장을 써서 만든 간단 샘플은 SDK 느낌 그대로다. 하여 SDK(Service Development Kit)라는 말은 없지만 그렇게 불러봄직도 하다.
왜냐? SDK(Software ...)와 다른 점을 들어 번들의 유용함을 배울 수 있기 때문이다. 촉류방통법(觸類旁通法)2이 슬쩍 떠오른다. Software Development Kit에서 Software에는 모듈화 개념이 없다. 하지만, OSGi의 서비스는 번들(bundle)로 배포하여 소프트웨어를 모듈화 할 수 있다. 가장 세련된 모듈화이자 그야 말로 원론에 가까운 CBD(Compoent-based Development)이다.
결론, 조금은 억지스런 SDK(Software ...)에서 SDK(Service ...)로 라는 모토는 학습용으론 괜찮은 것 같아. :)
![]() | 다산선생 지식경영법 - ![]() 정민 지음/김영사 |
글
KSUG 포럼 개설... 얼렁 모이세요~
2008/Spring Framework
2008/06/30 01:19
일민형이 고대하던 포럼이 만들어졌다. 오픈시드때 지쳐 나가떨어진 물개형을 지켜주지(?) 못해 아쉬웠는데 초반부터 댓글이 장난 아니다. 일민형이 스프링 전문자로써 할 일을 해주는 이때, 별로 아는 것도 없는 나는 정안수 떠 놓고 기도하는 심정으로 과거에 세미나에 참석했던 분들 명단을 가지고, 일일이 메일을 보내고 있다. 대충 200통은 보낸 것 같은데 장난 아니다. 일방적으로 정보 전달하는 형태를 벗어나기 위해 나부터 참가자 분들에게 관심을 보이기로 한 것이다. 대 여섯번은 '그만 둘까?'했는데, 이제는 익숙해졌다. 극기 훈련하는 기분이긴하다. 낼 일하려면 여기 까지 하고, 점심때나 퇴근 후에 계속해야겠다.
글
SDS의 스프링 기반 오픈소스 커뮤니티 개설
2008/Spring Framework
2008/06/16 11:06
글
KSUG 블로그 이전
2008/Spring Framework
2008/06/09 13:10
살다보면 기존의 것(legacy)을 이어가는 것이 성숙한 모습임을 배웁니다. KSUG 블로그 이전은 그렇게 하지 못했습니다. RSS와 링크마저 복구가 어려운 상황입니다. 가장 중요한 자산이라 할 수 있는 세미나 자료는 복원하도록 하겠습니다.
5일부터 일민형에게 글을 하나 쓰라고 압박을 해도 소식이 없더니, 그야 말로 장타를 올렸네요. 마소 특집 쓰듯이 쓰네요.^^
5일부터 일민형에게 글을 하나 쓰라고 압박을 해도 소식이 없더니, 그야 말로 장타를 올렸네요. 마소 특집 쓰듯이 쓰네요.^^
글
without EJB가 아닌 without Java EE
2008/Spring Framework
2008/05/22 12:51
* 2주 전에 InfoQ 글을 보고 메모했던 것을 잊어버리고 있다가 공개한다.
오늘 다시 인포큐의 글을 보니, 메시지가 더욱 명쾌하다. 특히 로드 존슨의 인터뷰 내용을 요약한 박스의 글이 핵심을 말하고 있다. S2AP를 내놓는다고 해서, 고객에게 '그것이 옳다고 강요하는 것이 아니라'는 스프링의 철학(결국, 고객이 항상 옳다는). 아이러니하게도 닷넷과 경쟁하던 시절 J2EE 기술이 마케팅 포인트로 제시했던 '선택의 자유'는 이제 J2EE를 공격하고 있다. 새로운 Java EE 스펙에도 참여하고 있는 로드 존슨은 JEE 6의 일면에 대해서도 대략적으로 언급하고 있다. 하나의 프로그래밍 모델이 아닌 다양한 프로그래밍 기반을 프로파일(Profile)이라는 이름으로 논의하고 있다.(UML Profile과 개념적으로 유사하다.) 마지막으로 로드 존슨이 S2AP의 강점을 요약해서 전해준다. 하지만, 그것이 강점으로 발현되기 위해서는 S2AP 사용뿐 아니라 EAR이라는 큰 덩어리가 아니라, 작은 단위로 시스템을 조각하고 관리할 수 있는 역량을 요구한다.
점심시간에 이를 소화제 삼아 동료 개발자와 논의한 바 있지만, 과연 국내 SI 환경에서 이를 운용할 능력을 갖추는 것이 수년 안에 가능할지는 무척 회의적이다. 물론, 서비스를 시장에 내놓는 이른바 Time to Market 측면에서는 엄청난 위력을 가진 기술이니까... 경쟁이 치열해지면, 현재 조직이나 구성원의 역량에도 불구하고, 갈구하게 될 가능성은 높다.
InfoQ가 선도적인 엔터프라이즈 개발 매체답게 감각적인 제목의 글을 내놓았다.
SpringSource Launches New Application Server without Java EE
Spring이 로드 존슨의 책 제목과도 같은 without EJB 개발을 가능하게 했다면, Spring Source는 이제 without Java EE가 가능한 플랫폼을 제공을 준비하고 있다. InfoQ의 글을 보면 천만 달러 펀딩이라는 배경으로 시작해서 로드 존슨과의 인터뷰 내용이나 롭 해롭의 기술적 포스트에 대한 해설등을 담고 있다.SpringSource의 상업화 전략에 대한 인터뷰에 거론했던 사항과 함께 생각해보면 Spring Source의 행보는 더 명확해진다. Covalent 인수로 톰캣에 대한 기술력도 확보한 상태이고, JBoss 등과 유사한 서비스를 수행할 것으로 추측할 수 있다. 물론, Java EE 서버와 OSGi 컨테이너는 엄연한 차이가 있지만, 결국 고객 입장에서는 같은 선상에 놓인 벤더일 뿐이다. 조금은 미래의 일이겠지만, WAS 제품 중에 선택하는 것이 아니라, 플랫폼의 유형을 고르는게 선택 포인트가 되려나.
기술적인 이해를 위해서는 롭 해롭의 글을 보라.
Introducing the SpringSource Application Platform
SpringSource Launches New Application Server without Java EE
Spring이 로드 존슨의 책 제목과도 같은 without EJB 개발을 가능하게 했다면, Spring Source는 이제 without Java EE가 가능한 플랫폼을 제공을 준비하고 있다. InfoQ의 글을 보면 천만 달러 펀딩이라는 배경으로 시작해서 로드 존슨과의 인터뷰 내용이나 롭 해롭의 기술적 포스트에 대한 해설등을 담고 있다.SpringSource의 상업화 전략에 대한 인터뷰에 거론했던 사항과 함께 생각해보면 Spring Source의 행보는 더 명확해진다. Covalent 인수로 톰캣에 대한 기술력도 확보한 상태이고, JBoss 등과 유사한 서비스를 수행할 것으로 추측할 수 있다. 물론, Java EE 서버와 OSGi 컨테이너는 엄연한 차이가 있지만, 결국 고객 입장에서는 같은 선상에 놓인 벤더일 뿐이다. 조금은 미래의 일이겠지만, WAS 제품 중에 선택하는 것이 아니라, 플랫폼의 유형을 고르는게 선택 포인트가 되려나.
기술적인 이해를 위해서는 롭 해롭의 글을 보라.
Introducing the SpringSource Application Platform
오늘 다시 인포큐의 글을 보니, 메시지가 더욱 명쾌하다. 특히 로드 존슨의 인터뷰 내용을 요약한 박스의 글이 핵심을 말하고 있다. S2AP를 내놓는다고 해서, 고객에게 '그것이 옳다고 강요하는 것이 아니라'는 스프링의 철학(결국, 고객이 항상 옳다는). 아이러니하게도 닷넷과 경쟁하던 시절 J2EE 기술이 마케팅 포인트로 제시했던 '선택의 자유'는 이제 J2EE를 공격하고 있다. 새로운 Java EE 스펙에도 참여하고 있는 로드 존슨은 JEE 6의 일면에 대해서도 대략적으로 언급하고 있다. 하나의 프로그래밍 모델이 아닌 다양한 프로그래밍 기반을 프로파일(Profile)이라는 이름으로 논의하고 있다.(UML Profile과 개념적으로 유사하다.) 마지막으로 로드 존슨이 S2AP의 강점을 요약해서 전해준다. 하지만, 그것이 강점으로 발현되기 위해서는 S2AP 사용뿐 아니라 EAR이라는 큰 덩어리가 아니라, 작은 단위로 시스템을 조각하고 관리할 수 있는 역량을 요구한다.
점심시간에 이를 소화제 삼아 동료 개발자와 논의한 바 있지만, 과연 국내 SI 환경에서 이를 운용할 능력을 갖추는 것이 수년 안에 가능할지는 무척 회의적이다. 물론, 서비스를 시장에 내놓는 이른바 Time to Market 측면에서는 엄청난 위력을 가진 기술이니까... 경쟁이 치열해지면, 현재 조직이나 구성원의 역량에도 불구하고, 갈구하게 될 가능성은 높다.
글
Spring Security 2.0 예제
2008/Spring Framework
2008/04/29 17:16
Spring Security 2.0.4 다운로드 파일에 들어있는 예제를 이해하는데 도움을 주기 위해 두 가지 작업만 했다.
Todo 목록: 아래 사항을 쉽게 쓸 수 있는 래퍼 혹은 적용을 도울 예제 만들기
참고사항: Pathway from ACEGI to Spring Security 2.0
- jsp를 한글로 변경해서 톰캣에 올려서 보면서 이해하기 쉽게 함
- 이클립스 프로젝트로 변경
Todo 목록: 아래 사항을 쉽게 쓸 수 있는 래퍼 혹은 적용을 도울 예제 만들기
- Simplified namespace-based configuration syntax. Old configurations could require hundreds of lines of XML but our new convention over configuration approach ensures that many deployments will now require less than 10 lines.
- OpenID integration, which is the web's emerging single sign on standard (supported by Google, IBM, Sun, Yahoo and others)
- Windows NTLM support, providing easy enterprise-wide single sign on against Windows corporate networks
- Support for JSR 250 ("EJB 3") security annotations, delivering a standards-based model for authorization metadata
- AspectJ pointcut expression language support, allowing developers to apply cross-cutting security logic across their Spring managed objects
- Substantial improvements to the high-performance domain object instance security ("ACL") capabilities
- Comprehensive support for RESTful web request authorization, which works well with Spring 2.5's @MVC model for building RESTful systems
- Long-requested support for groups, hierarchical roles and a user management API, which all combine to reduce development time and significantly improve system administration
- An improved, database-backed "remember me" implementation
- Support for portlet authentication out-of-the-box
- Support for additional languages
- Numerous other general improvements, documentation and new samples
- New support for web state and flow transition authorization through the Spring Web Flow 2.0 release
- New support for visualizing secured methods, plus configuration auto-completion support in Spring IDE
- Enhanced WSS (formerly WS-Security) support through the Spring Web Services 1.5 release
참고사항: Pathway from ACEGI to Spring Security 2.0
글
KSUG 7번째 모임은 자바지기와 함께
2008/Spring Framework
2008/04/25 13:01
글
SpringSource Tool Suite의 문제 해결 정보
2008/Spring Framework
2008/04/21 07:17
출처: Runtime Error Analysis in the SpringSource Tool Suite
프로그래밍을 할 때 가장 시간을 소모하는 부분 중 하나가 런타임 디버깅이다. 사용하는 라이브러리가 문서화가 잘 되어 있지 않거나, 버그가 많을수록 소모적인 시간은 길어진다. 자신이 짠 코드에 대해서는 테스트와 디버깅은 반비례한다. 세번의 프로젝트에서 연속적으로 SI 환경의 테스트에 관해 집중하다 알게 된 것은, 시스템 성격에 따른 테스트 수위다. 그 이야기는 추후 기회를 기다리고....
다시 SSTS(SpringSource Tool Suite)로 돌아가보면 동영상을 보고 처음 느끼기에 MS의 원격 보고가 떠올랐다. MSDN도 떠오르고... 조만간 플러그인을 만들어야 하는데 좋은 영감을 준다.
Context-sensitive Help + Knowledge Base
관련 글:
SpringSource Tool Suite에 이런 기능이?!
SpringSource Tool Suite preview
[SpringSource Tool Suite review] Mylyn을 사용한 튜토리얼 제공
글
자바 개발자 직업 분류
2008/Spring Framework
2008/04/18 22:23
글
SpringSource의 상업화 전략에 대한 인터뷰
2008/Spring Framework
2008/04/17 13:11
SpringSource의 COO인 Neelan Choksi의 인터뷰 내용을 요약한 것이다. SpringSource Enterprise의 구성은...
서비스 수준을 묻는 질문에서는 플래티넘 고객은 1시간 이내의 응답시간을 보장한다고 한다. 그러나, 지원 인력(support engineers)이 호주, 영국, 캐나다에 국한해 있다는 것. 자세한 서비스 레벨 소개는 인터뷰만으로 알기 힘들었다. 맥도날드의 모델을 차용한 것이라는데... 맥도날드가 어떻게 하길래?
툴 스위트의 기본 구성은 모두 오픈소스인 Spring IDE, AJDT와 Mylyn이다. 툴 스위트 고유의 특징은 마치 MS를 연상케 하는 context-sensitive 도움말과 날리지 베이스이다. 한편, Covalent 인수로 SpringSource는 애플리케이션 수준에서 인프라 수준(ApacheHTTP, ActiveMQ)까지 컨설팅이 가능하게 되었다.
3.0에 대한 방향을 요약하면 다음과 같다.

동기는 자연스런 진화라고 설명한다. Rod Johnson의 책에서 오픈소스 프로젝트로, 다시 컨설팅 회사로, 다음 단계가 기업 고객(enterprise customers) 지원 체계를 정비한 것이라 한다.
서비스 수준을 묻는 질문에서는 플래티넘 고객은 1시간 이내의 응답시간을 보장한다고 한다. 그러나, 지원 인력(support engineers)이 호주, 영국, 캐나다에 국한해 있다는 것. 자세한 서비스 레벨 소개는 인터뷰만으로 알기 힘들었다. 맥도날드의 모델을 차용한 것이라는데... 맥도날드가 어떻게 하길래?
툴 스위트의 기본 구성은 모두 오픈소스인 Spring IDE, AJDT와 Mylyn이다. 툴 스위트 고유의 특징은 마치 MS를 연상케 하는 context-sensitive 도움말과 날리지 베이스이다. 한편, Covalent 인수로 SpringSource는 애플리케이션 수준에서 인프라 수준(ApacheHTTP, ActiveMQ)까지 컨설팅이 가능하게 되었다.
3.0에 대한 방향을 요약하면 다음과 같다.
- Java 5 기반 구현, 최선 JEE 지원(Profile 등)
- 웹이 정보시스템(enterprise) 영역외에서도 쓰일 수 있게, Ajax 기능을 강화하고, REST 지원 및 Spring Expression Language 추가 예정
SpringOneAmericas2008Summary.pps
SpringOneAmericas2008Summary.pdf



springsecurity.zip