비얌

이 블로그에서 가장 많이 들어오는 URL이 javax.mail 사용기이다... 그런데 이게 동작하지 않는다는 것을 알고 나서 이러면 안되겠다 싶어서 다시 javax.mail 사용기를 새 버전으로 해야겠다고 생각했다... (개발을 처음 시작할 때 만들었던 소스인데... 다시 만드려니 좀 그렇다...ㅎㅎ) 그럼 이제 시작해 보자. 자 일단 javax.mail jar를 받자... http://www.oracle.com/technetwork/java/index-138643.html 해당 jar를 프로젝트에 포함 시킨다.. import java.io.File; import java.io.FileInputStream; import java.util.Date; import java.util.Properties; im..

http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Connector_Comparison NIO Connector 한번 써봐야 할 듯.. Connector ComparisonBelow is a small chart that shows how the connectors differentiate. Java Blocking Connector Java Non Blocking Connector APR/native Connector BIO NIO APR Classname Http11Protocol Http11NioProtocol Http11AprProtocol Tomcat Version 3.x onwards 6.x onwards 5.5.x onwards Suppor..

Apache 와 Tomcat 의 연동은 이제는 평범하다 못해 진부하게 되었다. 그런데 조금 웃긴 사실은 이러한 연동에 대한 기본 개념을 정확히 알지는 못하고 Blog에 있는 내용을 따라하다 보니 실제로 연동이 오류가 났을 때에는 블로그 글을 보고 다시 처음부터 해보는 경우가 많다. 가령 디렉토리명을 apache2.2에 Tomcat 7.0으로 설치했다가 apache2, tomcat7로 했다가 apache_real, tomcat_real 으로 한다던지 이다... 뭐 딱히 위에 방식이 잘못된 것은 아니지만 다음에 인수 받는 사람이 있으면 부끄러워지는 소스가 된다.... Apache와 Tomcat의 연동 방식은 여러가지가 있으나, 가장 기본적으로 많이 사용하는 것은 mod_jk 이다. 그 다음으로 유명한 것은 ..

eclipse를 사용하다 보면 jquery를 받아서 사용하다보면 Script의 Validate 오류가 나서 컴파일 시, 프로젝트가 정상적으로 작동하지 않을 경우가 있다. 이 때, 해결할 수 있는 방법은 아래와 같다. [해당 project] --> [Properties] --> [JavaScript] --> [Include Path] --> [Source] --> [Excluded] --> [Edit] --> [Exclusion patterns] --> ["**/jquery*.js"를 입력 ]

AWS Web Console 작업 없이 개인 PC 혹은 IDC Linux 장비에서 AWS 제어하기 들어가면서 AWS는 기본적으로 Command Line으로 모든 것을 처리할 수 있습니다. 실제로 AWS가 오픈할 2006년 당시 Web에서 서버를 할당 받는 작업만을 수행하고 실제로는 Terminal에서 모든 작업을 하였습니다. 그러던 시스템이 이제 사용자가 많아지고 제공되는 서비스가 많아지면서 Web Console에서 몇 번의 Click으로 작업을 처리할 수 있게 되었습니다. [AWS Web Console] (참~ 많은 것을 하게 되었지요...만약에 잘 쓰면 개인 IDC 구축은 일도 아닐 듯...) 문제는 Web Console에서 제공되어지지만 내 맘데로 움직이려면 제약이 있습니다. 가령 AMI(흔하게 쓰..

AWS에서 Architecture를 설계하고자 한다면 다음을 생각하자. 1. 중앙집중식 Framework 설계에서 기능 중심형 Framework 설계로 2. JAVA Framework 만이 아닌 기능의 복잡성 혹은 Transaction의 중요도에 따라서 다양한 언어 Framework 적용 3. 기능 중심의 서버 배치 4. Data 동기화 대상 선별 및 해당 Data 동기화 Time 결정 (실시간, 스케쥴링) 5. Region 별 기능별 서버 spec 결정 (일별 사용자 최대치가 아닌 일별 평균치에서 10%~20%로 산정하되 Auto Scale-out 방안 결정) 6. Scale-up은 Region별 사용률 모니터링에 따라 순차 적용 (Auto 적용 불가) 7. Geo DNS 도입 여부 결정하여 서버별 접..

요근래에 Amazon Web Service를 사용하고자 하는 국내 기업들이 많다. 하지만 실제로 런칭한 서비스는 손에 꼽을 정도 이다. (자세하게 얘기하고 싶지만 Amazon 관계자도 쉬쉬 하는 내용이니깐....) 그런데 AWS를 꼭 써야만 하는지에 대해서 깊게 생각하지 않고 "걍 외국에서 쓰고 있고 좋은 걸꺼야" 라는 기류에 편승해 쓰려고 하는 것이 아닐까라는 생각이 강하게 든다. (꼭 EJB 같다...) 아는 컨설턴트의 얘기를 빌리면 국내 유수의 기업에서도 도입을 검토했다가 비용 및 구조에 좌절해서 포기하는 경우가 있다고 한다. 따라서 윗분(?)들의 생각은 조만간에 고착화 될 것 같다...두가지로.. 1. 외국에서 쓰니 우리도 글로벌을 위해 쓰자. 2. 그거 어차피 거품이다. 쓸모가 없으니 쓰지 말자..

Amazon Web Service 준비물 1. Amazon 계정 2. 해외 결재 가능 신용카드(VISA, Master, ....) 3. 연락 받을 수 있는 전화기 위 사항들만 있으면 Amazon Web Service를 할 수 있다. 자세한 것은 ...... 다음 기회에......

난 정말 튜토리얼을 좋아한다. 그냥 1번 뭐하고, 2번 뭐하고,....끝으로 실행 하면 'Hello World'가 찍힙니다.... 이 얼마나 단순하고 깨끗한 구성이란 말인가.. Hello World에서 마음데로 변화도 시켜보고 지워도 보고 하면서 내가 공부하고자 하는 넘이 좋은지 안좋은지 판단할 수 있으니깐...난 튜토리얼이 넘 좋다. 그런데 요근래 플러그인이 갑자기 개발하고 싶어졌다. 그냥 막 개발을 하고 싶어졌다.(사실 게을러서 쉽게 돌아가는 뭔가가 필요했다.) 구글링과 네이X의 지식iN까지 뒤지면서 Hello World를 짤 수 있는 튜토리얼을 막 찾았다. 하지만 없었다...있을 법도 한데 없었다. 정말 없는 건가 싶었다. 하지만 튜토리얼은 정말 근처에 있었다. 이클립스 도움말에 있었다...ㅡ.ㅡ;..

예전에는 중복 로그인이 가장 큰 이슈였다. 지금 생각해보면 중복 로그인에 대한 관점을 그렇게나 고민해야 했나는 생각이 든다.어차피 Web은 환경이 중복 로그인을 허락하는 환경이 아닌가? 굳이 중복 로그인을 금지해야할 필요성을 좀 못느끼게 되는 것은 사실이다. 물론 전자 상거래 시스템에서 같은 사이트를 여러 창으로 열어 물건을 주문하게 되면 주문이 동시에 진행되기 때문에 데이터가 꼬일 수는 있으나, 과연 이것을 중복 로그인을 막음으로써 해결하는게 정답일까라는 생각이 든다. 지금 생각으로는 Session에 데이터를 쌓아두고 아니면 conversation level에서 처리를 해야하지 않을까? 좀 더 생각을 해봐야겠다. 아래글은 예전에 싱글톤 방식의 디자인 패턴에 대한 욕심이 나서 중복로그인과 연결해 본 글이..