지난번의 ContextLength 체크 문제에 이어 웹로직 적용후 또 하나의 이상 현상이 발견되었다. 톰캣에서 잘 인식되던 url 패턴이 웹로직에서 인식이 안되는 것이었다.
다른분이 포스팅한 글을 쉽게 찾을 수 있었으나 동일한 케이스라고 인식하지 못하고 몇 시간 헤매었다.
1. 결론
대충 결론은 웹로직에서는 톰캣과 다르게 이미 *.do 패턴이 포워드 페이지인 *.jsp 로 풀린(resolved) 된 상태로 sitemesh가 request에 대해서 처리하기 때문이라는 거 같다.
따라서, 톰캣에서 개발후 웹로직에 deploy할 경우 톰캣을 위한 *.do 패턴에 대한 것과 웹로직을 위한 *.jsp 패턴에 대한 것 두개다 써줄 필요가 있는 거긴 한데,
뭔가 착오가 생길 우려는 있어 보인다.
출처: http://wiki.opensymphony.com/display/SM/SiteMesh+on+Tomcat+vs+Weblogic
SiteMesh on Tomcat vs Weblogic
Findings:
(1) TOPIC(S) -> SITE MESH, TOMCAT, WEBLOGIC, DECORATORS.XML
Here are some findings of mine regarding SiteMesh on Tomcat 5 vs. Weblogic 8.1sp2 when used in conjunction with Struts.
Both work fine, but here are some nuances with the way the app servers handle the filters that you might find useful:
This mainly concerns the decorators.xml file.
My sitemesh servlet is mapped in web.xml as *.do.
On tomcat I can use either .do or / in my decorators.xml file.
On weblogic I must use /* in the decorators.xml file!!!! Using *.do does not work because weblogic has already resolved the foo.do to bar.jsp by this point.
Additionally, this means that if the you have /one/* and /two/* in tomcat, this will work fine. However, on weblogic, if /two/foo.do resolves to a jsp in say the /one directory,
then the request comes through as /one/bar.jsp and the second pattern is not a match, like it is on tomcat. I have no preference of one app server over the other, but it is annoying that they are handled differently because now my decorators.xml file has to be altered when porting applications.
Note, that I could map to two site mesh servlets in my web.xml file to avoid this problem, but that somewhat defeats the purpose of the decorators.xml file.
invalid-file
