> -----Original Message----- > From: Juergen Donnerstag [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 03, 2006 1:22 AM > To: [email protected] > Subject: Re: [Wicket-user] Wicket outside of servlet container > > Please WicketTester, WicketTestCase and the vaarious Mock* objects. > Many of our core junit tests are based on out-of-container tests. >
I noticed all these both in the Javadocs and the source tree. However... The Mock* stuff all derives from WebApplication, which has dependencies on the servlet container, namely HttpServletRequest, HttpServletResponse, and HttpServletContext. And most of the Mock* classes are directed at mocking out the servlet dependencies. That's still a bit of a problem for me... Which means that even if I use these mock classes, I still have a runtime dependency on the servlet.jar, which I'd like to avoid. I realize it's really just a dependency on a few interfaces, but I still need the servlet.jar in my classpath. Would be nice to avoid this altogether, although I'll probably use the Mock* stuff as a kickstart... Peeking around under the covers, it appears that what I really want to do is extend Application instead of WebApplication, since Application knows nothing of the servlet container. However, I suspect there is some initialization and processing that WebApplication does that I'd need in my extension of Application that isn't servlet related. An out-of-container architecture that needs to mock out the servlet dependencies smells of an opportunity for another level of refactoring. I'm sure this area is still evolving in Wicket. I'm thinking something along the lines of: *************************************************** * ServletApp * PortletApp * MockApp * MyCustomApp * *************************************************** * WebApplication Layer * *************************************************** In my case with MINA, I've simply got a input and output streams of the HTTP socket. So MyCustomApp would need to parse the input stream for headers/params/etc and provide to WebApplication layer to setup Wicket request/response cycle. Much like the Mock* stuff appears to do, but without the express need to introduce the servlet.jar dependency. This might even allow you to produce a wicket-core.jar without any external build/runtime dependencies, and then provide add-on jar artifacts that add convenience classes for deploying wicket in various environments (i.e. wicket-servlet.jar, wicket-portlet.jar, wicket-apache.mod, etc) I don't know... Just thinking outside the J2EE box... And Wicket is the only web framework that I know that can even come close to doing this... --timothy ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
