Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#533 closed defect (fixed)

null pointer exception

Reported by: Olaf Seibert 1 Owned by:
Priority: minor Milestone: DASISH backend
Component: DASISH backend Version:
Keywords: Cc: olhsha


I did this:


with this body:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<annotation xmlns="">
    <headline>    This is some text on the same line. </headline>
            <ColTime xmlns:ns2="" xmlns="" xmlns:xsi="" ColTimeMessageID="20165e20-ae94-4eeb-9d5f-b4785a238ee2" noNamespaceSchemaLocation="">
                <MediaFile ColTimeID="dc69b390-5edf-46fd-b326-8c120651675b"/>
                <AnnotationFile ColTimeID="ddab97c6-6e01-48fa-9156-879da20237c2" type="EAF">urn:nl-mpi-tools-elan-eaf:59d08e6a-5cd9-4aed-8aa4-7074c270e635#t=0.000/0.500</AnnotationFile>
                <Message>    This is some text on the same line.   It has leading and trailing spaces.      </Message>
        <targetInfo ref="urn:nl-mpi-tools-elan-eaf:59d08e6a-5cd9-4aed-8aa4-7074c270e635">

which resulted in this:

HTTP Status 500 -

type Exception report


description The server encountered an internal error ({0}) that prevented it from fulfilling this request.


	sun.reflect.GeneratedMethodAccessor381.invoke(Unknown Source)

And if one looks at the location of the exception:


671     @Override
672     public Number addPrincipalsAnnotation(Number ownerID, Annotation annotation) throws NotInDataBaseException {
673         Number annotationID = annotationDao.addAnnotation(annotation, ownerID);
674         int affectedAnnotRows = this.addTargets(annotation, annotationID);
675         int addedPrincipalsAccesss = this.addPermissions(annotation.getPermissions().getPermission(),
annotationID); // <<<-----
676         int updatedPublic = annotationDao.updatePublicAttribute(annotationID,
677         return annotationID;
678     }

Indeed, I did not include permissions.

Maybe, if permissions are not included, it is useful to assign some default permissions?

(Oh, and I see now that the class is called ...Imlp instead of ...Impl)

Attachments (1)

olaf-elan2.xml (2.1 KB) - added by 10 years ago.

Download all attachments as: .zip

Change History (6)

comment:1 Changed 10 years ago by DefaultCC Plugin

Cc: olhsha added

Changed 10 years ago by

Attachment: olaf-elan2.xml added

comment:2 Changed 10 years ago by

Je xml is niet correct. Eerst voeg de schema etc als attributen van de annotatie toe:


Daarna krijg je drie volgende fouten te zien:

— ownerRef attribute (required) is gemist (voeg een tijdelijke)
— URI attribute (required) is gemist (voeg een tijdelijke)
— permissions zijn ook.

Zie de bijlage voor de gecorregeerde xml. Pas op: elke targetRef die niet door de backend gedefineerd is, wordt als nieuwe en tijdelijk geinterpreteerd en wordt door de "peristent" DB-ref vervangen.


comment:3 Changed 10 years ago by

Resolution: fixed
Status: newclosed

comment:4 Changed 10 years ago by Olaf Seibert 1

I agree that I should try to send better XML to the server.

However, from the viewpoints of security, safety and reliability, a
server should *never* crash because of the input it gets. Clients may be
simply buggy or even malicious, and the server should refuse service
gracefully with an error message, not null pointer exceptions or SQL
errors. It should simply never get that far.

If such problems can (partly) be avoided by validating the XML, the
server should validate the XML.

(Warning: the rant below is because of frustration with the way the
usual Java libraries handle validation as I understand it (I still hope
I have misunderstood it!). The problem is there because of the way the libraries work,
not through some defect in the server code. But it really should be handled better
somehow. I have not found a good enough solution for
this yet, just a partial one)

If the validation on the server side depends on the presence and correctness of
something like

<annotation xsi:schemaLocation="http://something/some-schema.xsd">

and isn't done if it is not present, then this is the completely wrong
way to go about it!

If you don't trust the input (and you shouldn't), then of course you
should certainly even less trust the input to tell you how to validate

If there is some XML that will crash the server, I as an attacker can easily send such
XML including a reference to a schema that says that my XML is perfectly ok.

In fact, if the validator just fetches the given URL in the hopes to
find a schema there, this could be considered a security problem. The
given URL could point to something malicious.

Even if the URL is the right one and it does give you the correct
schema, why do a network access every time a client request comes in?
Surely it would be more efficient to have the schema available locally.
Preferably pre-compiled if possible.

What I have tried in ELAN to at least avoid the network access is the
following. I don't know how or if this would fit in with the JAXB
(un)marshalling. And I think it still doesn't really do the validation
of there is no reference to a schema at all.

		private XMLReader reader;

	        reader = XMLReaderFactory.createXMLReader(
	        // This works to make sure the schema isn't fetched from the web but from here:
        	reader.setEntityResolver(new EAF28Parser.EAFResolver());
     * @see {@link}
     * @author olasei
    public static class EAFResolver implements EntityResolver {
		public InputSource resolveEntity (String publicId, String systemId)
    		InputStream stream = null;
    		String resource = null;
    		if (systemId.equals("")) {
    			resource = "/mpi/eudico/resources/EAFv2.8.xsd";
    		} else ...

    		if (resource != null) {
    			// return a special input source
    			try {
    				stream = this.getClass().getResource(resource).openStream();
        			Reader reader = new InputStreamReader(stream);
        			return new InputSource(reader);
    			} catch (IOException e) {
    		// use the default behaviour
    		return null;

comment:5 Changed 10 years ago by

We have planned to add xml-validation on server side, as Menzo suggested
, and may be it will fix the problems. I have not just had time to implement it.

I will have at look at this later after I'm "done" with refactoring since the validation issue is becoming urgent.

Note: See TracTickets for help on using tickets.