context path를 결정하는 3가지 방법

context path를 결정하는 3가지 방법

WAS라고 부르는 java web application server에 web application을 배포하면 context path 라고하는 경로가 생성된다. 이 문서는 이를 결정하는 3 가지 요소에 대해 정리하려 한다.

구현체 마다 다르지만 Web application server(이하 server)에는 복수의 host를 구성할 수 있으며 하나의 host내에는 복수의 web application을 배포 할 수 있다. web application은 Servlet API상에서는 context라는 개념으로 대입된다. (Web application == context) 하나의 host내에서 각각의 context를 구분하기 위한 방법으로 context path를 부여 받는다. 다음 두 가지 url을 예로 설명한다.

Servlet security

Servlet security

본 문서는 Servlet specification 4.0에 기술된 Servlet security를 Servlet containter 구현 관점에서 재해석 했다. 인증과 권한 그리고 웹 리소스의 보안적 제한에 대한 내용을 다룬다.

웹 어플리케이션은 응용프로그램 개발자에 의해 개발되며 이를 배포자에게 주던, 팔던간에 런타입 환경에 설치며, 응용프로그램 개발자는 보안 요구사항을 배포자와 배포 시스템에 전달하게 된다. 이 정보는 애플리케이션의 배포 설명자, 애플리케이션 코드 내의 주석을 사용하거나 ServletRegistration.Dynamic 인터페이스의 setServletSecurity 메서드를 통해 프로그래밍 방식으로 전달될 수 있다.

Introducing Hydejack 9

Introducing Hydejack 9

Version 9 is the most complete version of Hydejack yet. Modernized design, big headlines, and big new features.

Version 9 is the most complete version of Hydejack yet.

프롤로그

이번에 다룰 내용은 java.util.concurrent package에서 제공하는 Synchronizer(동기자)들에 대한 내용이다. 동기자라 비 동기화된 각 Thread의 작업을 동기화 시키는데 그 목적이 있다. 하나의 일을 여러 스레드가 나누어 수행을 하고 이를 모아서 하나의 결과를 얻는 집계와 같은 프로세스를 예로 들 수 있다. JAVA 1.5 이전의 전통적인 방법으로 thread를 다룬다면 object.wait()로 프로세스를 멈추게 하고 다른 스레드에서 object.notify() 또는 object.notifyAll()을 호출 했을 때 이 멈춤이 풀리게 된다. 그런데 이 방법은 잘못 사용하면 상당히 위험 해질 수 있으니 조심해야 할 뿐만 아니라 특정 플랫폼에서는 소위 허위 각성 현상이라는 문제가 있어 깨우지도 않았는데 깨는 현상이 발생한다고 한다. 이를 대신하여 사용할 수 있는 몇몇 class를 소개하려 한다.

프롤로그

이번 글에서 다루려고 하는 Executor framework는 지금까지 작성해온 스레드 관련된 글에서 예제 코드를 통해 이미 많이 등장했던 내용이다. 전통적인 방법으로 Runnable을 구현하여 Task를 만들고 start()를 호출하여 새로운 스레드를 만드는 방법을 사용하다 보면 자칫 너무 많은 스레드를 만들어 오히려 효율을 떨어뜨리는 문제가 있다. 이런 문제의 해결을 위해 JAVA 1.5에서 처음 이 개념이 등장했다. 적절한 thread 수를 유지시키고 submit 된 작업을 먼저 Queuing 하고 이를 준비된 thread들이 가져다 작업을 하고 결과를 반환하는 방식이다.

프롤로그

전편에서 다루었던 가시성과 이번에 다루려고 하는 “원자성”이라는 주제가 Multi-Thread 상황에서 Thread간 공유 메모리 이슈를 발생시킨 다는 점에서 공통분모를 가지고 있고 서로간의 상호작용을 잘 염두해두어야 한다는 것은 사실이다. 그렇지만 시스템 관점에서 보면 이 두 개념은 조금 다른 곳에 존재한다. 가시성은 CPU - Cache - Memory관계상의 개념이다. 반면 원자성은 한 줄의 프로그램 statement가 컴파일러에서 기계어로 변경되며 이를 기계가 순차적으로 처리하기 위한 여러 개의 machine instruction이 만들어져 실행되는데 여기서 이 하나의 machine instruction 이 컴퓨터 입장에서 최소 연산 단위인 “원자”적 연산이다. 말을 풀어 놨는데 여전히 어려울 것이다. 오히려 본론으로 들어가 그림과 예제 코드를 보면 이해가 쉬울 것이다.

프롤로그

가시성과 원자성 이 두가지를 이해 하면 Multi-thread프로로그램을 작성할 때 무엇을 주의해하는지 명확해진다. 또 다른 표현으로 설명 하자면 단일 Thread 프로그램에서는 가시성과 원자성을 괘념치 않아도 프로그램 작성하는데 문제가 없다. 그렇다고 해서 가시성과 원자성이 Multi-thread를 할 때만 뚜둥 나타나는 개념은 아니라는점 명확히 밝혀둔다. 하드웨어를 설계한 사람들에 의해 만들어진 원래 컴퓨터 내의 구조에 관한 이야기다. 이번 편에서는 지난편에서 설명한 이 두 가지 개념중에 가시성을 좀더 깊게 파고들어보려 한다.

Java Concurrent Programming - Overview

Java Concurrent Programming - Overview

이번 글은 Java concurrent programming의 기초 개념인 가시성과 원자성에 대해 알아본다.

프로그래밍이라는 것을 시작한 이래로 늘 무겁게 다가오는 주제가 Multi-Thread였다. 어떤 언어로 하던간에 어렵고 난해했다. 그렇기에 늘 내가 알고 하고있구나 하는 느낌 보다는 어디서 주섬 주섬 주워온 코드로 현실에 Issue들을 해결하기 급급했다. 헌데 지금은 양상이 다르다. 서버 프로그램밍을 하고 있는 시점에 "아 됐어, 돌아가!" 그리고 다음진도를 빼기에는 너무 불안하다. 사실 이 글을 쓰기전에 atomicReference와 atomicStampedReference등의 자바 Class를 이용한 기술 단편을 정리해서 글을 작성 했는데 내가 이거 뭐 알고 쓰고 있는거야 하는 자책감에 차마 공개하지 못하고 모든 진도와 계획을 멈추고 책과 자료를 찾아 뒤졌다. 자료를 하루 이틀 찾다 보니 그간 내가 정말 개념 없이 volitile, atomic을 운운 했구나 하는 생각이 들었다. 약 일주일의 시간이 긴 터널 같이 느껴질 정도로 간만에 정말 열심히 공부 했다. 더 나가기 전에 이 글을 이해하려면 적어도 Thread가 뭔지는 알아야 한다. 그렇지 못한 독자가 있다면 잠시 다른 자료를 통해 개념이 라도 이해 하고 다시 돌아오시기 바란다.

Example Content III

Example Content III

A page showing Hydejack-specific markdown content.

Hydejack offers a few additional features to markup your markdown. Don’t worry, these are merely CSS classes added with kramdown’s {:...} syntax, so that your content remains compatible with other Jekyll themes.

Pagination