XML/Parser.pm very wierd problem

This is a strange one....

I have a mechanism where a client uses CSSDK to write an XML file into a TeamSite workarea.
A (perl) at trigger, picks up this write event and performs some operations on the XML (actually instantiates a workflow).
All was working well, until a new developer ran the CSSDK write code on his PC and began writing files to the workarea.
In my custom logfile for my at trigger, I got the following:

01/11/2006 15:44:56: Processing file /iwmnt/default/main/B2B/ImportRequests/WORKAREA/content/requests/37474a382af0bf21-7c764b7a108b9ea6910-8000.xml
01/11/2006 15:44:56: FATAL ERROR} Error Parsing XML Job description:
01/11/2006 15:44:56: FATAL ERROR} no element found at line 1, column 0, byte 0 at /usr/iw-home/iw-perl/vendor/lib/XML/Parser.pm line 187

Now for the strange part.

I logged into ContentCenter, clicked on the XML file. Downloaded it to my local machine. Opened it using IE to confirm it was valid (it was). Opened it using textpad to check for whitespace before declaration (there was none). Manually copied it into the workarea. The at trigger picked up the file and processed it without any errors.

Now for the stranger part.

The developer who found the issue suddenly reported that he was no longer having it.

In my story so far, all has been happening on Windows 2000 using TS 6.5 SP2. This issue seems to have disappeared on all of these dev environments.
However.... This issue is still present on our Solaris 9, TS 6.5 SP2 server and shows no sign of vanishing as it has on the win2k servers.

I am posting here as I have no idea how to debug this. By copying the file out of the backing store and opening it locally I have discovered that there is no whitespace on the front of the XML as the parser error suggests.

Is there some obscure bug with at triggers and CSSDK written files?
Has anyone seen anything like this before?

worst case scenario: I modify the at trigger to read and re-write the file before trying to parse it.

Any help much appreciated.

Darren.

Find more posts tagged with

Comments

Adam Stoller

Are you able to post the file in question (as an attachment, preferably from the solaris machine)?

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

dazzlad

Here it is..... but.

The project here is reasonably secretive, so had to open it up in textpad and replace a few bits of info. I guess me having opened it and saved it again probably voids any investigative path you were going to take with it Smiley Sad

I downloaded it via FTP rather than contentcenter UI this time, and opened it with a hex editor to make sure there were no nasty characters in front of it.

Did you have any ideas as to what may be happening.

Darren.

Adam Stoller

It looks okay to me - no spaces,no ^M's - so no - I have no ideas about it anymore. Sorry

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

dazzlad

As it turns out, another developer just got a file not found error, so it looks like the trigger is sometimes being fired before or during a write (which is ****).

Darren.

chandraiw

In reply to:

01/11/2006 15:44:56: FATAL ERROR} no element found at line 1, column 0, byte 0 at /usr/iw-home/iw-perl/vendor/lib/XML/Parser.pm line 187

In reply to:

I am posting here as I have no idea how to debug this. By copying the file out of the backing store and opening it locally I have discovered that there is no whitespace on the front of the XML as the parser error suggests.

I think "no element found"' doesn't necessarily mean that the parser is encountering a whitespace. It could also be a valid text with different encoding than what the parser expects it to be.

Having said that, I would suggest converting the text to be parsed to UTF-8(or whatever the encoding the parser expects).

BTW, this is my most favorite error of all, stumbled upon it quite a few times...

~Chandra

Edited by chandraiw on 01/12/06 08:52 AM (server time).

chandraiw

Perl code snippet to convert to UTF-8 can be found here