Chcecie poznać Ruby on Rails? 29-30.09 w Warszawie odbędą się warsztaty, na których będziecie mieli taką okazję http://railsgirls.com/warsaw. Zgłoszenia przyjmowane są do 21.09. TouK jest jednym ze sponsorów.
Rails Girls Warsaw
— Previous article
How to create a native Java App
Next article —
Summer internship all new low ceremony code review application
You May Also Like
Turing completeness II
- bypawelz
- December 19, 2010
Well, as I wrote in the previous post, sed is a Turing complete language. We can use it to implement some simple algorithms, or even a dc interpreter. But what does it really mean? How complex tasks may we achieve using plain sed?What about writin...Well, as I wrote in the previous post, sed is a Turing complete language. We can use it to implement some simple algorithms, or even a dc interpreter. But what does it really mean? How complex tasks may we achieve using plain sed?What about writin...
Kotlin, Callable and ExecutorService
- byDominik Przybysz
- October 11, 2015
I've recently written about using Callable in Groovy, but how does it look like in kotlin?Callable instance as separete class First, let's create class which implements Callable interface:class MyJob : Callable<Int> { override fun call() = 42}...
Grails with Spock unit test + IntelliJ IDEA = No thread-bound request found
- byRafał Nowak
- September 17, 2013
During my work with Grails project using Spock test in IntelliJ IDEA I've encountered this error:
java.lang.IllegalStateException: No thread-bound request found: Are you referring to request attributes outside of an actual web request, or processing a request outside of the originally receiving thread? If you are actually operating within a web request and still receive this message, your code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request.
at org.springframework.web.context.request.RequestContextHolder.currentRequestAttributes(RequestContextHolder.java:131)
at org.codehaus.groovy.grails.plugins.web.api.CommonWebApi.currentRequestAttributes(CommonWebApi.java:205)
at org.codehaus.groovy.grails.plugins.web.api.CommonWebApi.getParams(CommonWebApi.java:65)
... // and few more lines of stacktrace ;)
It occurred when I tried to debug one of test from IDEA level. What is interesting, this error does not happen when I'm running all test using grails test-app for instance.
So what was the issue? With little of reading and tip from Tomek Kalkosiński (http://refaktor.blogspot.com/) it turned out that our test was missing @TestFor annotation and adding it solved all problems.
This annotation, according to Grails docs (link), indicates Spock what class is being tested and implicitly creates field with given type in test class. It is somehow strange as problematic test had explicitly and "manually" created field with proper controller type. Maybe there is a problem with mocking servlet requests?
This annotation, according to Grails docs (link), indicates Spock what class is being tested and implicitly creates field with given type in test class. It is somehow strange as problematic test had explicitly and "manually" created field with proper controller type. Maybe there is a problem with mocking servlet requests?