현재 진행 중인 프로젝트에서 오픈 소스를 분석해서 설계서를 역으로 만들고 있는데(클래스 설계서),

 

약 400여개의 클래스를 손수 MS 워드 문서로 옮겨야 하니 노가다의 절정이라고 생각된다..

 

R&D 사업이니 설계 산출물 자체에 의미가 있다기보다는 예산에 대한 증빙 자료인 셈이다.

 

 

 

각론하고, 다행히 오픈 소스가 Java로 작성되어 있어 리플렉션으로 클래스 정보를 읽은 후 HTML 문서로 출력하고,

 

워드로 옮기면 되겠다. 라고 생각하고 작업을 했는데, 메서드의 파라미터 이름을 가지고 올 수 없었다.

 

 

 

이 문제를 해결하기 위한 방법을 두 가지 찾았는데, 하나는 Java 8의 리플렉션에 추가된 Method.getParamter()를 통해 얻은 파라미터 정보에서 getName()을 이용해 파라미터의 이름을 알아내는 것이고,

 

두 번째는 Java Parser를 이용하는 것이었다.

 

 

 

수작업을 줄이려고 시작한 건데 일이 커지기 시작했다.

 

거기에 더해 오픈소스를 분석한다는 의미는 사라지고 설계서를 만든다는 것만 남았다. (...)

 

 

 

 

 

Java Parser로 테스트를 해 보기 전에 잠시 Java 8에서 테스트를 해보았는데, 파라미터 이름이 arg0 과 같이 실제 이름이 아닌 컴파일러에서 치환된 이름으로 변환되어 나와서 더 찾아보지 않고 Java Parser로 테스트를 했다.

 

 

 

Java Parser를 이용할 때는 원하는 대로 파라미터를 출력할 수는 있었지만, 구조화된 타입이 아닌 파라미터 선언부의 문자열로만 값을 가져올 수 있었고, 한 가지 문제점으로는 public void test(/*Param1*/String param) 과 같은 메서드 선언에서 주석을 같이 읽어오게 되어 예외 케이스에 대한 처리가 복잡해질 것 같아서 다시 Java 8 리플렉션을 통해 파라미터 이름을 얻어올 수 있는 방법을 찾아보게 되었다.

 

 

 

검색을 하면서 하나 놓친 것이 있었는데, 자바 컴파일 옵션에서 -parameters 옵션을 주면 메서드 파라미터의 이름이 그대로 컴파일 된 바이트코드에서도 유지된다.

 

Eclipse에서도 아래와 같이

Store information about method parameters (usable via reflection) 체크박스에 체크하면 파라미터 옵션을 줄 수 있다. (Java 1.8로 컴파일러가 설정된 경우에 활성화된다)

 

 

 

 

 

 

 

 

파라미터 이름을 얻는 소스코드는 아래와 같다.

 

 

 

 

 

 

이 외에도 paranamer라는 라이브러리가 있었지만, 매뉴얼을 대강 읽어보니 Java8에 추가되었다고 노트되어있었다.

 

 

 

 

 

참고 자료

 

https://docs.oracle.com/javase/tutorial/reflect/member/methodparameterreflection.html

 

https://github.com/javaparser/javaparser

http://stackoverflow.com/questions/2237803/can-i-obtain-method-parameter-name-using-java-reflection

 

 

덧붙여,

이 작업을 하고 있는 둘은 한 명은 클래스 명세표 양식을 출력하는 웹 애플리케이션을 만들고 있고, 한 명은 클래스를 리플렉션해서 필요한 메타데이터를 뽑아내는 툴을 만들고 있다. 이쯤 되면 배보다 배꼽의 배꼽 수준인 듯 ㅋㅋ

설문 조사 폼을 만들이 있어서 작업 중에 설문 조사의 질문과 선택 옵션의 수는 가변적이므로 Parameter 컬렉션을 사용했다. 작업을 마무리 한 후 정상적으로 동작하는 지 테스트를 한 후 서버에 배포했다.


그런데.


이른바 "내 컴퓨터에서는 잘 되는데요?" 문제가 발생했다.


그렇다. 테스트를 할 때는 아무리 많은 질문과 옵션을 추가해도 잘 동작하던 것이, 서버에스는 IndexOutOfBound 예외를 내면서 설문이 제대로 처리되지 않는 문제가 발생했다.


설문 조사를 올리시는 분께서는 "음.. 7개가 넘어가면 설문 내용이 없어져요."라고 했고, 나는 "그럴리가 없다! 그 부분에 있어서 내 로직이 틀릴 리가 없다!" 라고 했다.

무지하면 용감하다더니, 어찌도 그리 당당할 수 있었을까? 다시 생각하니 부끄럽다.


서버에 배포된 설문 조사 폼을 확인해 보니, 정말 7개 이상으로 질문을 추가하면 죽는 것이 아닌가? 똑같은 설문 내용으로 내 컴퓨터(개발 컴퓨터)에서 테스트를 하니 "내 컴퓨터에서는 잘 된다."..


이 때까지는 자바스크립트로 설문 내용을 추가하는 부분에 이상이 있을 것으로 예상했다. 그런데 역시 이때까지는 Integer의 범위를 벗어나는 것도 아니고, 왜 하필 7개일까? 라며 이상하게만 생각하고는 자바스크립트 부분을 확인해 봤지만, 역시 이상은 없었다.


그러다 문득 톰캣 이 자식이 방해 공작을 하는 것이 아닐까 하는 생각에

"tomcat post form input limit length"를 키워드로 검색하니 한 블로그 글이 검색됐다.

그리고 그 글에는 내 문제의 원인이 무엇인지 명확하게 나와있었다. 그렇다. 파라미터의 수를 제한하는 설정이 있었던 것이다.


테스트 서버의 톰캣 설정은 그 파라미터 갯수 제한이 무한대라서 파라미터 갯수의 제한이 있다는 걸 모르는 상태에서는 그런 문제가 발생할 지 전혀 예측할 수 없었고,

실서버에서는 maxParameterCount="50" 으로 50개의 제한이 있었다.


질문 하나를 구성하는 속성은 제목, 질문 타입, 옵션 5개로 7개였으니, 톰캣이 수용할 수 있는 최대 질문의 수는 7개가 되는 것이고, 그 수 이상이 되면 서버가 빵~ 예외를 터뜨린다. 여태까지 파일 업로드 크기의 제한이 있는 줄은 알았지만, 파라미터의 수에 제한이 있을 줄은 몰랐다. 폼 파라미터의 갯수 및 크기 제한을 하는 설정은 아래와 같다.


server.xml 파일


maxParamterCount 속성은 폼 파라미터의 최대 수이고, maxPostSize는 폼의 최대 전송 용량(byte)이다. 값을 -1로 하는 경우 제한을 두지 않도록 한다.



"내 컴퓨터에서는 잘 되는데요?"

"님 컴퓨터에서도 잘 돌아가요"가 될 수 있도록 내가 사용하는 것들을 잘 알고 써야겠다.

+ Recent posts