csfile and getInputStream issue

Using log4j and SAXReader I am having an issue reading a XML file from the Interwoven file system.

Code:
...
csfile = (CSSimpleFile)(client.getFile(vpath));
...
SAXReader reader = new SAXReader();
Document document=null;
try {
InputStream in = csfile.getInputStream(true);
document = reader.read(in);
} catch (CSAuthorizationException e) {
...

I am getting a document exception
<<
DocumentException :
org.dom4j.DocumentException: Error on line 1 of document : The processing instruction target matching "[xX][mM][lL]" is not allowed. Nested exception: The processing instruction target matching "[xX][mM][lL]" is not allowed.
...
>>

Googling indicates that this is caused by an extra character before the starting xml. My XML file is clean with no extra characters which points me towards the getInputStream method of CSfile.

Has anyone come across this issue and/or can see an issue with my approach ?

In the meantime I intend to try an alternative XML parser.

Thanks

Find more posts tagged with

Comments

thatfish

Apologies above log4j should read dom4j.

This works :-
new File f = new File("/tmp/my_config.xml");
InputStream is = new FileInputStream(f);
Document doc = builder.parse(is);

Accoding to the API this should also work (but does not - fails as mentioned above)
InputStream in = csfile.getInputStream(true);
Document doc = builder.parse(in);

I'm guessing it is java/unicode/utf-8 thing.

Any ideas ? e.g at a guess something like
InputStream in = csfile.getInputStream(true);
Document doc = null;
doc.setencoding("utf-8");
builder.parse(in);

It is a pretty fundamental requirement to pass XML from the iwmount using the CSSDK I have to be missing something ! Has anyone successfully used the getInputStream method of the CSSimpleFile Interface and successfully passed the InputStream to a create a DOM ?

My current workaround is passing the CSSimpleFile InputStream object to a string object and then convert the string to an InputStream and pass to the XML parser.

somens

InputStream in = csfile.getInputStream(true);
document = Dom4jUtils.newDocument(in);

The above code will work..

Rick Poulin

Googling indicates that this is caused by an extra character before the starting xml. My XML file is clean with no extra characters which points me towards the getInputStream method of CSfile.

Has anyone come across this issue and/or can see an issue with my approach ?

I can confirm that I've seen this as well in an implementation about 2yrs ago. For me, the parser couldn't figure it out on its own so I had to slurp the input stream into a string, regex out any garbage that might precede the <?xml, then parse that.

Somens' suggestion, if it works, would be much cleaner but I don't personally like tying my TeamSite-side code to classes in the LiveSite-side packages. It works, but it feels dirty. Instead, just copy the spirit of what the Dom4jUtils class does, which is this:
[PHP]
public Document newDocument(InputStream inputStream) {
SAXReader xmlReader = getReader();
InputStreamReader inputReader = new InputStreamReader(inputStream, "UTF-8");
org.dom4j.Document doc = xmlReader.read(inputReader);
doc.setXMLEncoding("UTF-8");
return doc;
}
[/PHP]

Adam Stoller

What was used to produce the XML that's being processed?
Some editor applications stick a binary BOM character sequence in front of the xml declaration - which then causes problems with the parsing by the libraries supplied with TeamSite / LiveSite (perhaps other tools too - but those are the ones we're talking about - right?)

Capture.GIF

RankingAggregates.rptdesign

Rick Poulin

What was used to produce the XML that's being processed?
Some editor applications stick a binary BOM character sequence in front of the xml declaration - which then causes problems with the parsing by the libraries supplied with TeamSite / LiveSite (perhaps other tools too - but those are the ones we're talking about - right?)

As far as the issues I've encountered, it was when trying to parse DCRs produced by FormsPub, which AFAIK still doesn't print the BOM. Somehow, the cssdk's getInputStream() was introducing some other kind of invisible garbage before the XML declaration, which didn't even come across as unicode characters when logging to file, no matter how much I messed with content encodings. That's why I ended up having to regex-out anything coming before the declaration -- couldn't figure out what the problem character(s) actually were.