서비의 다락방

올해로 10번째를 맞이하는 한국 자바 개발자 컨퍼런스.
해를 맞이할수록 강의 내용도 알차지고, 진행도 매끄러워지는걸 느낀다.
그에 반해 올해는 어쩐 일인지 참관자 수가 그 어느 해보다 적은 것 같다. 재작년의 절반정도일까..?
불과 이삼 년 전만 해도 북적거렸는데.. 올 핸 조용하고 차분한 느낌.
뭐, 북적대는 것보단 이편이 훨씬 좋긴 하지만 주최 측인 JCO나 협찬 기업의 느낌은 좀 다르겠지?
이것도 다 어수선한 시국탓인가....?

Write in C 
C로 짜

When I find my code in tons of trouble
내 코드에서 수많은 문제를 발견했을때

friends and colleagues come to me,
친구들과 동료들이 다가와

speaking words of wisdom...
지혜를 말해주었네

Write in C
C로 짜

And as the deadline fast approasches,
데드라인이 빠르게 다가오고

and bugs are all that I can see
내게 보이는 모든건 버그들이었네

Somewhere someone whispers:
그때 누군가가 조용히 말했지

Write in C
C로 짜

Write in C, Write in C, Write in C, Write in C,
C로 짜, C로 짜~, C로 짜~, C로 짜

LOGO's dead and burried,
로고는 이미 죽었고 사장됬네

Write in C
C로 짜~

I used to write a lot of FORTRAN
한땐 포트란으로 엄청 짜댔지

For science it worked flawlessly
과학계산에선 결점이 없었다네

Try using it for grahpic
그러나 그래픽으로 보여줄려고 해봐

Write in C
C로 짜~

And if you've just spent nearly 30 hours
만약 니가 서른시간을

debugging some assembly
단지 어셈블리 디버깅하는데 썼다면

Soon you will be glad to
곧장 그리워질꺼야

write in C
C로 짜~

Write in C, Write in C, Write in C, Write in C,
C로 짜, C로 짜~, C로 짜~, C로 짜

BASIC's not the answer,
베이직은 답이 아니라네~

Write in C
C로 짜~

Write in C, Write in C, Write in C, Write in C,
C로 짜, C로 짜~, C로 짜~, C로 짜

PASCAL won't quite cut it,
파스칼로는 좀 해결하기가 힘들지

Write in C
C로 짜~

통합 언어 쿼리라고 불리는 LINQ ('링크'로 발음 합니다. )는 관계형 데이터 모델(RDB)를 객체지향 모델로 매핑하는
(MS의 표현에 따르면) 획기적인 방법을 제공 하는데요..  
이 LINQ 편집을 위한 좋은 툴이 있어 소개합니다.

LINQPad 사이트
물론, VisualStudio 2008에서도 이 언어를 편집할 수 있습니다만 여기서 소개하는 LINQPad 라는 프로그램은
C# 3.0 in a Nutshell의 저자 Joseph Albahari씨가 개발하였으며 설치가 필요없는 약 3MB 용량에 AutoUpdate를
지원합니다. 이 어플리케이션의 소스는 Standard Copyright Laws의 보호아래있지만 프로그램의 사용에는 별다른
라이센스 제약 없이 자유롭게 이용할 수 있습니다.
자동완성 기능을 지원하는 버전은 약간의 금액을 받는다고 합니다.

이 어플리케이션을 사용하기위해서는 .NetFramework 3.5가 필수요건입니다. 이는 어플리케이션보다는
Linq가 .NetFramwork 3.5 이후부터 사용가능하기 때문에 생긴 제약입니다.
현재 LINQPad를 적용할 수 있는 DBMS로는 SQL Express, SQL 2000, SQL 2005이며 약간의 제약이 있지만
SQL 2008에도 사용할 수 있다고 하네요.

LINQPad는 링크 편집에 도움이 될 뿐만 아니라 C# 3.0 in a Nutshell에 수록된 200여개의 예제 내장해 이를 통해
링크 문법을 익히는데도 큰 도움이 될듯합니다.
뿐만 아니라 아래 스크린샷에 있는 Linq to object, Linq to lambda, Linq to sql 같은 유용한 기능도 제공하고 있습니다.

스트럿츠 2.1.이 릴리즈 되었습니다. 요즘 MS쪽 어플리케이션 개발 프로젝트를 하고있지만 여전히 자바쪽 흐름을 읽는것도 게을리 하고 있지 않습니다만, 쉽지 않네요.

스트럿츠 2.1은 많은 양의 코드를 Plug-In Framework로 옮기는 리펙토링, Convention plug-in에 의한 XML 설정 감소, 향상된 REST 지원에 초첨을 두고 진행되었습니다.

InfoQ에서 스트럿츠2 커미터인 Musachy Barroso씨와 인터뷰한 기사가 올라와서 포스팅 합니다.

2.0과 2.1의 차이점은 무엇인가요?
많은 수의 버그픽스가 있었습니다. 그리고 REST, Convention, Java Template과 같은 플러그인이 추가되었습니다.

많은 기능이 플러그-인 형태로 변경되었습니다. 이렇게 한 이유는 무엇인가요?
스트럿츠 코어에는 진정한 core만을 남기자는 아이디어에서 출발했습니다. 그리고 나머지는 플러그인에 집어 넣는거죠. 이렇게 하면서 코드의 유지보수가 쉬워 졌습니다. 그러면서 Dojo 플러그인 같은 것들은 더 이상 스트럿츠에서 지원하지 않습니다. 이런 변화는 제거된 플러그인을 사용하지 않는 개발자와 작은 footprint를 원하는 개발자 이외의 사람에게 직접적인 장점은 없습니다.
 
Ajax 태그를 depreciate 한 이유는 무엇인가요?
Struts2의 ajax 태그는 Dojo 0.4.x에 기반하고 있습니다. 그것을 Dojo의 최신버전에 맞춰 포팅하는것은 모든 ajax 태그의 코드를 다시 작성해야한 다는것과도 같은 이야기입니다. Dojo의 새로운 버전은 너무 빨리 출시되고 마이너 버전에서도 변경되는 코드의 양이 너무 많습니다. 태그가 Dojo의 모든 기능을 다 포함하고 있지 않기때문에 개발자는 주로 Dojo 라이브러리를 직접 사용하는 경향이 있습니다. 이런 이유들과 ajax 태그 개발 지원자의 부족으로 ajax 태그를 depreciate 했습니다.

어떤 이유로 CodeBehind 플러그인들을 Convention 플러그인으로 바꾸게 되었나요?
Convention은 외부 프로젝트였고 늦게 Struts에 추가되었습니다. Convention은 좀 더 빠른 ClassPath Scanner, 더 나은 Configuration elements, 로깅, 다양한 configuration 옵션, configuation reloading, 더 나은 문서화 등을 지원합니다.

Java Template 플러그인은 무엇인가요?
Java Template은 FreeMarker를 이용하여 java만으로 구현한 'simple theme' 구현체입니다. 이 플러그인의 태그는 재작성이 불가능한 약점이 있는 원래의 그것보다 4~5배 가량 빠르게 동작합니다.

다른 많은 Web Framework가 있는데 우리는 왜 Strtus2를 선택해야 하나요?
스트럿츠2는 아마도 가장 약한 커플링(loosely-coupled)으로 구현된 프레임워크일 겁니다. 많은 기능이 커스터마이징 없이, 혹은 약간의 커스터마이징만으로 사용할 수 있으며, 프레임워크를 익히기가 쉽습니다. 약한 커플링은 스트럿츠의 실체에 대한 지식 없이도 비지니스 로직을 작성 할 수 있도록 해 줍니다. 그러면서도 스트럿츠는 대용량 트래픽을 발생하는 사이트에서 유연한 확장성을 담보하고 있다는 점입니다.

마지막으로 한마디.
스트럿츠 2.1 출시까지 오랜 기간 공을들였습니다. 우리는 스트럿츠 프레임워크의 빌드와 릴리즈 프로세스 개선을 위해 정말 열심히 일하고 있습니다. 앞으로는 좀 더 짧은 주기로 새로운 버전이 릴리즈 되는것을 기대하셔도 좋습니다.

마이크로소프트의 Pattern & Practices 에 RIA 패턴에 대한 글이 게시되었습니다.

이 시나리오는 개인정보와같은 민감한 Data를 이용할 수 없는 RIA 어플리케이션이며 DB를 이용한다는 가정에서
출발합니다. 결과적으로 클라이언트, 웹서버, 데이타베이스의  3-tier 로 구성이 됩니다.

위와 같은 구성에서 각 레이어에 적용하면 좋을 패턴을 마이크로소프트 사에서는 아래와 같이 제시합니다.
위 패턴이 적용된 이미지의 요약은 다음과 같습니다.

MVC패턴으로 유저 인터페이스를 구성.
유저인터페이스는 여러개의 control들로 구성.
Presentation 레이어와 Service 레이어사이의 통신에는 Proxy 패턴을 적용.
다양한 데이터 구조를 하나로 취합하기위해 DTO 패턴을 적용.
Service 레이어는 외부와 내부 데이터 구조 사이의 변환기능을 제공해야 함.
Bussiness 레이어는 메세지기반 운용을위해 facade 패턴 적용.
도메인 엔티티를 위한 Repository 패턴 적용.
Domain Entity 패턴은 오직 데이터만 나타내는 Business entity를 정의하는데 이용.
Domain Entity와 Database Schema 사이의 매핑을 위해 Data Mapper 패턴 적용.

위와 같은 패턴을 적용한 RIA 어플리케이션을 MS Silverlight로 구현할 경우 다음과 같은 Technical Solution을보여줍니다.

아래 링크에서 더 자세한 정보와 코드조각을 얻으실 수 있습니다.
http://www.codeplex.com/AppArch/Wiki/View.aspx?title=App%20Pattern%20-%20Three-Tier%20RIA%20Application%20Scenario&referringTitle=Application%20Patterns

... 어중간하고 갈피를 잡으려고 애쓰던 마음에 종지부를 찍을 계기를 줘 정말 고마워.

dev.java.net에 등록되어있는 VisualVM이라는 자바 프로라일러. 넷빈즈에 기본 포함된 프로파일러의 stand alone
버전인지 VisualVM을 넷빈즈 프로파일러로 집어 넣은건지는 잘 모르겟지만 UI나 기능이 거의 비슷.

아래 소개영상을 보고 마음에 든다면 https://visualvm.dev.java.net 에서 더 많은 정보를 접하실 수 있습니다.
http://java.sun.com/javase/6/docs/technotes/guides/visualvm/index.html 에는 튜토리얼과 개발자를 위한
Document가 준비되어 있습니다.

ㅋㅋㅋ. 아고 배야..
대체 무슨 게임이야?

자바 객체와 XML간의 변환에관해서는 몇 가지 라이브러리들이 존재하고 있습니다만 이번 시간에는 Java SDK에
기본으로 포함되어 있는 java.beans.XMLDecoder와 java.beans.XMLEncoder를 이용하여 자바객체<->XML간
변환 방법을 알아보겠습니다.

java.beans.XMLDecoder와 java.beans.XMLEncoder클래스는 J2SE 1.4 버전부터 이용할 수 있습니다.

우선, XML로 변환하고 XML로부터 복원할  적당한 자바 클래스를 작성합니다.
[code]
/*
 * Setter와 Getter를 가진 전형적인 JavaBean 클래스입니다.
 */

package com.yunsobi.beanxmltranslate;

import java.awt.Point;
import java.util.ArrayList;

/**
 *
 * @author 신윤섭
 */
public class SampleBean {
    private int[] scores;
    private String name;
    private Point seat;
    private ArrayList entry;

    public int[] getScores() {
 return scores;
    }

    public void setScores(int[] scores) {
 this.scores = scores;
    }

    public String getName() {
 return name;
    }

    public void setName(String name) {
 this.name = name;
    }

    public Point getSeat() {
 return seat;
    }

    public void setSeat(Point seat) {
 this.seat = seat;
    }

    public ArrayList getEntry() {
 return entry;
    }

    public void setEntry(ArrayList entry) {
 this.entry = entry;
    }

}

[/code]
보시면 아시겠지만 int 배열과 String, Point, ArrayList 객체를 갖는 전형적인 자바빈 객체 하나를 만들었습니다.

이제, 이 SampleBean 클래스를 xml로 변환하고 변환한 xml로 부터 SampleBean객체를 복원하는 코드를 작성합니다.
[code]
/*
 * java.beans.XMLDecoder와 java.beans.XMLEncoder는
 * Java객체를 XML로
 * XML에서 Java 객체로 변환하는 쉬운 방법을 제공 합니다.
 */
package com.yunsobi.beanxmltranslate;

import java.awt.Point;
import java.beans.XMLDecoder;
import java.beans.XMLEncoder;
import java.io.BufferedInputStream;
import java.io.BufferedOutputStream;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.util.ArrayList;

/**
 *
 * @author 신윤섭
 */
public class BeanXmlTranslator {

    public static void main(String args[]) throws Exception {
 
 //xml로 변환할 클래스를 생성
 SampleBean sample = new SampleBean();
 //파라메터를 세팅해 봅시다.
 sample.setScores(new int[]{100, 90, 75}); //int[]
 sample.setName("Gore"); //String
 sample.setSeat(new Point(5, 3)); //java.awt.Point
 //ArrayList에 String과 Point도 넣어보구요..
 ArrayList entry = new ArrayList();
 entry.add("우리는");
 entry.add("하나다");
 entry.add(new Point(1,1));
 sample.setEntry(entry);
 
 //자.. 객체를 XML로 변환 시킵니다.
 XMLEncoder encoder = new XMLEncoder(
     new BufferedOutputStream(
     new FileOutputStream("C:\\Sample.xml")));
 encoder.writeObject(sample);
 encoder.close();
 //객체 레퍼런스를 찍어보구요..
 System.out.println(sample);
 
 //이젠 XML에서 객체로 복원시켜 봅니다.
 XMLDecoder decoder = new XMLDecoder(
     new BufferedInputStream(
     new FileInputStream("C:\\Sample.xml")));
 SampleBean sample2 = (SampleBean) decoder.readObject();
 decoder.close();
 //객체 레퍼런스를 찍어보구요..
 System.out.println(sample2);
    }
}

[/code]
예.. 변환의 핵심은 XMLEncoder 클래스의 writeObject() 메소드와 XMLDecoder  클래스의 readObject() 메소드
에 있습니다.

객체를 xml로 변환한 결과를 한번 볼까요?
[code]
<?xml version="1.0" encoding="UTF-8"?>
<java version="1.5.0_13" class="java.beans.XMLDecoder">
 <object class="com.yunsobi.beanxmltranslate.SampleBean">
  <void property="entry">
   <object class="java.util.ArrayList">
    <void method="add">
     <string>우리는</string>
    </void>
    <void method="add">
     <string>하나다</string>
    </void>
    <void method="add">
     <object class="java.awt.Point">
      <int>1</int>
      <int>1</int>
     </object>
    </void>
   </object>
  </void>
  <void property="name">
   <string>Gore</string>
  </void>
  <void property="scores">
   <array class="int" length="3">
    <void index="0">
     <int>100</int>
    </void>
    <void index="1">
     <int>90</int>
    </void>
    <void index="2">
     <int>75</int>
    </void>
   </array>
  </void>
  <void property="seat">
   <object class="java.awt.Point">
    <int>5</int>
    <int>3</int>
   </object>
  </void>
 </object>
</java>

[/code]
객체의 타입과 할당된 값이 깔끔한 xml문서로 작성된것을 확인 하실 수 있습니다.

자바에는 객체 직렬화(Serialize) 란게 있지요..
위 XMLDecoder와 XMLEncoder가 직렬화 기능을 이용하는건지 아닌지 확인 해 볼까요?
가장 정확한 방법은 XMLDecoder와 XMLEncoder의 소스를 보는것이겠지만 이미 위 예제 소스만으로도
충분히 예상 하실 수 있습니다. 위 예제의 SampleBean 이 Serializable 하지 않음에도 xml문서로 생성되었습니다.
예.. XMLDecoder와 XMLEncoder 내부적으로 java Reflection을 이용하여 xml, 객체간 변환을 수행하고 있습니다.

java Reflection을 이용한다고 했습니다. 이는 getXXX, setXXX 메소드가 없다면 해당 변수를 xml로 만들어내지
못하고 객체로 복원해 내지도 못함을 의미합니다.

또 하나, XMLEncoder를 통해 변환된 xml은 문서의 형태로 보아도 외부 시스템과의 정보의 교환보다는
객체의 상태저장/복원을 목적으로 사용하는게 더 어울릴거란 생각이 드네요.

후지쯔의 U2010을 구매한 후 종종 넷북/UMPC 게시판을 찾아가곤 하는데 근래에는 빌립의 S5, S7 출시 소식과
실버쏜 아톰 플랫폼에 들어간 폴스보칩의 H.264코덱의 가속 기능에 대한 이야기가 한창인듯하다.
이 H.264 코덱 영상의 하드웨어 가속을 활성화하는 방법이 그리 녹녹치만은 않아서 설정에 쉽게 성공한 사람도
안된다는 사람도 있는 모양이다.

해서 나도 한 번 도전해 봤다.

확인 결과 이 H.264 코덱을 하드웨어로 가속(DXVA)하기위해서는 몇가지 조건이 갖추어 져야 하는데
1. 그래픽 카드 칩셋이 H.264 가속을 지원해야한다.
2. 그래픽 카드 드라이버도 이를 지원해야 한다.
3. 그래픽 칩을 활용하여 H.264를 디코딩할 코덱(디코더)이 필요하다.
4. 마지막으로 렌더러의 설정이 필요하다.
보통 KMPlayer나 다음팟플레이어 등을 이용한 따라하기식 설정에는 3번까지만 설명하고 있는데
직접 설정하면서 확인한 바로는 렌더러의 설정까지 완료되어야 정말 하드웨어 가속이 되는것 같았다.

가지고있는 기기가 후지쯔 U2010이니 이녀석을 기준으로 설명하면...(아, OS는 Vista Home Premium SP1이다.)

아톰 실버쏜에 들어간 그래픽 칩인 GMA500은 위 사항 중 1,2번은 만족한다.
그 다음 3번. 현재 H.264를 H/W 디코딩 한다는 디코더는 몇 가지 있는걸로 알고 있는데 궁합이 잘 맞는 것이
CyberLink사의 Power DVD 7 이상에 들어간 디코더인 듯하다.
4번 렌더러는 DXVA(Direct-X Video Acceleration)가 가능해야하는데 DXVA1 계열로는 Overlay Mixer,
Video Mixing Renderer 7, Video Mixing Renderer 9 가 있고 DXVA2 계열은 Enhanced Video Renderer (vista only)
가 있는데 U2010의 경우 DXVA1 계열의 렌더러를 사용할 경우 비디오 아웃풋에서 상당한 CPU점유율을 보였으며,
DXVA2 쪽의 렌더러를 이용해야 비로소 낮은 CPU점유율로  원활한 재생이 가능하다.

위에 설명한 내용대로 잘 설정이 이루어지고나면 1920X1080 30fps H.264 동영상을 20%~40%대의 CPU 점유율로
부드럽게 재생해내는것을 볼 수 있다.

참고로 설정한 방법을 정리하자면
1. 윈도우즈 설치 후 업데이트 (가능하다면 .net framework 3.5 sp1 까지 설치)
2. Power DVD 8 ultra 버전 (혹은 코덱) 설치
3. k-lite codec pack 최신버전 설치
4. 다음 팟 플레이어 설치
5. Power DVD 설정
6. 팟플레이어 설정
7. ffshow 설정(이 설정을 통해 WMP11에서도 Power DVD 코덱을 이용할 수 있다.)
의 순서로 세팅하였다.

1,2,3,4 의 경우 일반적인 프로그램 설치의 과정이니 특별한 내용이 없다. 5번부터 설명하면
5. Power DVD 설정 - 설정화면에서 DxVA를 활성화 해 준다.

6.팟 플레이어 설정





7.ffshow 설정
 


여기까지가 설정의 전부이다. 이제 H.264 영상을 돌려보면 된다.( 빙고!! )
테스트에 쓰인 영상은 H.264로 인코딩된 1920X1080 30fps의 메탈기어 솔리드4 트레일러이다.

2009년 12월 수정 : Java 7에 클로저를 도입하기로 했네요.( http://www.yunsobi.com/blog/513 )

2010년 초반 출시를 목표하고있는 Java 7의 기능을 Java SE의 수석 엔지니어 Mark Reinhold가 Devoxx에 게시한 이후 여러 반응이 나오고 있습니다. 비록 그의 발표가 완전히 결정나지 않은 사항에 대한 잠정적인 내용이라곤 해도 커뮤니티 - 특히 클로저(Closure)의 누락을 주시하는 - 의 반응은 대단합니다.

Mark의 소식을 전한 Hamlet D'Arcy는 그의 블로그에 Java 7 Update from Mark Reinhold at Devoxx란 제목으로 Devoxx에 발표한 Java 7 중요한 새로운 기능을 요약해 올렸습니다.

모듈화 - JSR-294와 Project Jigsaw.
JSR 292 - JVM의 dynamic language 지원
JSR 203 - 진정한 비동기 I/O( non blocking I/O가 아닌)로 구현되는 더 새로워진 I/O API
JSR TBD - 아래에 기술하는것 같은 약간의 언어적 변화
   - 안전한 rethrow
   - Null dereference 표현식 : '?' 신택스를 이용한 Null 체크
   - 향상된 타입 추론
   - Multi-catch : catch 절에 ','를 이용하여 다수의 Exception 기술
JSR 296 - 스윙 어플리케이션 프레임워크
6u10 기능들의 개선(자바 커널, 퀵스타트,플러그인 등)

위 내용과 함께, 심사숙고했지만 Java 7에 포함되지 않을 몇몇 기능도 언급했습니다.

Closure - 의견을 통일하지 못해서.
구상화 제네릭 ( Reified generics )
퍼스트 클래스 프로퍼티
연산자 오버로딩
BigDecimal Syntax
JSR 295 - Beans Binding

이에대해 Java.net 에는 "Java 7에서 제외된 아래 기능 중 당신이 가장 관심을 두고 있는것은 무엇?"이란 주제로 투표가 진행되고 있습니다.

Ricky Clarkson같은 사람은 극단적으로 Closure없이는 자바는 죽을 것이라고까지 표현하고있습니다.

So it's confirmed. Despite James Gosling wanting closures, despite 3 working closure prototype compilers, despite every other JVM language supporting closures, Java 7 will not have closures.

Martin Kneissl 역시 Java7에 Closure가 빠진것을 아쉬워하는 사람 중 하나입니다.

It should have closures instead of the new style "for" loop added in Java 5. It should have closures in Java 6. Now it seems that it will not get closures in Java 7. Closures are not that difficult to understand. At least when you compare them to anonymous inner classes in Java. Others disagree. I don't follow the reasoning of the closure opponents when they say that because there are stupid Java programmers out there you should limit the Language trying to prevent them from doing too much harm. That's just impossible. Incompetent programmers will shoot themselves in the foot in any language. Fortunately there are other languages on the JVM that can use the real strength of Java: libraries, portability, and (to some extent) tooling.

이 외에도 정말 많은 개발자들이 자바언어의 Closure 미 지원을 아쉬워합니다.

이번 발표와 커뮤니티의 반응을 통해 너무나 많은 개발자들이 클로저를 원하고 있다는 사실을 알수 있었습니다. 아직 Java 7의 모든 기능 확정되지 않은 상황이기에 커뮤니티의 반응에따라 기능이 추가될 여지도 배제할 순 없지만 개인적으로도 개발의 편의성을 고려하여 언어차원에서 클로저를 지원하면 좋겠다는 생각입니다.
현재 한국 자바 개발 현장에선 1.4가 주류를 이루고 있다고 보여지고 많지 않은 곳에서 1.5 이상이 쓰이고 있는 현실에 비추어보면 1.7이 현장에서 침투하기까진 적지않은 시간이 필요하겠지만요..

Closure에 대해 관심을 갖으신 자바개발자라면 "Neal Gafter의 자바를위한 클로저 프리젠테이션" 을 훑어 보시는것을 추천합니다.

슈퍼패치 레지스트리

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\

레지스트리 키값

0 = 비활성
1 = 응용 어플리케이션 실행시 프리패치 활성
2 = 부트시 프리패치 활성
3 = 모두 프리패치로 활성(기본값)

서블릿 API에 근간한 대부분의 자바 웹 어플리케이션 프레임웍은 web.xml파일에 하나 이상의 서블릿, 필터, 리스너 등 웹 어플리케이션에 관계한 설정을 기술해야만 합니다. 의존관계에 있는 WEB-INF/lib 디렉토리의 jar들도 포함해서 말이죠.
EE6의 한 부분을 구성하는 Servlet 3.0 스펙인 JSR-315은 이것을 바꿀 방법을 모색하고 있습니다. 서블릿 3.0 스펙은 현재 Public Review 상태이면 그 내용은 아래 링크에서 확인하실 수 있습니다.

JSR-000315 Java^TM Servlet 3.0 Specification

서블릿 3.0 스펙에는 무설정(Zero Configuration) 지향과 이식성(Plugability) 향상을 목표로 다음과 같은 새로운 기능이 추가됩니다.
    1. annotation의 추가 : 서블릿 3.0 스펙에는 서블릿의 url-mapping 정보를 제공하기위한 @Servlet과 같은 수 개의 새로운 어노테이션(@ServletFilter, @FilterMapping 등)이 추가됩니다.
    2. web.xml의 분할(fragments) 설정 지원 : 서블릿 정의, 필터 혹은 리스너 등을 각각 지정한 설정 파일을 web.xml에 merge하는 방식을 채택해 개개의 웹 프레임워크 jar 파일들의 각자 고유한 설정을 가질 수 있도록 하였습니다.
Flag(metadata-complete)는 annotation과 fragment 모두의 스캐닝을 제어하는데 이용됩니다.

위와 같은 사양 추가로 인해 원치않는 서블릿이나 필터들의 배포로 야기될 수 있는 보안 위협에 Expert Group내에서도 적지않은 논쟁을 펼치고 있습니다. 물론, 그런 보안 위협은 제거할 수 있을만큼 충분히 유연하다는 의견도 만만치 않구요.
이에 대한 Expert Group의 잠정적인 결론은 커뮤니티의 피드백을 받아보자는 쪽인것 같습니다.

Greg Wilkins는 Automatic Scanning 과 분할된 설정파일의 merge를 예로든 그의 글을 통해 <include>라는 옵셔널 엘리먼트를 추가하는 방식을 제안했습니다.

"Without a web.xml or with a 3.0 web.xml that does not list any inclusions,
the default would be to search all of WEB-INF for annotated servlets and filters,
TLD listeners and web.xml fragments as currently proposed. If however,
a web.xml contained <include> element, then the discovery process would be
modified as the following examples illustrate:
<include src="WEB-INF/lib/dwr.jar"/>
<include src="WEB-INF/lib/cometd.jar"/>
<include src="WEB-INF/classes"/>
This include would scan only the dwr.jar and cometd.jar for annotations,
TLD fragments and web.xml fragments, the WEB-INF/classes directory would be scanned for
annotated servlets. No other jars or classes would be scanned unless listed in their
own include elsewhere in the web.xml."

Specification 리더중의 한 명인 Rajiv Mordani는 위와 같은 방법에 놀랍긴 해도 수긍할 순 없다고 하네요.

"Greg Wilkins의 제안하는 방법은 의도하지 않은 서블릿과 필터들이 노출되는 것을 우려하는
곳에나 먹히는 매우 특별한 경우로 그것은 프레임워크 개발자의 문제이며 특정 컴포넌트를
노출하지 않기를 원하는 이용자의 문제는 아니라고 생각한다. 이런 경우라면 flag를 이용하여
jar의 집합으로부터 효율적으로 스캐닝을 컨트롤 할 수 있다."  

다른 두 가지 가능성에 대해 올해 Java One Conference에서 Expert Group 사이에서 논의가 있었습니다.
한 가지 방법은 web fragments와 annotations의 스캐닝 여부를 활성화(enable/disable)하는 두 번째 flag를
metadata-complete에 추가하는 방법이 있겠습니다.
Rajiv Mordani의 요지는 어노테이션 메카니즘은 이미 web.xml 파일의 설정을 상속받을 수 있도록 구현 되었기
때문에, 이런 방법을 통해서도 원하는 수준의 제어가 가능하다는 것입니다.

"When you use annotations to declare servlets and Filters then you must have a url-mapping
/ FilterMapping attribute on the corresponding servlet / Filter.
In this way there is no convention by which a servlet is exposed without having an explicit mapping.
Also, as with the rest of the Java EE platform, specifically technologies like EJB and Web Services,
the deployment descriptor is used to override information that is specified via annotations....
If you didn't want any of the annotations to be processed at all by the container and wanted to specify
all the configuration via the deployment descriptor, then, like with the rest of the Java EE 5 platform,
we have the metadata-complete element in the descriptor. If the element is present and set to "true" then
the container will not process any annotations and just use the configuration specified in the descriptor.
This provides a way [to] disable the auto-scanning for those that have concerns about performance,
and security.”

마지막 방법은 아래와 유사한 방식으로 서블릿과 필터를 무효화하는 메카니즘을 web.xml에 기술하자는것

<servlet>
      <servlet-name>FrameworkServlet</servlet-name>
      <enabled>false</enabled>    
</servlet>

등이 있습니다.

해당 이슈에 관심이 있거나 feedback을 원하는 분은 jsr-315-comments@jcp.org으로 의견을 보내실 수 있습니다.

** 본 포스팅은 2006년 12월 20일 네이버 블로그에 포스팅한 내용을 백업, 내용을 보강한 것입니다. **

자바 진영에서 웹어플리케이션(jsp,servlet,jsf,struts,webwork 등을 통틀어)을 구성하는데는 크게 두가지의 표준디렉토리 레이아웃이 존재한다.
( 모든 웹 프로젝트가 표준을 따르는것은 아니며 각각의 프로젝트마다 달라질 수있다. 여기서는 두 표준이 제시하는 디렉토리 레이아웃을
살펴보고자 할 따름이다.)

하나는 SUN에서 내 놓은 JAVA Blueprint, 나머지 하나는 자카르타 프로젝트이다.
두 레이아웃의 차이는 아래 다이어그램으로 표현 할 수 있다.

주황색으로 구분지어 놓은 부분이 두 구성간의 디렉토리 차이이다.

J2EE 환경을 구축하기 위해선 Java Blurprint 형식의 레이아웃이 더 알맞은 형식이라 생각한다.
netbeans 에서 웹 어플리케이션 프로젝트를 생성 하면 위의 두 형식의 표준을 모두 지원한다.
메뉴 -> File -> New Project... -> 프로젝트 카테고리에서 Web 선택 -> next 하면 아래와 같은 대화창이 뜬다.



붉은 색 박스 안과 같이 두 양식 중 하나를 선택 할 수 있으며 이 두 양식의 선택에 따라 아래와 같은 표준 레이아웃으로 프로젝트가 생성 된다.
(추가 : 현재의 넷빈즈는(버전 6.0이상) 위와 같은 옵션이 사라지고 Java BluePrints형식에 맞추어 디렉토리가 설정됩니다. )



맨 위 디렉토리 형식에 추가하여 nbproject 와 test 디렉토리가 추가로 생성 되는데 nbproject에는 해당 웹 프로젝트에 대한 메타 데이타와
build.xml에 기술 되어야 할 앤트 스크립트의 실제 내용이 배치되며, test 디렉토리에는 test용 클래스등을 구성 할 수 있는 디렉토리로 존재하게 된다.

* MANIFEST.MF ?
Executable JAR 파일을 생성 할 때 main 클래스를 지정 하게 되는데
이 내용을 기술 하는 텍스트 파일이다.

그 기술 내용은

Mainfest-Version: 1.0
Main-Class: [filename] (.class 없이)
Created-By: [생성자 정보] (필요한 내용을 자유롭게 기술...)

이며 
실행은 콘솔에서
java -jar jarfilename.jar [엔터]
혹은 jre 가 설치 되었다면  jar 파일을 더블클릭 하는것으로 실행이 가능하다.

MS Live Labs에서 마이크로소프트사의 첫번째 iPhone용 어플리케이션인 Seadragon Mobile 을 출시하였습니다.Seadragon은 MS사의 Deep Zoom 기능을 이용한 이미지 뷰어 어플리케이션입니다. 고해상도의 많은 이미지의 효율적인 관리가 가능하다고 하고 애플 앱스토어에서 무료로 다운로드 할 수 있다고 합니다.

애플 앱스토어에 게시된 Seadragon Mobile

Seadragon은 Photosynth(링크의 스크린 캐스트 참조)라는 MS의 Photo-browsing 기술을 이용하고 있습니다.

Seadragon Mobile이 지향하는 바는 모바일 디바이스 유저가 그들의 기기에서 다량의 고해상도 이미지를 부드럽고 자연스럽게 보여주는데 있다고 합니다. 이 어플리케이션의 초기 리뷰들이 대부분 긍정적인 반응을 보였지만 몇몇은 속도에 불만을 토로하고 있다고 하네요. Seadragon Mobile은 10 기가픽셀(!!) 이상의 샘플 이미지가 포함되어 있으며, 이용자는 photosynth feed나 RSS 이미지 feed를 통하여 컨텐트를 추가할 수 있다고 합니다.

시연이 아닌 실제 제품으로 PhotoSynth를 이용해 볼 수 있다니.. iPhone에서 동작하는 Seadragon을 보고싶네요.