Failed to serialize hudson.model.Actionable#actions for class hudson.maven.MavenBuild

The problem

I just started a new Glassfish v2.1 and deployed a Hudson 1.327 on it. Unfortunatelly, after configuring my first build, it always failed due to a serialization problem:

[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to serialize hudson.model.Actionable#actions for class hudson.maven.MavenBuild
access denied (java.io.SerializablePermission enableSubclassImplementation)
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.RuntimeException: Failed to serialize hudson.model.Actionable#actions for class hudson.maven.MavenBuild
    at hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:160)
    at hudson.util.RobustReflectionConverter$2.visit(RobustReflectionConverter.java:131)
    at com.thoughtworks.xstream.converters.reflection.PureJavaReflectionProvider.visitSerializableFields(PureJavaReflectionProvider.java:130)
    at hudson.util.RobustReflectionConverter.doMarshal(RobustReflectionConverter.java:116)
    at hudson.util.RobustReflectionConverter.marshal(RobustReflectionConverter.java:89)

For a full month I asked that issue in several mailing lists and nothing changed, I even submitted an issue on the Hudson project. The first attempt to solve the problem was the classical to remove everything and reinstall the software from the scratch, supposing the Hudson installation was corrupted somehow. A second desperate attempt was to apply chmod 777 on several folder looking to fix the crazy permission problem. All in vain, the damn Hudson continued to torture me for a bit of more time until a glorious moment I got off the keyboard and started to think again. The first good move was to start digging the server.policy file of Glassfish. I knew the secure policy file was the key, but I was so drunk of repeated-try-failprocess that I was unable to identify what permission in which file would do the magic. Preparing to accept the possibility to give up the Hudson forever I started to talk with my friends - and God knows how I love this Glassfish technologies. Thanks Lord I have smart friends, and then Phillipe Marschal sent me an email with the purple pill: java.io.SerializablePermission enableSubclassImplementation. That simple line dissipated all my fears and - I saw the face of my enemy for the first time in weeks, and I knew it was a matter of very short time to kill the bastard issue! The manual gave me the rest of the information I was looking for:

grant {
  permission java.io.SerializablePermission 
    "enableSubclassImplementation";
  permission java.io.SerializablePermission 
    "enableSubstitution";
};

This code should be included in the file $AS_HOME/domains/domain1/config/server.policy

Done, the drama is over and our Old Hudson is cured from its permission pandemia ... !

Thanks Phillipe, you saved the day ... and thanks Fabrizio to be around during the rain ...

* It was in the manual, and after the explanation it seems trivial, but why people took so long to answer my questions? Time to Glassfish people to blog more and better about our preferred server permissions file.