xmlParse() with schema breaks Lucee server/web admin?

We have a couple of apps that we are looking to move to Lucee from Adobe ColdFusion. They deal with lots of incoming XML and we have schemas that incoming XML must be validated against. We’ve run into something that makes no sense: calling function xmlParse() with a schema (either a file reference or a string containing the schema) causes the Lucee server and web admin UI’s to break and remain broken until we stop and restart the Tomcat instance Lucee is running on. It’s very repeatable, using the following code:

<cfscript>
	// XML:
	savecontent variable='x' {
		writeOutput('<?xml version="1.0" encoding="UTF-8" ?>
			<ac:application
			  xmlns:ac="https://foo.org/test"
				xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
				xsi:schemaLocation="https://foo.org/test test.xsd"
			>
			  <settings>
			    <setting name="goo" type="boolean">false</setting>
			  </settings>
			</ac:application>
		');
	}

	// Schema:
	savecontent variable='s' {
		writeOutput('<?xml version="1.0" encoding="UTF-8" ?>
			<xs:schema
				targetNamespace="https://foo.org/test"
				xmlns:ac="https://foo.org/test"
				xmlns:xs="http://www.w3.org/2001/XMLSchema"
				>
				<xs:element name="application" type="ac:Application" />
				<xs:complexType name="Application">
					<xs:sequence>
						<xs:element name="settings" type="ac:Settings" />
					</xs:sequence>
				</xs:complexType>
				<xs:complexType name="Settings">
					<xs:sequence>
						<xs:element name="setting" type="ac:Setting" minOccurs="0" maxOccurs="unbounded" />
					</xs:sequence>
				</xs:complexType>
				<xs:complexType name="Setting">
					<xs:simpleContent>
						<xs:extension base="xs:normalizedString">
							<xs:attribute name="name" type="xs:token" />
							<xs:attribute name="type" type="ac:SettingType" default="string" />
						</xs:extension>
					</xs:simpleContent>
				</xs:complexType>
				<xs:simpleType name="SettingType">
					<xs:restriction base="xs:token">
						<xs:enumeration value="string" />
						<xs:enumeration value="boolean" />
						<xs:enumeration value="integer" />
						<xs:enumeration value="numeric" />
					</xs:restriction>
				</xs:simpleType>
			</xs:schema>
		');
	}

	d = xmlParse(x, true, s);
	writeDump(var = d, label = 'd', expand = false);
</cfscript>

To reproduce the behavior:

  1. Start Lucee
  2. Sign into Lucee’s admin API and go to the “Overview” page. Note that the dynamically-generated charts are updating.
  3. In another browser tab/window, run the above script… but keep an eye on the dynamically updating charts. Note that the script dumps the XML document structure.
  4. Note that, as soon as the script runs, the dynamically updating charts stop updating.
  5. In the Lucee admin, try to go to any other page within the admin. You’ll get redirected to the admin’s sign-in page.
  6. When you attempt to sign in, Lucee throws an exception.

The Lucee admin will remain broken until we stop and restart the Tomcat instance. We can’t find anything in any of the Lucee or Tomcat logs that details the breakage (except the exception captured in the screenshot, which is from trying to go to a different page within the admin UI or trying to sign back in, and thus well after the admin UI breaks and the charts stop updating). Inspecting the traffic behind the dynamic charts, each AJAX request is returning the Lucee admin sign-in page.

Is this a known problem with xmlParse() and Lucee? We’ve verified this behavior on two different dev servers running 5.3.2.77. The logic behaves as expected under ACF on these same two systems. The behavior is specific to calling xmlParse() with the third argument present (calling it without a schema has no unexpected side effects on the Lucee admin) and calling it with a path to a schema, the URL for the schema, or the schema passed in as a string all behave the same. Changing the second argument for case-sensitivity has no impact on the noted behavior.

Any help troubleshooting this (or confirmation that this is in fact an issue with Lucee) would be most welcome.

1 Like

Sounds like [LDEV-1645] - Lucee

Thanks, @Zackster! That does sound like it. I will weigh on on that thread, as well.

My searching there had come up empty.

1 Like

Yes, I encountered a similar problem when I migrated from Lucee 5.2.9 to Lucee 5.3.2+77. My queries no longer work because I am reading a schema.xml file in my DAOs with the XmlSearch() and XmlParse() functions to generate all the queries. XmlSearch() retrieves the field names and table name from schema.xml in the child DAO while XmlParse() builds the query in the parent class (baseDAO). In my case, it is very critical indeed, and I really hope that the Lucee team can fix this issue in the next stable version.

Good news, It’s been fixed in the latest 5.3.2.78-SNAPSHOT, [LDEV-2253] - Lucee

there is also a mini hot patch workaround for earlier versions

add the following code to your Application.cfc|.cfm so it is executed before the first xmlParse

1 2 3 4 // initialize the patch to memory if(isNull(server.patch2253)) server.patch2253=createObject('java','com.rasia.patch.Patch2253',["path/to/my/patch-2253.jar"]); server.patch2253.fix(); // fixes it (not necessary here but does not hurt)

the jar defined with createObject (“path/to/my/patch-2253.jar”), you can find here http://download.lucee.org/patch-2253.jar

THen after every XMLParse that uses 3 arguments (xmlParse(xml,false,dtd))
you need to do the following afterwards

1 server.patch2253.fix();

THis patch need no restart of Lucee.

As soon you update Lucee to 5.3.3.53-SNAPSHOT or higher, that has fixed the issue, will this patch do nothing anymore, but also throw no error. But you should remove it anyway.

1 Like

@Zackster Thanks for the follow-up on this; that’s good news.