search

HughP / simal

Automatically exported from code.google.com/p/simal
0 stars 0 forks source link

Project failed to save/load #397

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
I've heavily modified the doapcreator widget to save projects. I put three 
projects in successfully, then this one exploded. I really don't know why. 
Attached: the RDF that caused it, the error message shown in the browser, and 
some log messages around the time of saving and retrieving.

I'd really appreciate any tips for how to debug these kinds of issues myself. 
The debug output just isn't quite verbose enough.

Original issue reported on code.google.com by Stevage on 1 Mar 2011 at 8:30

Attachments:

GoogleCodeExporter commented 9 years ago 
It would really help if we knew what "this one exploded" meant. What did you 
do? What were you expecting to happen? What actually happened?

You say you've heavily modified the widget but don't tell us in what way or how 
this might affect the bahaviour you are seeing. If the problem is in your 
modified code then I don't see how we can help unless we have the code.

Having said that, from your logs it looks like you were trying to display the 
project detail page and thus the project has actually been created.

In error.txt:

Root cause:

java.lang.NullPointerException

<!-- snip exception chain -->

org.apache.wicket.WicketRuntimeException: Error calling method: public void 
uk.ac.osswatch.simal.model.jena.DoapResource.setDescription(java.lang.String) 
on 

In your RDF you have:

<description xml:lang="en">xx</description>

There is nothing wrong with the RDF you provide as I've inserted it into our 
public registry at [1] and it displays just fine. This implies that either you 
have a local modification that breaks things, or we have a change in svn head 
that breaks things. I don't have my development machine to hand so I'm unable 
to test using SVN Head right now. Can you checkout a clean copy of Simal and 
test it.

[1] http://registry.oss-watch.ac.uk/project/simalID/prj5012

Original comment by ross.gardler on 1 Mar 2011 at 12:51

GoogleCodeExporter commented 9 years ago

Original comment by ross.gardler on 1 Mar 2011 at 12:52

GoogleCodeExporter commented 9 years ago 
I just realised I was to libral with my snipping of log files since you 
explicity ask for tips on how to debug this. I dont agree the debug output 
isn't verbose enough, you just need to know how to read it. Generally speaking 
Java exception traces are too verbose. I find that, more often than not the top 
level exception is the most important but the lowest level stack trace is the 
one that has your cause in it.

In my previous comment I point to the Root cause of "NullPointerException". 
Scanning the stack trace shows that we have to go to the very last exception to 
see any reference to our own code. But what we can see is that the null pointer 
is occurs when we call 
"uk.ac.osswatch.simal.model.jena.DoapResource.setDescription(java.lang.String)"

Reading the stack trace from this WicketException we see:

at 
uk.ac.osswatch.simal.wicket.panel.project.EditProjectPanel$EditProjectForm.addRi
ghtColumn(EditProjectPanel.java:355)

So we appear to be displaying the EditProjectPanel, specifcially the right 
column (this makes sense since that is where the description is shown). Since 
we are displaying the proejct detail page this means the data has been inserted 
into Jena (since we are trying to display it). This is confirmed by continuing 
to read the stack trace from this point which eventually tells us we called the 
constructur for ProjectDetailPage:

at 
uk.ac.osswatch.simal.wicket.doap.ProjectDetailPage.<init>(ProjectDetailPage.java
:70)

This is further confirmed by the debug log which says:

DEBUG uk.ac.osswatch.simal.service.jena.JenaProjectService - Retrieved project 
name: ReDBoX

If we retrieved it the prvious creation must have succeeded (read the log to 
see the creation and retrieval stages - although this is not necessary as the 
stack output told us already we are displaying the project detail page).

So, in sumamry, the stack trace tells us that:

- the project record in Jena has been created
- we are trying to display the project detail page
- for some reason the setDescription method of the project object is being 
called with a null value
- there is a description in the RDF

We need to ask ourselves why is setDescription being called at all when we are 
trying to display a page, not edit the model.

We can confirm that this error does not occur in the last relase (which did not 
include the edit facilities), so maybe the edit features in svn head are 
causing this problem, or maybe you have a local change that causes the problem.

First we should elimate or demonstrate that the problem is in SVN head, so we 
need to insert the RDF into a clean install of the code from SVN head.

You might also want to inspect the RDF for this project as it is returned from 
Jena. The log provides you with the SPARQL needed to retrieve it using the 
SPARQL endpoint in the tools section.

See: 
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> PREFIX rdf: 
<http://www.w3.org/1999/02/22-rdf-syntax-ns#>PREFIX simal: 
<http://oss-watch.ac.uk/ns/0.2/simal#>SELECT DISTINCT ?project WHERE { ?project 
simal:projectId "5dd8565c-3a4a-4c3d-9760-ec499ffa09e6-prj117" }

Original comment by ross.gardler on 1 Mar 2011 at 1:20

GoogleCodeExporter commented 9 years ago 
Thanks for taking a look at this, and the very sensible suggestion to confirm 
that this problem exists in the head. I have just checked; it doesn't. So I 
guess I'm on my own.

Original comment by Stevage on 2 Mar 2011 at 12:31

GoogleCodeExporter commented 9 years ago 
You are never on your own, we want your contributions so, as far as is possible 
we'll help you get them to a maintainable state.

Of course the more you diverge from the code we have here the harder it is for 
us to give practical help. Nevertheless, we can at least illiminate some red 
herrings for you, or provide ideas for where to look.

Original comment by ross.gardler on 2 Mar 2011 at 1:01

GoogleCodeExporter commented 9 years ago 
On a fresh start, with the same codebase, I loaded the same RDF. It behaved 
perfectly. So there is something a bit complicated here.

Original comment by Stevage on 3 Mar 2011 at 7:01