일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- subversion
- svn
- egrep
- yum
- Apache
- 삽질
- 이클립스
- eclipse
- Galileo
- 권한변경
- trac
- CentOS
- tomcat
- Babel
- 지름신
- 파워목업
- CentOS6
- SSL
- resin
- 연동
- 갈릴레오
- tagx
- 3.5
- netstate
- Powermockup
- linux
- Find
- Java
- 보드
- NEXUS
- Today
- Total
목록JAVA (7)
....
어플리케이션 측에서는 서버에서 요청이 들어온것으로 판단하므로 mod_jk가 아닌 ReverseProxy 를 사용하면서 https 스킴을 일어버리게 됨. 다음과 같은 문제가 발생로그인 페이지에 진입시 http인 경우 https로 리다이렉트 처리. (무한 리다이렉트 발생)OAuth2를 사용하면서 요청한 URL은 http이나 응답은 https로 [invalid_redirect_uri_parameter] 인증 오류가 발생. 해결 방법 Apache에서는 아래와 같이 설정 ServerName www.myapp.org ProxyPass / http://127.0.0.1:8080/ RequestHeader set X-Forwarded-Proto https RequestHeader set X-Forwarded-Port ..
tiles와 같은 프레임도 있지만, JSP + el을 이용하고 custom-tag를 사용해서 모듈화를 하는걸 나는 선호한다. 특히 gnb, lnb, footer와 같은 부분을 jsp include를 사용할 경우 리소스의 경로에 의존성을 가지게 되지만, 커스텀테그는 경로에 대한 의존성도 없으며, 무엇보다 파라매터를 전달하고 타입체크도 가능하고, 여러 이점이 있기 때문에.. *.tag는 그냥 JSP처럼 작성을 하고 편하게 사용을 하면 되지만, 문제는 XML로 작성하는 *.tagx로 구현할 때이다.내가 만든 다른 *.tag나 tld를 임포트하는 방법을 맨날 잊어버리고, 또 막상 인터넷 검색을 해보면 tagx에 대한 자료를 찾기가 어렵다.. /META-INF/*.tld의 uri로 임포트 (일반적인 xmlns:s..
자체 release도 아니고 snapshot도 아닌 의존성 라이브러리가 필요할 때가 있다.. 대표적인 경우가 오라클 드라이버.... 실컷 메이븐 프로젝트로 만들어놓고 오라클만 따로 사용자 라이브러리로 개발자마다 직접 등록하라고 할 수는 없는 일.... 그렇다고 11버젼의 jdbc는 중앙 리포지토리에서 구할 수 없고... 10버젼도 잘 다운로드가 안되고.... 그럴때 내부 thirdparty 에 등록해두면 편하다.. mvn deploy:deploy-file -DgroupId=com.oracle -DartifactId=ojdbc14 -Dversion=10.2.0.4.0 -Dpackaging=jar -Dfile=C:\OraClient\ojdbc14.jar -Durl=http://xxx.xxx.xxx.xxx:8..
결론부터 말하자면 반나절 완전 삽질... 음핫핫... 크나큰 교훈을 얻었다.. 예전에 JFreeChart에서 서블릿을 지원하지 않던 시절 Redhat9.0에 JFree + Cewolf를 올리면서 한글과 관련된 설정을 찾아서 수정하느라 애먹은 기억이 있다.. 환경은 운영서버는 윈도우... 하지만 통합테스트는 리눅스다... 통합에 올렸을때 한글이 깨져도 별로 신경쓰진 않았지만... 불현듯 나중에 리눅스에 배포할때 삽질할 수는 없지 않는가~! 라는 생각이 서두였다.... 다시 부랴부랴.. 인터넷을 뒤지기 시작.. $JAVA_HOME/jre/lib/fontconfig.properties 파일을 복사해서 고쳐라 뭐해라... 전부 찾아서 수정했는데도 안된다. 3시간 삽질후 재부팅 한방에 해결했다는 글도 봤고.. 덕..
내맘대로 정규식이다... 맨 앞에 ^와 맨뒤에 $는 각 항목의 글자수 제한을 유효하게 만드는 역활도 한다. 패키지는 com.sun.org.apache.regexp.internal.RE 를 주로 사용한다. 우편번호 : ^(\\d{3})-?(\\d{3})$ 시작부터 끝까지.. 숫자 3개씩 끊어서 받아들인다... 중간에 -가 있든 말든... 주민번호 : ^(\\d{6})-?(\\d{7})$ 아주 딱딱하게 숫자 6개, 7개씩만 끊어서 받는다. 역시 중간에 -가 있든말든... 뒷자리 맨 앞번호를 1,2,3,4로 제한하는 방법도 있지만... 재외국민번호의 경우 8번까지도 쓴다... 전화번호 : ^(\\d+)-(\\d{3,4})-(\\d{4})$ 숫자-숫자(3~4)-숫자(4) 로만 입력 받는다. 암호 : ^([:al..
이전부터도 물론 중요한 사항이였지만... 이번에 IE8에서 개발자툴을 기본으로 지원하면서 특히 파라매터 위조와 관련해서 더욱 문제가 공론화 되가고 있는것 같다. 실제로 클라이언트에서 전송되어온 값을 그대로 믿고 받아들이는건 말도 안되는거지만... 의외로 그렇게 구성된 사이트가 정말 많다는데 적잖히 놀라고 있기도 하다... 대표적인 예를 들어서 회원가입... 보통 실명인증엔진을 탑재한 페이지의 경우... 실명인증으로 우선 이름과 주민번호(혹은 대체수단)을 받는다. 이 경우 실명인증에서 제공하는 Javascript암호화를 이용해서 이름과 주민번호를 다른 Form에 암호화해서 넣어서 서버로 발송한다. 그런데... 열심히 암호화해서 발송하면서.. 이름과 주민번호를 또 평문으로 같이 발송하는 사이트가 있다.. 더..
뜬금없이 다른곳에서 개발한 서버의 고도화 프로젝트를 떠안게 됐다... Spring을 공부하면서 나름 이것저것 손을 많이 대버리는 바람에 어느정도 자신이 있었지만... 유일하게 나중에 공부해야지~ 라고 생각했던 Struts가 두둥~ 하고 내 눈앞에 펼쳐졌다... OTL 소스 분석, 환경 분석을 주구장창 시작하고... 아항.. 아항.. 이렇게 돌아가는 거구나.. 대충 통밥으로 감 잡고.. 확실히 스프링을 공부하고 실무에 적용하면서 익히게 되는 많은 지식들이 엄청난 도움이 된다는걸 실감했다. 어찌됐는 기존의 소스코드는 가히 엉망 진창이였다... SQL Injection에 대한 처리도 전혀 안되어 있었으며, 주석또한 거의 전무하고, 그나마 있는 주석들이 다 중국어..(이건 뭐냐......) 아주 간간~~~히 가..