<entry key="runnable"><value>com.mycompany.alfresco.deployment.SampleDR</value></entry>The issue was that whenever this class failed, it corrupted the metadata directory that the deployment module created (Excerpt of Stacktrace below).
...
org.alfresco.deployment.impl.DeploymentException: Recovery failed for afc9657c-ace2-11dc-a0c4-7b3d7cd0abf4
...
Caused by: java.io.FileNotFoundException: depmetadata\default.md\.md.clone (The system cannot find the file specified)
...
So my solution was:
- Comment the runnable line on
application-context.xml - Delete the depdata, depmetadata and deplog dirs from ALF_DEPLOYMENT_HOME dir
- Do a successful deployment from Alfrescos webclient. This will generate the missing
ALF_DEPLOYMENT_HOME/depmetadata/default.md/.mdfile that is not created during failed deployments (when the runnable class throws a RuntimeException). - Uncomment the runnable line on
application-context.xml - Restart the Alfresco Deployment Windows Service
- Do a redeploy. This time it will execute the runnable class and if it executed succesfully everything will work smoothly
If somebody out there found out a better solution please let me know.
1 comment:
Hi there, thanks for the post.
I'm wondering, why was your custom runnable class causing the corruption of the metadata in the first place? Is this an error in alfresco? Does this only happen when your class throws an exception?
On a related matter - can these custom classes return an error code back to the alfresco deployment-report? For example, the first part of the deployment may be successful but cannot be considered finished until the custom class has done it's job successfully too.
Keep up the alfresco blogging - great stuff.
Post a Comment