[
http://www.stripesframework.org/jira/browse/STS-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11318#action_11318
]
Reid M. Pinchback commented on STS-488:
---------------------------------------
Slight qualitification on the last comment. getInstanceConfiguration() isn't
static. Mock round trip would need to ask MockServletContext for the
initialized StripesFilter instance, and that reference is what
getInstanceConfiguration() would get invoked on.
> StripesRunTimeException in StripesFilter during test suite
> ----------------------------------------------------------
>
> Key: STS-488
> URL: http://www.stripesframework.org/jira/browse/STS-488
> Project: Stripes
> Issue Type: Bug
> Components: ActionBean Dispatching
> Affects Versions: Release 1.5
> Environment: JDK 1.6.0_03-b05, on Ubuntu Linux 7.10 with Trunk
> version 794
> Reporter: David G. Friedman
> Assignee: Tim Fennell
> Priority: Minor
>
> In my own Test suites and the nightly build this Exception keeps appearing:
> 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.
> If we alter the StripesFilter.init() method and add 2 lines so we go from:
> this.configuration.setBootstrapPropertyResolver(bootstrap);
> this.configuration.init();
> Package pkg = getClass().getPackage();
>
> To:
> this.configuration.setBootstrapPropertyResolver(bootstrap);
> this.configuration.init();
> configurationStash.set(this.configuration); // my change part I
> initialInvocation.set(false); // my
> change part II
> Package pkg = getClass().getPackage();
> Then the Exception disappears on the TestNG suite. Since the doFilter()
> references the ThreadLocal shouldn't the init() be storing the first thread's
> configuration there too? I don't know why but in TestNG that configuration
> object is being lost by the StripesFilter. This makes no sense to me unless
> the Mock suite works strangely with filters. I tried adding printlns but it
> showed the thread was always the same Id. Regardless, my 2 line fix stores
> the configuration in ThreadLocal so it is persisted throughout the test suite
> and the 4 instances of this exception disappear (and my own testSuite runs
> cleaner).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://www.stripesframework.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development