운영툴 갈아엎기 후기.

최근 간만에 운영툴 새로 셋업할 기회가 생겨서

메뉴 대여섯개밖에 안되는 운영툴이라

이 참에 Java8로 올리고, Spring framework도 Annotation 방식으로 바꾸고,

Transaction 관리도 Spring 스럽게 바꿔주고,

Angularjs 같은 새로운 프레임워크 적용해서 밑바닥부터 깔끔하게 다시 짜려고 시도해봤다...

근데 역시 밑바닥부터 새로 만들려던 시도는

망했다..;;

일단 시작은 이랬다.

Java8 + Spring 4.1 + Santa Transaction Manager + Angularjs + DDD 지원.

간단할것만 같았다.

메뉴 대여섯개 노가다 좀 뛰어서 고치면 될 줄 알았다.

그런데...

Java8 포기

일단 프로젝트에서 com.sun 패키지를 사용하는 바람에 Java8로 올리는 것이 물거품됐다.

어차피 배포 서버도 Java6에 고정되어 있어서 배포 시스템에서 Java 버전을 동적으로 관리하게 하기 전까지는 Java6밖에 못쓰기도 했다.

그래서 Java6으로 원복.

로그인 라이브러리 갖다쓰기

로그인 관련해서도 사내 로그인은 LDAP 서버를 감싸는 서비스를 사용해야 하는데 이를 위해선 ip 등록을 해줘야 하는 문제가 있었다. 그리고 이 사내로그인서비스에서 만든 쿠키를 다루는 Java 라이브러리도 만들어져 있었다. 오호라~ 덮썩!

그런데...이 라이브러리가 Thread-safty를 신경쓰지 않아서, 동시 접속할 경우 세션이 서로 꼬여버리는 버그가 있다 =.=;;... fork 떠서 재작성 ㅠ.ㅠ.. 그나마 오픈 소스라 다행이다..;;

SantaTransactionManager

기존에 만들어 쓰던 것이 있었는데... AbstractPlatformTransactionManager 클래스만을 구현해 놓은 상태였고,  connection 관리를 싸제 Util 클래스에서 THreadLocal로 하는 바람에 dao를 직접 호출할 경우에는 connection 관리가 엉망이었다.

그래서 AbstractPlatformTransactionManager부터 시작해서 Connection 관리에 사용되는 JDBC 관련 모든 클래스를 본떠서 Santa용으로 만들었다...

기존에 거의 다 했다 싶어서 나머지만 구현하면 되겠다 했던게 클래스 6개 더 만들어 주면서 한 2주 쯤 걸린 듯 OTL

AuthFilter

기존 인증 방식은 각 controller 코드 안에 인증 체크해서 로그인에대한 처리를 해주는 코드가 들어가있던 방식이였다. 로그인관련 룰이 하나라도 바뀌면 모든 클래스를 손봐야 하는 구조.

당연히 로그인 기능은 별도 기능으로 모두 들어냈다.

이 시점만해도 Angularjs를 포기하지 않은 상태여서 controller 접근 없이도 plain html 파일에 운영툴 UI가 그대로 노출되는 형태였다.

Angularjs에서 사용하는 html도 같이 인증처리해주기 위해서는 HandlerInterceptor로는 부족하고 JEE Filter를 써야 했다. Spring-Security는 전부터 쓸데없이 복잡하고 코드가 너무 묵시적이라서 파악도 힘들다 생각했기에 간단히 하나 만들었다. 어차피 인증처리는 별도 서비스를 통해 받고 있으므로 로그인이 필요할 때 redirect만 해주면 될일이였다.

그런데 Filter에 Spring-bean injection 연결해서 만들려다보니 몇일 까먹었다..;;

ContentNegotiationManager!!

확장자에 따라서 HTML, JSON, XML을 알아서 내려준다는 컨셉이 정말 마음에 들었다.

Spring 스럽게, Controller는 데이터 생성에만 치중하고 View 관련된 모든 부분을 각각의 포멧에 맞는 View에서 알아서 처리한다는 부분도 정말 마음에 들고.

그래서 이것도 붙여 보았는데...@ResponseBody가 없는 경우에 대한 JSON/XML 렌더링이 빈 객체로 한번 더 감싸져있다는게 어설펐고, ExceptionHandling에 있어서도 HTML일때와 API일때(JSON/XML) 미묘하게 차이가 날만한 부분이 생기면서 처음 생각과 달리 이건 아니다 싶은 느낌이 강해졌다.

일단 현재는 handlerMethod 단위로 @ResponseBody가 있는 애들은 API용(JSON/XML), 없으면 HTML용으로 구분해놓은 상태이다.

이것도 시간을 꽤 들였으나, 결론은 HTML과 API는 분리하는게 좋겠다는 것이 현재 결론.

Angularjs + Sitemesh3

Angularjs가 보기에는 참 좋았다...쓰기에도 좋을것 같았다....Single Page App이라는 단점을 제대로 이해하기 전까지는...

사실 Angularjs 기능중 가장 마음에 안드는게 routing 기능이다. app처럼 이쁜 transition을 위해서 어쩔 수 없다 하더라도 난 그딴거 쓸 생각 없었다. 근데 HTML5의 include는 아직 브라우져 특성을 타기 때문에 공통메뉴, header, footer를 적용할 마땅한 방법이 Angularjs에는 없다.

그리고, 운영툴이 기존에 velocity로 되어 있었다. 모든 페이지를 한번에 Angularjs로 갈아타기에는 확실히 부담이었다.

모든 메뉴를 갈아엎지 못할 경우 등도 고려해서 일부 페이지는 velocity로 유지하고 싶었다....근데 Single Page App이다..;;

짱구를 굴려보다가 Sitemesh가 떠올랐다. 올커니~ Filter 방식이라 Angularjs에 투명하게 동작한다.

Angularjs용 html 파일을 여러개 만들어 두었어도 Sitemesh로 한번 걸러서 Header, menu, Footer 처리가 완벽히 동작한다! Sitemesh decorator를 jsp로 구현해서 Angularjs에 필요한 app-name도 1depth path 기반으로 자동생성 해준다!

일단은 클리어 해보이는데...어쨌든 기존 vm 파일들을 모두 재작성해야 하고, 이게 생각보다 손이 많이 가는 관계로 sandbox에만 머무름.