변수명 맞추기...


잘 만들어지고 있던 사이트에 마지막 기능을 추가하는 중...
갑자기 등록과 수정(POST,PUT) 과정에서 400 Bad Request 오류가
발생을 한다.


다른 메뉴에서는 잘 되는 것으로 보아 설정의 문제는 아니고...
새로 구현된 기능에 국한된 문제인 듯싶은데...


반나절 이상을 날리면서 오늘 아침 겨우 찾아낸 문제의 원인은...
서버측 domain 클래스의 변수명과 등록/수정 시 넘기는
JSON 문자열의 변수명이 일치하지 않았던 것...ㅠ.ㅠ


서버쪽에서 변수명에 오타가 하나 있어 수정을 했는데
클라이언트쪽에서 수정을 안한 것이다.


참으로 소박한 실수였다...ㅠ.ㅠ

블로그 이미지

마즈다

이제 반백이 되었지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

댓글을 달아 주세요

지난 번 잠시 언급한 적이 있지만 현재 Spring 3.1.1 + MyBatis + jQuery + Bootstrap을 이용하여

업무에 사용할 작은 사이트를 만들고 있다.


기업체의 내부망에서 작업하는 중이라 소스를 공개하지 못하는 것이 못내 아쉽다.


사실 Spring을 다시 만져보는 것이 거의 7년만이라 약간의 낯설음은 있지만 그 낯설음을 상쇄할만한

변화가 있었기에 어렵지 않게 다시 시작해 볼 수 있었다.


그래도 어디 세상 일이 밥 달라면 밥 나오고 물 달라면 물 나오던가?

이래 저래 소소한 에러들을 자주 접하게 된다. 그리고 언제나 그렇듯 아무 것도 아닌 문제로

반나절을 그냥 날리기도 하고...


어차피 전문적인 내용이야 볼 수 있는 곳이 천지니 나는 내가 겪은 에러나 정리하련다.


1. Mapped Statemets collection already contains value for...

톰캣을 기동하는데 이런 메시지가 나오면서 디플로이가 제대로 안되었다.

얼핏 메시지 내용을 봐서는 어딘가 중복된 설정이 있거나 id명을 중복해서 썼거나 했을 것 같았는데...

나같은 경우 특정 Mapper의 Query문에 문제가 있었다.

갑자기 기억이...쿼리 자체의 오류였다기보다는 MyBatis 쿼리 설정 상의 문제였던가? 

하여간 이런 오류 만나면 Mapper에 있는 쿼리도 잘 살펴야 한다.


2. requestmappinghandlermapping did not find handler method for

요건 메시지 내용대로 request에 대한 mapping이 잘못되어 요청한 리소스를 찾을 수 없다는 뜻이다.

요런 것이 참 별것도 아니면서 시간 잡아먹는 하마다.

문제의 원인은 Controller에는 request parameter를 userId로 해놓고는 jQuery의 ajax 호출 시

파라미터 명을 userID라고 써서 발생한 문제였다.


3. Invalid bound Statement (not found): Mapper.function

요것도 메시지를 눈여겨 보면 답이 나온다.

문장과 Mapper의 함수가 연결이 안된다잖는가~

바로 Mapper.xml에 있는 쿼리 id와 Mapper.java에 있는 메소드 명이 달라서 발생한 문제다.


4. 건 에러는 아니지만 get방식으로 request할 때 한글 깨지는 문제 처리 방법이다.

클라이언트 측 : jQuery에서 한글로된 인자를 넘길 때 encodeURI(encodeURIComponent(value))로 넘긴다.

서버 측 : Controller에서 한글 인자를 받을 때 URLDecoder.decoded(value)로 처리해준다.


참...적어놓고 보니 초급자 수준의 실수가 날 울리네....ㅠ.ㅠ







블로그 이미지

마즈다

이제 반백이 되었지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

Tag error, Spring

댓글을 달아 주세요

먼저 이 글은 기술적인 분석이 아닌 학습 과정에서 느낀 개인적인 느낌을 적은 글임을 밝힙니다...^^






별로 바쁘지도 않은 SM 업무를 하면서도 어찌 그리 시간을 내지 못했는지...

거의 2년에 가까운 시간 동안 앱 개발도 못하고 실습을 동반한 학습을 진행하지도 못했다.

이러다가 바보 되는 것이 아닌가 싶어 마침 급조된 몇몇 업무용 시스템을 통합하여 조금은 쓸모있게 만들 겸

Spring기반으로 재구축하는 작업을 시작하였다.


얼마전 공부하던 Springboot + JPA + AngularJS + Bootstrap으로 진행하려 했으나 대부분의 기업 환경이 그렇듯이

최신 기술을 적용할 만한 상태가 아니기에 Spring 3.1.1 + MyBatis + jQuery + Bootstrap으로 진행할 수밖에 없었다.


Springboot를 사용하면서 가장 좋았던 점이 view단에 JSP 사용을 권장하지 않는 점이었다.

사실 이제는 너무 익숙해진 기술이긴 하지만 JSP 소스를 볼 때마다 JAVA 코드와 HTML 코드와 Javascript 코드가

흉물스럽게 뒤엉킨 그 모습이 너무나 보기 싫었던 것이 사실이다.


Template 엔진 사용을 권장하지만 그렇다고 템플릿 엔전을 사용한 것도 아니다. 

설정은 Thymeleaf로 했지만 실제로는 쌩 HTML만 사용을 했다.


사실 많은 수의 화면을 가지고 있어 그야말로 생산성 측면에서 Template라는 것이 필요한 상황이라면 모를까

위에 JSP 관련해서 언급한 것 처럼 뭔가 익숙하지 않는 코드들이 뒤섞이는 것에 거부감이 든다.

게다가 요즘 Javascript/CSS Framework들이 워낙 잘나와서 굳이 따로 Template 엔진들을 써야 하는지도 의문이다.


각설하고 공부하면서 사용한 2가지 조합에 대해 각각의 구성 요소에 대한 느낌을 비교해보고자 한다.


1. Spring vs Springboot


뭐 얘네들은 태생이 같은지라 비교의 의미가 있을까 모르겠지만 Springboot로 먼저 진행을 하다가 Spring으로 하니

뭐가 그리 복잡한지...신속한 개발이 필요하다면 단연 Springboot다. 다만 편하다는 것은 많은 부분들이 캡슐화 되어

감추어져 있다는 의미이고 이런 상황에서는 '도대체 이게 왜 이렇게 작동하지?'하는 갑갑증에 못견뎌하는 개발자들이

분명 있을 것이다. 그만큼 Spring 기본에 대한 학습이 절대적으로 필요하다고 보여진다. 


참고로 Spring의 경우도 Spring 3.2 이후 사용 가능해진 Java config를 이용하면 좀 더 심플하고 이해하기 쉽게 설정이

가능하다. Java config를 사용하기 위해 필요한 사양은 다음과 같다.

  • Java 5.0 or higher

  • Spring 2.5.6 or higher

  • AspectJ 1.6.2 or higher

  • CGLIB 2.1.3


2. JPS vs MyBatis(iBatis)


얘네들은 너무 성격이 달라 호불호가 명확하게 갈릴 것 같다.

우선 MyBatis는 우리 나라에서는 워낙 널리 사용되는 기술이다보니 대부분의 개발자에게 거부감이 없을 것 같다.

게다가 웬만한 개발자들이 가 쿼리 한가닥 씩은 하지 않나? 물론 이게 시스템이 복잡해지면 또 문제가 다르지만...

암튼 여러가지 측면에서 개발자들에게 '익숙'하다는 것이 장점이라면 장점이겠다.

다만 xml을 포함하는 설정이 지저분하고 mapper단으로의 parameter 전달이라든지 mapper에서의 result를 돌려받는

과정이 참으로 거시기 하다. 이미 제대로 된 OR Mapping이 아니라는 의견이 중론인만큼 말 그대로 'Mapping'이라기 보다는

그냥 쿼리 날려서 받은 컬럼들을 적당히 model 클래스의 속성에 할당한다는 느낌이다.


JPA같은 경우 아직 겉만 핥은 단계라 뭐라 할 말은 없는데 그냥 느낌이니까~

우선 DB의 테이블(Entity)와 1:1로 매핑되는 Entity 클래스가 존재한다. 쉽게 말해 테이블의 구성을 그대로 Java 클래스로

옮겨왔다고 보면 된다. 이 것이 진정한 OR Mapping이겠으나 사실 처음 접하는 입장에서는 '이제는 쿼리 뿐만이 아니라

DB Scheme까지 빠삭하게 알아야겠구나'하는 부담감이 생긴다. 특히나 거의 SQL 쿼리를 그대로 사용하던 MyBatis에

비한다면 데이터를 가져오는 과정도 상당히 생소하다. 물론 학습이 투자된다면 훨씬 나을 것 같긴 하다.

요는, JPA는 학습이 많이 필요한 기술이라는 것이다.


3. jQuery vs AngularJS


일단 이 두 기술을 구분하는 가장 중요한 요소로 꼽는 것이 

jQuery는 DOM 컨트롤 중심이고 AngularJS는 데이터 바인딩 중심이라는 것이다.

사실 jQuery의 경우 구현된 소스를 보다보면 js 파일과 html 파일을 모두 보아야 전체적인 그림이 그려진다.

html파일에는 template성의 태그 구성만 두던거 아니면 이조차도 없이 비워두고 js단에서 DOM 처리를 통해

내용을 채우는 경우가 많기 때문이다. 그래서 브라우저의 개발자 도구를 통하지 않고는 전체 화면 구성을

가늠하기가 어렵다. 하지만 js에서 단순히 append를 통해 문자열로 만들어진 태그를 집어넣는 식으로만

처리한다면 그리 복잡하지 않고 코드도 깔끔해진다. 그리고 서버와의 통신도 이미 익숙해진 기술이라 그런지



AngularJS의 경우 사실 처음 사용했을 때는 '오~이거 물건인데~' 했었는데 나중에 다시 jQuery로 작업을 하다보니

오히려 jQuery의 심플함에 더 정이 가버렸다.

데이터 처리를 쉽고 다양하게 할 수 있다는 점도 좋고 각종 Object들을 적절히 사용할 경우 보기 좋고 이해하기 쉬운

설계가 나올 수 있겠으나 여전히 제일 맘에 안드는 것은 HTML파일에 익숙하지 않은 코드들이 많이 들어가게 된다는 것과

의외로 navigation 처리가 복잡한 것, DOM에 대한 제어를 억제하다보니 은근히 코드가 길어지는 점 등이 좀 불만이다.

(물론 DOM을 제어하는 것은 AngularJS에 포함된 jQuery Object로도 가능하다)


일단 이렇게 초보자 수준에서의 감상을 적어보았다.

아직은 공부를 하는 단계라서 수박 겉핥기에서 벗어나지 못하고 있다.

이 말인 즉슨~ 계속 공부해야 한다는 것!

다음에는 좀 더 영양가 있는 분석을 할 수 있어야 할텐데...ㅠ.ㅠ

블로그 이미지

마즈다

이제 반백이 되었지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

댓글을 달아 주세요