비얌

이 블로그에서 가장 많이 들어오는 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(흔하게 쓰..

test

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를 할 수 있다. 자세한 것은 ...... 다음 기회에......

어케어케 하다가 질렀다... 넘 싸다....39,600원....(oneaday...무서운 사이트..결재까지 30초 걸렸다...ㅡ.ㅡ;) 3월 27일 배송 시작 오면 가지고 놀아야지...ㅋㅋ