Hmm, the failure is reliable on my system.
I also discovered that having a file that is not XML and attempting to load it as XML will fail.
I had a file named "file1.xml" with the content "added" (created by some accident of my flailing with bash no doubt) in the directory I was loading using a filter on *.xml. I got the same failure. When I removed this file, the failure went away.
It could be an issue with Java versions or another OS X-specific issue, perhaps. Here's what I'm running:
Contrext01:dfst-sample-project ekimber$ java -version java version "1.7.0_65" Java(TM) SE Runtime Environment (build 1.7.0_65-b17) Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
Unfortunately I don't really have time just now to spend trying to debug this more deeply but it must be something in the DTD-aware XML parsing tool chain that fails before the "skip corrupt = true" logic comes into play.
I'll log an issue for it and try to track it down once I have a bit more time. Definitely don't want to have this sort of failure hanging about if we can avoid it.
Cheers,
E. ————— Eliot Kimber, Owner Contrext, LLC http://contrext.com
On 4/13/15, 8:41 AM, "Christian Grün" christian.gruen@gmail.com wrote:
Hi Eliot,
Having the CATPATH set or not set does not affect the failure.
Do you possibly mean QUERYPATH or any other BaseX option?
That is, this fails:
basexclient -c 'CHECK dfst_dfst-sample-project_develop; SET DTD true; REPLACE dfst/metadata.xml
<dfst_metadata><gitstate><branch>develop</branch><commit>2df2f9674f7e8a5d 43 865411b193f76b19e9565d</commit></gitstate></dfst_metadata>' -U admin -P admin -p 1984 -n localhost
Hm, once again it does not fail on my system. What I did was...
- download and unzip basex.zip
- start bin/basexserver
- run your command (on Windows, replacing the single with double quotes)
What else do I have to do? C.
And this succeeds:
basexclient -c 'CHECK dfst_dfst-sample-project_develop; SET DTD false; REPLACE dfst/metadata.xml
<dfst_metadata><gitstate><branch>develop</branch><commit>2df2f9674f7e8a5d 43 865411b193f76b19e9565d</commit></gitstate></dfst_metadata>' -U admin -P admin -p 1984 -n localhost
Cheers,
E.
————— Eliot Kimber, Owner Contrext, LLC http://contrext.com
On 4/12/15, 12:40 PM, "Eliot Kimber" ekimber@contrext.com wrote:
No obvious cause for the failure yet but it feels like a bug that is revealed by a particular configuration organization.
Cheers,
E. ————— Eliot Kimber, Owner Contrext, LLC http://contrext.com
On 4/12/15, 12:19 PM, "Eliot Kimber" ekimber@contrext.com wrote:
It's definitely a function of my local .basex settings. If I revert to the default settings (make the basex install dir .basexhome and remove ~/.basex) then the replace succeeds.
Trying to figure out what the setting is that results in the failure.
Cheers,
E. ————— Eliot Kimber, Owner Contrext, LLC http://contrext.com
On 4/12/15, 11:36 AM, "Eliot Kimber" ekimber@contrext.com wrote:
Using the basex Zip distribution for both 8.0.3 and 8.1, I'm getting a failure on REPLACE but not ADD for the same XML data.
This command succeeds:
basexclient -c "CHECK dfst_dfst-sample-project_master; OPEN dfst_dfst-sample-project_master; ADD to dfst/metadata.xml <dfst_metadata/>"
But this command fails
basexclient -c "CHECK dfst_dfst-sample-project_master; OPEN dfst_dfst-sample-project_master; REPLACE dfst/metadata.xml <dfst_metadata/>"
"..." (Line 1): Premature end of file.
This definitely worked in the past, so something must have changed on my system.
Obviously, the error message is not very helpful in this case.
Any idea what the problem might be or how I would diagnose this failure?
Thanks,
E.
————— Eliot Kimber, Owner Contrext, LLC http://contrext.com