[ 
http://www.stripesframework.org/jira/browse/STS-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11317#action_11317
 ] 

Reid M. Pinchback commented on STS-488:
---------------------------------------

Unless I'm missing something, I think this is a case of misleading content in 
the log content, not functionality that is breaking.  

This hunk of the stripes code seems to bounce between static references and 
thread-local references in a way that works for normal request processing but 
doesn't quite work for MockRoundtrip.   I think this is a case of needing to 
invert control on configuration access.

When initialization of the trip attempts to set the source page parameter, 
CryptoUtil.encrypt invokes StripesFilter.getConfiguration(), but 
getConfiguration() is initiaized during the very first doFilter() invocation, 
which hasn't had a chance to take place yet.  A possible solution is to change 
the signature of CryptoUtil.encrypt so that the caller can inject the 
configuration, like:

     Configuration config 
         = StripesFilter.getConfiguration();                   // for live code 
executed in request-processing lifecycle
         = StripesFilter.getInstanceConfiguration();   // for mock round trip, 
or anything executed in filter/servlet init
     String url = CryptoUtil.encrypt(url, config);

Also noted that the "if (url != null)" logic in setSourcePage is redundant, 
already handled inside of CryptoUtil.encrypt().

While it doesn't look like anything is breaking at the moment I think logging 
an exception stack for an exception that will never be thrown is a questionable 
way of telling people there is a problem.  Logging categories, levels, and 
layout patterns are more than sufficient for letting people see messages that 
tell them something they need to know.  If you have tests that are failing for 
a completely unrelated reason (which I just did), then you end up wasting time 
investigating the wrong stack trace.


> 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

Reply via email to