섭이의 개발일지

만약 저와 똑같이 젠킨스 허접이라면

'왜 내가 jenkins로 올린 톰캣(startup.sh)이 쉘로 잘 작동했는데 jenkins job이 끝나면 왜 서버가 안올라가있을까?' 

라는 의구심을 품게됩니다...

저도 그랬거든요

너무 슬픈 이야기 ..

https://wiki.jenkins.io/display/JENKINS/ProcessTreeKiller

jenkins 공홈에서 위와같은 내용을 볼 수 있습니다.

ProcessTreeKiller라는 놈인거같은데 내용 역시 jenkins 공홈을 보시길 추천합니다.

간략하게 설명하면 jenkins job이 돌때 jenkins가 올린 프로세서들은

job이 끝나는 지점에서 전부 종료?시키는거 같은데

저희의 was서버는 job이 끝나도 백그라운드로 계속 돌아야하죠 ..

방법은 아래!! 

Jenkins의 'Freestyle project' 에서 '이 빌드는 매개변수가 있습니다' 를 클릭하고

'String Parameter'를 선택해서 위와같이 'donKillMe'를 사용해서

job이 끝나도 쉘에서 작동시킨 process를 종료시키지 않게하는 파라미터를 던질 수 있습니다.

만약 pipeline으로 작성하시느분들은

In case of Jenkins Pipeline use JENKINS_NODE_COOKIE instead of BUILD_ID

참고!

https://wiki.jenkins.io/display/JENKINS/ProcessTreeKiller

pom.xml에 

	<!-- oracle -->
		<dependency>
			<groupId>com.oracle</groupId>
			<artifactId>ojdbc14</artifactId>
			<version>10.2.0.4.0</version>
		</dependency>

다음과 같이 입력해도 maven이 해당 라이브러리를 다운받지 못한다.

오라클 라이센스와 관련이 있는듯하다

따라서 직접 ojdbc 라이브러리를 구한다음에 local maven repository에 등록시켜야

아마 해당 프로젝트가 원활하게 돌아갈 것이다

나는 쫄보여서 라이센스 관련된건 못올리겠지만

사실 구하는건 어렵지 않으니 직접 jar파일을 구해서 아래의 명령어를 참고하여 local maven repository에 등록시키자~!

mvn install:install-file -DgroupId=com.oracle -DartifactId=ojdbc14 -Dversion=10.2.x.x.x -Dpackaging=jar -Dfile=ojdbc14.jar -DgeneratePom=true

https://stackoverflow.com/questions/9007009/is-there-an-issue-with-the-oracle-dependency

https://stackoverflow.com/questions/28787495/missing-artifact-com-oracleojdbc14jar10-2-0-1-0

이 글을 보시는 분들의 특징은 아마도

spring + mybatis 환경에서

xml파일이 src/main/java 내부에 *.mapper.xml로 java소스랑 섞여있으실꺼다

왜냐면 우리 회사가 그러거든 ^^

일단 권장하는 설정은 java파일 이외에 xml 등등의 resource파일은 src/main/resources 내부에 두는것이다.

하지만 나처럼 프로젝트를 크게 건들기 싫은사람은 아래의 방법을 사용한다

<build>
    <resources>
        <resource>
            <directory>src/main/java</directory>
            <includes>                      
                <include>**/*.xml</include>
            </includes>
        </resource>
        <resource>
            <directory>src/main/resources</directory>
        </resource>
    </resources>
</build>

build 태그 내부에 다음부분을 명시해주면

mvn package 이후에

src/main/java/../SomeMapper.xml 이 같이 말려있는것을 확인할 수 있다!

https://stackoverflow.com/questions/9798955/with-maven-clean-package-xml-source-files-are-not-included-in-classpath

와 .. 난 이걸 1년동안 가만히 뒀는데

도저히 내가 잡을 수 없는 그런 이클립스의 종특이라고 생각했다 ...

사람마다 다를 듯 하지만 내가 쓰는 eclipse에 내장된 maven은 기본 default compiler의 jdk 설정이 1.5였다

만약 본인이 따로 maven compiler plugin을 설정해서 사용한다면

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>2.1</version>
  <configuration>
    <source>1.6</source>
    <target>1.6</target>
  </configuration>
</plugin>

위와같이 configruation 태그 안에 source, tartget을 본인이 사용할 jdk 설정으로 바꿔주면된다.

만약 본인이 maven compiler plugin 을 사용하지 않고 default를 사용하는데

컴파일 jdk를 변경하고싶다면

<properties>
    <maven.compiler.source>1.6</maven.compiler.source>
    <maven.compiler.target>1.6</maven.compiler.target>
</properties>

다음과 같이 변경함다

* 내 생각에 이 글은 버전에따라 먹힐수도 안먹힐 수도 있을꺼 같긴하다... 물론 내생각!

https://stackoverflow.com/questions/28509928/java-version-automatically-change-to-java-1-5-after-maven-update

보통 이 에러는 mockito + powermock 조합일때 나는것 같다.

powermock이 리플렉션으로 이루어져있어서 private , protected 메서드 의존성을 깨부술라고 너무 기쁜 맘에 도입했다

결과는 역시 fail ...

하지만 우리에겐 구글신이 있지

만약 Mockito 2.x 버전을 쓰고 있으면 powermock-api-mockito 모듈은

java.lang.NoClassDefFoundError: org/mockito/cglib/... 의 에러를 뿜뿜할 것이다

Mockito 2.x 에는 powermock-api-mockito2 모듈을 얻혀주면 잘 동작할 것이다

만약 위 방법으로 해결되지 않았다고 하더라도

Mockito 와 PowerMock의 의존성이 어느정도 있는 듯 하니 반드시 버전체크를 진행한다

여담으로 라이브러리 버전 맞춰주니까

이번엔 jdk 문제가 나서 (회사 jdk 1.6 =_=)

 그냥 Mockito 1.10.x powermock 1.6.x 로 올려주니까 잘 돌아간다 ..

https://proandroiddev.com/mockito-2-x-over-powermock-migration-tips-and-tricks-top-ten-118c52abd1d8

회사에 테스트 프레임웍을 포함해 테스트코드는 하나도 없어서 내가 구축해서 해보려고 하는데

난관이 많았다 ... 위 에러는 비교적 간단하지만 그래도 글을 남겨본다

우리가 대표적으로 사용하는 tomcat은 서블릿컨테이너를 포함하고있는데

웹 어플리케이션을 이클립스에서만 빌드해본게아니라 maven 명령어로 빌드해보신분들은 잘 아실꺼다

빌드하는 순간 javax.servlet ... 어쩌구 에러가 나는데 이게 단순히 mvn package 명령어로 빌드하는 시점에는

서블릿 컨테이너가 없기 때문에 컴파일시점에서는 오류가 난다.

그래서

		<dependency>
		    <groupId>javax.servlet</groupId>
		    <artifactId>javax.servlet-api</artifactId>
		    <version>3.0.1</version>
		    <scope>provided</scope>
		</dependency>

위와같이 scope 설정을 provide로 둔다. provided 설정은 javax.servlet 에 대한 의존관계를 컨테이너에게 떠넘긴다? 라고 생각하면 편하다. 따라서 빌드하는 시점에는 오류가 나지 않는다.

뭐 이거는 그렇다 치고 .. 똑같이 웹어플리케이션을 테스트할때도 마찬가지다.

junit이 돌아갈때는 javax.servlet 패키지에 대한 의존관계를 아무도 해결해주지 않기때문에 스프링 컨테이너가 올라가는 시점에 에러가 난다.

No qualifying bean of type [javax.servlet.ServletContext] found for dependency ... 어쩌구

이때 사용 할 수 있는것이 바로

@WebAppConfiguration 어노테이션이다.

spring doc을 확인해보면

The presence of @WebAppConfiguration on a test class indicates that a WebApplicationContext should be loaded for the test using a default for the path to the root of the web application. 

테스트 클래스에 @WebAppConfiguration이 있으면 웹 응용 프로그램의 루트에 대한 경로에 대한 기본값을 사용하여 테스트를 위해 WebApplicationContext를로드해야 함을 나타냅니다. 

라는 말이 있다. 여기서 경로에 대한 기본값은 따로 지정하지 않으면 "src/main/webapp" 로 올라간다.