the Rabbit_Sand, IT Blog

[Java/Error] java.lang.ClassNotFoundException

Ma_Sand — Thu, 21 Aug 2025 10:45:27 +0900

8월 21, 2025 10:22:15 오전 org.apache.catalina.core.StandardContext listenerStart
심각: Error configuring application listener of class 클래스경로
java.lang.ClassNotFoundException: 클래스경로
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1352)
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1180)
at org.apache.catalina.core.DefaultInstanceManager.loadClass(DefaultInstanceManager.java:544)
at org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:525)
at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:150)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4822)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5363)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1410)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1400)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

프로젝트를 업데이트한 후 톰캣을 기동했더니 ClassNotFoundException 에러가 발생했다.

해당 클래스가 존재함에도 클래스를 찾을 수 없다고 계속 뜨길래 프로젝트와 톰캣을 clean하니까 정상적으로 실행되었다.

프로젝트 clean

: 상단 'Project' 클릭 -> 'Clean' 클릭 -> 팝업에서 'Clean' 클릭

톰캣 clean

: 'Servers' 탭 클릭 -> 톰캣 우클릭 -> 'Clean' 클릭 -> 팝업이 뜨면 'Clean' 클릭

[PostgreSQL] role "rolename" cannot be dropped because some objects depend on it

Ma_Sand — Sat, 12 Oct 2024 18:37:56 +0900

psql 접속 후 \du 입력 시 users의 역할이 출력된다.

사용하지 않는 것을 정리하고자 역할을 삭제하려 했다. 그런데 에러가 발생하였다.

username1의 role을 삭제할 때 발생한 'some objects depend on it'라는 에러는 해당 role이 특정 객체(ex. 데이터베이스)에 대한 권한을 가지고 있을 때 발생한다.

이러한 경우에는 다음과 같이 해결하면 된다.

1. 데이터베이스 접속

'drop role username1'을 입력했을 때 발생한 에러에서 데이터베이스 username2의 권한이라는 세부사항(DETAIL: privileges for database username2)이 있었다. 그 말인즉슨, username2가 username1의 role을 제어할 수 있다는 것이다. 그러므로 username1의 role을 삭제하기 위해선 username2로 데이터베이스 접속을 해야 한다.

\c username2

2. 권한 제거

username1 role이 소유한 권한을 제거한다. REVOKE 쿼리를 입력한 후 REVOKE라고 출력되면 정상적으로 권한이 제거된 것이다.

REVOKE ALL PRIVILEGES ON DATABASE username2 FROM username1;

3. Role 삭제

username1 role을 삭제한다.

DROP ROLE username1;

이때, 해당 role이 객체를 소유하고 있으면 다음과 같이 에러가 발생하면서 role이 삭제되지 않는다.

이 경우에는 해당 객체(view, table, sequence, etc...)의 소유자를 변경한 후 role을 삭제하면 된다.

cf. 객체의 소유자 변경

username1 대신에 객체를 소유할 user를 만들어서 해당 user에게 소유권을 넘긴다.

ALTER TABLE tablename1 OWNER TO new_owner;
ALTER VIEW viewname1 OWNER TO new_owner;

나머지 객체들도 위처럼 동일하게 변경한 후 다시 '3. Role 삭제'의 쿼리를 실행하면 된다.

[Linux] vi 모드에서 파일 내 특정 라인으로 이동하기

Ma_Sand — Fri, 11 Oct 2024 17:09:44 +0900

vi 모드에서 어떠한 파일 내 특정 라인으로 이동하려면 다음과 같이 입력하면 된다.

예를 들어, aaa.txt를 vi로 열어 line 15로 이동하고 싶다.

1. aaa.txt을 vi 모드로 열기

vi aaa.txt

2. line 15로 이동하기

15 입력 후 shift + g 누르기

이때, 콜론(:)은 입력하지 않는다.

>결과

line 15로 이동한 것을 좀더 확실히 확인하려면 다음 명령어를 입력하면 된다.

:set nu

[PostgreSQL] 권한 부여 및 제거

Ma_Sand — Thu, 12 Sep 2024 22:58:27 +0900

권한 부여

데이터베이스에 대한 권한 부여

-- 접속 권한
GRANT CONNECT ON DATABASE 데이터베이스명 TO 계정명;
-- 객체 생성 권한
GRANT CREATE ON DATABASE 데이터베이스명 TO 계정명;
-- 모든 권한
GRANT ALL PRIVILEGES ON DATABASE 데이터베이스명 TO 계정명;

테이블에 대한 권한 부여

-- 조회 권한
GRANT SELECT ON TABLE 테이블명 TO 계정명;
-- 삽입 권한
GRANT INSERT ON TABLE 테이블명 TO 계정명;
-- 수정 권한
GRANT UPDATE ON TABLE 테이블명 TO 계정명;
-- 삭제 권한
GRANT DELETE ON TABLE 테이블명 TO 계정명;
-- 모든 권한
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO 계정명;

스키마에 대한 권한 부여

-- 스키마 사용 권한
GRANT USAGE ON SCHEMA 스키마명 TO 계정명;
-- 객체 생성 권한
GRANT CREATE ON SCHEMA 스키마명 TO 계정명;
-- 모든 권한
GRANT ALL PRIVILEGES ON SCHEMA 스키마명 TO 계정명;

시퀀스에 대한 권한 부여

-- 조회 및 사용 권한
GRANT SELECT, USAGE ON SEQUENCE 시퀀스명 TO 계정명;
-- 모든 권한
GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO 계정명;

함수에 대한 권한 부여

-- 실행 권한
GRANT EXECUTE ON FUNCTION 함수명 TO 계정명;
-- 모든 권한
GRANT ALL PRIVILEGES ON ALL FUNCTIONS IN SCHEMA public TO 계정명;

계정에 대한 권한 부여

-- 데이터베이스의 관리자 권한
ALTER USER 계정명 WITH SUPERUSER;
-- 데이터베이스 생성 권한
ALTER USER 계정명 WITH CREATEDB;

권한 제거

데이터베이스에 대한 권한 제거

-- 접속 권한
REVOKE CONNECT ON DATABASE 데이터베이스명 FROM 계정명;

테이블에 대한 권한 제거

-- 조회 및 추가, 변경, 삭제 권한
REVOKE SELECT, INSERT, UPDATE, DELETE ON TABLE 테이블명 FROM 계정명;

스키마에 대한 권한 제거

-- 사용 권한
REVOKE USAGE ON SCHEMA 스키마명 FROM 계정명;

시퀀스에 대한 권한 제거

-- 조회 및 사용 권한
REVOKE SELECT, USAGE ON SEQUENCE 시퀀스명 FROM 계정명;

함수에 대한 권한 제거

-- 실행 권한
REVOKE EXECUTE ON FUNCTION 함수명 FROM 계정명;

계정에 대한 권한 제거

-- 데이터베이스의 관리자 권한
ALTER USER 계정명 WITH NOSUPERUSER;
-- 데이터베이스 생성 권한
ALTER USER 계정명 WITH NOCREATEDB;

[VMware/Error] 잘 실행되던 VM이 갑자기 열리지 않을 때

Ma_Sand — Thu, 12 Sep 2024 14:22:01 +0900

한동안 쓰지 않던 VM을 사용하려고 켰는데 어떤 팝업창이 뜨면서 켜지지 않았다.

Error while powering on: 다른 프로세스가 파일의 한 부분을 잠갔으므로, 프로세스가 해당 파일을 액세스할 수 없습니다

Cannot open the disk 'C:\Users\사용자계정명\Documents\Virtual Machines\VM이름\VM이름.vmdk' or one of the snapshot disks it depends on.

Module 'Disk' power on failed.

Failed to start the virtual machine.

위 에러는 다른 프로세스가 VM의 vmdk 파일을 잠가서 발생하는 에러이다.

이를 해결하는 방법은 간단하다.

에러팝업에 작성된 경로로 들어가 .vmdk.lck로 끝나는 파일 또는 디렉토리를 찾아 삭제하고 VM을 재기동하면 된다.

VM을 사용하다보면 이런 경우가 몇 번 있었는데 계속 까먹어서 기록해놓는다.

[Java/Error] 서버 기동 시 발생하는 log4j 에러(라이브러리 버전 충돌)

Ma_Sand — Sat, 7 Sep 2024 12:29:24 +0900

Exception in thread "main" java.lang.NoSuchMethodError: org.apache.logging.log4j.util.LoaderUtil.newCheckedInstanceOfProperty(Ljava/lang/String;Ljava/lang/Class;)Ljava/lang/Object;
        at org.apache.logging.log4j.core.util.Loader.newCheckedInstanceOfProperty(Loader.java:338)
        at org.apache.logging.log4j.core.impl.Log4jContextFactory.createContextSelector(Log4jContextFactory.java:98)
        at org.apache.logging.log4j.core.impl.Log4jContextFactory.<init>(Log4jContextFactory.java:59)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
        at java.lang.Class.newInstance(Class.java:442)
        at org.apache.logging.log4j.LogManager.<clinit>(LogManager.java:96)

위 에러는 log4j 라이브러리에서 특정 메소드를 찾을 수 없다는 에러이다.

주로 다음의 원인으로 발생할 수 있다.

log4j 라이브러리 버전 불일치: 현재 사용 중인 log4j 버전과 위 에러에서 해당 메소드를 호출하는 라이브러리 버전이 일치하지 않을 수 있다.
의존성 문제: Maven 또는 Gradle을 사용하는 경우, 의존성 설정하는 부분에서 log4j가 여러 버전으로 설정되어 있을 수 있다.
클래스패스 문제: 애플리케이션의 클래스패스에 잘못된 버전의 log4j가 포함되어 있을 수 있다.

테스트해야 할 프로그램의 서버 모듈 기동 시 다음 에러가 발생하였다.

나의 경우에는 서버 모듈의 외부 라이브러리에 여러 버전의 log4j 라이브러리가 존재했었다.

$ ls -l | grep log4j

$ ls -l | grep slf

사진을 보면 다음 jar 파일들이 버전 충돌된다. 낮은 버전은 전부 삭제하고 가장 높은 버전만 남긴다.

log4j-api-*.jar
log4j-core-*.jar
log4j-jul-*.jar
log4j-web-*.jar
log4j-slf4j-impl-*.jar

그리고 jcl-over-slf4j-1.7.28.jar와 log4j-slf4j-impl-2.17.1.jar, slf4j-log4j12-1.7.28.jar는 전부 동일한 역할을 하기 때문에 log4j-slf4j-impl-2.17.1.jar만 남기고 나머지 2개는 삭제하였다.

$ ls -l | grep log4j

$ ls -l | grep slf4j

위 작업 후에 서버 모듈을 재기동하였더니 오류 없이 정상적으로 기동되었다.

[Java/Error] OutOfMemoryError: unable to create new native thread

Ma_Sand — Thu, 5 Sep 2024 23:25:32 +0900

프로그램 테스트를 하다가 다음의 에러가 발생하였다.

14:25:10.187 [http-nio-8085-exec-8] WARN  io.netty.channel.AbstractChannel - Force-closing a channel whose registration task was not accepted by an event loop: [id: 0xc83c8a8c]
java.lang.OutOfMemoryError: unable to create new native thread
        at java.lang.Thread.start0(Native Method) ~[?:1.8.0_265]
        at java.lang.Thread.start(Thread.java:717) ~[?:1.8.0_265]
        at io.netty.util.concurrent.ThreadPerTaskExecutor.execute(ThreadPerTaskExecutor.java:32) ~[netty-all-4.1.58.Final.jar:4.1.58.Final]
        at io.netty.util.internal.ThreadExecutorMap$1.execute(ThreadExecutorMap.java:57) ~[netty-all-4.1.58.Final.jar:4.1.58.Final]
        at io.netty.util.concurrent.SingleThreadEventExecutor.doStartThread(SingleThreadEventExecutor.java:978) ~[netty-all-4.1.58.Final.jar:4.1.58.Final]
        at io.netty.util.concurrent.SingleThreadEventExecutor.startThread(SingleThreadEventExecutor.java:947) ~[netty-all-4.1.58.Final.jar:4.1.58.Final]
        at io.netty.util.concurrent.SingleThreadEventExecutor.execute(SingleThreadEventExecutor.java:830) ~[netty-all-4.1.58.Final.jar:4.1.58.Final]
        at io.netty.util.concurrent.SingleThreadEventExecutor.execute(SingleThreadEventExecutor.java:818) ~[netty-all-4.1.58.Final.jar:4.1.58.Final]
        at io.netty.channel.AbstractChannel$AbstractUnsafe.register(AbstractChannel.java:471) [netty-all-4.1.58.Final.jar:4.1.58.Final]
        at io.netty.channel.SingleThreadEventLoop.register(SingleThreadEventLoop.java:87) [netty-all-4.1.58.Final.jar:4.1.58.Final]
        at io.netty.channel.SingleThreadEventLoop.register(SingleThreadEventLoop.java:81) [netty-all-4.1.58.Final.jar:4.1.58.Final]
        at io.netty.channel.MultithreadEventLoopGroup.register(MultithreadEventLoopGroup.java:86) [netty-all-4.1.58.Final.jar:4.1.58.Final]
        at io.netty.bootstrap.AbstractBootstrap.initAndRegister(AbstractBootstrap.java:323) [netty-all-4.1.58.Final.jar:4.1.58.Final]
        at io.netty.bootstrap.Bootstrap.doResolveAndConnect(Bootstrap.java:155) [netty-all-4.1.58.Final.jar:4.1.58.Final]
        at io.netty.bootstrap.Bootstrap.connect(Bootstrap.java:116) [netty-all-4.1.58.Final.jar:4.1.58.Final]
        ...

위 에러는 자바 애플리케이션이 새로운 스레드를 생성할 수 없을 때 발생한다. 보통 다음의 원인으로 발생할 수 있다.

스레드 제한 초과: JVM에서 허용하는 최대 스레드 수 초과
메모리 부족: 시스템 메모리가 부족하여 새로운 스레드를 생성할 수 없음
무한 루프: 스레드가 계속해서 생성되고 종료되지 않음

나의 경우에는 메모리 부족인 듯하여 free -h 명령어로 현재 시스템의 메모리 사용량을 확인하였다.

테스트 중인 서버 OS가 CentOS 계열(Linux)이라서 free 명령어를 사용했는데, 만약 macOS에서 메모리를 확인하려면 top 명령어를 사용하면 된다.

# CentOS, RHEL 계열
free -h

# macOS
top -l 1 -s 0 | grep PhysMem

예시사진

free -h 입력했을 때 위 사진과 같은 내용이 출력된다. 메모리 부분을 보면 used(사용된 메모리)와 free(사용되지 않은 메모리)가 있는데, 나의 경우에는 총 15.8G 중에 약 15.0G 정도를 사용하고 있었다.

서버에서 불필요한, 사용하지 않는 디렉토리를 전부 삭제하고 테스트 중인 프로그램을 재기동했다.

여전히 똑같은 에러가 발생했다.

혹시나 해서 VM을 재기동해보았는데, 다행히 에러 없이 정상적으로 프로그램 기능이 작동하였다.

[Python] 삼항 연산자

Ma_Sand — Mon, 2 Sep 2024 23:00:26 +0900

파이썬의 삼항 연산자는 다음의 문법으로 표현한다.

# 참일 때의 값 if 조건 else 거짓일 때의 값

is_gold_yellow = True
print("YES" if is_gold_yellow else "NO")

# 실행결과: YES

기본적인 삼항 연산자는 위와 같은데,

삼항 연산자를 여러 줄에 걸쳐서 사용하려면 '\'를 사용하면 된다.

예시) 0 < angle < 90이면 1, angle = 90이면 2, 90 < angle < 180이면 3, angle = 180이면 4를 출력해라.

angle = 100
print(
    1 if angle > 0 and angle < 90 else \
    2 if angle == 90 else \
    3 if angle > 90 and angle < 180 else \
    4 if angle == 180 else None
)

# 실행결과: 3

[Oracle] 테이블 스페이스(Table Space) 변경

Ma_Sand — Mon, 2 Sep 2024 21:08:15 +0900

솔루션 릴리즈 파일을 설치 및 테스트를 위해 오라클에서 데이터베이스와 계정을 새로 생성했다.

해당 DB로 설치한 후 테스트를 하는데 계속 테이블 스페이스가 부족하다는 에러가 발생했다.

그래서 현재 세션에서 사용 중인 테이블 스페이스를 조회했다.

SELECT tablespace_name
FROM dba_segments
WHERE owner = USER;

위 쿼리로 조회했더니 테이블 스페이스 용량이 매우 작은 것으로 할당되어 있었다. DB 생성할 때 테이블 스페이스를 용량 큰 걸로 지정해놓은 줄 알았는데 제대로 설정되지 않았다.

테이블과 인덱스의 테이블 스페이스를 변경하는 쿼리는 다음과 같다.

- 테이블의 table space 변경 쿼리

ALTER TABLE 테이블명 MOVE TABLESPACE USERS;

- 인덱스의 table space 변경 쿼리

ALTER INDEX 인덱스명 REBUILD TABLESPACE USERS;

테이블 스페이스를 변경하려고 보니 테이블과 인덱스 개수가 매우 많아서, 다음 프로시저를 통해 접속 중인 데이터베이스의 모든 테이블과 인덱스의 테이블 스페이스를 변경하였다.

- 모든 테이블과 인덱스의 table space 변경 쿼리

BEGIN
   FOR t IN (SELECT table_name FROM user_tables WHERE tablespace_name = '기존 테이블스페이스명') LOOP
      EXECUTE IMMEDIATE 'ALTER TABLE ' || t.table_name || ' MOVE TABLESPACE 변경 테이블스페이스명';
   END LOOP;
END;

테이블 스페이스 변경하니 테스트 중에 이와 관련한 문제는 발생하지 않았다.

[Unix] homebrew 설치(mac os)

Ma_Sand — Mon, 26 Aug 2024 00:44:51 +0900

맨날 Linux에서 systemctl 명령어 사용해서 프로그램 기동하다가 Unix에는 systemctl 명령어가 없어서 찾아보니까 brew 명령어를 사용해야 한다고 한다. brew 명령어는 homebrew라는 프로그램을 설치하여 사용할 수 있다. ( https://brew.sh/ko/ )

homebrew란 macOS용 패키지 관리자로, 소프트웨어 패키지를 쉽게 설치하고 관리할 수 있도록 도와주는 역할을 한다.

간편한 설치: 복잡한 설치 과정을 단순화하여 명령어 한 줄로 소프트웨어를 설치할 수 있다.
의존성 관리: 필요한 라이브러리나 패키지를 자동으로 관리한다.
커뮤니티 지원: 많은 오픈소스 패키지가 homebrew를 통해 제공되며, 사용자들이 쉽게 접근할 수 있다.

homebrew 설치 명령어

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

이때, root 계정으로 설치 시도하면 'Don't run this as root!'라고 경고문구가 출력된다. root 계정 이외의 계정으로 접속하여 설치하면 된다.

homebrew 설치 확인 명령어

brew --version

위 명령어를 입력했을 때 해당 버전이 출력되면 정상적으로 설치된 것이다.

만약에 아래 사진처럼 'zch: command not found: brew'라고 출력되면 설치가 완료된 것이 아니다.

이 경우엔 zshrc에 homebrew 경로 환경변수를 추가 후 source 명령어로 환경변수를 적용해야 한다.

homebrew 경로 추가 및 적용

echo 'export PATH=/opt/homebrew/bin:$PATH' >> ~/.zshrc
source ~/.zshrc

이 과정을 거치면 homebrew의 설치가 완료된다.