고구마맨

기존 시스템에 모듈 추가 작업을 진행하는데 해당 에러가 발생했다. 해당 에러는 XML을 파싱하는 과정에서 발생했는데 이런 경우 보통 참조하고 있는 JAR 파일의 충돌 문제로 해당 파일 제거를 통해 해결할 수 있었다. 하지만 이번에는 서버에 직접 접근하지 못하는 이슈와 기존에 알고 있었던 파일이 아닌 다른 파일의 존재로 여러 가지 시도를 하게 되었다. java.lang.NoClassDefFoundError: org/w3c/dom/DOMConfiguration  위의 오류로 검색을 하면 딱히 마음에 드는 해결책을 찾지 못했었다. 참고할 수 있는 글도 많지 않아서 였는데 이게 자주 일어나는 문제는 아닌 것 같았다. 웹 화면의 일부는 아래와 같은 메세지를 표시하고 있었다. 보통 이런 에러를 유발하는 JAR 파일..

위와 같은 오류는 거의 발생하는 경우가 없을 것 같다. jar 파일을 이용하거나 class 파일을 이용할 때 특정 알고리즘을 이용하는 함수를 호출하는 경우 알고리즘을 제공하지 않을 때 발생하는 에러이다. 나의 경우에도 로컬에서는 문제가 없었으나 설치 작업을 진행하는 와중에 발생했다. 알고리즘을 제공하는 목록에서 확인해도 값이 들어있었는데 이해가 되지 않았다. 프로세스를 변경하거나 JAR 파일을 수정한 것도 아니었는데.. 알고보니 서버 다른 디렉토리 내에 과거 버전의 JAR 파일이 존재해서 새로 위치한 JAR 파일을 로드시키지 못해 발생하는 문제였다. 다른 서버에서는 JAR 파일은 존재하지 않았으나 과거 버전의 class 파일들이 특정 경로에 위치하고 있어 위의 에러가 발생했었다. 처음 보는 에러가 발생해..

■ 자바 실행 명령어로 작업할 일이 생겼는데 자바 실제 위치를 알아내는 명령어가 갑자기 기억이 안났다. which java 만 생각나고... 자주 안써서 까먹었다. 간단한 명령어이지만 거의 쓸 일이 없어서 그런지 오랜만에 명령어를 입력하려니까 생각이 나질 않아 글을 쓴다. which - 실행 파일의 위치를 찾을 수 있는 명령어 보통 which java 를 많이 썼다. 그런데 실제 자바의 원본 파일 위치를 알기 위해선 다른 명령어가 필요하다. 그럴땐 readlink - 심볼릭 링크가 연결되어 있는 파일의 경로 찾을 수 있는 명령어 readlink -f /usr/bin/javac 명령어를 통해 자바 파일 위치를 찾을 수 있었다.

■ 프로젝트를 실행하는 중에 에러가 발생했다. 처음에 어떤 에러인지 알 수 없어 검색을 했는데도 쉽게 해결법을 찾을 수 없었다. 해당 에러가 왜 나는지 소스를 분석해도 별다른 특이점이 없었다. 그런데 알고 보니 JDK 버전 문제였다. JDK1.8을 쓰면 안되는 이슈가 있어서 테스트를 JDK17로 했더니 17 특징 중 reflection을 통한 함수 접근을 할 수 없다는 내용을 발견했다. 그래서 버전을 JDK 11 로 바꿔 다시 테스트를 완료했다. 발생에러 해결방법 JDK 버전을 9 ~ 16 사이로 변경 참고사이트 https://revf.tistory.com/269 JDK 9 부터 17까지 총정리 JDK 버전별 주요 Feature 요약 Java 9 JPMS (Java Platform Module Syste..

■ 모듈을 테스트할 때 암호화 부분 관련해서 에러가 발생했다. SHA1 관련해서 프로세스를 진행할 때 발생했는데 해결법을 찾는데 상당히 오래 걸렸다. 자바 버전마다 설정과 사용값이 달라서 발생하는 버전이 있고 발생하지 않는 버전이 있었는데 나는 자바 17 을 사용했다. 에러 발생 설정 경로 : C:\Program Files\Java\jdk-17\conf\security 사진에 나온 부분이 주석처리 되어 있지 않았었다. 그래서 해결방법으로는 이 부분을 주석처리 했다. SHA1의 기한 때문인 것 같은데 딱히 모듈을 실행하는데 쓰이지 않는 것 같았다. 참고사이트(검색키워드 : Disable SHA-1 signed jars) Configure Oracle's JDK and JRE Cryptographic Alg..

■ 소스 코드를 작업할 때 우린 예외 메세지를 분석해서 발생하는 오류를 해결하고는 한다. 그러나 너무 많은 오류 메세지는 불필요하게 느껴질 때도 있다. 그럴 땐 에러 메세지 출력 범위를 함수를 통해 제어할 수 있다. 해당 메세지들의 출력 범위는 많이 다르므로 프로세스 오류 메세지 중요도에 따라 다르게 작업해야 한다고 생각한다. 1. getMessage() 발생한 에러의 원인을 간략하게 출력한다. (Exception의 유형도 존재하지 않음.) 2. toString() 발생한 에러의 원인의 이유를 출력하지만 자세한 발생 위치는 출력하지 않는다. 3. printStackTrace() 발생한 에러의 원인과 발생 위치를 구체적으로 출력한다. (전체적인 프로세스 단계를 모두 출력)