A small but useful addition to the common-spring-aspects project: forked execution of a bean method.
Using the ForkAspect, it is possible to define bean methods to be executed in a separate thread. This is useful to avoid waiting on slow methods whose results we do not actually need to proceed (common examples - email sending, statistics event registration, etc).
Caused by: java.security.NoSuchAlgorithmException: SunTlsRsaPremasterSecret KeyGenerator not available at javax.crypto.KeyGenerator.<init>(DashoA13*..) at javax.crypto.KeyGenerator.getInstance(DashoA13*..) at com.sun.net.ssl.internal.ssl.JsseJce.getKeyGenerator(JsseJce.java:223) at com.sun.net.ssl.internal.ssl.RSAClientKeyExchange.<init>(RSAClientKeyExchange.java:89)The solution was to remove Installed JREs in Eclipse configuration and add them again (using the "Search..." button).
As you might know, Android Market only allows people in certain countries to buy paid apps. Also, developers can only publish those applications if located in supported countries. The list of those countries is published here.
As I'm a visual type of person, I like to see maps. Surprisingly, there is no map of of Android Market supported countries available anywhere yet. So I've created one myself:
Developers based in "green" countries can publish paid apps. Users based in "green" or "blue" countries can buy them.
As you see, all the "Western world" is covered. What is notably not covered is Eastern Europe and Asia. And that's unfortunate, as there is a lot of good developers (and potential buyers) in those regions.
Sometimes I'm surprised to see strange Tomcat crash - no error message in log, the process just stopped running.
As usual, the root cause is between the keyboard and the chair - I have some infinite loop in the code :)
Too bad that there is no log to give a hint. So the only way to tell is to do remote debugging and find out the code line where the problem occurs.
Of course this can happen also on Jetty, or whatever other servlet container.
It is amazing how many people still write some log.debug() to track execution time of their methods or create a caching proxy class for each class they want to cache.
Come on, this is done million times before, why not reuse ?
Today I've written some documentation on the Common Spring aspects project. This project collects some handy aspects that I find myself using on almost every project - currently, performance logging (using JaMon library) and caching bean method invocations results (using Ehcache). The code itself is fairly small, mostly it just delegates execution to the respective library.
Yesterday I updated my Mac Java version to Update 7 - it's always better to use new things, isn't it ? :) Alas, after the upgrade my Eclipse Subversion plugin stopped working - every attempt of interaction with SVN (browsing, commit etc) caused freezing.
After long and painful investigation I've narrowed the problem: it occurs when using SVNKit with some (not all) SVN servers that use HTTPS client certificate authentication. It turned out that Java Update 7 fixes a security vulnerability by disabling SSL renegotiation. As the server tries to renegotiate SSL session and client (using JSSE) refuses, the whole process enters infinite loop with SVNKit log showing "javax.net.ssl.SSLHandshakeException: renegotiation is not allowed".
The workaround is to re-enable SSL renegotiation in JSEE (yes, this means exposing yourself to the vulnerability again). To do this, set the JVM option allowUnsafeRenegotiation:
-Dsun.security.ssl.allowUnsafeRenegotiation=trueIn case of Eclipse, it can be set in eclipse.ini.
Posts
All Comments
