Did you ever figure out a solution for this? I'm seeing it with Stripes 1.5
and Maven 2.0.9. If I set the surefire plugin to use
<forkMode>pertest</forkMode>, I get no errors. However, if I use the default
(once), I get the following error (but the test still passes).
WARN - Log.warn(161) | No MultipartWrapper implementation could be loaded
ERROR - Log.error(78) |
net.sourceforge.stripes.exception.StripesRuntimeException: Something is
trying to access the current Stripes configuration but the current request
was never routed through the StripesFilter! As a result the appropriate
Configuration object cannot be located. Please take a look at the exact URL
in your browser's address bar and ensure that any requests to that URL will
be filtered through the StripesFilter according to the filter mappings in
your web.xml.
at
net.sourceforge.stripes.controller.StripesFilter.getConfiguration(StripesFilter.java:160)
at
net.sourceforge.stripes.util.CryptoUtil.encrypt(CryptoUtil.java:123)
at
net.sourceforge.stripes.mock.MockRoundtrip.setSourcePage(MockRoundtrip.java:184)
at
net.sourceforge.stripes.mock.MockRoundtrip.<init>(MockRoundtrip.java:119)
at
net.sourceforge.stripes.mock.MockRoundtrip.<init>(MockRoundtrip.java:88)
at
net.sourceforge.stripes.mock.MockRoundtrip.<init>(MockRoundtrip.java:74)
at
org.appfuse.web.UserFormBeanTest.testView(UserFormBeanTest.java:42)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at
org.springframework.test.ConditionalTestCase.runBare(ConditionalTestCase.java:76)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997)
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.36 sec
Strangely enough, if I run the same test using Ant (and maven-ant-tasks for
dependencies), it works fine.
Here's my TextFixture class:
public class StripesTestFixture {
private static MockServletContext context;
public void init() {
StripesTestFixture.context = new MockServletContext("");
context.addInitParameter(ContextLoader.CONFIG_LOCATION_PARAM,
"classpath:/applicationContext-resources.xml,
classpath:/applicationContext-dao.xml," +
"classpath:/applicationContext-service.xml");
ServletContextListener contextListener = new
ContextLoaderListener();
ServletContextEvent event = new ServletContextEvent(context);
contextListener.contextInitialized(event);
// Add the Stripes Filter
Map<String, String> filterParams = new HashMap<String, String>();
filterParams.put("ActionResolver.Class",
"org.appfuse.web.ActionResolver");
filterParams.put("ActionResolver.Packages", "org.appfuse.web");
filterParams.put("Interceptor.Classes",
"net.sourceforge.stripes.integration.spring.SpringInterceptor");
filterParams.put("LocalizationBundleFactory.ErrorMessageBundle",
"messages");
filterParams.put("LocalizationBundleFactory.FieldNameBundle",
"messages");
context.addFilter(StripesFilter.class, "StripesFilter",
filterParams);
// Add the Stripes Dispatcher
context.setServlet(DispatcherServlet.class, "StripesDispatcher",
null);
}
public MockServletContext getServletContext() {
init();
return StripesTestFixture.context;
}
}
Thanks,
Matt
AlexTR wrote:
>
> Hi, Gentlemen
>
> Recently I’ve hit the wall with the "Something is trying to access the
> current Stripes configuration but the current request was never routed
> through the StripesFilter!” during testing action beans (full-cycle, with
> real business services/etc) using the Stripes mock framework.
>
> Tests were run by Maven’s Surefire in a single thread under the
> integration server (no forking for each test due performance).
>
> I've checked the forum and found some similiar problems (some related
> problems were fixed earlier) but no clear resolution – and the trunk
> version of the StripesFilter still the same.
>
> The situation is very simple – the MockServletContext is created each time
> before each new test class/test suite execution (this was a simple
> practice from previous times, to ensure that all things are clear before
> the run, spec. in-memory DB under the Hibernate and stuff). But due to the
> mechanism the Stripes uses to determine the right configuration for the
> current request processing pipeline (static configuration single-access
> point via StripesServlet and the support of multiple filters in a single
> application container) during each instantiation of the StripesFilter
> (inside the MockServletContext) the weak reference map receives a new
> configuration each time the filter is being instantiated.
>
> As you can understand the GC not always capable to purge the unused
> configuration from memory between tests – and that’s why we have two or
> more configurations in the StripesFilter’s configuration weak reference
> map at the time the new MockServletContext is being created.
>
> And now the problem:
> MockRoundTrip:
> public void setSourcePage(String url) {
> if (url != null) {
> url = CryptoUtil.encrypt(url);
> }
>
> And the CryptoUtil:
> public static String encrypt(String input) {
> if (input == null)
> input = "";
>
> // encryption is disabled in debug mode
> Configuration configuration = StripesFilter.getConfiguration();
>
> This code is called on the creation of the MockRoundTrip.
> No request is put through the filter yet – so no ThreadLocal-contained
> configuration is there yet, the StripesFilter.configurations have two or
> more configurations and the check of the
> "if (StripesFilter.configurations.size() == 1) { "
> is failed.
>
> As I don’t want to touch the StripesFilter itself, and cannot replace it
> with inherited StripesFilter (as a lot of Stripes code has direct
> references like StripesFilter.getConfiguration() in the code) I were
> forced to do a little dirty trick by creating the ancestor of the
> MockServletContext (with full-code replacement from the original
> MockServletContext) and added methods for receiving the current instance
> of the StripesFilter to set it in the next version of the
> MockServletContext during the next instantiation. So multiple different
> MockServletContext instances created prior each test share the same single
> instance of the StripesFilter (thus leaving only one configuration in the
> weak reference map). It solves my problems completely – but I simply don’t
> like how it looks (it's not a solution, it's a patch for sure).
>
> I’ve read Stripes Book and Stripes Unit Testing page and still don’t get
> the right solution for the provided scenario (as running of multiple tests
> in a single thread is a standard situation, and ability to re-create mock
> objects without limitations looks like perfectly acceptable scenario).
>
> Any thoughts (or at least please point me to the discussion of the problem
> if it's alread presents)?
> Thanks in advance!
>
>
--
View this message in context:
http://www.nabble.com/StripesFilter.getConfiguration%28%29-and-JUnit%284%29-under-Maven-%28or-JUnit-test-suits%29-tp20619084p21045598.html
Sent from the stripes-users mailing list archive at Nabble.com.
------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Stripes-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users
