Status: Open (View Workflow)
Using TAP plugin v1.9 and Jenkins v1.496, the attached stack trace occurs in a loop when Jenkins is restarted. We are now seeing this prevent Jenkins starting up.
Our Service Engineer tells me that the plugin is unable to load the attached build.xml
Apart from becoming larger in size, the TAP test results we are producing have not changed appreciably to cause this problem.
Hi Bruno - sorry for the delay getting back to you.
Can you advise paths to the fields you'd like me to delete from build.xml? Is there a case perhaps for the TAP plugin to perform some sanity checking before build.xml is parsed? I manually removed a Jenkins plan that was listing old 1.8 Plugin results but our problem remains.
Currently, whenever Jenkins is restarted we lose our history of previous builds and we see the attached stack trace (stack3.txt).
No worries re. the delay =)
Finally I managed to reproduce this stack trace. Here's the steps required:
1) create simple job, with at least one TAP file and with ok/not ok's and comments
2) execute the job (I have 2 builds)
3) open build.xml and look for an entry similar to: <org.tap4j.model.Comment reference="../../tapLines/org.tap4j.model.TestResult/comments/org.tap4j.model.Comment
4) replace the  by any higher random number (here I used 5)
5) as the objects have already been loaded in memory, stop/start jenkins
6) open the build in Jenkins WEB UI
7) watch the log for an error similar to the following (windows box, that's why the stack trace is word-wrapped)
Caused by: com.thoughtworks.xstream.converters.ConversionException: Invalid refe
---- Debugging information ----
reference : ../../tapLines/org.tap4j.model.TestResult/comments/org.
class : hudson.model.FreeStyleBuild
required-type : java.util.LinkedList
path : /build/actions/org.tap4j.plugin.TapTestResultAction/tapRes
line number : 132
I looked again at tap4j versions, as well as previous releases of the plug-in and couldn't spot a reason for this error happen in your environment. I'm seeing if the plug-in can do some sanity check or if I can find why your build.xml causes this error.
And as this build raised this exception during initialization, Jenkins didn't load it. Thus, I've lost my history too, remaining only 1 build (the one I didn't modify). My guess is that if we manage to fix whatever wrong information we find in build.xml, you'll have your build history back and no more initialization errors.
Created a sample repository  at GitHub to isolate the issue.
There I used the same xstream library as Jenkins 1.496, as well as same tap4j as TAP Plug-in 1.9 (3.3).
Unfortunately (or fortunately) I didn't see the same error. Maybe I'm missing something, so I'll continue to investigate.
Alex, could you confirm if the build.xml attached, is the one that is failing, please? I couldn't reproduce the error using your build.xml in my tests (link above).
Hi Alex, I'm starting a cycle to work on other Open Source projects. Feel free to update this issue. My next Jenkins Plug-ins cycle will happen within few weeks.
New stack trace as requested.
One way to trigger the problem is to kill the subprocess triggered by Jenkins that will ultimately produce the TAP.
Ok, I have a new cycle to work on TAP plug-in. Time to give it another try :o)
Hi Alex, today I had some time to try with the XML you provided, and could see similar errors in my stack trace.
I fixed the issue at my test box by removing the missing fields from the build XML. Looks like somewhere in the past some of the fields of this job got removed, probably when the plug-in was downgraded or upgraded.
I couldn't find anything when going to the configuration page. I was expecting to find the buttons to manage/dismiss missing data. But in case you see these buttons, you may try using it to manage the data.
I tried it after finding this thread from the dev-mailing-list .
I took a look at tap4j 3.2 and tap4j 3.3 (the 1.8 and 1.9 plug-in versions use the 3.3) and both have the field marked as missing in your stack trace. I couldn't find a way to circumvent this error.
Could you give it a try? See if by removing the missing fields from your build.xml?