안 평범한 개발자의 하루

Scenario

내 프로젝트에서 commons.jar 내부에 있는 commonController의 로직을 바꾸고 싶었다. 내 프로젝트 내부에서 새로 정의한다면 오버라이드 되지 않을까? 하고 생각해보았다.

Solution

class load scenario
예를 들어보자. 만약 내 프로젝트의 이름은 test이고 test 프로젝트 내부에서 a.jar에 대한의존성을 추가하였다.

a.jar 내부에있는 com.a.a 라는 class가 있었다.  
test 프로젝트 내부에서 com.a.a 라는 경로와 똑같이 class를  만든다면 어느 class가 load가 될까?

-> 정답은 배포되었을시에 web-inf에 있는 classes 폴더에있는 것들이 최우선순위로 load 되고 그다음부터는 lib 내부에 있는 jar들이 알파벳 순서에따라 class가 loadㄷ가 된다.

참고사항: tomcat 실행시 java -verbose:class 옵션을주면  어느 jar에서 load 되었는지 알게해줌
+추가 공부내용: 배포될때 WEB-INF/classes 폴더는 classpath와 관계가 있으니 잘 확인해볼 것

Scenario

Maven Pom.xml 파일을 업데이트 한뒤, compile error는 모두 잡았으나 tomcat을 실행할때 계속해서 

java.util.zip.ZipException: invalid LOC header (bad signature)

.....

No naming context bound to this class loader 

위와 같은 에러가 계속해서 떳다. 

에러를 해결하기 위한 삽질에 대해 적어보겠다.

Solution

사실

java.util.zip.ZipException: invalid LOC header (bad signature)

에러가 떳을때 구글링을 해보면 가장 많이 나오는 해결 방법은 그냥 maven repository를 삭제했다가 update를 하라고 가장 많이나온다. 하지만 나의경우에는 다 삭제 후 메이븐을 다시업데이트 해도 에러가 계속해서 났다. 그리고 메이븐 업데이트 할때 시간이 엄청나게 오래걸려서 스트레스가 쌓여만 갔다.

가장좋은 방법은 

1. java.util.zip.ZipException 내 ZipException 메소드에 break point를 걸어준다

2.에러가 날때 왼쪽 스택트레이스를 보면 JarFile.getManifestFromReference() 하는 부분이 있다. 그 부분을 더블 클릭해 본다.

3.manEntry 변수 내부에 jar를 확이하여 그 jar파일만 삭제 후 다시 받아본다.

위와 같이 하면 통짜로 repository를 삭제 할 필요가 없이 자르만 삭제 후 다시받으면된다

출처: https://stackoverflow.com/questions/32090921/deploying-maven-project-throws-java-util-zip-zipexception-invalid-loc-header-b

1. STS.ini 최적화 설정변경

＊ 현재 사용중인 STS.ini 설정내용

-Dosgi.requiredJavaVersion=1.8

-vm

C:/Program Files/Java/jdk1.8.0_172/bin/javaw.exe

--add-modules=ALL-SYSTEM

-Dosgi.module.lock.timeout=10

-Dorg.eclipse.swt.browser.IEVersion=10001

-XX:+UseParallelGC

-XX:permSize=128m

-Xms1024m

-Xmx4096m-Dosgi.requiredJavaVersion=1.8
-vm
C:/Program Files/Java/jdk1.8.0_211/bin/javaw.exe
-Xms1024m
-Xmx4096m
-XX:+UseParallelGC
-XX:+UseStringDeduplication
--add-modules=ALL-SYSTEM
-XX:permSize=128m
-Xverify:none
-XX:+UseParallelGC
-XX:+AggressiveOpts
-XX:-UseConcMarkSweepGC
-XX:PermSize=128M
-XX:MaxPermSize=128M
-XX:NewSize=128M
-XX:MaxNewSize=128M
-XX:NewSize=128M

• 선택사항

-Xverify:none

-XX:+UseParallelGC

-XX:+AggressiveOpts

-XX:-UseConcMarkSweepGC

-XX:PermSize=128M

-XX:MaxPermSize=128M

-XX:NewSize=128M

-XX:MaxNewSize=128M

-XX:NewSize=128M

• 설명

1) -vm 

    C:/Program Files/Java/jdk1.8.0_172/bin/javaw.exe 

    >이클립스에서 사용할 JDK

2) -Dosgi.requiredJavaVersion=1.8

    > 이클립스가 사용할 최소버전의 JDK

3) -Xverify:none 

    > 설정시 이클립스 초기 구동시 클래스 및 플러그인의 유효성 검사를 건너뛰겠다는 의미이며 구동속도 향상

4) -XX:+UseParallelGC

   > 병렬 가비지 컬렉션사용, 병렬처리로 인한 처리속도 향상

5) -XX:+AggressiveOpts

   > https://www.opsian.com/blog/aggressive-opts/

6) -XX:-UseConcMarkSweepGC

   > http://zzikjh.tistory.com/entry/Java-GC%ED%83%80%EC%9E%85-%EB%B0%8F-%EC%84%A4%EC%A0%95-%EC%A0%95%EB%B3%B4

7) -XX:PermSize=128M

   -XX:MaxPermSize=128M

   > JVM 클래스와 메소드를 위한공간이며 Out of Memory 발생시 크기 상향조절

8) -XX:NewSize=128M

   -XX:MaxNewSize=128M

   > 새로 생성된 객체들을 위한 공간

9) -Xms1024m

   > 이클립스가 사용하는 최소메모리

10) -Xmx4096m

  > 이클립스가 사용하는 최대메모리 - 사용할 컴퓨터에따라 할당크기를 변경해줘야됨.

2. 이클립스 Show Heap Status

 - Window > preferences > General - Show heap status 체크

3. 스펠링체크 설정 해제

 - Window > preferences > General > Text Editors > Spelling - Enable spell checking 체크해제

4. Automatic Updates

 - Window > preferences > Install/Update > Automatic Updates - Automatically find new updates and notify me 체크해제

5. 이클립스 인코딩 UTF-8 설정

- Window > preferences > General >Workspace - Text file encoding

6.Controll 눌렀을시 느려지는 현상 해결

- Window -> Preferences -> General -> Editors -> Text Editors -> Hyperlinking 나는 다 uncheck

Scenario

스프링 시큐리티 소스를 적용하려고 했는데, 소스 옆에 GA 및 SNAPSHOT이라는 태그가 붙여 있었다. 가장 높고 최신 버전의 소스가 좋은 것인지 아니면 무엇을 보고 판단해야 할지 모르겠어서 포스팅

Solution

- GA (General Availability) - 테스트가 완료된 정식 릴리즈 버전으로 안정적으로 운영되어야 하는 프로젝트에서 사용. 대부분 GA 버전을 가져다 사용하면 된다.

- RC (Release Candidate) - 베타 버전이다. 정식 릴리즈 버전은 아니므로 기능은 픽스되었으나, 안정적 동작은 보장할 수없다.

- M (Milestone) - 테스트 버전이다. 아직 기능이 픽스되지 않아 구현될때마다 테스트 버전이 릴리즈 될 수 있다.

- SNAPSHOT - 스냅샷이 붙으면 아직 개발단계라는 의미이며, 일종의 백업시점인 것이다.

Scenario

기존 AS-IS 프로젝트의 url pattern이 아래와 같이 .do 로 끝나는 url만 이 action이라는 이름의 dispatcher sertvlet으로 요청을 받게 설정이 되어 있었다.

    <servlet-mapping>
        <servlet-name>action</servlet-name>
        <url-pattern>*.do</url-pattern>
    </servlet-mapping>

나는 이를 /* 또는 / 으로 받으려고 했는데, main.html을 못불러오는게 아닌가?

    <servlet-mapping>
        <servlet-name>action</servlet-name>
        <url-pattern>/</url-pattern>
    </servlet-mapping>

이유를 알고자 다음과 같이 정리하였다.

Solution

위를 알려면 서블릿 컨테이너와 웹 어플리케이션의 연동 방법을 알아야한다.

실제로 WEB-INF 외부에 있는 jsp 파일을 요청하더라도, 직접 접근하는게 아니라 tomcat was라는 미들웨어를 통해  브라우저가 알아볼 수 없는 jsp 파일을 html로 변형해서 서버로 내려준뒤 브라우저로 내려준다.

(was는 동적 파일 처리(jsp 같은 파일) web server는 정적 파일 처리)

위와 같은 내용는 tomcat web.xml에 다음과 같은 설정을 통해 알 수 있다.

<servlet-mapping>
	<servlet-name>jspServlet</servlet-name>
	<url-pattern>*.jsp</url-pattern>
</servlet-mapping>

앞의 사전지식을 사용하여 url pattern 문제에 대해 접근해보자.

'/*' 은 요청받는 모든 URL을 처리한다는 의미이다. 모든 요청을 처리하게 되면 .jsp라는 view에 대한 요청도 action 이라는 이름의 Dispatcher Servlet이 처리하겠다는 것이다. 이렇게 되면 .jsp 파일은 tomcat web,xml 에서 정의된 jsp Servlet으로 처리되어지지 않고 .jps 요청에 대한 view를 내려줄 수 없다. (action dispatcher servlet설정에 의해 마스킹)

'/' 로 해준다면 default servlet 타게되는 요청들이 action servlet을 타게 되는데  *.jsp은 톰캣에 설정에 의해 dispatcher servlet에서 처리되지 않고 WAS내 jsp servlet으로 처리되므로 제대로 view를 리턴해줄 수 있으나. 여기서 문제는 톰캣 설정에서 default servlet 은 .html .css .js 같은 정적인 파일들을 처리 해주었으나 이제 처리해 줄 수 없으므로, 정적인 파일들에 대하여 404 not found error가 뜨게된다. (action servlet이 그것을 마스킹 하게 되어버린다.)

이제 여기서 필요한 설정이 context-dispatcherServlet.xml 내에 아래와 같은 설정이다.

<mvc:resources location="/resources/" mapping="/resources/**"/>
//또는
<mvc:default-servlet-handler />

위와  xml을 설정하게 된다면, 정적파일을 호출하게 되는 Request URL에 대하여 default servlet으로 위임 하는 것이다.

Scenario

MockMVC를 활용하여 벤더사 Param을 위해 만든 MessageConverter를 테스트 하려고 하였다. 

Meesage Converter를 Junit에서는 Test하였을때 잘 동작하였는데, 막상 Spring application 에서는 잘 동작하지 않았다. 그 이유는 원래 HttpServletRequest에서는 inputstream을 한번밖에 읽을 수 없지만, MockHttpServletRequest 에서는 getInputStream을 할때마다 Byte[]를 만들어서 준다. 

그래서 실제 스프링 환경과 똑같이 단위테스트를 하기위해 NotReuseHttpServletRequest을 만들게 되었다.

Solution

1. 먼저,  Junit의 RequestBuilder을 Delegate 하기위해 만든  NotReuseMockHttpServletRequestBuilder가 존재한다.

public class NotReuseMockHttpServletRequestBuilder implements RequestBuilder{

	private RequestBuilder requestBuilder;
	
	public NotReuseMockHttpServletRequestBuilder(RequestBuilder requestBuilder) {
		this.requestBuilder = requestBuilder;
	}
	
	@Override
	public MockHttpServletRequest buildRequest(ServletContext servletContext) {
		MockHttpServletRequest buildRequest = this.requestBuilder.buildRequest(servletContext);
		return new NotReuseHttpServletRequest(buildRequest);
	}
}

2.다음으로 실질적으로 MockHttpServletRequest 리턴하는 NotReuseHttpServletRequestNotReuseHttpServletRequest 클래스가 존재한다. 

Java 11.83 KB
/**
 * Movck MVC 테스트시에 실제 Spring MVC 환경과 똑같이   
 * InputStream을 두번 읽지 못하도록 테스트하기위한 클래스
 */
class NotReuseHttpServletRequest extends MockHttpServletRequest {
 
    private MockHttpServletRequest buildRequest;
    private ServletInputStream servletInputStream;
   
    public NotReuseHttpServletRequest(MockHttpServletRequest buildRequest) {
        this.buildRequest = buildRequest;
    }
   
    public ServletInputStream getInputStream() {
        if(this.servletInputStream == null) {
            this.servletInputStream = this.buildRequest.getInputStream();
        }
        return this.servletInputStream;
    }
 
    public int hashCode() {
        return buildRequest.hashCode();
    }
 
    public boolean equals(Object obj) {
        return buildRequest.equals(obj);
    }
 
    public ServletContext getServletContext() {
        return buildRequest.getServletContext();
    }
 
    public boolean isActive() {
        return buildRequest.isActive();
    }
 
    public void close() {
        buildRequest.close();
    }
 
    public void invalidate() {
        buildRequest.invalidate();
    }
 
    public String toString() {
        return buildRequest.toString();
    }
 
    public Object getAttribute(String name) {
        return buildRequest.getAttribute(name);
    }
 
    public Enumeration<String> getAttributeNames() {
        return buildRequest.getAttributeNames();
    }
 
    public String getCharacterEncoding() {
        return buildRequest.getCharacterEncoding();
    }
 
    public void setCharacterEncoding(String characterEncoding) {
        buildRequest.setCharacterEncoding(characterEncoding);
    }
 
    public void setContent(byte[] content) {
        buildRequest.setContent(content);
    }
 
    public int getContentLength() {
        return buildRequest.getContentLength();
    }
 
    public long getContentLengthLong() {
        return buildRequest.getContentLengthLong();
    }
 
    public void setContentType(String contentType) {
        buildRequest.setContentType(contentType);
    }
 
    public String getContentType() {
        return buildRequest.getContentType();
    }
 
 
 
    public void setParameter(String name, String value) {
        buildRequest.setParameter(name, value);
    }
 
    public void setParameter(String name, String[] values) {
        buildRequest.setParameter(name, values);
    }
 
    public void setParameters(Map params) {
        buildRequest.setParameters(params);
    }
 
    public void addParameter(String name, String value) {
        buildRequest.addParameter(name, value);
    }
 
    public void addParameter(String name, String[] values) {
        buildRequest.addParameter(name, values);
    }
 
    public void addParameters(Map params) {
        buildRequest.addParameters(params);
    }
 
    public void removeParameter(String name) {
        buildRequest.removeParameter(name);
    }
 
    public void removeAllParameters() {
        buildRequest.removeAllParameters();
    }
 
    public String getParameter(String name) {
        return buildRequest.getParameter(name);
    }
 
    public Enumeration<String> getParameterNames() {
        return buildRequest.getParameterNames();
    }
 
    public String[] getParameterValues(String name) {
        return buildRequest.getParameterValues(name);
    }
 
    public Map<String, String[]> getParameterMap() {
        return buildRequest.getParameterMap();
    }
 
    public void setProtocol(String protocol) {
        buildRequest.setProtocol(protocol);
    }
 
    public String getProtocol() {
        return buildRequest.getProtocol();
    }
 
    public void setScheme(String scheme) {
        buildRequest.setScheme(scheme);
    }
 
    public String getScheme() {
        return buildRequest.getScheme();
    }
 
    public void setServerName(String serverName) {
        buildRequest.setServerName(serverName);
    }
 
    public String getServerName() {
        return buildRequest.getServerName();
    }
 
    public void setServerPort(int serverPort) {
        buildRequest.setServerPort(serverPort);
    }
 
    public int getServerPort() {
        return buildRequest.getServerPort();
    }
 
    public BufferedReader getReader() throws UnsupportedEncodingException {
        return buildRequest.getReader();
    }
 
    public void setRemoteAddr(String remoteAddr) {
        buildRequest.setRemoteAddr(remoteAddr);
    }
 
    public String getRemoteAddr() {
        return buildRequest.getRemoteAddr();
    }
 
    public void setRemoteHost(String remoteHost) {
        buildRequest.setRemoteHost(remoteHost);
    }
 
    public String getRemoteHost() {
        return buildRequest.getRemoteHost();
    }
 
    public void setAttribute(String name, Object value) {
        buildRequest.setAttribute(name, value);
    }
 
    public void removeAttribute(String name) {
        buildRequest.removeAttribute(name);
    }
 
    public void clearAttributes() {
        buildRequest.clearAttributes();
    }
 
    public void addPreferredLocale(Locale locale) {
        buildRequest.addPreferredLocale(locale);
    }
 
    public void setPreferredLocales(List<Locale> locales) {
        buildRequest.setPreferredLocales(locales);
    }
 
    public Locale getLocale() {
        return buildRequest.getLocale();
    }
 
    public Enumeration<Locale> getLocales() {
        return buildRequest.getLocales();
    }
 
    public void setSecure(boolean secure) {
        buildRequest.setSecure(secure);
    }
 
    public boolean isSecure() {
        return buildRequest.isSecure();
    }
 
    public RequestDispatcher getRequestDispatcher(String path) {
        return buildRequest.getRequestDispatcher(path);
    }
 
    public String getRealPath(String path) {
        return buildRequest.getRealPath(path);
    }
 
    public void setRemotePort(int remotePort) {
        buildRequest.setRemotePort(remotePort);
    }
 
    public int getRemotePort() {
        return buildRequest.getRemotePort();
    }
 
    public void setLocalName(String localName) {
        buildRequest.setLocalName(localName);
    }
 
    public String getLocalName() {
        return buildRequest.getLocalName();
    }
 
    public void setLocalAddr(String localAddr) {
        buildRequest.setLocalAddr(localAddr);
    }
 
    public String getLocalAddr() {
        return buildRequest.getLocalAddr();
    }
 
    public void setLocalPort(int localPort) {
        buildRequest.setLocalPort(localPort);
    }
 
    public int getLocalPort() {
        return buildRequest.getLocalPort();
    }
 
    public AsyncContext startAsync() {
        return buildRequest.startAsync();
    }
 
    public AsyncContext startAsync(ServletRequest request, ServletResponse response) {
        return buildRequest.startAsync(request, response);
    }
 
    public void setAsyncStarted(boolean asyncStarted) {
        buildRequest.setAsyncStarted(asyncStarted);
    }
 
    public boolean isAsyncStarted() {
        return buildRequest.isAsyncStarted();
    }
 
    public void setAsyncSupported(boolean asyncSupported) {
        buildRequest.setAsyncSupported(asyncSupported);
    }
 
    public boolean isAsyncSupported() {
        return buildRequest.isAsyncSupported();
    }
 
    public void setAsyncContext(MockAsyncContext asyncContext) {
        buildRequest.setAsyncContext(asyncContext);
    }
 
    public AsyncContext getAsyncContext() {
        return buildRequest.getAsyncContext();
    }
 
    public void setDispatcherType(DispatcherType dispatcherType) {
        buildRequest.setDispatcherType(dispatcherType);
    }
 
    public DispatcherType getDispatcherType() {
        return buildRequest.getDispatcherType();
    }
 
    public void setAuthType(String authType) {
        buildRequest.setAuthType(authType);
    }
 
    public String getAuthType() {
        return buildRequest.getAuthType();
    }
 
    public void setCookies(Cookie... cookies) {
        buildRequest.setCookies(cookies);
    }
 
    public Cookie[] getCookies() {
        return buildRequest.getCookies();
    }
 
    public void addHeader(String name, Object value) {
        buildRequest.addHeader(name, value);
    }
 
    public long getDateHeader(String name) {
        return buildRequest.getDateHeader(name);
    }
 
    public String getHeader(String name) {
        return buildRequest.getHeader(name);
    }
 
    public Enumeration<String> getHeaders(String name) {
        return buildRequest.getHeaders(name);
    }
 
    public Enumeration<String> getHeaderNames() {
        return buildRequest.getHeaderNames();
    }
 
    public int getIntHeader(String name) {
        return buildRequest.getIntHeader(name);
    }
 
    public void setMethod(String method) {
        buildRequest.setMethod(method);
    }
 
    public String getMethod() {
        return buildRequest.getMethod();
    }
 
    public void setPathInfo(String pathInfo) {
        buildRequest.setPathInfo(pathInfo);
    }
 
    public String getPathInfo() {
        return buildRequest.getPathInfo();
    }
 
    public String getPathTranslated() {
        return buildRequest.getPathTranslated();
    }
 
    public void setContextPath(String contextPath) {
        buildRequest.setContextPath(contextPath);
    }
 
    public String getContextPath() {
        return buildRequest.getContextPath();
    }
 
    public void setQueryString(String queryString) {
        buildRequest.setQueryString(queryString);
    }
 
    public String getQueryString() {
        return buildRequest.getQueryString();
    }
 
    public void setRemoteUser(String remoteUser) {
        buildRequest.setRemoteUser(remoteUser);
    }
 
    public String getRemoteUser() {
        return buildRequest.getRemoteUser();
    }
 
    public void addUserRole(String role) {
        buildRequest.addUserRole(role);
    }
 
    public boolean isUserInRole(String role) {
        return buildRequest.isUserInRole(role);
    }
 
    public void setUserPrincipal(Principal userPrincipal) {
        buildRequest.setUserPrincipal(userPrincipal);
    }
 
    public Principal getUserPrincipal() {
        return buildRequest.getUserPrincipal();
    }
 
    public void setRequestedSessionId(String requestedSessionId) {
        buildRequest.setRequestedSessionId(requestedSessionId);
    }
 
    public String getRequestedSessionId() {
        return buildRequest.getRequestedSessionId();
    }
 
    public void setRequestURI(String requestURI) {
        buildRequest.setRequestURI(requestURI);
    }
 
    public String getRequestURI() {
        return buildRequest.getRequestURI();
    }
 
    public StringBuffer getRequestURL() {
        return buildRequest.getRequestURL();
    }
 
    public void setServletPath(String servletPath) {
        buildRequest.setServletPath(servletPath);
    }
 
    public String getServletPath() {
        return buildRequest.getServletPath();
    }
 
    public void setSession(HttpSession session) {
        buildRequest.setSession(session);
    }
 
    public <T extends HttpUpgradeHandler> T upgrade(Class<T> handlerClass) throws IOException, ServletException {
        return buildRequest.upgrade(handlerClass);
    }
 
    public HttpSession getSession(boolean create) {
        return buildRequest.getSession(create);
    }
 
    public HttpSession getSession() {
        return buildRequest.getSession();
    }
 
    public String changeSessionId() {
        return buildRequest.changeSessionId();
    }
 
    public void setRequestedSessionIdValid(boolean requestedSessionIdValid) {
        buildRequest.setRequestedSessionIdValid(requestedSessionIdValid);
    }
 
    public boolean isRequestedSessionIdValid() {
        return buildRequest.isRequestedSessionIdValid();
    }
 
    public void setRequestedSessionIdFromCookie(boolean requestedSessionIdFromCookie) {
        buildRequest.setRequestedSessionIdFromCookie(requestedSessionIdFromCookie);
    }
 
    public boolean isRequestedSessionIdFromCookie() {
        return buildRequest.isRequestedSessionIdFromCookie();
    }
 
    public void setRequestedSessionIdFromURL(boolean requestedSessionIdFromURL) {
        buildRequest.setRequestedSessionIdFromURL(requestedSessionIdFromURL);
    }
 
    public boolean isRequestedSessionIdFromURL() {
        return buildRequest.isRequestedSessionIdFromURL();
    }
 
    public boolean isRequestedSessionIdFromUrl() {
        return buildRequest.isRequestedSessionIdFromUrl();
    }
 
    public boolean authenticate(HttpServletResponse response) throws IOException, ServletException {
        return buildRequest.authenticate(response);
    }
 
    public void login(String username, String password) throws ServletException {
        buildRequest.login(username, password);
    }
 
    public void logout() throws ServletException {
        buildRequest.logout();
    }
 
    public void addPart(Part part) {
        buildRequest.addPart(part);
    }
 
    public Part getPart(String name) throws IOException, IllegalStateException, ServletException {
        return buildRequest.getPart(name);
    }
 
    public Collection<Part> getParts() throws IOException, IllegalStateException, ServletException {
        return buildRequest.getParts();
    }
}

3.실질적인 사용법은 다음과 같다.

@Test
public void example() throws Exception {

        logger.debug("############# Post Test #################");

        MockHttpServletRequestBuilder builder =
				  MockMvcRequestBuilders.post("/test")
							.contentType(MediaType.TEXT_XML)
							.content(content);
                                        
		//Spring MVC에서는 스트림을 한번 읽으면 Flush되나 MockMVC에서는 Stream을 Reuse를 할 수 있으므로 
		//실제 Spring MVC와 똑같이 Reuse 할 수 없게 하기위해서 delegator를 만들었다. 
		NotReuseMockHttpServletRequestBuilder delegator = new NotReuseMockHttpServletRequestBuilder(builder);

		MvcResult result = mockMvc.perform(delegator).andExpect(MockMvcResultMatchers.status().isOk())
													.andDo(MockMvcResultHandlers.print())
													.andReturn();
}

출처

https://www.slipp.net/questions/166

http://toby.epril.com/?p=934

Scenario

Spring AOP를 설정하다. AOP 관련 설정을 Context 파일로 따로 빼서 설정하려고 했다.

Eclipse 상의 AOP Marker도 다 뜨고, 설정이 된 줄 알았는데 막상 서버를 돌릴때 Service를 호출하면 AOP LOG가 뜨지 않는 것이었다.

그렇게 삽질의 서막이 시작되었다.......

Solution

일단 Context가 무엇인지 부터 알아보자.

1.Context 란?

 지금 다루고 있는 웹환경에서의 컨텍스트란 (Spring 상의), 웹환경상에서의 웹호출처리를 위한 환경설정에 관한 각종 정보들을 갖고있는 것이다.

 환경설정파일과 다른것은, 웹 실행시에 실시간으로 생성되어 참조되는 문맥정보?? 인 것이다.

2.Root plication Context vs Servlet Context

[그림] web.xml에 context 설정

Root context xml 파일들은 Tomcat 실행시에 로드 되며, Dispatcher Servlet Context xml은 클라이언트 요청시 dispatcher Servlet 객체 생성시에 로드 된다.

Root Application Context
  - 전체 계층구조에서 최상단에 위치한 컨텍스트
  - 서로 다른 서블릿 컨텍스트에서 공유해야하는 Bean들을 등록해놓고 사용할 수 있다.
  - 웹 어플리케이션 전체에 적용가능한 DB 연결, 로깅기능등에 이용
  - Servlet Context에 등록된 Bean 이용 불가능 하다
  - Servlet Context와 동일한 Bean이 있을 경우 Servlet Context Bean이 우선된다.
  - 하나의 컨텍스트에 정의된 AOP 설정은 다른 컨텍스트의 빈에는 영향을 미치지 않는다.

Servlet Context
  - 서블릿에서만 이용되는 컨텍스트
  - 타 서블릿과 공유하기 위한 Bean들은 루트 웹 어플리케이션 컨텍스트에 등록해놓고 사용해야 한다
  - DispatcherServlet은 자신만의 컨텍스트를 생성,초기화하고
    동시에 루트 어플리케이션 컨텍스트를 찾아서 자신의 부모 컨텍스트로 사용

결론부터 말하자면 root context 에는 Controller를 제외한 Component 를 스캔해주어야 하고 dispathcer servlet에는 Controller Component만 스캔을 해주어야 한다.

[그림] 잘못된 Dispathcer Servlet에서 Component Scan 방법 (dispatcher-servlet.xml)

[그림] Aop 적용을 위한 Context 설정  (aop-context.xml)

위와같이 패키지 전체를 Component 스캔을 해주었었는데 이는 옳지 않은 방식이다.

패키지 전체를 Servlet Context에서 스캔을 하면 Root Context에서 AOP를 위해 Component 스캔을 한것은 스캔이 되지 않는 것이다. (root와 dispatcher 두 Context에서 빈을 명시하면 root Context는 무시된다)

[그림] 올바르게 Dispathcer Servlet에서 Component Scan 방법 (dispatcher-servlet.xml)

********************************************************************************

[참고]

검색하다보니 Root Application Context와 Servlet Context 설정시 도움이 될만한 정보가 있어서 퍼온다.

출처는 http://bumsgy-innori.tistory.com/tag/%EC%8A%A4%ED%94%84%EB%A7%812.5%EC%84%A4%EC%A0%95

이곳인데 이곳 쥔장도 퍼온글인것 같다.

********************************************************************************

SpringMVC를 이용한 개발에서 Controller류는 xxx-servlet.xml에 그 외의 Service, Dao류는 applicationContext*.xml에 등록해야 합니다. 직접 등록이 아닌 Scanner을 사용할 경우 중복하지 않도록 해야 합니다. 따라서 처음 만드신 것처럼 xxx-servlet.xml에서 모든 Stereotype 빈을 모두 다 검색하는 component-scan 설정은 잘못됐습니다.

이 원칙만 잘 준수하시면 아무 문제없을 것입니다.

이번엔 좀 복잡하게 설명해보죠.

세가지 사용하신 stereotype이 있습니다. @Repository, @Service, @Controller죠.

제가 이전에 작성한 viewtopic.php?f=5&t=20#p33 을 읽어보시면 잘 설명이 되어있는 내용이 있습니다. 일반 applicationContext*.xml에 설정한 내용과 xxx-servlet.xml에 설정한 내용은 두개의 다른 ApplicationContext(이하 AC)로 만들어지고 xxx-servlet.xml의 AC는 applicationContext*.xml에 의해서 만들어진 AC의 child context로 등록이 됩니다.

상위 AC를 ac, 웹에서 정의된 AC를 web-ac라고 불러보죠.
 
원래 하신 설정에 따르면 ac에서는 controller,form류(@Controller)를 제외한 나머지만 scan하도록 되어있습니다. 따라서 @Repostiory, @Service가 붙은 bean들이 등록이 되겠죠.

web-ac는 exclude조건없이 full-scan을 했습니다. 따라서 @Repository, @Service, @Controller가 붙은 빈들이 다 등록이 됐죠.

그리고 ac와 web-ac가 상-하위 ac관계를 가집니다. 이때 같은 bean이 두번 등록되도 문제는 없습니다. 하위 context에서는 상위 context에 등록된 bean을 override합니다. 하위 context에서 먼저 bean을 찾고, 없으면 그때 상위를 찾기 때문에 override한 것과 마찬가지입니다.

따라서
ac - @Service, @Repository
web-ac - @Service, @Repository, @Controller

이렇게 각각 빈들을 가지고 있는 상태입니다.

스프링이 transaction을 적용하는 방법은 AOP를 이용해서 해당 빈의 proxy를 만들어서 tx가 적용되는 bean을 바꿔치기 하는 방법을 이용합니다. 그러면 원래 @Service(@Transactional)이 붙은 빈은 뒤로 숨고 tx가 적용된 proxy bean이 @Service가 붙은 bean으로 대치됩니다. tx설정은 ac에만 되어있기 때문에 이 것이 적용되면

ac - tx적용(@Service), @Repository
web-ac - @Service, @Repository, @Controller

이런 형태가 됩니다.

web-ac쪽은 tx가 적용되지 않은 @Service가 그대로 남아있습니다.

그리고 @Controller가 동작하고 여기에 @Autowired를 걸면, 우선 같은 context에서 검색을 합니다. 여기서도 @Service가 지정된 같은 bean이 등록되어있기 때문에 web-ac에 등록된 @Service bean을 사용합니다. 하지만 이 bean은 tx를 위한 proxy bean이 아니기 때문에 tx가 동작하지 않습니다. 따라서 처음과 같은 문제가 발생합니다.

다음은 @Service를 떼고 <bean>으로 등록하니 tx가 적용된 상황을 살펴보죠.
이때는 @Service에 의해서 scan되지는 않고 bean에 의해서 명시적으로 service bean이 등록됩니다. 물론 <bean>을 등록한 ac에서만 되겠죠. web-ac에서는 full-scan을 하지만, @Service가 없기 때문에 등록되지 않습니다.

ac - Service, @Repository
web-ac - @Repository, @Controller

이런 상황이 되는거죠.

여기에 tx설정이 적용되면 @Transactional이 붙은 것을 ac 내에서 찾아서 적용하므로

ac - tx적용(Service), @Repository
web-ac - @Repository, @Controller

이런 구조가 됩니다.

이제 Controller가 @Autowired에 의해서 service를 찾으면 이때는 ac에 등록된 tx적용(Service) 빈이 호출됩니다. 그러니 당연히 tx가 먹겠죠.

따라서 앞에서 하신 모든 가정들(@Service, @Transactional은 같이 쓰면 안된다, 인터페이스에 적용을 안해서 그렇다거나.. 기타등등)은 다 틀렸습니다.

마지막으로 제가 알려드린대로 하시면

ac - tx적용(@Service), @Repository
web-ac -@Controller

이렇게 깔끔하게 설정되겠죠.

Web을 사용하는 스프링 애플리케이션의 설정의 기본원칙만 지키시면 아무 문제가 없는 것입니다. 보통 component-scan을 사용하면 exclude, include등을 잘 적용하지 못해서 이런 문제가 발생할 수 있습니다. 편리한만큼 신경쓸 것도 있는거죠.

그리고 exclude 하실때 이름을 가지고 regex를 적용하셨는데 그보다는 annotation filter을 이용하시는 것이 더 깔끔할 것 같습니다. 아예 web쪽과 나머지를 root경로부터 분리하면 간단하긴 하지만, 보통 모듈별로 몰아두기 때문에 annotation 방식이 편합니다.

제가 사용하는 방법은

ac쪽은

 web-ac쪽은

 입니다.

---------------------------------------------------------------------------------------------------------------------------------

참고글: http://www.mungchung.com/xe/spring/21220

Scenario

깃 헙이나, 외국 사이트를 돌아다니다 보면 보일러 플레이트 코드란 말을 많이 들을 수 있다. 이 '보일러 플레이트' 코드란 무엇일까?

Solution

보일러플레이트 코드; 보일러플레이트, 상용구 코드, 상용구

• 최소한의 변경으로 재사용할 수 있는 저작품
• 적은 수정만으로 여러 곳에 활용 가능한 코드, 문구
• 각종 문서에서 반복적으로 인용되는 문서의 한 부분 

제타위키 펌

Java진영에서 어느날 갑자기 등장하여 개발자들을 모호하게 만들어 버렸던
POJO!!

이 녀석이 당췌 뭐야?
많은 사람들은 그럴싸한 이론으로 POJO를 포장하려 한다.
실제 강의나 책을 통해서 설명되는 POJO는 이해하기 힘듬. ㅜㅜ

본인 또한 처음 POJO란 용어를 접했을때 이게 뭐지? 
직역하면 명백히 오래된 자바 객체?

아쒸 명백히 오래된 자바객체가 한두개야?
jdk 1.0 버전때 부터 제공되던 수 많은 클래스들을 통해 생성하는 객체들이 그럼 다 POJO야?

POJO는 2000년 9월에 열린 컨퍼런스(어떤 컨퍼런스인지는 모름)에서
Rebecca Parsons, Josh MacKenzie, Martin Fowler 가 처음 사용한 용어이다.

다른 개념 다 버리고

POJO = Java Beans
여기서 Java Beans는 Sun의 Java Beans나 EJB의 Bean을 뜻하는것이 아닌
순수하게 setter, getter 메소드로 이루어진 Value Object성의 Bean을 말한다.

예를 들면 아래와 같다.

우리가 열심히 코딩하거나 이클립스를 통해 자동으로 생성하던
그 깡통 빈 클래스!! 를 통해서 생성된 객체!
맞다 바로 이것이 POJO 다.

그럼 왜 이전 부터 사용하던 Beans라고 말하지 않고
사람들 헤깔리게 POJO 새로이 불렀을까?

이유인즉, Beans라는 용어로 위의 깡통 빈 클래스를 정의하기에는
Java Beans나 EJB의 Beans와 구분이 모호하고 또한 Beans라는 용어로
정의되는 여타 다른 개념들과의 확실한 분리를 위해
POJO라는 용어를 사용한것이라 볼 수 있다.

=========================================================================================

-- 쉽게 따라하는 자바 웹 개발 중 --

POJO라는 용어는 평범한 자바 객체라는 뜻인데 어떤 객체를 평범하다고 지칭하는지

그리고 POJO를 사용해서 개발하는게 왜 중요한지 설명 한다. 

먼저 평범하다고 말하는 객체는 다음과 같은 특징. 

• 클래스 상속을 강제하지 않는다. 
• 인터페이스 구현을 강제하지 않는다. 
• 애노테이션 사용을 강제하지 않는다.

POJO가 아닌 대표적인 객체

public HelloServlet extends HttpServlet{ ... } 

자바 서블릿 코드를 작성할 때는 이렇게 반드시 HttpServlet을 상속바아야 한다. 

서블릿 프로그래밍을 한다는 이유로 객체지향 프로그래밍의 핵심적인 기능 중 하나인 상속을 빼앗긴 것이나 마찬가지이다. 코드를 작성하고 있는 개발자가 직접 상속을 사용할 수 있는 기회가 없어졌으니.. 

그리고 extends HttpServlet이 추가되면서 이 코드를 이해하기 어려워 진다. 

HttpServlet에서 어떤 기능을 제공하는지 어떤 코드를 어떻게 재사용해야 할지 판단하기도 어렵다. 

POJO는 그러한 제약이 없는 일반적인 객체를 말한다. 

상속이나 인터페이스 구현을 사용하지 않은 객체를 말하는 것이 아니라, 그런 것을 라이브러리나 프레임워크로부터 강제받지 않는 객체라는 것이다. 

public HelloController { .... } 

이런 클래스라면 개발자의 선택에 따라 자신이 만든 다른 Controller클래스를 상속받게 하거나 인터페이스를 구현하게 할 수 있다. 또한 이해하기 쉬운 코드이기도 하다. 무엇보다도 이런 객체가 테스트를 작성하기 편하다. 테스트를 작성하기 쉬운 코드가 곧 좋은 코드이다. 

POJO는 자바 표준 스펙이 아니다.