[
http://www.stripesframework.org/jira/browse/STS-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11319#action_11319
]
Tim Fennell commented on STS-488:
---------------------------------
I think I actually fixed this on the trunk the other week without realizing
there was a JIRA for it. I added a little code so that
a) Whenever a StripesFilter inits it adds its configuration to a static
List<Configuration>
b) In StripesFilter.getConfiguration if there isn't one in thread local and
the aforementioned list has size==1, return that config
So now, assuming you don't have multiple Stripes configurations setup in the
same WebApp/CL/TestFixture, it'll always be able to find the configuration.
> 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
