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.
— Previous article
How to create a native Java App
Next article —
Summer internship all new low ceremony code review application
You May Also Like
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?
SoapUI ext libs and its weirdness
- byMarcin Cylke
- November 2, 2011
Suppose you want to add some additional jars to your SoapUI installation. It all should work ok if…
Phonegap / Cordova and cross domain ssl request problem on android.
- byPaweł Byszewski
- July 29, 2013
In one app I have participated, there was a use case:
You have to remember that secure connection to service with self-signed certificate is risky and unrecommended. But if you know what you are doing there is some workaround of the security problem. Behavior of method
Thus add new class extended CordovaWebViewClient and override ‘onReceivedSslError’. I strongly suggest to implement custom onReceiveSslError as secure as possible. I know that the problem occours when app try connect to example.domain.com and in spite of self signed certificate the domain is trusted, so only for that case the SslError is ignored.
Now the app created in release mode can connect via https to services with self-signed SSl certificates.
- User fill up a form.
- User submit the form.
- System send data via https to server and show a response.
- ant release
- align
- signing
res/xml/cordova.xml
If whitelist looks fine, the error is most likely caused by inner implementation of Android System. The Android WebView does not allow by default self-signed SSL certs. When app is debug-signed the SSL error is ignored, but if app is release-signed connection to untrusted services is blocked. Workaround
CordovaWebViewClient.onReceivedSslErrormust be changed.Thus add new class extended CordovaWebViewClient and override ‘onReceivedSslError’. I strongly suggest to implement custom onReceiveSslError as secure as possible. I know that the problem occours when app try connect to example.domain.com and in spite of self signed certificate the domain is trusted, so only for that case the SslError is ignored.
public class MyWebViewClient extends CordovaWebViewClient {
private static final String TAG = MyWebViewClient.class.getName();
private static final String AVAILABLE_SLL_CN
= "example.domain.com";
public MyWebViewClient(DroidGap ctx) {
super(ctx);
}
@Override
public void onReceivedSslError(WebView view,
SslErrorHandler handler,
android.net.http.SslError error) {
String errorSourceCName = error.getCertificate().
getIssuedTo().getCName();
if( AVAILABLE_SLL_CN.equals(errorSourceCName) ) {
Log.i(TAG, "Detect ssl connection error: " +
error.toString() +
„ so the error is ignored”);
handler.proceed();
return;
}
super.onReceivedSslError(view, handler, error);
}
}Next step is forcing yours app to use custom implementation of WebViewClient. public class Start extends DroidGap
{
private static final String TAG = Start.class.getName();
@Override
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
super.setIntegerProperty("splashscreen", R.drawable.splash);
super.init();
MyWebViewClient myWebViewClient = new MyWebViewClient(this);
myWebViewClient.setWebView(this.appView);
this.appView.setWebViewClient(myWebViewClient);
// yours code
}
}That is all ypu have to do if minSdk of yours app is greater or equals 8. In older version of Android there is no class android.net.http.SslErrorSo in class MyCordovaWebViewClient class there are errors because compliator doesn’t see SslError class. Fortunately Android is(was) open source, so it is easy to find source of the class. There is no inpediments to ‘upgrade’ app and just add the file to project. I suggest to keep original packages. Thus after all operations the source tree looks like:![]() |
| Class SslError placed in source tree. |
