I just updated my (virtual) server, on which this weblog is running too. The update log was rather interesting this time:
Setting up tzdata-java (2011j-0ubuntu0.11.04) ... Setting up ca-certificates (20090814+nmu2ubuntu0.1) ... Updating certificates in /etc/ssl/certs... WARNING: Skipping duplicate certificate brasil.gov.br.pem 0 added, 1 removed; done. Running hooks in /etc/ca-certificates/update.d.... updating keystore /etc/ssl/certs/java/cacerts... does not exist: /etc/ssl/certs/DigiNotar_Root_CA.pem done.
For those living outside the Netherlands: DigiNotar was a issuer of ssl and pki certificates, similor to Verisign. Their main customer was the Dutch government. Turned out DigiNotar was hacked by Iranian hackers, but not only that, the hack happened a few months ago but they decided not to inform their clients. In the mean time, Dutch governmental communication wasn't as secure as you might hope.
Of course the Dutch government did perform audits on DigiNotar - sort of, they outsourced the audit to the great company PwC, who verified that all of their procedures were correctly written down in Word documents with proper headings and jargon that pleases business consultants (quote from the DigiNotar website: 'Certificering ETSI door PricewaterhouseCoopers (november 2010 - november 2013) ') Of course they didn't look at the actual software and IT security - why would anyone care about such technical details?
For more information, I found the following timeline.
When you use Wicket as webfrontend framework to build your application, sooner or later you'll encounter the NotSerializableException. This is because Wicket will want to serialize any state you have into a HTTPSession. In Wicket, the first three pages are usually in memory too, so you could ignore the exception for a while, but of course this will fail immediately in case use want to use your webapplication in a clustered configuration. Not to mention you should never ignore Exceptions anyway.
The problem in solving such a Serializable exception is finding the field that is not Serializable. The stacktrace of java doesn't help much. Fortunatelly, after some searching I've found the solution, in the comment of blog posting: add the option -Dsun.io.serialization.extendedDebugInfo=true to the JVM startup parameters.
Now the stacktrace gives you the exact fieldname or expression that is causing the problems, as you can see in the example below:
2011-07-23 21:44:50,362 ERROR [http-8080-1]  org.apache.wicket.util.lang.Objects - Error serializing object class nl.gerbrandict.forum.AdminPage [object=[Page class = nl.gerbrandict.forum.AdminPage, id = 2, version = 0]] java.io.NotSerializableException: org.springframework.beans.factory.support.DefaultListableBeanFactory - field (class "org.springframework.orm.hibernate3.HibernateTransactionManager", name: "beanFactory", type: "interface org.springframework.beans.factory.BeanFactory") - object (class "org.springframework.orm.hibernate3.HibernateTransactionManager", org.springframework.orm.hibernate3.HibernateTransactionManager@10fd8ce3) - custom writeObject data (class "org.springframework.transaction.interceptor.TransactionInterceptor") - object (class "org.springframework.transaction.interceptor.TransactionInterceptor", org.springframework.transaction.interceptor.TransactionInterceptor@2c96cb51) - field (class "org.springframework.transaction.interceptor.TransactionAttributeSourceAdvisor", name: "transactionInterceptor", type: "class org.springframework.transaction.interceptor.TransactionInterceptor") .. - field (class "nl.gerbrandict.forum.AdminModel", name: "person", type: "class nl.gerbrandict.forum.Person")
(note: not publishing the entire stack trace and using some sample dummy field/classnames).
Although I haven't tried, enabling this option in production is most likely a bad idea, because Serialization is already a pretty inefficient process without any debugging information enabled. In my case, I was using a PropertyModel somewhere, using non model as target object.
subscribe via RSS