java : 서버에서 구동중인 jsp파일을 수정하면 자동으로 서버에 반영이되요!

한번즈음은 생각해볼 필요가 있겠죠?

※ 우선 이 글은 이클립스와 같은 자동으로 컴파일을 해주는 IDE를 사용하는 입장에서 작성하였습니다.

이미 구동중인 class파일들이 서버에 올라가서 구동중에 있는데 개발자들은 언제든 jsp 파일 등을 수정하고
저장하면 서버에서는 수정한 사항이 보여집니다.
이미 서버에는 class파일이 올라가 있을텐데 어떻게 이런 아름다운 일이 벌어질까요?

이는 class loader와 dynamic binding에 밀접한 관련이 있습니다.

상식적으로 메모리에 상주하고 있는 객체와 같은 이름의 객체가 메모리에 올라올 경우는 반드시 문제가 발생합니다.
같은 이름의 변수들을 선언할 수 없는 것과 같은 이치죠.(block 처리 등을 예외하고^^;;)
따라서 구동중인 애플리케이션은 적재되어 실행중인 객체를 없애고 수정된 새로운 객체를 메모리에 적재해야합니다.
이를 unloading, reloading 등으로 표현하더군요.
(발췌를 해외 article 보고 하였는데 이해하느라 오래걸리면서 url을 잊었네요 ㅠㅠ)

실상 java.lang의 classloader가 이러한 역할을 하고 있는데 실제 내부 소스를 살펴본다면
이러한 처리를 지원하지 않습니다. dynamic reloading 을 지원하지 않는다는 것이죠. 
(제가 잘못알고 있는 것이라면 속시원히 지적 부탁드리겠습니다;;
소스를 다 뒤져봐도 이해가 안가고;; 수없이 구글링을 통해서도 확인이 안되어 잠정 결론지었습니다 ㅠㅠ)

그렇다면 어떻게 서버에서 구동중인 jsp 파일을 수정하였을 때 자동으로 서버에 반영이 될까요?
서버는 바뀐 jsp파일의 역할을 반영할까요? 그건 바로 tomcat과 같은 웹서버 녀석이 처리해줍니다.
이 녀석들은 끊임없이 모든 객체들을 살피면서 네이밍룰을 제대로 따르고 있는 녀석이 중복되는지 체크합니다.
중복되는. 즉 같은 jsp 파일에서 생성된 객체들이 있다면 (제 생각에 의해서)
보다 전에 생긴 객체의 모든 linking을 끊어버리고 보다 나중에 생성된 이 객체를 dynamic linking합니다.

위 문장은 앞서 작성한 문장과 함께 이렇게 해석할 수 있습니다.
java.lang.Classloader 자체는 dynamic binding(dynamic linking) 을 지원하지 않지만
이를 상속하여서 이를 지원할 수 있는 클래스로 만들면 그만!!! 이란 것이죠.

그럼 모든 linking이 끊긴 이 가여운 오래된 객체는 GC가 나중에 메모리가 찼을때 삭제합니다.
(메모리부분에 대해서는 나중에 또 작성하도록 하겠습니다. 사실 국내 많은 개발자분들께서 잘 정리해주셨습니다 ㅎㅎ)


jsp를 작성하고 수정하고 하면서 늘 궁금했고 어느날 JEUS라는 웹서버를 사용하던중
classloader가 망가져서 더이상 배포할 수 없다는 error문구를 접한 후에 한동안
시름시름 앓다가 겨우 알아낸 것인데... 틀린 부분이 있다면 언제든 지적 부탁드리겠습니다. :)

그림으로 표현하는 것이 더욱 이해가 수월하시겠으나 ... 아 혹시나 해서 찾아봤는데
굳굳굳 자료를 링크해둡니다. :)

4장. Class Loader

View more presentations from 김 한도
http://www.slideshare.net/novathinker/4-class-loader

여기까지 이해하는데 많은 도움을 준 분은 또한 현재 몸담고 있는 회사 사장님. 감사합니다 ㅎㅎ