Error 'declaration of the element "jhoveConfig" could not be found'

[lwo]

I first saw this error when I switched my virtual test boxes and later it was mentioned by here too:
https://groups.google.com/forum/#!topic/dataverse-community/XMRhg1UiwmE

Error 'declaration of the element "jhoveConfig" could not be found' 

In my test on Ubuntu 12 the LANG environment has no effect. But explicitly setting the Saxon class for Jhove does. E.g.:

${glassfish home directory}/jhove/jhove.properties
edu.harvard.hul.ois.jhove.saxClass=com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl

And the jhove.conf is parsed ok. But remove that properties file and the application throws the 'declaration of the element "jhoveConfig" could not be found' again. It is consistent.

I don't really see why this would be necessary, because one of the domain's vm settings is already set thus

-Djavax.xml.parsers.SAXParserFactory=com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl"

Unless the jvm on this machine behaves different that expected ? In this particular case it is:
OpenJDK Runtime Environment (IcedTea 2.5.6) (7u79-2.5.6-0ubuntu1.12.04.1)

[pdurbin]

@lwo do you happen to know what happens when this error occurs? Jhove is used to identify file types so is it that the file type is not correctly identified?

[raprasad]

See Leonid's August message below re: jhove

Begin forwarded message:

From: Leonid Andreev <leonid@hmdc.harvard.edumailto:leonid@hmdc.harvard.edu>
Date: August 4, 2015 at 8:32:43 PM EDT
To: "datascience@lists.fas.harvard.edumailto:datascience@lists.fas.harvard.edu" <datascience@lists.fas.harvard.edumailto:datascience@lists.fas.harvard.edu>
Subject: [Datascience] Developers: please make sure to update your JHOVE config file!

The config file lives in your source tree, in conf/jhove/jhove.conf.
Copy it to your domain config directory -
YOUR_GLASSFISH_DIRECTORY/domains/domain1/config.
I don't think you need to restart glassfish.

I updated this file in the source tree back in Jan. However, if you
haven't re-run the installer since then, you still have an old version.

That old version contains the URL for the schema file. And the way jhove
library is written, if the URL is present, it insists on downloading
it... just to parse the config file.
This also becomes a problem if this schema cannot be downloaded. Which
is what happened this week - they have apparently stopped serving it.

---

Datascience mailing list
Datascience@lists.fas.harvard.edumailto:Datascience@lists.fas.harvard.edu

To unsubscribe from this list or get other information:

https://lists.fas.harvard.edu/mailman/listinfo/datascience

On Oct 1, 2015, at 7:25 PM, Philip Durbin <notifications@gitpro.ttaallkk.topmailto:notifications@github.com> wrote:

@lwohttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_lwo&d=BQMCaQ&c=WO-RGvefibhHBZq3fL85hQ&r=EkFi6BF7pof1mvmoyqcphtSeruEfuDmHCUNhyy4Y_XM&m=JBQtqm6gsVFyQNQt264h54GdfiKREeksAKngW4d1SrY&s=11DaInwj7yza8r_Wsl97_K5q_-k_xHN8Aza9c2Y3B8A&e= do you happen to know what happens when this error occurs? Jhove is used to identify file types so is it that the file type is not correctly identified?

Reply to this email directly or view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IQSS_dataverse_issues_2619-23issuecomment-2D144875946&d=BQMCaQ&c=WO-RGvefibhHBZq3fL85hQ&r=EkFi6BF7pof1mvmoyqcphtSeruEfuDmHCUNhyy4Y_XM&m=JBQtqm6gsVFyQNQt264h54GdfiKREeksAKngW4d1SrY&s=Fc5kuYgCrBGVBeezqBPEPni2g3cJ1KTn0_Oe0EkNebQ&e=.

[bencomp]

We have seen this error in our logs too - when a file is uploaded this error is logged. I haven't determined if there is any effect of JHOVE not being able to find this declaration.

[lwo]

The jhove.properties settings do not seem to be relevant here.

I have in domain1/config//jhove.conf:
https://raw.githubusercontent.com/IQSS/dataverse/4.3/conf/jhove/jhove.conf

When I upload an Excel file with or without an extension: myfile.bin or myfile.bin.xlsx I get the following:

[2015-10-02T03:24:37.327-0700] [glassfish 4.1] [INFO] [] [edu.harvard.iq.dataverse.ingest] [tid: _ThreadID=51 _ThreadName=jk-connector(2)] [timeMillis: 1443781477327] [levelValue: 800] [[buffer_size: 500]]
[2015-10-02T03:24:37.363-0700] [glassfish 4.1] [SEVERE] [] [] [tid: _ThreadID=51 _ThreadName=Thread-9] [timeMillis: 1443781477363] [levelValue: 1000] [[[Error] jhove.conf:2:14: cvc-elt.1: Cannot find the declaration of element 'jhoveConfig'.]]
[2015-10-02T03:24:37.366-0700] [glassfish 4.1] [SEVERE] [] [edu.harvard.hul.ois.jhove] [tid: _ThreadID=51 _ThreadName=jk-connector(2)] [timeMillis: 1443781477366] [levelValue: 1000] [[Testing SEVERE level]]

And the UI displays:

Unknown
MD5: 0185b7535a95ccf69e113db4235e9888;

Using the above jhove.properties has no real effect and break things:

[2015-10-02T03:32:21.541-0700] [glassfish 4.1] [SEVERE] [] [] [tid: _ThreadID=50 _ThreadName=Thread-9] [timeMillis: 1443781941541] [levelValue: 1000] [[edu.harvard.hul.ois.jhove.JhoveException: SAX parser not found: com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl

However, here the file with the extension ( myfile.bin.xsls ) does get correctly identified as a "MS Excel (XLSX)". So there is probably a fall back on file extensions if the JHove content check fails. The file myfile.bin still has the Unknown status.

If you deliberately add the jhove.conf with invalid XML you get the same fall-back-on-extension effect.

I can replicate something similar on the https://dataverse-demo.iq.harvard.edu/ site. There the xsls file with extension is identified as an Excel:

MS Excel (XLSX)
MD5: 0185b7535a95ccf69e113db4235e9888;

Without it is not:

Unknown
MD5: 0185b7535a95ccf69e113db4235e9888;

[pdurbin]

Huh. What, if anything does all this have to do with "Removed remote schema location url from the jhove config file" at f4b7889 (part of #951)?

[akio-sone]

The latest version of jhove.conf has the following line :

/usr/local/src/jhove

I wonder whether this path setting is correct because the installer does not have a block that copies jhove's jars to this directory; the location of these jars would be "../applications/${dataverse_war_file_name}' , i.e. for version 4.2, "../applications/dataverse-4.2", if no "contextroot" is set during the war-file-deployment, because these jars are stored with the war file.

[landreev]

OK, I know what it is. It's not a fatal condition (you should still be able to upload your files and all). But it's still an issue, and I'll have a fix shortly.

[pdurbin]

@landreev was this fixed in #2429? Is there anything I should document in the Installation Guide as part of #2884?

[pdurbin]

I spoke to @landreev about this and he said it should be fixed in the next release (post 4.2.3). I just took a quick look for the ticket but couldn't find it. Need to remind him to link it up here.

[landreev]

No, not what I meant.
The issue is fixed in 4.2.3.
I meant as of 4.3 the installer will be taking care of the installation-specific path in the config file. In 4.2.3 it needs to be done hand.

Kevin, could you please close this one?

[kcondon]

Leonid, passing back to you to add to release notes. Then go ahead and close this.

[landreev]

@kcondon
Oh, you wanted me to close this - yes, closing now.