IngoHofmann
|
Posted: May 19, 2009 15:45 by IngoHofmann
|
|
Hi, For some reason it seems to me that the MockServletContext class does not implement the getContextPath() method. However, our applications need to invoke this method.  It would be great if you used an "own" servlet context class when building the context at ServletContextFactory->createContextForWebAppAt() that implements this method. e.g. public class FacesTesterServletContext extends MockServletContext { public FacesTesterServletContext (WebAppResourceLoader webAppResourceLoader) { super(webAppResourceLoader); } public String getContextPath() { return "/"; } } I would appreciate it! Best, Ingo |
MockServletContext does not implement getContextPath() !?
11 posts
Replies: 10 - Last Post: June 04, 2009 14:46
by: IngoHofmann
by: IngoHofmann
showing 1 - 11 of 11
Jason Lee
|
Posted: May 20, 2009 04:23 by Jason Lee
|
|
Another good point. I'm not super happy about depending on the Spring mock objects, but we got going a lot quicker that way. I've tinkered with implementing the ServletContext as part of FacesTester and reducing the dependencies a bit, but haven't had time to make much headway in that area. For the 0.2 release, I'll try this approach to get you going, then revisit the greater issue for 0.3. Thanks again. Lots of good feedback. 
|
|
IngoHofmann
|
Posted: May 20, 2009 07:26 by IngoHofmann
|
|
Yes, removing the Spring dependency would be great. Good luck with tinkering!
|
|
IngoHofmann
|
Posted: May 26, 2009 11:38 by IngoHofmann
|
|
Thanks a lot so far, Jason. Now I also have a problem with the getMimeType(String) method of the MockServletContext. It always produce an UnsupportedOperationException. Try to request a non-facelets page, e.g. facestester.requestPage("/foo/jsfunctions.js"); Then he tries to invoke the getMimeType() method what leads to the given exception. Adding this simple implementation to the new FacesTesterServletContext could resolve my problem: @Override public String getMimeType(String filePath){ return "foo"; } I couldn't notice some side effects due to this, in fact wrong, implementation. Don't know if these alternatives are making more sense: http://www.rgagnon.com/javadetails/java-0487.html Nevertheless, a solution for that would be great. Greets, Ingo |
|
Jason Lee
|
Posted: May 28, 2009 13:59 by Jason Lee
|
| I'll override that method as well. I've been doing some experimenting with custom API impls (and removing the Spring mock objects), but I'm running into some odd issues where I'm not getting my JSF environment bootstrapped correctly, for some reason I haven't been able to track down. The changes from 0.2 to 0.3-SNAPSHOT/tip aren't all that invasive, but something broke. I think I'll back out my Servlet API changes, then reapply the config parsing fixes, etc. and see if that helps. When I get that back to usable, I'll update this method for you and push out a snapshot. |
|
IngoHofmann
|
Posted: May 28, 2009 14:37 by IngoHofmann
|
|
No sweat! Except for the missing filter binding everything works very fine now. If you can't remove the Spring dependency, it wouldn't be the end of the world. |
|
IngoHofmann
|
Posted: May 29, 2009 12:40 by IngoHofmann
|
|
Great, works, thanks!
|
|
IngoHofmann
|
Posted: June 04, 2009 14:46 by IngoHofmann
|
|
Great, works, thanks!
|
showing 1 - 11 of 11
Replies: 10 - Last Post: June 04, 2009 14:46
by: IngoHofmann
by: IngoHofmann
