Skip to main content

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

Posted by felipegaucho on October 3, 2009 at 9:43 AM PDT

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 href="https://hudson.dev.java.net/issues/show_bug.cgi?id=4592">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! href="http://java.sun.com/developer/onlineTraining/Programming/JDCBook/appA.html">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 href="http://fgaucho.dyndns.org:8080/hudson/">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.

Related Topics >>