Question
· May 18, 2023

CR/LF changes in DTL files causing load errors (#6301: SAX XML Parser Error)

Is CR/LF changes to DTL files edited/committed to git via VS Code a known issue?

We had an issue with exporting files from one server and importing on another, using XML code exported from Studio: ERROR #6301: SAX XML Parser Error. Turns out that issue was down to CR/LF changes made when transferring the XML from one server to the other.

Now we are getting the same error only with DTL files when (1) creating DTL on Management Portal, then (2) exporting via VS Code ObjectScript extension, (3) committing to git (GitLab, self-hosted instance, if it matters), and then (4) subsequently cloning from git and importing and compiling, again via VS Code ObjectScript extension.

So, our suspicion is that:

  • somewhere in the tool chain the CR/LF's in these files are being changed, and
  • DTL's specifically are sensitive to these CR/LF changes in a way that other ObjectScript files are not (it looks like its around the XData segment)

Anyone able to confirm, point to documentation, or suggest a working set of configuration options for this kind of environment?

Product version: Ensemble 2018.1
$ZV: Cache for Windows (x86-64) 2018.1 (Build 184U) Wed Sep 19 2018 09:09:22 EDT
Discussion (7)4
Log in or sign up to continue

Turns out it wasn't git's fault - though really helpful for us to clarify what git is doing, and ensure we have a decent set of default .gitattributes set...

We don't fully know what is going on, but ALL DTLs on one Ensemble instance throw this error, on load in Management Portal or compile via Studio or VS Code - can't even create a new DTL. So we are currently suspecting some kind of corruption/error on that server, rather than something related to the code we are bringing from git. But no idea what has gone wrong. Its a dev server - we may just scrub it and reinstall...

Hi @Colin Brough,

Did you guys manage to resolve this issue? 
I was having the same issue while compiling few local server classes (LF) that extends %CSP.REST class and if I remove the "Extends  %CSP.REST" from the classes, they would compile successfully but the RESP API would give error.

  • Tried reinstalling the cache thinking it would flush out the issue but still stuck in the same one.
  • Tried changing the end of line sequence from VS Code but could not save it.

I would appreciate if you could share how you have resolved this issue.

Hi Robert , the code looks good and the same code is working in our live environments (Test and Prod) and compiles without any issue.

Since the routine has REST WebService endpoints and due to company's policy I am not able to post the code but thanks for your concern.

As Colin mentioned, it must be the file corruption, will try reinstalling the dev environment again.