[
http://www.stripesframework.org/jira/browse/STS-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11187#action_11187
]
David G. Friedman commented on STS-488:
---------------------------------------
My stack traces show the cause to be the same one addressed in STS-484
(http://www.stripesframework.org/jira/browse/STS-484). This happens with any
new MockServletContext("anything") call and it is before I call addFilter() or
addServlet(). Relevant stack snippet:
at
net.sourceforge.stripes.controller.StripesFilter.getConfiguration(StripesFilter.java:124)
at
net.sourceforge.stripes.util.CryptoUtil.getKeyMaterialFromConfig(CryptoUtil.java:271)
at
net.sourceforge.stripes.util.CryptoUtil.getSecretKey(CryptoUtil.java:230)
at
net.sourceforge.stripes.util.CryptoUtil.getCipher(CryptoUtil.java:205)
at net.sourceforge.stripes.util.CryptoUtil.encrypt(CryptoUtil.java:121)
at
net.sourceforge.stripes.mock.MockRoundtrip.setSourcePage(MockRoundtrip.java:160)
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)
> 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
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
